AI生成代码的规模，已经让代码审查这项传统工作濒临失效。工程师们面对的是动辄500行的diff，这些代码并非出自自己之手，而是由他们无法完全掌控的模型生成。在这样的节奏下，逐行仔细阅读几乎成为不可能完成的任务。

但问题随之而来：如果AI现在生成了大部分代码，而人类根本不可能全部阅读，那么代码审查原本承担的知识共享职能，该如何保存？

打开网易新闻 查看精彩图片

代码审查曾是知识流动的核心通道

在传统开发流程中，代码审查一直是团队知识传递的关键环节。初级工程师通过观察资深工程师的思维方式来学习，架构决策在这里被挑战，代码库的心智模型在这里形成，共同所有权也在这里逐步建立。这是一条隐形的教学管道。

ThoughtWorks市场技术总监Vanitha Kumar在一次播客对话中，意外触及了这个问题的核心。她构建了一个智能体，专门用于捕捉反模式，并向团队中不符合典型画像的开发者解释这些问题。她会指导这个智能体按照团队参考文档中的实践标准审查代码，识别团队偏离规范的地方，并解释为什么这种偏离会产生负面影响。这个智能体最初更像一个教学工具，而非纯粹的代码审查工具，只是后来逐渐演变成了后者。

这引出一个关键思考：这种教学不应该等到代码提交之后才发生。无论是人类还是智能体执行代码审查，都应该大幅提前，甚至根本不必以“审查”的形式出现。它可以是一次橡皮鸭调试，或者一个教学时刻。

认知债：一种新型的技术负债

关于用AI替代代码审查的讨论，大多聚焦于捕捉bug和标准检查。这类工作大部分确实可以通过基于LLM的对抗性审查、自动化验证和确定性检查来完成。但如果标准检查被完全自动化，而知识共享问题被搁置，我们只是解决了更简单的那部分工作。

在AI介入之前的团队中，初级开发者的PR通常会收到资深工程师4到8条关于惯用模式的评论，围绕边界情况展开往返讨论，以及一条隐含的“我会这样思考这个问题”的示范。而在AI重度参与的团队中，同样的变更由AI生成、人工轻量编辑、AI审查、轻量批准，然后合并——全程没有任何人类对这个变更形成心智模型。

Margaret-Anne Storey为这种协作消失后的后果起了一个精准的名字：认知债。技术债存在于代码中，而认知债存在于人身上。当团队不再理解他们正在构建的系统时，认知债就开始累积，而且没有任何仪表盘会告诉你它正在发生。

Storey最初是在一群使用AI快速构建产品的学生身上注意到这一现象的。某个节点，学生们告诉她，他们再也无法对产品进行修改了。她起初怀疑是技术债，是代码混乱。但学生们失去的，其实是他们对系统的理解。

代码审查左移，知识共享也必须跟着左移。如果审查从“提交后”提前到“编写中”，那么知识传递的时机也需要同步前移。否则，我们优化的只是流程速度，牺牲的却是团队长期的理解力和自主性。