副标题：工程吞吐量正在上升。然而，缺陷、事故和返工上升得更快。来源：Faros.ai，《AI Engineering Report 2026: The Acceleration Whiplash》说明：本文为中文翻译版（ChatGPT 5.5 pro + 人工审阅）。PR、QA、CI/CD、SDLC、DORA、Jira 等常见工程术语保留英文缩写。注释若无特别说明，都为原文注释。

摘要

更多代码。但不是可直接进入生产环境的代码。

AI 编码工具刚出现时，其定位很清晰：它们是开发者身边的智能助手，帮助开发者更快完成工作。人类掌控全局，AI 提出建议，人类做出最终判断。

实际发生的情况并非如此。

随着模型能力提升、厂商目标不断上调，AI 编码工具的角色定位也随之改变：从辅助开发者的“副驾驶”，逐渐变成可以共同完成工作的“同伴”。而在大多数组织并未明确做出这一决策的情况下，AI 已经跨过了这一关键门槛。如今，60% 的 AI 生成代码会被接受并进入代码库。在实践中，“助手”与“作者”之间的区别已经消失。AI 不再只是助手，而是在事实上成为了代码作者。

本报告衡量了这种转变带来的结果，数据来自 Faros 平台上 22,000 名开发者和 4,000 个团队过去两年的数据。^[1]

注 1：排除了运行在非标准基础设施上的组织。

吞吐量数字毋庸置疑：

• 任务完成量上升 34％。
• 每名开发者完成的 Epic 数量上升 66％。
• 涉及代码的任务增加 210％。
• AI 正在编写比以往更多的代码。

但 AI 没有做到的是：写出可直接进入生产环境的代码。

缺陷数按开发者计上升 54％。事故与 PR 之比增长超过三倍。PR 评审时间中位数增长 5 倍。未经过任何评审就被合并的 PR 增加 31％。随着 AI 采纳程度加深，AI 采纳与生产质量之间的关系正在恶化，而不是趋于稳定。

我们称之为 加速反噬（Acceleration Whiplash）。AI 将大量输出注入到一个原本围绕人类开发节奏和人类质量标准构建的系统中，而该系统从未被设计成可以吸收这种输出。加速是真实的，但也是具有迷惑性的：它掩盖了下游每个阶段正在积累的压力。增加评审人员、扩充 QA，或投入更快的事故响应，只是在治疗症状。问题必须在源头解决，也就是在代码生成阶段解决。

贯穿所有数据分段的一项发现是：所有组织都会遭遇加速反噬，无论其工程成熟度如何。在 AI 出现之前就拥有强工程实践的组织，也会出现与其他组织相同的质量退化。

本报告要回答的问题不是 AI 是否能写代码。它可以，而且规模惊人。问题是这些代码是否足够好；以及这对工程领导者此刻正在做出的人员规模、流程，以及 AI 作者角色边界等决策意味着什么。

报告目的

2025 年 7 月，我们第一份《AI 工程影响报告》识别出一种现象，称为 AI 生产力悖论：尽管组织对 AI 工具进行了大量投资，预期中的生产力提升并未体现在交付结果中。当时的数据集覆盖超过 10,000 名开发者和 1,255 个团队。

本报告带着同一个问题重新审视这一现象。这次使用的是规模更大、时间更新的数据集：我们在两年内跟踪了超过 4,000 个团队中的 22,000 名开发者。报告要问的是：这一模式是否发生了变化？答案是发生了变化，但方向并不是多数组织所期待的方向。

这个悖论已经加剧成一场危机。AI 采纳加速了。AI 所生产的内容与工程组织能够安全吸收的内容之间的差距扩大了。数字也变得更难忽视。

本报告面向工程领导者、CTO，以及为他们提供建议的组织。我们让数据本身提出论证，同时将编辑性评论锚定在数字之上。

连续性说明：本研究与我们 2025 年报告是行业的两个独立横截面，并不是同一个纵向面板。两份数据集在规模、时间窗口和组成上均不同。凡涉及与上一份报告的比较，均用于说明方向上的一致性，而不是主张精确的逐年趋势。

研究方法

本研究分析 AI 采纳与工程结果之间的关系，样本覆盖大量开发团队，数据来源为大约两年的工程系统数据。这一时期正好跨越了行业内 AI 工具显著采纳的阶段。工程系统数据聚合自以下系统：

• 任务管理系统
• IDE
• 静态代码分析工具
• CI/CD 流水线
• 版本控制系统
• 事故管理系统
• HR 系统元数据

