AI 编码提速后：验证环节成为新瓶颈

当 Agent 把代码写快之后，两个团队同时撞上了同一堵墙：验证环节跟不上了

Agent 让代码编写变得更快。两个工程团队先后发表了文章，讲述在这一过程中发生在验证环节的情况。两篇文章从不同角度得出了相同的结构性结论。Linear 发现其 CI 门禁成了瓶颈。Salesforce 发现其人工评审不再起作用。两支团队都没有把问题归咎于生成环节。两支团队都认为，系统中用来评判一次变更的那部分，没有跟上生成变更的那部分的发展速度。

CI 端：Linear 的漏斗

Linear 的工程师在 2026 年 9 月 21 日发表了一篇题为《AI 编码让 CI 成了瓶颈，于是我们重新设计了 CI 以跟上》的文章，报告称自今年年初以来其测试套件数量几乎翻了两番。Pull Request 等待时间从超过 6 分钟降到刚过 5 分钟，每个测试的 Runner 耗时下降了近一半。这些吞吐量提升是真实的，但问题的关键在于这些提升从何而来。Linear 并没有通过让 Agent 放慢速度来提速——他们对验证机制进行了重新设计。

这份改动清单大多是机械性的。换用 CPU、存储和缓存更好的第三方 Runner，让同样的流水线平均快了约 34%，其中 tsc 工作负载下降了 52%。迁移到 tsgo 编译器将 tsc 检查的周中位数降低了 73%，足以将类型检查从瓶颈中解放出来。几条依赖 TypeScript 类型信息的自定义 lint 规则被重写为使用抽象语法树，这使得 ESLint 完全摆脱了 TypeScript，并将 API lint 时间减少了 68%。一个变更检测任务原本在只需要检查极少量文件时却检查了整个工作树，其中位数从 26 秒降到了 8 秒。将缓存标记的写操作从关键路径上移走，为每个 API Pull Request 节省了 42 秒。

这里最关键的指标是没有人会拿来宣传的那个：一次提议的变更等待被评判需要多长时间，以及评判过程消耗了多少机器时间。当测试套件在 Agent 负载下翻两番时，这个数字才决定了 Agent 在实际使用中是否让人感觉快。

评审端：Salesforce 的 plateau

在同一个漏斗的另一端，Salesforce 工程师 Shan Appajodu 和 Ravi Boyapati 于今年 1 月发表了《规模化代码评审：适应 AI 生成代码的激增》。他们的内部信号是：代码量增长了约 30%，Pull Request 经常超过 20 个文件和 1000 行变更，评审延迟逐季攀升。他们标记为最令人担忧的信号是，最大 Pull Request 的评审时间趋于平稳甚至下降。他们将此解读为评审人员不再进行有意义的参与。

这与 CI 失败是不同的另一类问题。大幅 Diff 跨越了不相关的文件和架构层级，导致评审人员在导航上花的时间比推理还多，第二双眼睛的保障被侵蚀了。Salesforce 的答案不是在吞吐量意义上让评审更快，而是围绕重建意图重建评审系统，将上下文作为一等依赖，并逐步披露风险，使评审人员将注意力花在真正重要的地方。我之前单独写过当评审时间保持平稳时，这个 plateau 说明什么。

将两份报告放在一起看，形状就很清晰了。Linear 的验证瓶颈是机械性的，修复成本低，所以他们让它变快了。Salesforce 的瓶颈是认知性和结构性的，所以他们重建了评审如何呈现变更的方式。但两者是同一种失败：生成变得更便宜、更快，而验证变更的系统却没有随之扩展。这是每支引入 Agent 的团队现在都在承担的负载，只是在两个不同的地方，往往同时在两个地方。

Linear 的文章给出了机械端的具体数字。Salesforce 的文章给出了认知端的语言。工程任务是知道自己撞上的是哪一端。如果 Pull Request 停在等待 green check 上且 Runner 成本高昂，你遇到的就是 Linear 的问题。如果大变更畅通无阻地通过而评审时间保持平稳，且高级评审人员整天在上下文切换，你遇到的就是 Salesforce 的问题。两种解决方案不能互换。

该度量什么

团队通常跟踪周期时间和生成吞吐量，两份报告都表明这些不是正确的衡量标准。Linear 跟踪的是"等待 CI"时间和每个测试的 Runner 时间。Salesforce 跟踪的是最大 Pull Request 上的评审时间，因为当那里数字走平，就是一个参与度下降信号在掩盖审查质量下滑。在 Agent 负载下，一个有用的评审指标是验证成本与变更大小的比率，按 PR 大小分桶观察，这样就不会在平均值中迷失那些庞大的 1000 行变更。

工具链在两端都在迎头赶上。CI 感知的验证和成本感知的 Runner 在机械端提供支撑，而上下文优先的评审工具则在认知端发力，通过保持相关变更分组在一起来呈现风险。Kodus 属于上下文优先评审工具的同一类别，应用团队特定规则而非通用 linting。这番比较的目的不是哪个产品胜出。而是说明评审工具要在漏斗中你的瓶颈所在的那一端赢得自己的位置，所以第一个问题是你的哪一端正在出问题。

两篇主要来源，一个结论

两篇文章都值得完整阅读，而且两者在方法论上都异常坦诚。Linear 公布了前后对比数字。Salesforce 明确指出了真正发出警报的指标。如果你想要一个核心结论：当 Agent 使代码生成实际上变得免费时，剩下的约束就是验证，而那些发表了经过度量的工作的团队正在修复验证这一侧。

那些营销"评审每个 PR"的厂商说的是吞吐量。有据可查的来源在说人是否仔细看了，无论是在 CI 门禁处还是评审台前。当被要求评审越来越多由 AI 撰写的代码时，第一个有用的步骤是将你自己的瓶颈定在这条光谱上的位置。如果最大变更的评审时间走平而变更规模越来越大，问题不在于评审太慢——而在于评审停止了阅读。这个数字才是值得关注的，而且也是供应商仪表板通常不会展示的那个。