大多数关于与智能体协作的指引，都在为智能体的理解能力做优化：上下文文件、MCP 服务、文档化的技能、喂给它正确的信息，好让它能对你的代码库进行推理。却很少有人讨论如何确保人类依然理解智能体正在改动的系统。

Addy Osmani 曾写过一篇很棒的文章谈理解债——AI 生成代码的隐性成本。AI 生成代码的速度远快于人类评估代码的速度，这种落差会掏空团队对自身代码库的理解。

我们在为智能体的理解做优化的同时，人类的理解却在流失。正是这一落差，让我开始认真审视自己的工作方式，以及在快速前进又不失去维系代码库健康所需的理解之前，究竟需要先把哪些基础打好。

代码审查原本在做什么

审查不只是质量保障，它是理解在团队中传播的方式。当有人足够仔细地阅读你的代码并给出通过时，他就在构建关于“改了什么、为什么改”的心智模型。正是通过这种机制，团队才能对自己的代码库保持集体的认知。

智能体给这一机制带来了压力，倒不是因为它把代码写得更差，而是因为它生成代码的速度超过了审查流程当初设计所能承载的范围。有时快速推进并信任智能体是正确的选择，尤其是在测试覆盖充分、理解透彻的代码区域。但一旦出错，后果会不断叠加。每一次理解不充分的改动，都会让下一次审查变得更没有意义，因为你已经是在用一个早已偏移的心智模型去推断新代码了。

尝试之后的体会

我一开始遇到这个问题时的本能反应是靠流程来解决。把智能体产生的大块变更拆成更小、有序的 MR，每个 MR 讲述故事中连贯的一部分，每个都可独立部署，就像在快进之后做一次慢动作回放。这么做有一定道理。我曾把一个大 MR 重新整理提交，让审查者可以逐个 commit 来看，结果毫无阻碍地就合入了。让变更变得易读、讲好一个连贯的故事，永远是正确的直觉。

但我在一个遗留代码库上还有五个堆叠的 MR 一直处于草稿状态。我明白这些改动做了什么，却不信任现有的测试覆盖能捕捉到可能被破坏的副作用和功能行为。没有这份信心，整个变更背后就隐含着对人工验证的期待，这等于让审查者去承担你尚未解决的风险。

流程可以让变更更易读，却无法替代本就不存在的安全网。

如今的理解是什么样的

它不再是逐行审读，这已经不现实了，假装还能做到只会让一些审查流于形式。但它也并非可有可无。我认为它体现在三个层面。

第一是行为层面：它是否按预期工作？这正是测试覆盖成为团队最重要投入的地方。真正有价值的覆盖，是覆盖用户实际会走的路径上的真实行为，再加上能在编译期捕获类型错误的类型安全。如果编译器和测试套件各司其职，审查者就不需要逐行追踪。在那些覆盖薄弱、或长期依赖人工测试的地方，智能体带来的速度就不再是效率，而成了疏忽。

第二是架构层面：我们是否大致理解这些改动是如何运作的，能否据此更新对系统的心智模型？这一点智能体可以直接帮忙。让智能体去总结变更集中有意义的决策，不是机械的改动罗列，而是人类需要评估的那些选择：考虑过哪些替代方案、哪些是不直观的决策、如果是作者做代码走查会强调哪些点。把这些作为 MR 描述的基础。我已将其打包成一个智能体技能，你可以直接放到自己的工作流中使用，它会生成结构化的 MR 描述和提交结构建议，供你审阅和采用，帮助让智能体生成的变更集对审查者更易读。

第三是规范层面：代码是否符合团队约定的规范？Lint 工具已经能自动处理其中大部分，能推给 linter 的，就少一件需要人工审查者分心的事。对于 linter 捕捉不到的部分，我之前写过关于智能体技能的文章。如果你的规范文档已经详尽到足以指导智能体写代码，那它也足以指导智能体去审查代码。

展示你的推导过程

好的作者意识向来重要，现在则更为重要。审查者并没有参与你的智能体会话，对你想做什么、权衡了哪些利弊、智能体做了哪些你经过深思熟虑后保留下来的决策，毫无背景了解。这些上下文不会通过 diff 自动传递，你必须有意地去传递它。

这意味着要标出需要人工审查者关注的架构决策，并描述改了什么、为什么改。这意味着要认真考虑提交结构，让变更的故事在别人读代码之前就在审查中清晰呈现。这意味着要写出能证明你理解了智能体产出内容的描述，因为如果你无法清晰地解释它，就有风险说明你已经滑向了被动委托。

Addy 引用的Anthropic 研究发现，把 AI 当作被动委托工具、只是让它产出代码而自己不再积极参与的工程师，在理解力测试中的得分，显著低于那些把 AI 当作思考工具来用的人。智能体并不会取代工程师，它只是一个工具，你依然需要理解它在做什么、为什么这么做，而不只是知道它能跑通。你的审查者理应得到这份理解：去引导他们接近它，而不是留给他们从零开始重建。

并非每次变更都承载同样的风险、或需要同样深度的审查，把这一点说清楚，本身也是好的作者意识的一部分。Ship / Show / Ask 为此提供了一个有用的框架，可以根据变更的性质以及与团队之间已建立的信任，来校准审查的力度。

快速前行需要什么

那五个处于草稿状态的 MR，并非被流程或我对代码的理解所阻塞，而是被缺失的安全网卡住了。这是首要的责任：在发布之前、而不是之后，把它补上。

但只有扎实的测试套件、而没有作者本身的投入，也只意味着你的审查者能确认“没坏东西”。这和理解“改了什么、为什么改、以及智能体做了哪些你有意保留的决策”是两回事。智能体给了你速度，而让这种速度真正成立的，是你能解释清楚自己构建了什么、为什么这么构建，而不只是证明它能用。