分析重点是开发团队在 AI 工具采纳率超过 50％ 每周活跃用户阈值 后的变化。AI 采纳包括面向开发者的编码助手，例如 Claude Code、Cursor、GitHub Copilot、Windsurf 以及类似工具，也包括直接集成到 SDLC 中的自主智能体。

我们如何隔离信号

• 对每家公司内的所有指标进行标准化，以消除组织之间的差异。
• 使用 Spearman 秩相关系数（ρ）评估指标与 AI 使用量之间的关系。
• 只报告来自至少 6 家公司、且相关性具有统计显著性（p-value < 0.05）的指标。
• 对每个团队，计算观察期内 AI 采纳最低的两个季度与 AI 采纳最高的两个季度之间，指标值的百分比变化。
• 排除离群数据以及历史覆盖不足的指标。

这种方法能够在每家公司内部进行随时间变化的比较，并避免在不同组织结构之间进行误导性的总体假设。

版本说明：本报告版本反映的是截至 2026 年 3 月的分析。

发现

更多代码。质量下降。事故加速。

AI 不只是加速了软件开发。它还重构了由谁，或者由什么，来完成这项工作。

在我们研究的组织中，AI 已经从辅助工程师的工具，转变为大规模编写代码的作者。人类越来越多地处于评审和监督角色，而不是创作角色。这一转变在吞吐量数字中清晰可见，也在后续所有环节中清晰可见。

本报告的数据覆盖软件开发工作流的每一个阶段：工作如何被启动、代码如何被编写、代码如何经过评审和测试，以及代码进入生产后发生了什么。在每一个下游阶段，信号都是一致的：数量上升，质量下降，并且随着采纳加深，两者之间的差距正在扩大。

对 DORA 2025 发现的直接反驳

DORA 的 2025 年《AI 辅助软件开发现状》报告认为，AI 会放大既有优势和弱点，并且强大的工程基础可以防护 AI 带来的负面影响。^[2]

注 2：DORA 的 2025 年《AI 辅助软件开发现状》报告。

我们从数千个团队的工程系统中提取的工程系统数据并不支持“强工程基础是保护因素”这一结论。高绩效工程组织正在经历与其他组织相同的下游恶化。

这种差异值得审视。DORA 的发现基于调查。调查捕捉的是开发者对自己工作的感受。而现在，开发者确实感觉更有生产力，因为在个体层面，他们确实更有生产力。任务完成量上升，代码流动更快，工具感觉非常强大。

调查无法捕捉的是下游发生的事情：悄悄堆积的评审队列、在生产中累积的事故、以及本应更早被发现却抵达客户面前的缺陷。考虑本报告中的一项发现：未经过任何评审就被合并的 PR 增加 31.3％。关卡只有在守门人没有被雪崩般的工作掩埋时才有效。当这些后果最终体现在人的感受中时，已经过去数月，信号已经滞后。

这就是在快速 AI 转型时期，基于调查的研究存在的根本限制。感知滞后于现实，而工程系统数据不会。工程组织正在围绕人员规模、工具和流程做出重大决策，需要尽可能接近实时的数据，并且这些数据应来自工作实际发生的系统，而不是来自人们事后对工作的感受。

工程成熟度这一发现最值得注意。那些在 AI 出现之前就已经具备强工程能力、成熟 DevOps 实践、高 DORA 分数和严谨交付流程的组织，并没有因此免受影响。无论原本的工程成熟度高低，加速反噬都会出现。即使基础最扎实的组织，也正在 AI 生成代码的洪流冲击下承压。

本报告的发现按照以下顺序组织：

1. AI 采纳
2. 开发者认知负荷
3. 吞吐量
4. 代码复杂度
5. 合并前代码质量
6. 流动与效率
7. 生产中的代码质量

发现 1：AI 采纳

AI 现在是标准配置，而不是实验项目

80％ 的团队经常使用 AI。代码接受率增长三倍。AI 使用已经成为常态。

AI 工具采纳正在急剧加速，开发者接受 AI 产出的比例比以往任何时候都更高。

软件开发中 AI 采纳现状

这一转变背后的机制很有启发性。持有至少一种 AI 工具许可证的开发者比例保持平稳。组织早已购买了席位，因此真正变化的是利用率：过去一年，公司一直在积极推动那些已经有权限、但尚未持续使用工具的开发者采用 AI。

公司在过去一年中积极推动那些已经拥有访问权限、但尚未持续使用工具的开发者采纳 AI。

代码接受率也反映出同样的加速。AI 生成代码被接受进入代码库的总体比例已经从 20％ 上升到 60％。这一增长在很大程度上由 Cursor、Claude Code 等工具在智能体模式下运行所推动，在这种模式下，智能体会直接应用变更。

AI 生成代码被接受进入代码库的总体比例已经从 20％ 上升到 60％。

