当每个人都拥有 AI 编程助手：那些无人提醒你的团队动态

一个由十二名工程师组成的团队热情地采用了 AI 编程工具。六个月后，每位工程师合并的 Pull Request (PR) 数量几乎翻了一番。工程经理为此欢欣鼓舞。随后，值班轮换开始频繁报警。调试过程的持续时间延长了一倍。没有人能解释为什么某个特定模块要采用那样的结构。编写它的工程师诚实地回答道：“我不知道 —— 这大部分是 AI 生成的，看起来没问题。”

这种情景正在各地的公司上演。个人生产力的故事是真实的：开发人员更快地完成任务，编写更多的测试，更高效地清理积压工作。但团队层面的情况则更为复杂，大多数组织尚未为此做好准备。

代码审查中的生产力悖论

团队规模化采用 AI 导致崩溃的第一个地方是最显而易见的：代码审查。

当开发人员生成代码的速度变快时，他们提交 PR 的速度也会变快。关于大规模 Copilot 部署的研究发现，AI 采用率高的团队完成的任务增加了 21%，合并的 PR 数量增加了 98% —— 但 PR 审查时间却增加了 91%。瓶颈不再是编码者，而是流程中的其他所有人。

这在直觉上是合理的。审查者并没有获得与他们被要求审查的工作量成比例增加的 AI 协助。他们仍然在逐行阅读，检查正确性，理解意图，并评估架构契合度。代码产出与代码审查的比例发生了反转，而大多数团队还没有改变他们的审查文化来做出补偿。

其结果是两种失败模式之一。要么审查者为了跟上进度而对 PR 进行“盖章式”批准 —— 这就是低质量的 AI 生成代码如何未经挑战地进入代码库的；要么他们为了进行适当的审查而放慢所有环节，这会导致开发人员的挫败感，并产生审查是需要规避的瓶颈这一认知。

有效的做法应该是：停止像对待手写 PR 那样对待 AI 生成的 PR。自动化工具应该处理常规检查 —— 语法、安全模式、重复代码检测 —— 这样人类审查者就可以专注于架构契合度、业务逻辑正确性和意图一致性。审查清单发生了变化。“这段代码实现了它所说的功能吗？”变得不那么重要了。“这段代码以这种形式存在于代码库中合适吗？”变得更加重要。

知识孤岛如何更快形成

在广泛采用 AI 工具之前，知识孤岛是逐渐累积的。一个开发人员会花数月时间研究一个模块，成为非正式的专家，其他人随着时间的推移向他们学习。这虽然缓慢，但它创造了分布式的理解。

AI 工具加速了代码产出，但没有加速理解的传递。现在，一名初级开发人员可以在一小时内生成一个可运行的身份验证模块，由一名确认其看起来正确的资深人员进行审查，然后合并 —— 而他们中没有一个人深入理解为什么要这样构建。代码能运行，但知识孤岛瞬间形成了。

测量代码理解力的研究证实了这一点。与独立编写代码相比，使用 AI 协助的初级开发人员对其交付的代码的理解力显著降低。理解差距是可衡量的：自己编写代码的初级人员在理解测试中的得分比使用 AI 生成代码的人员高出 17 分。他们交付的代码在功能上是等效的，但他们内化的知识却并非如此。

当问题发生时，这一点最为关键。理解你真正编写的代码与理解生成的、且在审查时看起来正确的代码有着本质的区别。当凌晨两点发生生产事故时，你需要的是真正理解系统的工程师，而不是只能根据代码表面现象描述系统“应该”做什么的工程师。

这里的协议转变是刻意的知识归因。当 PR 包含大量的 AI 生成部分时，PR 描述应该解释 意图和权衡 —— 而不仅仅是代码做了什么。这迫使作者建立足够的理解力来阐述理由。当理解力不足时，它也能给审查者一个信号：如果作者无法解释为什么模块要这样构建，那就是一个警示信号。

代码审查文化已经瓦解

除了数量之外，还有一个更微妙的问题：围绕代码审查用途的规范已经悄然发生了转变。

从历史上看，代码审查同时承担着多种功能。它捕捉 Bug。它确保风格一致。它在团队中传播知识。它还是资深工程师指导初级工程师的一种机制 —— 审查评论是初级人员学习如何编写更好代码的方式之一。

AI 工具同时破坏了这四个功能。风格执行被委派给了格式化工具和 Lint 工具。Bug 检测被移交给了 AI 审查工具。知识传播崩溃了，因为代码是生成的，而不是经过推理的。而导师制 —— 最难替代的功能 —— 消失了，因为初级工程师并没有在问题中挣扎。他们通过 Prompt 绕过了问题。

团队中最有经验的工程师正越来越多地将代码审查时间花在“考古”上。他们正在查看那些局部连贯但全局混乱的 AI 生成代码 —— 这些代码语法正确并能通过测试，但做出了任何人都不会刻意选择的架构抉择。GitClear 2024 年的分析发现，在大量使用 AI 的代码库中，重复代码块增加了 8 倍，而传统的重构活动从开发人员活动的 25% 下降到 10% 以下。这并不是因为代码库需要的重构变少了，而是因为没有人建立必要的理解来识别哪些地方需要重构。

加载中…