过去一两年，AI 几乎被放在了所有技术讨论的中心。

每天都能看到各种声音：AI 会重塑软件开发，AI 会替代大量岗位，AI 会让一个人完成一个团队的工作。各种 demo 看起来也足够震撼，好像只要掌握了 AI，就能立刻拥有成倍的效率；如果没有跟上，就会很快被淘汰。

这些声音对我产生了很强的影响。它让我一边兴奋，一边焦虑。兴奋的是，好像一个新的时代真的来了；焦虑的是，我会不会已经慢了？会不会别人已经在用 AI 大幅提升效率，而我还停留在旧的工作方式里？

所以我开始更主动地把 AI 带进自己的工作流里，不是浅尝辄止，而是真的希望用它参与设计、开发和测试。我想知道，它到底能不能帮我追上这种“时代速度”。

但真正把 AI 放进日常工作之后，我慢慢发现，宣传里的 AI 和工程现场里的 AI，中间隔着很长一段距离。

AI 不懂上下文，不只是因为它没有读完文档

我日常工作的项目是一个非常大型的微服务系统。这样的系统里，一个需求往往不是改一个接口、一个页面、一个表那么简单。它背后可能牵涉多个服务、历史兼容、业务规则、灰度流程、权限、账务、风控，以及一堆只有长期参与其中的人才知道的隐性约定。

在设计阶段，我经常会发现 AI 给出的方案太空泛。它可以很快列出模块、流程、接口、异常处理，看起来很完整，但仔细看就会发现，它并没有真正理解系统。它可能虚构不存在的流程，误解服务之间的边界，或者给出一种标准化但落不了地的设计。

一开始我会觉得，这是因为我没有给 AI 足够的上下文。但后来我意识到，问题没那么简单。

真实的大企业环境里，上下文本来就不是一个干净、完整、随时可用的东西。

首先，不是所有内容都有文档。很多关键知识存在于老员工的记忆里，存在于一次线上事故之后形成的口头共识里，存在于某个没人敢动的判断条件里。

其次，即使有文档，文档也可能已经过时。系统持续演进几年后，文档和真实实现之间出现偏差是很常见的事情。

有人可能会说：talk is cheap, show me your code。那直接让 AI 看代码不就好了？

但现实是，代码也不总是真相。线上代码只能说明系统现在是这样运行的，不代表它在业务上就是正确的。我们曾经有一个和付费相关的特性，上线半年之后才被发现存在问题，最终造成了上百万美金的损失。这个例子让我很受触动：线上代码不天然等于正确答案，它也可能只是一个尚未暴露的问题。

更麻烦的是，代码通常只能告诉你“现在怎么做”，却很难告诉你“为什么这么做”。

你可以从代码里读出 request.type != 2 时要走某个分支，但你未必知道 type = 2 在业务上意味着什么，为什么当年要这么判断，这个逻辑是临时补丁、历史兼容，还是某个财务规则的体现。尤其在缺少注释、命名抽象、业务快速迭代的系统里，代码提供的是行为痕迹，而不是完整语境。

所以，当我说 AI 不懂上下文时，我并不是简单地说它没有读完代码库。更准确地说，它面对的是一个连人类工程师都需要长期浸泡才能理解的复杂现场。

真实工程里的上下文，不只是代码和文档，而是代码、历史、事故、组织记忆、业务约束，以及那些还没有被发现的错误。

AI 写得很快，但 review 并不轻松

到了开发阶段，AI 的能力又会呈现出另一种反差。

不可否认，AI 写代码真的很快。很多时候，一个小时可以生成我过去两三天才能写完的代码。样板代码、字段转换、接口适配、简单逻辑实现，这些事情它完成得非常快。

但问题是，我不能完全信任它的代码。

AI 写出来的代码需要 review，而且这个 review 过程经常非常痛苦。因为它的改动往往很大，动辄几千行 diff。它像是把“完成需求”当成唯一目标，却不太在意改动半径、架构边界、可维护性，以及这个系统未来会如何演化。

这背后还是上下文问题。越是不理解系统，AI 越容易用大范围修改来覆盖不确定性。它可以很快把功能写出来，但可能没有意识到，这次修改是否破坏了原有抽象，是否绕开了既有流程，是否引入了难以维护的新分支。

于是，一个很微妙的变化发生了：AI 看起来替我完成了工作，但其实也把另一种工作交还给了我。

以前我主要是在写代码，现在我更多是在判断代码。

使用 AI 之后，我写代码的时间变少了，但承担判断的时间变多了。

测试阶段，AI 的帮助最有限

如果说设计阶段和开发阶段，AI 至少还能提供一些帮助，那么测试阶段可能是我目前感受到 AI 最薄弱的环节。

在一个庞大的微服务系统里，很多功能并不能简单地在本地验证。它需要发布到验证环境，需要依赖真实或接近真实的数据，需要 Web 或 App 配合操作，需要观察日志、链路、指标，有时还要经过多个服务之间的联动。

在这种场景下，AI 很难真正参与完整验证。

它可以帮我列测试点，可以提醒我注意边界条件，可以生成一些测试用例草稿。但如果它不能访问真实环境，不能操作 Web 或 App，不能看到链路日志，不能判断验证环境里的真实状态，那么它的帮助就会停留在比较浅的层面。