由 AI 智能体打开的 PR 低于 1%。这里指的是 AI 智能体在没有人类发起的情况下，独立编写、提交并发起代码变更评审。智能体式 PR 评审则从 0 增长到 25%，部署速度显著更快。

发现 2：开发者认知负荷

频繁切换与认知负荷正在增加

AI 让开始工作变得容易。但它没有让完成工作变得容易。

关于软件开发中上下文切换的研究结论很明确：几乎每一次中断都会迫使开发者先重建上下文，然后才能写下第一行代码。^[3]

注 3：Parnin, C., & Rugaber, S. (2011). Resumption strategies for interrupted programming tasks. Software Quality Journal, 19(1), 5-34. https://doi.org/10.1007/s11219-010-9104-9

数据表明，AI 增加了这种负担，而不是减少了它。一个运转良好的系统应该将认知工作从工程师身上卸下，让他们专注于需要人类判断的决策。但我们的数据显示，工程师正在管理更多并行线索、更多并行 PR，并在更多状态之间来回切换。这一程度高于我们数据中此前任何时点。

上下文切换：团队从低 AI 采纳转向高 AI 采纳时的指标变化

上下文切换在我们 2025 年报告中已经上升，并且还在继续加速。在高 AI 采纳情况下，开发者每天触碰的 PR 数量现在上升了 67.4％，每天触碰的任务数量上升了 17.7％。随着开发者在 AI 辅助下能够更快启动工作，他们也倾向于同时开启更多线索。这也预示了智能体式工作流会进一步强化的趋势：开发者并行编排多个 AI 智能体，评审其输出，为其解除阻塞，并决定接受哪些结果。这是当前数据中已经可见的上下文切换动态的自然演进。

这种认知负荷的增加，也体现在数据中。每名开发者的工作重启次数上升了 13.8％。这里的“重启”指任务已经进入其他阶段后，又被退回到“进行中”状态。它的代价很高，因为开发者必须重新找回此前中断的上下文：当时做到哪里、要解决什么问题，以及为什么做出了那些决策。

同时，过去 7 天内没有 PR 或任何活动的进行中任务增加了 26％。这些任务已经启动，占用了团队产能，却随后停滞下来。整体图景很清楚：AI 让工作更容易开始，但没有让工作更容易完成。

过去 7 天内没有 PR 或任何活动的进行中任务增加了 26％。这些任务已经启动，占用了团队产能，却随后停滞下来。整体图景很清楚：AI 让工作更容易开始，但没有让工作更容易完成。

尽管如此，吞吐量的提升是真实的，下一节会具体说明。AI 确实能加快个人产出，但这些数据也表明，频繁的上下文切换正在成为加速背后的额外成本，而且这一成本还在上升。

发现 3：吞吐量

输出上升。但并非全部留得住。

开发者做得更多。执行正在加速。但代码 churn 提出了一个关键问题：哪些产出才真正算数？

AI 显著加速了输出。任务吞吐量、Epic 完成量和 PR 合并率都在上升。部署频率是例外。但有一个数字提出了仅靠吞吐量无法回答的问题：代码 churn，也就是一个季度内删除代码行数与新增代码行数之比，在高 AI 采纳下增加了 861％。吞吐量数字衡量的是已经发布或合并的东西，但它无法告诉你有多少真正留存了下来。

吞吐量：团队从低 AI 采纳转向高 AI 采纳时的指标变化

所有类型任务，包括文档、研究和设计工作，每名开发者吞吐量上升 33.7％。但具体涉及代码的任务，即关联 PR 的任务，在团队层面的增长速度超过前者的六倍。这正是 AI 工具被设计来做的事情：加速编写软件的行为。总体任务完成量与代码相关任务完成量之间的差距，本身就是一个信号，说明 AI 影响最集中的位置在哪里。

Epic 完成率的提升是与业务结果最直接相关的一项发现。Epic 代表大型功能、多轮 Sprint 的工作，通常对应有意义的产品能力。每名开发者完成的 Epic 数量增加 66.2％，表明 AI 正在帮助团队完成更大规模的工作，而不只是完成单个任务。

每名开发者完成的 Epic 数量增加 66.2％，表明 AI 正在帮助团队完成更大规模的工作，而不只是完成单个任务。

有一个数字需要背景说明。高 AI 采纳后，每名开发者的 PR 合并率上升 16.2％，但显著低于我们 2025 年报告中的 98％ 增幅。最可能的解释不是工具边际收益递减，而是代码质量正在制造评审瓶颈，进而抑制吞吐量。组织正在生成比系统能够评审和合并的量更多的代码。

