你的团队采用编程 Agent 的那个季度，发生了两件没人会放在同一张幻灯片上的事情。吞吐量上升了 —— 更多的 PR、更多的合并代码、更多的工单被关闭。然而，你最资深的三位工程师却变慢了。这种慢不是因为偷懒，而是因为“溺水”。他们自己的提交量枯竭了，日历被评审任务填满，一对一面谈的主旋律也从“这是我交付的内容”变成了“我花了一整周时间在帮别人排障”。
这就是“资历倒挂”。那些本该通过 AI 获得更多杠杆效应的人，反而被它埋没了。这既不是动力问题，也不是工具差距，而是 Agent 改变工作形态后的结构性后果：它们让生成变得廉价，而让验证变得昂贵。验证正是你无法交给初级人员或其他 Agent 的那一项任务。
数据很快就印证了这些轶事。METR 在 2025 年的一项随机对照试验中，让经验丰富的开源开发者在他们已经贡献多年的仓库中执行任务。结果发现，使用 AI 工具让他们变慢了 19% —— 尽管这些开发者事先预测会提速 24%，事后也依然认为自己变快了。这种认知偏差就是整个故事的缩影：工作感觉 更快了，因为打字变快了；但真正制约交付的部分 —— 判断输出是否正确 —— 却变得更繁重，并转移到了更少的人手中。
生成变廉价，验证变昂贵
在软件历史的大部分时间里，编写代码和评审代码的成本大致处于同一量级。一份花了一天时间编写的代码变更，大约需要一小时来评审，这个比例维持得很好，以至于评审从未成为瓶颈。但 Agent 打破了这个比例。
当一个 Agent 能在四分钟内生成一个 600 行的 PR 时，生成 变更的成本几乎坍缩为零。但信任 该变更的成本却完全没有下降 —— 如果非要说的话，它反而上升了，因为输出在语法上非常整洁，这掩盖了缺陷。Agent 生成代码的失败模式并不是 Linter 能捕获的拼写错误或缺失的分号，而是对需求的误解、看似合理实则错误的边缘案例处理，以及逻辑上正确解决了与你设定的问题略有偏差的问题。看起来正确但微妙错误的代码是评审成本最高的东西，因为没有任何表面信号能标记它。你必须重构意图，并逐行对照实现进行检查。
相关的遥测数据非常残酷。追踪数千名开发者的工程智能平台报告称，在 AI 采用率较高的情况下，平均 PR 规模增长了一半以上，首次评审时间（time-to-first-review）攀升了约 157%，而评审的中位耗时攀升了 400% 以上 。团队合并的 PR 数量几乎翻倍，而每次变更的评审时间却急剧膨胀。分析中有一个令人难忘的定义：资深工程师已经变成了“产品模糊性的验证层” —— 他们正在进行“产品考古”，重构原本的意图，而不是验证已经构建的内容。
为什么压力落在了无法分担的人身上
这就是让它成为“倒挂”而不仅仅是瓶颈的原因。生成工作可以分摊到整个团队以及 Agent 本身 —— 每个人都能产出更多。但捕捉微妙错误的工作只有一项任职资格：在特定代码库中深耕多年所形成的模式识别能力。这无法分摊。
评审 Agent PR 的初级工程师可以确认测试通过、风格匹配。但他们通常无法察觉到，Agent 添加的缓存层在生产环境的并发下会因为竞态条件悄悄提供过期数据，或者看似“等效”的重构改变了事务边界。这种判断力正是你聘请 Staff Engineer 的原因，也是再多的 Agent 吞吐量也无法缓解的压力。因此，随着看起来合理的代码量增加，唯有 资深人员才能负责任地批准的代码比例也随之上升 —— 这一切都涌向了那三个相同的收件箱。
你无法通过增加另一个 Agent 来评审第一个 Agent 的代码来解决这个问题。第二个模型可以捕捉一类机械性问题，部署它是有价值的。但让 LLM 成为衡量这项 变更对你的 系统是否安全的最终仲裁者，只会复制你试图逃避的那个问题：一个自信、流畅的判决，背后却没有可负责的判断。责任最终止于一个理解爆炸半径的人类，而那个人定义上就是资深人员。
其结果是一种在吞吐量仪表盘上不可见的“税收”。你的速度图表看起来很棒 —— 更多的 PR，更多的合并。它们没显示的是，感知到的加速正不断被隐藏的验证成本所抵消，而该成本正在消耗一项稀缺且不可替代的预算：资深工程师的注意力。2025 年的 DORA 研究从另一个角度得出了相同的结论 —— AI 不会修复团队，它只会放大团队原本的样子。如果你的评审流程已经是制约因素，Agent 只是在火上浇油。
二阶伤害
如果任由其发展，这种“资历倒置”会以超出季度周期的规模产生复合影响。
导师制度停滞。 曾经在周五带新人结对编程的高级工程师，现在把时间都花在了清理审核队列（review queue）上。新人不断交付他们并不完全理解的 AI 生成代码，而本可以建立他们判断力的反馈循环从未启动。你正在制造一代只会写提示词（prompt）却不会代码审查的工程师——这会让高级工程师的瓶颈变成永久性的。架构工作消失。 只有高级工程师才能进行的深度的、不可中断的思考——系统设计、迁移策略、以及“我们到底该不该构建这个”的决策——需要长时间的连续专注。每小时都会填满的代码审查队列恰恰破坏了这一点。你正把你最昂贵的认知资源浪费在对模板代码逐行进行审计上。流于形式的审查悄然滋生。 当队列堆积如山时，人类会通过加快批准速度来适应。遥测数据直接证明了这一点：在大规模使用 AI 的情况下，未经审查直接合并（merge）的 PR 比例上升了约 31%。瓶颈并非干脆利落地断裂，而是会产生“泄漏”。这些泄漏正是生产事故的源头——研究表明，看起来整洁的 AI 代码，其正确性和安全性问题溜进代码库的概率是普通代码的 1.5 到 2 倍。人才流失风险。 一个为了构建系统而加入的资深工程师（Staff Engineer），如果现在 70% 的时间都充当“人工代码格式检查器”（human linter），那么他离职的风险极大。替换这样一名员工的全部成本高达 15 万至 30 万美元。审查负担不仅是速度问题，它还是披着速度问题外衣的人才流失问题。 如何重新平衡负载 本能的反应是要求高级工程师“审快点”。这无异于要求约束条件自我放松，行不通的。杠杆作用存在于除审查步骤之外的任何地方——审查的上游、周围，以及你如何核算它的成本。
将判断力前置到上下文环境中。 最廉价的审查是你不需要做的审查。要达到这个目标，方法是为 Agent 提供足够的代码库特定上下文，使其第一次就能产出正确的变更。架构模式、测试标准、历史 PR、规格说明背后的意图——将这些编码为目录级的 AGENTS.md 文件，并输入深层的 Git 历史记录。一个引人注目的发现是：一个拥有良好上下文的“弱”模型，在正确性上优于没有上下文的“强”模型。上下文工程（Context engineering）是减少审查负担的另一种说法。
构建自动化屏障，让审查不再以人开始。 在 Agent 和人工审查者之间增加自动化验证：类型检查、扩展测试生成、针对重复出现的故障模式调优的静态分析，以及在高级工程师看到之前捕获机械类错误的防护栏。目标是当变更到达人工手中时，所有机器能发现的问题都已被清理，剩下的只是真正需要人来做的判断。投入这一领域的团队报告称，代码审查周期更少，高级工程师介入率也更低。
缩小批量。 一个 600 行的 Agent PR 在实际操作中是无法审查的；而一个 60 行的是可以审查的。让“小批量”成为硬性规范，而非建议。2025 年的 DORA 报告反复强调，小批量是唯一最可靠的缓解措施，因为审查成本随 diff（代码差异）大小呈超线性增长——在 600 行代码中重建意图的工作量远超 60 行代码的十倍。
将验证作为一等公民，并投入资源。 不要再把代码审查视为“正式”工作之间看不见的开销。将其列入任务板。将审查时长（time-in-review）和审查者负载作为显性指标进行跟踪。轮换负载，避免压力集中在三个人身上。衡量团队层面的产出——合并的价值、变更失败率——而不是个人的生成吞吐量，这样仪表盘才不会在成本去向问题上欺骗你。
把高级工程师的时间花在需要他们的审查上。 对队列进行分诊。高影响范围的变更——鉴权、支付、数据迁移、并发——交给高级工程师。低风险、经过充分测试的模板代码，由自动化屏障加初级工程师处理，高级工程师进行抽查。将每个 Agent 生成的 PR 都路由给你最昂贵的审查者，这才是真正的资源错配；在要求任何人提速之前，先优化路由规则。
撒谎的指标与诚实的指标 “资历倒置”之所以持续存在，是因为每个人关注的指标——吞吐量——正朝着“正确”的方向发展，而系统却在恶化。更多的 PR、更多的合并、更多的结单，以及一群正在默默耗尽精力、产出骤减、架构工作停滞的高级工程师后备力量。
诚实的指标不是你的团队生成了多少代码，而是它产出了多少“经过验证并交付”的价值，除以实现这些价值所消耗的高级工程师注意力。按此标准衡量，许多在上一季度声称“成功应用 AI”的团队，实际上在处理核心业务上的速度变慢了，并且在这个过程中让优秀的工程师感到工作体验变差了。下一季度的赢家不会是那些让 Agent 写出最多代码的团队，而是那些意识到稀缺资源从来不是生成能力——而是判断力——并围绕这一认知构建了整套工作流，将判断力花在刀刃上的团队。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
