AI-translated from English; not yet reviewed by a fluent editor. # AI 编码之后，可靠交付成为工程新挑战 > 当 AI 提高代码产出量时，工程经理需要了解变更在哪些环节等待、验证工作需要多少成本，以及发布的软件是否按预期运行。 By BIG CHANGE Editorial Published: 2026-09-22T05:31:05.772Z Updated: 2026-09-22T05:31:05.772Z Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery ![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery. AI 编码智能体可能已经完成一个补丁，而此前补丁的检查仍在运行。对于工程经理而言，这会造成一种棘手的区别：团队编写了更多代码，但客户还没有收到任何新功能。 Linear 提供了一个有用案例。工程师 Mufeez Amjad 在 9 月 21 日的工程实践记录中称，自 2026 年初以来，Linear 的测试套件数量几乎增至四倍；持续集成（CI）的拉取请求等待时间则从六分多钟降至五分多钟。每项测试所需的运行器时间大约减半。这些是彼此独立的改善；最后一个数字并不表示 CI 总账单也减半。Linear 将验证压力增长归因于 AI 辅助开发，但其记录并非受控实验，不能据此证明 AI 对生产力的影响。[Linear 的工程实践记录](https://linear.app/now/ci-bottleneck-reworked)。 持续集成（CI）会对提议的软件变更运行自动化检查。它处在一个看似可行的补丁，与团队愿意接受的变更之间。如果 AI 编码增加了补丁供应量，检查能力就会成为业务问题：组织能够安全地吸收多少有用工作？ 我们认为，管理者应同时关注三种结果：获得可信反馈所需的时间、计算工作总量，以及已发布变更的可靠性。更快得到答案固然有价值，但前提是团队理解这个答案究竟能证明什么。 ## 缩短等待时间，可能意味着增加工作量 设想一个测试套件在一台机器上需要运行 12 分钟。将工作平均分到四台机器上，可能在 3 分钟内完成。这是假设完全均衡分工的简化情形，忽略了其他所有因素。四台机器仍总共执行了 12 分钟的工作。 现在假设每台机器都需要一分钟准备时间。四台机器的方案用四分钟完成，共消耗 16 个运行器分钟；单台机器的方案用十三分钟完成，共消耗 13 个运行器分钟。等待时间大幅缩短，总机器用量却上升。实际费用还取决于运行器类型、价格和计费规则。 当仪表板用更短的绿色条庆祝时，这种区别很重要。购买并行容量，是为了更早获得反馈，可能也意味着额外成本。如果它消除了真实瓶颈，这种交换就可能非常值得；但若变更完成后还要等数小时才有审核者可用，就较难证明这笔支出合理。 分析单位不应只是一轮 CI 运行。一个补丁若引发反复修改、重新运行和第二轮审核，所消耗的总工作量可能远高于其中最快的一次运行。应统计接受一项变更所需的所有尝试，包括放弃的尝试。否则，看起来高效的流水线可能掩盖昂贵的开发过程。 等待的每一分钟，也不都等同于相同的人工成本。开发者如果在检查运行时开始另一项有用工作，就未必真的损失了整个时间段。反复中断和回到未完成工作则仍可能造成影响。要衡量这些效应，需要观察团队如何工作，而不是简单用经过的分钟数乘以工资。 ## 研究呈现出多方面的结果 DORA 于 2026 年 3 月发布的分析报告了两组不同的证据。其 2025 年研究发现，AI 采用率越高，既与软件交付吞吐量上升有关，也与不稳定性上升有关。另一项独立研究分析了 Google 工程师在 2025 年第三季度提交的 1,110 条开放式回答。工程师谈到 AI 帮助起草和完成其他任务，同时也提到验证工作开销。内部定性研究的受访者不是 DORA 更广泛关联分析背后的研究群体；两项研究都不能证明 AI 导致了某个团队的发布问题。[DORA 的分析与方法](https://dora.dev/insights/balancing-ai-tensions/)。 此外还有范围较窄、但实验控制更强的证据。METR 于 2025 年 7 月发布的随机研究，将 246 项任务分配给 16 名在熟悉代码库中工作的资深开源开发者。允许使用 2025 年初期的 AI 工具后，任务完成时间反而增加了 19%。参与者仍认为 AI 帮助他们加快了工作。该发现仅适用于这些开发者、任务和工具，不能决定今天所有编码智能体的价值。[METR 原始实验](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)。 2026 年 2 月，METR 表示其后续研究得出的当前生产力影响估算不可靠。开发者越来越多地拒绝无 AI 的工作，或自行选择提交哪些任务；同时运行的智能体也让时间测量变得复杂。研究人员认为加速效应可能更大，但表示数据只能为加速幅度提供微弱证据。若不加限定地重复旧研究中“速度下降”的数字，会误导读者。[METR 后续研究](https://metr.org/blog/2026-02-24-uplift-update/)。 对管理者而言，这些研究支持一种务实立场：保留有用工具、调查其影响，不要把乐观或怀疑转化为适用于所有团队的用工公式。同一团队可能在某类工作中获益显著，在另一类工作中却耗费更多时间。交付流程应能揭示这种差异。 ## 针对不同瓶颈采取不同措施 购买更多 CI 容量之前，应追踪一项变更从首个拟议补丁到投入生产的全过程。将实际运行的工作与等待中的工作区分开。找出真正拖延决策的检查、需要投入精力的审核者，以及之后仍需满足的发布条件。 简单的计时记录通常足以揭示错误的投资方向。如果大部分延误发生在审核开始前，那么将测试时间缩短几秒并不能解决问题。如果审核者反复等待一项耗时很长的必要检查，改进该检查就有直接价值。如果问题主要在部署之后出现，团队需要检查验证过程漏掉了什么。 依赖项缓存说明，为什么熟悉的优化也需要测量。GitHub 文档称，缓存可以在全新运行器上复用重新创建成本较高的文件；文档也指出，缓存不可用时，作业必须能够重新创建或下载这些文件。因此，评估缓存效果时，既要看命中，也要看未命中。[GitHub 依赖项缓存文档](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching)。 对经理而言，真正有用的问题是反馈变得多么可预测。平均值很好，仍可能伴随偶尔长到足以打乱发布安排的等待时间。应追踪分布中较慢的一端，并区分有效的测试失败，与下载失败或运行器耗尽。不同问题需要不同应对措施。 可靠且及时的反馈能让员工和智能体更早有机会纠正错误。改善这类共用基础设施，可以使多种开发工作受益，包括不使用 AI 编写的变更。即使编码工具的选择在变化，经理仍有理由为基础设施投入资金。 ![One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.](/api/media/file/elapsed-aggregate-work-inline-v1.png) ## 测试更快，也必须能抓住错误 某些性能优化会改变测试运行的条件。这比更换一颗更快的处理器更值得仔细审视。 JavaScript 和 TypeScript 测试工具 Vitest 默认会隔离测试文件，以防一个文件的状态影响另一个文件。其文档介绍了如何对适用测试选择性地取消隔离，同时指出，可变模块状态、被修改的全局变量和其他依赖都是保留隔离的理由。因此，缩短准备时间的设置也可能改变正确性边界。[Vitest 隔离机制指南](https://vitest.dev/guide/recipes/disable-isolation)。 Linear 对共享状态采用了选择加入的方式，增加了清理步骤，并为无法安全迁移的文件保留隔离。其性能收益取决于团队能否判断哪些测试可以安全地共享环境。[Linear 的实现方式](https://linear.app/now/ci-bottleneck-reworked)。 如果智能体同时编写变更和测试，还会带来另一项挑战。设想一条假设的折扣规则：只适用于年度订阅。智能体可能错误地把它实现为也适用于月度计划，再编写确认自身理解的测试。测试通过，只能证明实现与错误解释保持一致。 审核者需要以该实现之外的证据为依据：约定的需求、目标行为示例，以及应当失败的案例。要求智能体编写更多测试或许有帮助，但测试数量增加本身，并不能说明有人检验了被误解的需求。人类仍有责任决定软件应如何运行，以及证据是否回答了这个问题。 如果团队只奖励测试数量，却不审视测试能够证明什么，就有可能让审核者面对更多材料，却更缺乏信心。分配工作时，经理就应为这项审查留出时间，而不是在智能体完成后把它当成无法解释的延误。 ## 衡量最终交付给客户的变化 DORA 的交付指标可作为有用的下游检查，包括从代码提交到投入生产的时间、部署频率、部署失败后的恢复时间、需要立即干预的部署比例，以及因意外事件而返工的部署比例。这些指标衡量的是交付结果，而不只是测试是否通过。[DORA 指标定义](https://dora.dev/guides/dora-metrics/)。 调查 AI 编码流程时，我们会将这些结果与一份简明的诊断记录结合起来： - 反馈：完成必要检查所花的时间，包括运行较慢的时间和等待容量的时间。 - 消耗：每项已接受变更所对应的运行器总工作量和重复尝试次数。 - 审核：等待审核所花的时间、要求大幅修改的次数，以及每次修改的原因。 - 客户影响：已发布的变更是否实现了预期行为，以及之后是否需要修正。 用这份记录调查具体工作流程。一项小型文档修改与一次数据库迁移，不应被视为可互换的生产力单位。在可行时，应比较一段时间内相似的工作，并记录其他变化，例如更换运行器服务商或调整发布流程。AI 采用率提高的同时出现某项改善，并不能证明其原因就是 AI。 管理者随后就能作出一个具体决定：为阻碍有用变更以足够把握交付给客户的瓶颈提供资金。有时这意味着增加计算容量，有时则意味着明确需求、改进测试，或安排足够的资深审核时间来理解已经到来的提议。 ## Sources - [Linear：AI 编码与 CI 瓶颈](https://linear.app/now/ci-bottleneck-reworked) — 2026 年 9 月 21 日。Mufeez Amjad 的实施记录提供了开篇数据和选择性隔离的例子。这些第一方测量描述的是 Linear 自身系统，并非对 AI 生产力或总支出的受控估算。 - [DORA：平衡 AI 带来的张力](https://dora.dev/insights/balancing-ai-tensions/) — 2026 年 3 月 10 日。区分了 DORA 2025 年的关联发现，与对 Google 工程师回答所做的定性分析。内部研究报告的是个人体验，而非经过测量的因果效应；此前的问题也可能对回答形成提示。 - [METR：2025 年初期 AI 工具与资深开发者生产力](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 2025 年 7 月 10 日发布的随机实验，涉及在熟悉开源代码库中工作的开发者及 2025 年初期的工具。研究支持其限定范围内的速度下降结果和认知差异，但不能估算所有开发者或 2026 年 9 月模型的表现。 - [METR：开发者生产力实验的变化](https://metr.org/blog/2026-02-24-uplift-update/) — 2026 年 2 月 24 日更新。解释了参与者和任务选择、报酬变化及测量并发工作的困难。研究人员认为新的估算不可靠；本文没有把其原始数字呈现为当前加速幅度。 - [GitHub：依赖项缓存](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — 截至 2026 年 9 月 22 日查阅的当前文档，介绍了在全新运行器上复用文件，以及作业在无缓存时仍须能够工作的要求。该文档不能确定任何特定代码库的性能或账单。 - [Vitest：按文件设置隔离](https://vitest.dev/guide/recipes/disable-isolation) — 截至 2026 年 9 月 22 日查阅的当前文档，解释了默认隔离、选择性配置及需要保护的状态依赖。该技术指导有助于理解取舍；BIG CHANGE 未运行基准测试，也未修改测试套件。 - [DORA：软件交付绩效指标](https://dora.dev/guides/dora-metrics/) — 2026 年 1 月 5 日更新。定义了五项交付指标，并说明如何在服务层面应用。这些指标提供了 CI 时长之外的结果衡量方式；本文的诊断示例是分析，并非新实验的结果。