数据集中有约 10% 的组织能够追踪部署频率。在这些组织里，每周部署次数下降了 11.7％。也就是说，代码写得更多、合并得更多，但发布到生产环境的频率并没有提高。^[4]

注 4：部署频率由数据集中约 10% 的团队测量。这些发现仅在该子集中具有统计显著性，并且与更广泛数据方向一致。报告纳入这一指标，是因为随着 AI 采纳扩大，交付层可见性会变得越来越重要。

代码 churn 定义为一个季度内，已合并代码中删除代码行数与新增代码行数之比。在高 AI 采纳下，这一比例增加 861％。这相当于过去比例的 9.6 倍，意味着相对于新增代码，被删除的代码显著增加。

有多种可能解释可以说明这一增长，而在跨客户观察性研究中，以当前指标无法消除这些歧义。^[5]

注 5：这一发现基于跨客户的观察性研究，分析对象是工程元数据，而不是具体代码库。跨组织聚合指标可以提供方向性信号，但无法判断被删除的代码到底来自近期新增，还是来自遗留系统重构。要回答这个问题，需要 Git 级别的代码行历史数据。

第一种解释是，开发者快速接受了 AI 生成代码，但在实际使用中发现这些代码并不够好，于是又回头替换掉它们。如果这种返工发生在同一个统计周期内，那么它代表的就是实际浪费。

第二种解释更乐观：AI 让团队能够启动过去难以推进的大规模重构。过去，这类重构项目成本太高、周期太长，很难投入足够人力。现在，团队可以开始替换多年累积的遗留系统，因此产生了大量代码删除。在这种情况下，删除代码并不意味着失败，而是有价值的架构改进。

第三种可能是，AI 加快了工程师回头修改代码的速度。有些代码在发布时本来就不是工程师完全满意的版本，而 AI 让他们更快地回到这些地方进行改进。

这三种解释都能与当前数据相符。

因此，组织需要在自己的工程环境中进一步分析。如果能够查看 Git 级别的代码行历史，就可以判断被删除的代码是近期新增的，还是旧系统重构中清理掉的遗留代码。前者更可能说明 AI 生成代码带来了返工，后者则可能说明团队正在进行有价值的重构。

还可以按仓库或应用来分析删除行数与新增行数的比例，并把统计周期从季度缩短到月度。这样可以缩小被删除代码的来源时间窗口，让信号更清晰。

无论最终原因是什么，代码 churn 的大幅上升都值得关注。吞吐量只能说明交付了多少，不能说明有多少最终留下来。代码 churn 就是本节所有产出数字后面的注脚。

发现 4：代码复杂度

代码变更正在变得更大、更复杂

每一个结构性维度都在增长，而且是同时增长。

当 AI 采纳较高时，产生的代码不仅数量更多，而且在我们测量的每一个维度上，结构都更复杂。

代码复杂度：团队从低 AI 采纳转向高 AI 采纳时的指标变化

PR 大小衡量的是单个 pull request 中新增或删除的代码行数。它是一个变更一次性对代码库产生多大影响的最直接指标。小 PR 长期以来一直是软件工程最佳实践。更小、更聚焦的变更更容易理解、更安全地合并，也更容易在出问题时回滚。平均 PR 大小增加 51.3％，意味着更大、更不可预测的变更一次性进入代码库；如果发生问题，影响半径也更广。^[6]

注 6：PR 大小上升 51.3％，低于上一报告中的 154％ 增幅。两份数据集在规模、组成和时间段上不同，因此直接比较应按方向性看待。两者一致之处在于方向：高 AI 采纳时，PR 大小显著上升；本数据集中的其他复杂度指标也确认了这一模式。

典型代码变更的影响面显著扩大。每个 PR 平均编辑文件数上升 59.7％，意味着每次变更比以往触达代码库更深。在开发者层面，每月影响面增长更显著：每名开发者每月触碰的文件数上升 149.9％，每月触碰的代码仓库数上升 11.7％。每一次 AI 辅助代码变更都更大，触及代码库更多部分，并且携带比以往更宽的影响半径。

每一次 AI 辅助代码变更都更大，触及代码库更多部分，并且携带比以往更宽的影响半径。

有几个因素可能推动了这种扩张。编码智能体可能会更新人类本会遗漏的相关文件，也可能将范围扩展到超出任务所需的程度。AI 让长期推迟的重构项目成为可能，而这类项目本身就会设计成触及较大表面积。并且，开发者现在被赋能进入代码库中不熟悉的区域工作，可能缺乏判断力去限制 AI 应该触碰的内容。

