围绕如何与智能体协作的绝大多数指导，都在优化智能体的理解能力：上下文文件、MCP 服务器、记录完善的技能，以及向智能体提供正确的信息，让它能够推理你的代码库。相比之下，关于如何确保人类仍然理解智能体正在修改的系统，讨论少得多。

Addy Osmani（阿迪·奥斯曼尼）写过一篇很棒的文章，讨论comprehension debt（理解债务），也就是 AI 生成代码带来的隐性成本。AI 生成代码的速度远远超过人类评估代码的速度，而这道鸿沟会掏空团队对自己代码库的理解。

我们在优化智能体的理解能力，而人类的理解能力却在不断衰退。正是这道鸿沟促使我认真思考自己的工作方式，以及在能够快速推进而不丧失维持代码库健康所需的理解之前，究竟需要先做好哪些准备。

代码审查曾经发挥的作用

审查不只是质量保证，也是理解在团队中传播的方式。当有人足够仔细地阅读你的代码并批准它时，他们正在建立对变更内容及其原因的心智模型。团队正是通过这一机制，保持对自身代码库的集体认知。

智能体给这一机制带来了压力，并不是因为它们让代码变差，而是因为它们生成代码的速度超过了审查流程原本的承载能力。尤其是在代码库中测试覆盖充分、团队理解深入的部分，有时快速推进并信任智能体是正确的选择。但一旦出问题，后果会不断累积。每个理解不充分的变更，都会让下一次审查变得不那么有意义，因为你是在一个已经逐渐偏移的心智模型上，针对新代码进行推理。

尝试之后我的认识

我最初遇到这个问题时，本能地想到的是流程：把大型智能体变更集拆成更小、按顺序排列的 MR（合并请求），每个 MR 都讲述完整故事的一部分，并且都可以单独部署，就像在一次快进式工作之后播放慢动作回放。这种做法确实有道理。我曾经重组过一次提交，让一个大型 MR 可以逐个提交审查，最终它毫无阻力地合并了。让变更易于理解，并讲述一个连贯的故事，始终是正确的本能反应。

但我在一个遗留代码库中也有五个堆叠的 MR 处于草稿状态。我理解这些变更做了什么，却不相信现有的测试覆盖能够捕捉到可能导致功能和副作用出问题的部分。没有这种信心，整个变更就隐含着对人工验证的期待，而这等于要求审查者承担你尚未处理的风险。

流程可以让变更更容易理解，但它无法替代并不存在的安全网。

如今的理解是什么样的

它不再是逐行理解，那已经不可行了，假装还能做到只会意味着有些审查是在演戏。但它也并非什么都不做。我认为它体现在三个层面。

第一是行为层面：它是否按预期工作？这是测试覆盖能够成为团队最重要投资的地方。真正的覆盖应该覆盖用户实际走过的路径上的真实行为，同时还要有能在编译时捕捉类型错误的类型安全。如果编译器和测试套件都在发挥作用，审查者就不需要追踪每一行代码。覆盖薄弱的地方，或团队一直依赖人工测试的地方，正是智能体带来的速度停止成为效率、开始变成疏忽的地方。

第二是架构层面：我们是否大致理解这些变更的工作方式，并且能否更新自己对系统的心智模型？智能体可以直接帮助完成这件事。让智能体总结一个变更集中的关键决策，不是机械性的修改，而是人类需要评估的选择：考虑过哪些替代方案，哪些地方存在不明显的决策，以及作者会在代码讲解中重点指出什么。以此作为 MR 描述的基础。我已经把这套做法封装成一个agent skill（智能体技能），你可以将它加入自己的工作流。它会生成结构化的 MR 描述和提交结构建议，你可以审查并使用这些内容，帮助让智能体生成的变更集更容易被审查者理解。

第三是规范层面：代码是否符合团队约定的规范？Linting（代码检查）可以自动处理其中很大一部分，而任何能够交给 linter 的事项，都意味着人类审查者少需要分配一部分注意力。对于 linter 无法捕捉的事项，我之前曾写过agent skills（智能体技能）。如果你的规范记录得足够完善，能够指导智能体编写代码，那么它们也记录得足够完善，能够指导智能体审查代码。

展示你的工作过程

优秀的作者意识一直很重要。现在它更加重要。审查者并不在你的智能体工作会话中，也无法凭借周围的上下文理解你想做什么、考虑过哪些权衡，以及智能体做出的哪些决策是你有意识地保留下来的。这些上下文不会通过差异自动传递，你必须有意识地把它们传递出去。

这意味着要指出哪些架构决策需要人类审查者关注，并描述改了什么以及为什么要改。意味着要认真考虑提交结构，让变更的故事在审查中清晰可见，甚至在别人阅读代码之前就能看懂。还意味着要写出一份能够证明你理解智能体产物的描述，因为如果你无法清楚地解释它，就有可能已经转向了被动委托。

阿迪引用的Anthropic 研究发现，使用 AI 进行被动委托，只让它生成代码而不保持主动参与的工程师，在理解能力测试中的得分明显低于把 AI 当作思考工具使用的人。智能体不会取代工程师。它是一种工具，你仍然需要理解它在做什么以及为什么这样做，而不只是确认它能正常工作。这种理解正是你的审查者应当得到的：应当引导他们获得这种理解，而不是让他们从头开始自行重建。

并非每个变更都具有相同的风险，也不需要相同深度的审查；明确说明这一点，同样是良好作者意识的一部分。Ship / Show / Ask 为此提供了一个有用的框架，可以根据变更的性质以及团队中已经建立的信任程度，校准审查级别。

快速推进需要什么

那五个处于草稿状态的 MR，并不是被流程或我对代码的理解所阻塞，而是因为安全网还不存在。这是首先必须履行的责任：在发布之前修好它，而不是发布之后再修。

但如果没有作者意识方面的工作，再扎实的测试套件也只能让审查者确认没有东西被破坏。这与理解改了什么、为什么要改，以及智能体做出了哪些你有意识保留的决策，并不是一回事。智能体为你提供速度。让这种速度真正有价值的，是你能够解释构建了什么以及为什么构建，而不只是证明它能正常工作。