一个由十二名工程师组成的团队热情地采用了 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% 以下。这并不是因为代码库需要的重构变少了，而是因为没有人建立必要的理解来识别哪些地方需要重构。
“没人理解”问题的复利效应 一个没人深入理解的 AI 生成模块是可控的负债。但如果在 18 个月内，代码库中有 40-60% 的代码是在缺乏深入理解的情况下生成的，那就是另一种性质的问题了。
针对企业部署的研究发现，团队往往连基本的问责问题都无法回答：哪些服务包含 AI 生成的代码，谁批准了特定部分，以及预期的架构约束是什么。当这些上下文缺失时，复利效应就会变得非常严重。
AI 生成代码积累技术债的方式与人工编写的代码不同。人工编写的技术债通常是局部的且易于理解的：比如刻意采取的捷径，或是原作者能识别出的待清理区域。而 AI 生成的技术债通常是结构性的：某些设计选择在单个层面上是站得住脚的，但整体上却杂乱无章；抽象层的存在仅仅是因为模型默认使用了企业级模式；包含某些依赖项仅仅是因为它们出现在训练数据中。
在不尽早解决此问题的组织中，维护成本遵循特定的模式。考虑到评审开销和更高的代码变动率，第一年的成本比预期高出 12%。到了第二年，随着累积的结构性债务需要大规模重写，这一差距将显著扩大。负责重写的工程师必须从头开始重构架构意图，这比最初就保留了知识要耗时得多。
真正行之有效的协议 这并不是要反对使用 AI 编程工具。那些从采用 AI 中获得复利收益的团队，拥有一套共同的实践方法，能够将工具的采用与工具驱动的混乱区分开来。
将团队知识编码为可执行的制品 (executable artifacts)。 最高效的团队将隐性的架构原则转化为文档化、版本化的标准，AI 工具和评审人员可以根据这些标准进行检查。这不仅仅是一份风格指南——它必须足够具体，以回答诸如“这个模块应该使用事件总线还是直接调用？”以及“新服务的可接受抽象深度是多少？”之类的问题。当这些标准以可评审文档的形式存在时，违反标准的 AI 生成代码就是可检测的。
明确改变导师模式。 在 AI 之前的世界，资深开发人员通过评审代码并解释反馈背后的推理来指导新手。这种模式假设新手是通过奋斗和学习写出代码的。受 AI 辅助的新手需要不同的互动：资深人员需要探查他们对生成内容的理解，而不仅仅是代码看起来是否正确。要问的问题不是“这行得通吗？”，而是“为什么这是这里的正确方法？如果约束条件改变了，你会做些什么调整？”
建立生成阈值。 来自成熟团队的数据表明，AI 生成代码的比例在 25-40% 之间存在一个最优区间，此时生产力的提升超过了评审和质量开销。超过 40% 后，重做率和评审时间的增长速度将超过速度收益。这并非一个普适的常数，但针对你团队的评审能力，就合理的百分比进行明确讨论，比让这种采用纯粹自然发生要有用得多。
掌控评审瓶颈。 如果代码评审时间在增加，答案不是降低评审严谨性——而是将低价值的评审工作交给自动化工具，以便让人类集中精力进行高价值的评审。沿用 AI 时代之前评审规范的团队，要么会拖垮评审人员，要么会导致质量下降。流水线的进化速度需要与生成速度保持同步。
要求在 PR 层面记录意图。 包含大量 AI 生成部分的 PR 应该包含一个章节来回答：这解决了什么问题，选择了什么方法，以及为什么排除了其他替代方案？这并不是官僚化的负担——它是知识转移发生所需的最小上下文。它还能揭示开发人员何时不理解自己的 PR，这是在合并之前需要掌握的重要信息。
新手开发人员的问题 新手开发人员成长的长期后果值得明确关注。
有两种可能的未来。在一种未来中，AI 工具通过提供即时反馈回路、展示高质量模式并让他们更快处理更复杂的问题，从而加速新手的学习。在另一种未来中，AI 工具通过消除建立真正理解所需的“有成效的挣扎”来使基础技能萎缩，新手交付了更多代码，但从中学习到的东西却更少。
目前的证据表明，这两种情况正在同时发生——结果完全取决于资深工程师如何构建与使用 AI 的新手的指导关系。在资深工程师明确探查新手的理解情况，并要求新手用自己的语言解释 AI 生成代码的团队中，新手的成长速度更快且更扎实。而在评审只关注输出质量而非开发人员理解能力的团队中，正在积累一种隐性负债：一群能够生成可以运行的代码，但在出问题时却无法诊断的开发人员。
这关系到工程组织的长期健康。2030 年的资深工程师正是今天的新手开发人员。如果这些开发人员学习的是如何生成代码而不是理解代码，那么组织的知识库将在比任何季度生产力指标所能捕捉到的更长的时间尺度上发生侵蚀。
结构性约束在于组织，而非工具 在所有关于 AI 编程采用情况的团队规模研究中，最明确的发现是：组织结构才是束缚发展的约束条件，而非工具质量。拥有强大审查文化、明确知识传递实践以及能够随代码速度扩展部署流水线的团队，能从 AI 工具中获得复利回报。缺乏这些结构的团队，其生产力提升会随着债务的积累而进入平台期甚至出现倒退。
这是一个工程领导力问题，而非工程问题。个体开发者正在做的，正是工具赋予他们的能力。领导层需要思考的问题是：围绕代码审查、知识传递和质量标准的组织基础设施，是否跟上了速度增长的步伐。
那些回顾这一时期并将其视为竞争优势的团队，并非最先采用 AI 工具的团队。而是那些改变了团队结构、导师模式和审查实践，以适应全新生产现实的团队。这是一种更慢、更艰难的变革 —— 而正是这种变革决定了生产力的提升是产生复利还是化为乌有。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