为了进一步理解根因，组织应利用自己的工程数据，跟踪每个故事点对应的代码行数、按任务类型划分的 PR 大小，以及随时间变化的按 PR 大小划分的返工率。如果更大的 PR 评审时间明显更长，并产生更多事故，那么就有理由在工具层面强制执行大小限制。

发现 5：合并前代码质量

合并前代码质量正在下降

评审者发现的问题更多。他们也正在被低质量代码压垮。

评审阶段的代码质量信号已经恶化。然而，更危险的是，更多 PR 正在未经任何评审的情况下被合并，无论是人类评审还是智能体评审。

合并前代码质量：团队从低 AI 采纳转向高 AI 采纳时的指标变化

每个 PR 的评审评论数上升 25％，评论平均长度上升 22.7％。在得出结论之前，需要说明两个注意点。

第一，每个 PR 写入的代码更多，因此即使每行代码的缺陷率不变，评论量有所增加也是预期之内。

第二，智能体代码评审在该数据集中从 0 增长到 25% 的 PR，而这些评论统计并不区分人类留下的评论和智能体留下的评论。众所周知，智能体评论往往更冗长，并覆盖更广泛的问题，包括结构、格式和风格。因此，这可能独立于底层代码质量而推高评论数量和长度。

考虑这些限制后，对评论量和评论长度上升最直接的解读仍然是：进入评审的代码比以往需要更多审查。下一节会考察评审和工作流时间数据，这些数据不受同样混杂因素影响，并讲述了一个一致的故事：工作流中的每个阶段都明显变慢，瓶颈在评审点最为严重。

本节中最紧迫的发现是：未经任何评审即被合并的 PR 增加 31.3％。随着 AI 采纳扩大，代码在缺乏监督的情况下进入生产的比例显著提高。

未经任何评审即被合并的 PR 增加 31.3％，这是本节最紧迫的发现。随着 AI 采纳扩大，代码在缺乏监督的情况下进入生产的比例显著提高。

发现 6：流动与效率

工作流在每个阶段都在变慢

更多工作进入队列。负责管理这些工作的人员跟不上。

本节大多数指标来自 Jira、Azure DevOps 等工作管理系统。这些系统记录任务在团队工作流中的流转情况，例如从“进行中”到“评审中”，再到“QA”或“完成”。唯一的例外是 Lead Time，它来自版本控制和 CI/CD 流水线数据。数据显示，任务停留在“进行中”状态的平均时间增加了 225.2％。

当工作从进行中推进到评审、测试，再到完成时，每一次交接都是一个需要人类注意力、判断和容量来决定下一步的时刻。在每一个阶段，所花时间都大幅上升。

流动与效率：团队从低 AI 采纳转向高 AI 采纳时的指标变化

任务处于等待状态的平均时间增加了 81.8％。所谓等待状态，是指工作流中那些明确表示任务正在排队或被阻塞的阶段；此时工作并没有被实际推进。尽管不同团队对工作流的定义不同，但数据呈现出一致趋势：任务停留在静止状态的时间显著增加。

也就是说，工作不只是整体完成得更慢，还花了更多时间卡在没有人处理的环节里。

工作不只是完成得更慢；它还花了更多时间停留在根本无人处理的状态。

在评审者真正拿起一个 pull request 之前，等待时间中位数已经增长 156.6％。一旦有人开始评审，评审耗时平均增加 199.6％，中位数增加 441.5％。

我们已经证明，PR 变得更大、触碰更多文件，并包含更多 AI 生成代码。但复杂度本身无法解释这种增长幅度。在我们看来，质量相关发现指向一个更基础的问题：到达评审阶段的代码往往并未达到“可评审”状态。评审者不只是在评估更多代码，他们似乎还在更努力地将这些代码提升到 PR 打开前就应该达到的标准。

评审时间变长，还指向一个容易被低估的问题：高级工程师正在承担更多额外成本。

AI 生成代码对评审者很棘手，因为它往往表面上很有说服力：写法自然、命名规范，风格也与现有代码库一致，看起来像是由熟悉系统的人写出来的。但真正的问题如果存在，通常藏在结构和逻辑层面，而不是明显错误里。

因此，评审者必须认真阅读代码、推断实现意图，并重新理解这段代码原本要解决的问题。这是一种缓慢、昂贵的认知劳动，而最常承担这项工作的，正是高级工程师。

结果是，整个评审体系形成了一个从底部向上挤压的结构：底部产出的代码越来越多，顶部能够承担深度评审的工程师容量却有限。代码进入评审环节的速度，已经超过了现有流程原本能够消化的速度。

最了解系统的工程师，正在把最宝贵的时间用来拆解那些“看起来合理”的代码。而这些代码本不应该以这样的状态进入他们的评审队列。