这也让我意识到，软件工程里的“正确”不是写出一段看起来合理的代码就结束了。真正困难的是在真实环境里证明它是对的。

AI 暴露了系统的上下文债务

经历这些落差之后，我并不觉得 AI 没有价值。相反，我开始用另一个角度理解它的价值。

AI 不只是一个写代码的工具，它也是一面镜子。它照出了我们系统里原本就存在的上下文债务。

当 AI 不断问：这个服务是做什么的？这个字段是什么意思？这个流程为什么这么走？这个判断背后的业务规则是什么？

这些问题并不只是 AI 的问题。它们也在提醒我们：系统里有多少知识没有被好好沉淀下来。

过去这些问题也存在，只是靠人的经验、记忆和沟通勉强维持。AI 进入工作流之后，因为它不能默认知道这些隐性知识，所以这些缺口被更明显地暴露出来。

从这个角度看，给 AI 提供上下文的过程，本身就是一次系统知识盘点。

更进一步，AI 不仅能暴露这些缺口，也可以帮助修补这些缺口。它可以根据代码、接口、日志、历史需求，生成第一版模块说明、调用链梳理、字段含义猜测、业务流程文档、测试场景清单。人要做的不是从零开始写文档，而是校验、纠正和补充。

这件事的重点不是“让 AI 多写点文档”，而是建设一套可追溯、可验证、能持续更新的系统知识。

我理想中的 AI 工具，不应该只在需求开始时读取知识库，也应该在需求结束时反向更新知识库。每次完成一个功能或改动后，AI 可以根据本次需求、代码 diff、测试结果和 review 反馈，检查系统知识库中相关内容是否仍然准确：服务职责有没有变化，接口契约有没有变化，字段含义有没有变化，业务流程有没有变化，历史约束有没有被打破。

如果需要更新，AI 生成候选变更，并附带来源：它基于哪个 PR、哪段 diff、哪个需求背景做出这个判断。工程师在 review 时确认这些变更是否准确。

换句话说，AI 不应该只消费上下文，也应该帮助生产上下文。

当然，这里面也有风险。知识库更新不能变成 AI 自动生成的一堆漂亮文本。AI 生成的知识变更必须可 review，必须有来源、有证据、有不确定性标记，并且进入和代码同等严肃的 review 流程。

代码 review 看的是实现，知识 review 看的是解释。实现错了可能很快暴露，解释错了却可能长期潜伏。所以真正重要的不是自动生成文档，而是把知识变更纳入工程治理。

AI 让“写出来”更容易，也让“想清楚”更重要

AI 的另一个价值，是它确实减少了很多开发中的体力劳动。

过去需要花很多时间写的样板代码、重复逻辑、接口适配，现在 AI 可以很快生成初版。这当然不是免费的，因为后面还有 review、验证和修正。但它确实改变了工程师时间分配的可能性。

如果实现成本下降了，那么工程师就应该把更多精力放到更高价值的事情上：理解业务、设计边界、控制复杂度、思考系统演化。

这也是我对 AI 的一个新理解：AI 不一定降低了工程师的要求，反而可能提高了工程师的要求。

因为当“写出来”变得更容易时，真正稀缺的能力就变成了判断力。

什么该做，什么不该做？
哪里应该抽象，哪里应该保持简单？
这次需求应该顺手修复历史问题，还是控制改动范围？
这个功能上线后会不会影响账务、权限、风控或用户体验？
AI 生成的实现看起来能跑，但它是不是符合系统长期演进的方向？

这些问题不会因为 AI 会写代码就消失。相反，它们会变得更重要。

当然，这种转变不会自动发生。如果只是让 AI 大段生成代码，再由人疲惫地 review，那么我们只是把编码劳动换成了 review 劳动。AI 降低了写代码的成本，但不一定降低了做好软件的成本。甚至在某些情况下，它会把成本从编码转移到理解、review、验证和治理上。

所以 AI 更像一个放大器。

系统知识管理好，它会放大沉淀能力；系统混乱，它会放大混乱。工程师判断力强，它会放大产出；工程师只追求快，它会放大技术债。团队流程成熟，它会提升效率；流程脆弱，它会制造更多不可控变更。

结语

回到最开始的焦虑。

我曾经因为外界对 AI 的吹捧而感到焦虑，担心自己没有跟上时代。但真正把 AI 放进真实工作之后，我反而慢慢冷静下来。

AI 确实很强，但真实工程没有那么简单。

它可以快速生成代码，可以帮助理解系统，可以辅助整理知识，也可以减少一部分重复劳动。但它还不能替代工程师对复杂系统负责。它不天然理解历史，不天然理解业务，不天然知道哪些代码是正确的，哪些文档已经过时，哪些逻辑只是还没有暴露问题。

所以我现在对 AI 的态度，不再是盲目追赶，也不是简单怀疑。

我更愿意把它看成一个高产出但低上下文的协作者。它能帮我更快获得材料，但最终的判断仍然属于人。它能让我少写一些代码，但也要求我更认真地思考系统。

AI 给了工程师站得更高的可能，但也暴露了我们是否真的具备站高的条件。

真正的变化也许不是 AI 替我们完成所有工作，而是它逼着我们重新回答一个问题：

当写代码变得越来越容易时，工程师真正的价值到底是什么？