企业 AI 落地,为什么不能只做点状工具

上一篇，我写了为什么想给项目组打造一个“数字员工”。

但这个想法背后，其实还有一个更基础的问题：

为什么我不满足于做几个 AI 工具，而是希望 AI 真正进入研发流程？

这段时间做 AI 落地，我越来越明确一个判断：

一个 Task 变快了，并不意味着整个工作变快了。

企业真正交付的，不是一个 Task

现在很多 AI 应用，都是从一个具体任务开始的。

生成报告。

整理会议纪要。

分析需求。

生成测试用例。

辅助写代码。

这些事情当然有价值，而且很多场景已经可以带来非常明显的效率提升。

但企业真正创造价值的过程，通常不是由一个孤立任务完成的。

还是以研发为例。

一个需求从提出，到最终上线，中间要经历需求沟通、系统分析、方案设计、开发、Review、测试、上线等一系列环节。

真正有意义的结果不是：

“代码写完了。”

而是：

一个业务问题最终被正确地解决了。

写代码、写需求文档、生成测试用例，本质上都只是这个过程中的中间任务。

所以一个很自然的问题就出现了：

如果我们只优化其中一个 Task，这种效率提升能够传导到整个 Process 吗？

很多时候，答案并没有想象中那么乐观。

局部变快，瓶颈可能只是发生迁移

AI Coding 就是一个很典型的例子。

Coding Agent 越来越强，开发阶段确实可以明显变快。

但代码一天写完以后，需求可能还没有讨论清楚。

PR 增多以后，Review 可能开始排队。

开发产出越来越快，测试可能成为新的瓶颈。

这不是 AI Coding 没有价值。

而是因为：

局部最优，并不等于整体最优。

一个环节变快以后，限制整个系统效率的问题，很可能只是转移到了下一个环节。

所以，如果企业真正关心的是整体提质增效，问题就不能只是：

哪个地方还能加一个 AI？

而应该变成：

一件事情从开始到最终产生价值，中间到底发生了什么，AI 应该怎样参与这个过程？

点状 AI 的另一个问题，是把上下文切碎了

现在很容易出现一种建设方式。

需求分析做一个 AI。

测试用例生成做一个 AI。

研发文档再做一个 AI。

代码开发使用 Coding Agent。

每个工具单独看都成立。

但真正使用的时候，人往往需要不断重复同样的动作：

重新上传需求。

重新解释系统背景。

重新提供代码。

重新告诉 AI 前面发生过什么。

问题不一定出在模型能力上。

而在于真实工作本来就是连续的，我们却按照一个个独立场景，把它重新切成了很多碎片。

需求为什么这么设计，来自业务目标和系统现状。

代码最终修改了什么，会影响测试。

上线以后出现的问题，又应该重新成为以后需求分析的一部分。

这些信息天然属于同一条链路。

所以，如果 AI 只能在某个节点临时出现，它能够看到的就永远只是局部。

从 Task，走向 Process

所以我现在越来越倾向于这样理解企业 AI 落地：

第一阶段当然可以从一个个 Task 开始。

先把明确、重复、边界清晰的工作交给 AI。

但如果目标是提升整个组织的效率和质量，就不能永远停留在这里。

下一步应该开始考虑：

怎样让 AI 持续参与一件事情从开始到结束的过程。

一个需求进来以后，它参与需求理解。

需要分析方案时，它能够寻找系统现状和历史信息。

开发完成以后，它能够理解真实的代码变化。

准备测试时，它能够把需求和代码连接起来。

上线以后出现问题，这些结果还能重新回到整个项目的上下文里。

这也是我为什么想给项目组打造一个“数字员工”。

不是因为需要再增加一个 AI 功能。

而是因为我希望有一个 AI，能够真正进入这条研发链路，持续参与其中。

这条路其实还很长

我并不认为，现在已经有人知道企业最终应该怎样和 AI 一起工作。

模型还在快速变化。

Agent 的能力边界还在扩展。

企业原来的流程、系统和组织方式，也不可能因为 AI 出现就一夜之间全部重构。

真正把 AI 从一个工具，变成业务流程中的参与者，还有大量问题没有解决。

怎么让它理解项目？

上下文从哪里来？

哪些信息应该长期沉淀？

哪些信息应该临时获取？

什么时候让 Agent 自己判断？

什么时候必须让人确认？

现有系统又应该怎么为 Agent 提供能力？

这些问题都还需要一点一点实践。

所以某种意义上，现在可能只是万里长征的开始。

但我觉得，第一步不是急着把所有问题都解决。

而是先把思考问题的方式转过来：

不要只问“这里能不能加一个 AI”，而要开始问“AI 应该怎样进入整个工作过程”。

方向变了，后面很多问题才会真正出现。

而这些问题出现以后，我们才能沿着正确的方向，一步一步往前走。

接下来，我也准备开始记录更具体的问题：

如果真的想让一个 Agent 进入研发流程，它首先需要具备什么？

我现在的答案是：

它首先得真正“懂项目”。