说明：本数据集中的许多组织使用自动化工作流提醒来暴露停滞工作。这些发现反映的是团队已经在干预的环境。若没有这些自动化，数字很可能更高。

不同的测量工具，相同的信号

Lead Time 衡量从代码提交到生产部署之间的时间，捕获自版本控制和 CI/CD 流水线数据，而不是工作管理系统。不同于 Jira 中由人手动标记完成的 “done” 状态，Lead Time 反映的是交付基础设施中实际发生的事情：合并代码需要多长时间才能通过构建、测试和部署流水线，并抵达线上环境。

数据集中约 10% 的组织能够统计 Lead Time。在这些组织里，Lead Time 增加了 480.4％。^[7] 由于团队之间差异较大，这个数字应作为方向性信号理解。即便如此，趋势依然清楚：部署流水线正在承受与前面各个工作流阶段相同的压力。代码完成了，但并没有更快进入生产环境。

注 7：Lead Time 由数据集中约 10% 的组织测量。团队之间存在较大差异，因此报告纳入这一指标时，建议只按方向性理解，不宜直接使用该具体数值。

发现 7：生产中的代码质量

低质量代码正在抵达生产

缺陷是真实的。事故是真实的。进入生产系统的代码没有达到工程师曾经为自己设定的门槛。

AI 生成代码正在进入生产环境，但并没有稳定达到生产质量要求。相较于低 AI 采纳基线，事故数量已经增加到三倍。这意味着问题已经从开发阶段延伸到真实用户依赖的系统中。

生产代码质量：团队从低 AI 采纳转向高 AI 采纳时的指标变化

事故与 PR 之比增加 242.7％，意味着相对于低 AI 采纳基线，每合并一个 PR 触发事故的概率增加超过三倍。每一次事故都代表潜在宕机、安全事件或客户可见故障。AI 生成代码如今正在金融、医疗、基础设施等各行业的生产系统中运行，并推动月度事故数增加 57.9％。

事故与 PR 之比增加 242.7％，意味着相对于低 AI 采纳基线，每合并一个 PR 触发事故的概率增加超过三倍。

每名开发者缺陷数尤其值得关注。在我们上一份报告中，这一指标增加 9％。在当前数据集中，它增加了 54％。这是令人担忧的加速。随着更多 AI 生成代码进入代码库，每名开发者对应的缺陷数也在增加；并且随着 AI 采纳加深，这种关系正在变得更强。缺陷与 PR 之比同样上升，说明交付代码中的缺陷密度正在提高。

我们计划在后续报告中进一步研究：如果按 PR 大小进行归一化，缺陷和事故的增长是否仍然成立；还是说，更大的 PR 本身解释了大部分质量退化。

Jira 工单重新打开的比例上升了 12.6％。工单被重新打开，意味着某项已经标记为完成的工作，后来又被发现并未真正满足要求，因此被退回继续处理。这通常发生在 QA 阶段或部署之后。它是一个重要的质量信号，因为这些工作在被退回之前，已经通过了某种“完成”的判定。

行业内一直在争论：既然 AI 可以承担入门级编码工作，是否还需要初级工程师。但生产质量数据挑战的是一个更不舒服的假设：质量问题并没有在评审阶段被充分拦截，而评审阶段正是高级工程师最能发挥作用的地方。

不论根因是代码量过大、工具不足，还是对 AI 输出过度信任，结果都是一样的：质量下降、事故增加，更多未经充分评审的代码进入生产。换句话说，问题不在于由谁来评审代码，而在于到达评审阶段的代码本身还没有准备好。这是代码编写阶段的问题，而不是评审阶段的问题。

工程组织应该怎么做

AI 现在是主要作者。这意味着以下要求。

本报告的数据同时确认了两件事。AI 编码工具确实带来了真实的吞吐量收益：完成了更多任务、交付了更多 Epic、写出了比我们数据集中任何历史时点都更多的代码。与此同时，这些代码并不是生产级代码。更多缺陷正在抵达生产。每个合并 PR 对应的事故数已经增加三倍。围绕人类开发节奏和人类质量标准构建的工程系统，并不是为吸收 AI 现在产生的内容而设计的。

这两件事同时成立。任何只处理其中一面的响应都会失败。

在本数据集中，智能体式代码编写目前只占不到 1% 的 PR。就目前而言，这是好事。本报告中的数据反映的是：当开发者将 AI 用作主要编写工具、但人类仍在回路中时会发生什么。如果将人类完全移出回路，这里的每一个指标都会承受高一个数量级的压力。行业尚未准备好迎接这种转变，工具也没有准备好。

单纯加强评审，是错误的应对方式

