AI代码泛滥已让Code Review失效，知识共享机制如何重建

AI 生成的代码量已经让代码审查失效了。工程师们在审查他们自己没有写过的 500 行代码改动，由他们并不完全理解的模型生成，审查速度之快已经不可能做到仔细阅读。

但如果 AI 现在正在生成大部分代码，而人类根本不可能读完所有代码，我们如何才能保住代码审查曾经承担的知识共享职能？

“如果代码审查向左移，知识共享也必须向左移。”

代码审查一直是知识在团队中流转的场所，是初级工程师观察高级工程师如何思考的地方，是架构决策被挑战的地方，是代码库的mental model 形成的地方，也是共同所有权成形的地方。如果代码审查向左移了，知识共享也必须向左移。

代码审查作为教学工具

在我与 ThoughtWorks 市场技术总监 Vanitha Kumar 的播客对话中，她偶然间意识到了这一点。

Vanitha 构建了一个 Agent，旨在捕捉反模式，并向不符合她团队原型定义的开发者解释这些模式。她了解那个原型，于是指示它根据团队参考文档中的实践来审查代码，找出团队在哪些地方出现了偏离，并解释为什么这种偏离是有害的。她把它构建成了一个教学 Agent，而不是代码审查 Agent，尽管它逐渐演变成了后者。

我随后意识到，这不应该等到提交之后才被发现。无论是人类还是 Agent 做的代码审查，都必须更早进行，而且它甚至不需要是一场审查。它可以是一次橡皮鸭调试，或是一个教学时刻。

一种新型的债务：认知债务

大多数关于取代代码审查的讨论都集中在捕捉 bug 和标准检查上。这些工作中的大部分可以通过基于 LLM 的对抗性审查、自动验证和确定性检查来实现。但如果我们只解决了标准检查问题，而对知识共享无所作为，那我们只是解决了那个更容易的工作。

在 AI 前的团队中，初级工程师的 PR 会收到高级工程师的四到八条评论，关于惯用模式的讨论、关于边缘案例的来回辩论，以及一堂隐含的“我会如何思考这个问题”的课程。

在 AI 密集型团队中，同样的改动由 AI 生成，轻微编辑后由 AI 审查，轻微批准后合并，没有任何人类对其形成过 mental model。

Margaret-Anne Storey 给这种协作消失后的现象起了一个有用的名字：认知债务。技术债务存在于代码中。认知债务存在于人身上。当团队停止理解他们正在构建的系统时，债务就累积起来了，而且没有任何仪表盘会告诉你这正在发生。

“技术债务存在于代码中。认知债务存在于人身上。”

她最初是在一组使用 AI 构建且进展迅速的学生身上注意到这一点的。在某个时刻，他们告诉她他们再也无法对产品进行改动了。她怀疑是技术债务、代码混乱。但学生们已经忘记了他们正在尝试构建哪些功能以及为什么。他们不知道团队中谁掌握了什么知识。在其中一个团队中，只有一个人理解代码，因为他是监督生成代码的 AI 的人，而团队的其他人都无法理解。那个生成代码的人自己也不真正理解被生成的内容。

有人可能会说，如果我们有 AI 来回答所有关于代码的问题，就不应该存在认知债务。我们可以把它外包给 AI 来理解代码。尽管 LLM 非常擅长解释某个功能或行为是如何工作的，但我们失去了"What's"和"Why"。为什么要以这种方式创建更改？实现某个功能时做了哪些假设？某个能力有哪些副作用或行为，这将如何配合产品的路线图？为什么这个功能需要存在？这些都是认知债务；它没有写入代码中，而这正是我们需要 mental model 的地方。

意图驱动的验证让知识共享保持活力

解决代码审查瓶颈的方案是将人工检查点向上游移动，移到审查意图、审查代码应满足的契约上：计划、约束和验收标准。这同样适用于审查流程中知识共享的部分。

意图驱动的验证意味着捕获工程师在与 Agent 协作过程中做出的决策——架构选择、行为权衡和范围决定——并在提交更改之前将它们写成验收标准。简要描述范围、列出验收标准清单，以及说明哪些明确不在范围内。这些决策已经存在于 prompts 中。有了 Aviator Verify，工程师可以捕获它们，而不会在会话结束时丢失它们。

审查者的角色发生了变化。他们不再是阅读 600 行改动然后问“这看起来对吗”，而是阅读几条验收标准然后问“我们是在正确的约束下解决正确的问题吗”。他们不需要阅读每一行代码。他们需要理解其背后的意图、发生了什么变化，更重要的是为什么。这才是高级工程师时间的根本更好的使用方式。

“审查者阅读验收标准时，是在阅读实现背后的决策，而不是实现本身。”

这对作者的重要性不亚于对审查者。作为一名工程师，你需要对你的代码有一个 mental model，才能有效地与 Agent 来回交流，才能质疑它们的建议。如果你不能在行为层面理解正在构建的内容，你就无法捕捉到 Agent 何时跑偏。作为作者和审查者，捕获和审查意图与行为，正是构建和维护那个 mental model 的方式。这也是审查的知识共享功能得以延续的地方。审查者阅读验收标准时，是在阅读实现背后的决策，而不是实现本身。

我们一直说，团队中不应该有某个人掌握所有知识，如果有人中了彩票，工作也不应该停滞。很少有团队真正为此努力过。我们通常满足于一个人掌握所有上下文。现在 AI 编写了大部分代码，我们没有选择。生产力提升是真实存在的，值得获取。但如果没有一个刻意的流程来维护正在构建的内容及其原因的 mental model，团队会越走越快，理解却越来越少，直到速度本身成为问题。