增加评审人员、收紧合并关卡、延长 QA 周期，本质上都只是在缓解症状。评审的作用是发现错误，但目标不应是安排更多人去发现错误，而是让更少错误进入评审环节。

真正的解法，是提高代码在生成阶段的质量。当 AI 工具在生成代码时能够获得更充分的上下文，例如代码库规范、架构意图、实现指南和测试要求，它们产出的代码从一开始就会更接近可交付状态。

看见问题之后，就需要行动

这份数据背后的组织，已经拥有行业中许多组织还不具备的能力：它们能够看见工程环境中真实发生的事情。它们知道工作在哪里停滞，质量在哪里下降，事故在哪里集中。这种可见性是重要优势。

但仅有可见性还不够。下一步是建立控制能力。这里的控制不是为了放慢 AI，而是为了让 AI 在更清晰的约束下生成更好的代码。组织需要一个面向 AI 智能体的约束与编排框架，将代码库规范、架构意图、安全要求和系统历史等信息，转化为智能体可以遵循的护栏。

这个框架应当让智能体在人工看到输出之前，先完成测试和验证；在需要人类判断时，引入合适的协作；并通过反馈循环，让被接受和被拒绝的结果持续改进下一次输出。

接下来：工程领导者可以如何响应

本报告的数据具有诊断意义。下面十条建议，是为了把诊断转化为行动。并不是每个指标对所有组织都同样紧迫。建议先从今天已经能够测量的指标开始。

1. 同时衡量事故与 PR 之比，以及月度代码变更量与月度事故数

这两个指标都应该跟踪。事故与 PR 之比可以说明：每合并一个 PR，导致生产故障的概率有多高。月度事故数与代码变更量的对照，则可以说明：随着 AI 输出扩大，整体风险是否也在上升。

如果在扩大 AI 采纳之后，其中任一指标已经增长超过两倍，就说明评审关卡没有跟上节奏。还应结合缺陷严重性数据一起看，不只关注关键事故，也要覆盖其他严重性等级。这样才能更完整地判断生产质量趋势。

2. 制定评审策略，并将其作为gate-keeper

未经任何评审就被合并的 PR 增加了 31.3％，这是不可持续的。但答案不是简单规定“每个 PR 都必须由人类评审”。随着 AI 采纳扩大，代码产出量会继续增加，完全依赖人类评审的机制很快会被压垮。

工程领导者需要更精细地划分评审责任：哪些代码区域必须由人类评审，哪些可以由可信的 AI 智能体评审，哪些需要两者共同评审。

划分标准应基于风险。高风险系统、安全敏感路径和面向客户的服务，应保留人类评审；低风险区域则可以考虑智能体评审。但无论如何，完全没有评审都不可接受。每个 PR 在合并前都必须通过明确的关卡：人类、智能体，或两者兼有。这个关卡需要在工具层面强制执行，并定期审计。

3. 为编码智能体设置 PR 大小指南，并强制执行

平均 PR 大小上升了 51.3％。大型 PR 会放大高级工程师的评审负担：它们更难评审，影响范围更广，也更可能包含表层检查发现不了的结构性问题。

智能体开发应遵循 研究 → 计划 → 实现 的流程。计划阶段必须控制变更范围，确保最终 PR 是一个独立、自包含、可以部署到生产的价值单元，并且能够独立通过完整流水线。

这些要求应写入编码智能体的指令中。否则，智能体很容易生成超过评审流程承受能力的变更。组织也应检查事故率、缺陷率是否与 PR 大小相关。如果较大的 PR 带来了明显更多故障，就应在 PR 创建前设置硬性大小限制。

4. 将质量关卡建入开发环境，而不是评审队列

不要让结构复杂或不完整的代码抵达高级工程师的评审队列。AI 智能体不应只根据工单中的完成条件进行迭代，还应根据一组已定义的质量关卡进行迭代：静态分析阈值、lint 规则、测试覆盖率下限，以及测试中定义的成功标准。目标是在智能体层面实现测试驱动开发。智能体的完成定义不是只产出能运行的代码，而是通过一组代表任务规格的测试。

5. 将工作流阶段耗时作为持续复盘流程的输入

进行中、评审中、QA 中的耗时，在工作管理系统中普遍可追踪。仅仅监控它们是不够的。应部署智能体，定期检查每个阶段的耗时，识别模式、暴露根因，并生成关于哪些摩擦可以预防的假设。

例如，当一个任务在评审中停留异常长时间时，智能体应该追问原因：PR 是否太大？评审者是否缺少足够上下文，无法快速做决定？工作呈现方式是否迫使评审者深入原始代码和日志，而不是阅读清晰摘要？在许多情况下，摩擦并不来自工作本身，而来自工作被呈现的方式。

智能体可以在每个阶段提炼出最重要的信息，并以更容易消化的形式呈现，降低做决策的工程师的认知负荷。

这是一个持续改进循环，而不是一次性审计。智能体检查信号、提出优化方案，下一轮再测试其是否有效。每个工作流阶段的耗时会成为一个持续运行的复盘流程输入，不需要 Sprint 仪式，也不需要手动汇总报告。目标是形成一个随着时间可测量地变快的流水线，由那些能从每个周期中学习摩擦在哪里、下一次可以如何改进的智能体驱动。

6. 把工作重启作为智能体上下文质量的信号

工作重启，是指任务进入后续阶段后，又被退回到“进行中”状态。高 AI 采纳下重启增加，通常说明编码智能体一开始走错了方向，导致任务不得不返工。

这往往是因为智能体在编写阶段缺少足够上下文。如果重启率随着 AI 采纳一起上升，就应检查智能体在开始任务前获得了哪些信息：需求背景、相关代码、架构约束、测试要求和历史决策是否充分。

修复点应放在上游：在智能体开始前提供更完整的上下文，而不是在任务被退回后再人工补救。

7. 区分人类与智能体评审评论，并以不同方式处理

每个 PR 的评论数量增加、评论也变得更长，说明评审者正在投入更多精力。但并不是所有评论都同样重要。

智能体评审评论往往关注结构、格式和表层代码模式。这些问题有价值，但最好在 PR 创建之前就被自动化流程发现。人类评审评论则不同，它通常代表更昂贵的高级工程师判断，因此是更重要的信号。

当人类评审者指出某个问题时，应将其反馈到智能体的约束框架中，并转化为通用规则，避免未来 PR 重复出现同类问题。每一条有价值的人类评论，都是改进代码生成阶段的机会。

8. 围绕代码 churn 建立自动化分析循环

合并代码中，删除行数与新增行数之比正在上升。这不只是一个需要监控的指标，更是一个需要自动化分析的信号。

每次出现显著的代码 churn，系统都应该追问：主要原因是什么？影响了哪些代码库或应用？这是合理的重构，还是可以避免的返工？

然后，系统应分析其中的模式，并把结论反馈到智能体指令中。凡是可以预防的 churn，都应该用来持续改进代码生成流程。

9. 重新配置工程产能，而不是削减产能

不要因为 AI 提高了产出，就急于削减工程人员。风险在于：人员减少后，质量问题继续累积，几个月后又不得不重新招聘。很多看似可以被替代的工程师，实际上正在吸收 AI 生成代码带来的质量缺口。

正确做法是重新配置工程产能，而不是简单替代。把工程能力转向建设 AI 可持续使用所需的基础设施：评审系统、质量机制、上下文供给，以及能够持续发现问题并反馈改进的自动化复盘循环。

现在进入生产的代码量比以往更高，质量、安全和合规风险也更高。在做出人员决策之前，先让流程稳定下来。然后再基于受控的流程和清晰的信号做决策，而不是在压力下仓促调整团队规模。

10. 为工程环境构建上下文引擎

修复点在上游。AI 智能体无法只看代码库当前状态，就准确理解系统意图。代码库只是某个时间点的结果，真正的意图来自它的演进过程：变更历史、每次变更背后的原因，以及多年开发中累积下来的架构决策。

这些历史上下文，加上代码库规范、安全约束和测试要求，正是当前 AI 智能体缺少的东西。只有把这些信息接入代码生成环境，AI 才更可能产出接近可交付状态的代码，并减少后续人工干预。

否则，本报告记录的问题会继续存在，并随着智能体式代码编写扩大而进一步恶化。

这些建议有一个前提：你已经能看见自己的工程环境。如果今天还无法回答其中大多数问题，那么首先要解决的是可见性缺口。你无法治理自己看不见的东西。

附录：支持图表

输出上升，但并非全部留得住

吞吐量指标：从低 AI 采纳到高 AI 采纳的百分比变化。

频繁切换与认知负荷正在增加

上下文切换指标：从低 AI 采纳到高 AI 采纳的百分比变化。

代码变更正在变得更大、更复杂

代码复杂度指标：从低 AI 采纳到高 AI 采纳的百分比变化。

合并前代码质量正在下降

合并前代码质量指标：从低 AI 采纳到高 AI 采纳的百分比变化。

工作流在每个阶段都在变慢

流动与效率指标：从低 AI 采纳到高 AI 采纳的百分比变化。

低质量代码正在抵达生产

生产代码质量指标：从低 AI 采纳到高 AI 采纳的百分比变化。