20 篇博文 含有标签「developer-productivity」

你的下一次定级会（calibration meeting）存在一个没人愿意点破的衡量问题。委员会面前的材料显示，一名工程师在这半年提交了 340 个 PR，而另一名只提交了 90 个。五年前，这种差距意味着某些实质性的东西。而今天，它主要告诉你的是谁拥有更好的 Agent 工具链，谁的团队拥有更宽松的审查文化，以及谁对合并生成代码的容忍度更高。幻灯片上的数字衡量的是机群（fleet）。而委员会本应评估的是人。

这并非某种未来才会发生的虚构趋势。行业分析估计，在认真采用 Agent 的公司中，AI 编写的代码已占提交代码的 30% 左右；一项针对 300 名工程师的纵向研究发现，在采用 Agent 后，团队生成的 Pull Request 数量增加了 98%。你的评审流程从“前 Agent 时代”继承下来的每一项产出指标——代码行数变化、合并的 PR 数量、Story points、速率（velocity）——现在都是人类判断力和机器吞吐量的混合衡量，两者之间没有明确的归因界限。定级委员会正在比较这些混合数字，就好像他们仍在衡量人一样。

关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。

数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。

一份打磨精良、长达八页的设计文档（design doc），在有人读到其中的任何文字之前，就曾代表着某种意义。这种产物的存在本身就是证据：有人花了两个星期思考失效模式，与自己争论权衡利弊，并预判了评审者会提出的质疑。文档是思考的凭证。评审者仅凭打磨程度就能进行初步筛选，因为这种“精良感”很难造假，成本极高。

这种相关性如今已经消失了。一个智能体（agent）不到一小时就能生成一份内容详尽、结构严谨、图表丰富的 RFC——甚至还包含一个“已考虑的备选方案”章节，而这些方案实际上根本没人真正考虑过。产物保留了下来，但它承载的信号却消失了。大多数工程组织仍在运行一套隐性基于旧有写作成本而设计的评审流程。

“你昨天做了什么？”是每一场站会的第一个问题。对于一个通宵运行智能体集群（agent fleets）的团队来说，这已经变成了一个无法如实回答的问题。字面上的答案是：我写了三个提示词（prompts），然后回家睡觉，醒来发现有 11 个 PR，其中 4 个我还没看。那个正在陈述进展的人并不是故意撒谎。是这种仪式在替他们撒谎，因为它建立在一个不再成立的假设之上——即工作单元是一个人类在办公时间内串行地、一次只做一件事。

这个假设是起到承重墙作用的。它支撑着燃尽图、Sprint 承诺、速率值、“受阻 / 进行中 / 已完成”列，以及“谁在什么时候告诉谁什么”的整个协作流程。抽掉这个假设，这些产物并不会优雅降级。它们会继续产生看似权威但毫无意义的数字。一个团队可以拥有漂亮的燃尽图和绿色的 Sprint 状态，而其实际吞吐量有一半发生在午夜到凌晨 6 点之间，这些工作不归属于任何人，没人审计，也没有体现在任何仪式中。

你的仪表盘从未如此好看。合并的 Pull Request (PR) 数量几乎翻倍。每个工程师的提交次数正在攀升。代码行数源源不断。每一个活动图表都呈现上升趋势，你在六个月前引入的 AI 编程工具看起来是公司今年最划算的一笔支出。

然后，你检查了一个没人会放在幻灯片里的数字：客户从提出需求到实际拿到东西需要多长时间。这个数字纹丝未动。在某些季度，它甚至变得更糟。团队正在产出更多的一切，除了业务真正买单的东西。

这就是“速度幻象”。容易统计的指标上升了，而真正重要的结果却在悄然下滑。这是目前工程领域最昂贵的衡量失败之一，因为它看起来完全像是成功。

一年前，你的团队采用了 PR 描述模板。它包含 ## Summary、## Changes、## Test plan 和一排复选框。审查者非常喜欢它：每个 PR 都有上下文，每个 PR 都有测试计划，每个 PR 都有结构。六个月后，编程助手学会了填写它。现在，每个 PR 依然有 ## Summary、## Changes、## Test plan 和一排复选框 —— 但审查者不再阅读标题以外的内容了。曾经聚焦注意力的格式，现在反而成了“此处不值得关注”的信号。结构比它所承载的信号寿命更长。

这不是代码质量问题。这些 PR 中的代码通常是没问题的。问题在于，撰写描述的行为已经从思考变更的行为中被剥离，而描述正是审查者用来分级处理（triage）其有限注意力的工具。当该工具变得格式统一、措辞合理，且与其他所有 PR 毫无区别时，审查者的注意力分级机制就失效了。曾经用于挖掘异常情况的系统，现在将所有内容摊平成了同样的形状。

关于编码智能体（coding agents）提高生产力的说法是，它们消除了打字瓶颈。但在实践中，工程师真正遇到的瓶颈却截然不同。工程师再也无法在脑中掌握整个系统，因为智能体修改文件的速度快于工程师阅读的速度，编写测试的速度快于工程师推断覆盖率的速度，重构抽象的速度快于工程师在设计层面（而不仅仅是编译器层面）验证类型检查的速度。

那个紧凑的内环——假设、更改、观察、优化——定义了胜任的工程工作，但它正悄然瓦解为另一种循环。工程师现在是在审查智能体的输出，而不是建立对系统的直觉。2025 年中期的一项 METR 随机对照试验发现，经验丰富的开源开发人员在使用 AI 助手处理熟悉的代码库时，速度慢了 19%，但他们却报告感觉快了 20%。认知感知的生产力与实际生产力之间这 39 个百分点的差距并非测量误差。这是为了吞吐量而默默牺牲理解力的代价。

二十年来，软件工程的瓶颈一直是写代码。我们优化了 IDE、自动补全、重构工具和各种框架，让"打字"变得更便宜。我们赢了。可现在瓶颈往下游挪了一步：写代码很便宜，读代码却很贵。PR 机器人可以并行启动十次实现尝试，在你早上喝完咖啡之前就把十个 Pull Request 砸到你的仓库里。你的审查者做不到这一点。

AI 辅助的软件交付，速率限制器已经不再是模型的每秒 token 数，而是你每天能投入多少双"人眼"去看 diff。当这些眼睛被压垮，系统不会优雅地降级——它会开始盖橡皮图章。代码带着 LGTM 🚀 被合入，没有人真正读过。一名资深工程师批准了一份由 AI 写、又被另一个 AI 工具审查过的补丁，三周后一个数据不一致的 bug 吃掉了某个人四十个小时的人生。表面上的正确不等于系统层面的正确，绿色的流水线不等于"我理解了"。

AI 编程工具的 ROI 宣传在纸面上看起来无懈可击：在受控实验中，开发者完成任务的速度提升了 55%，合并的 Pull Request 数量增加了 98%，每周据称节省 3.6 小时。但当组织审视真实的交付指标——Bug 率、发布周期、故障频率——时，数字几乎没有任何变化。某些东西吸走了所有增益的时间，而它并不难找。

AI 数秒生成代码。工程师的审查速度，却和以前一样慢。

基准测试数据讲述了一个奇怪的故事。在 SWE-bench Verified 上，多个运行相同底层模型（均为 Opus 4.5）的智能体产品——Auggie、Cursor、Claude Code——产出了截然不同的结果。尽管“大脑”完全相同，Auggie 在 731 个问题中比最接近的对手多解决了 17 个。差距在于“脚手架”（scaffolding）：智能体是如何被提示的、被赋予了什么上下文、可以调用哪些工具，以及在困惑时测试框架（harness）做了什么。模型是商品，围绕它的脚手架才是产品。

这是成熟的工程团队在十年前对初级工程师达成的相同共识。一个聪明的毕业生能交付价值，并非仅仅因为模型优秀，而是因为 README 是最新的，测试套件运行迅速，代码审查标准每次都能捕捉到那六个同样的错误，并且有人编写了说明约束条件的 CONTRIBUTING.md。剥离这些脚手架，同一个人产出的代码可能局部连贯但全局错误，破坏了团队甚至没想到要写下来的生产环境不变量。

一位资深工程师打开了一个由 Agent 编写的 PR。Diff 非常整洁。测试通过了。命名规范一致。他们大致扫了一眼，点了个赞，然后合并。两个月后，另一位资深工程师正在重写那个模块，因为该模块引入的抽象在三个调用点悄悄泄露了状态，而测试套件从未发现这一点，因为它只断言了代码在做什么，而不是规范（Spec）的要求。

这种模式是 2026 年代码审查（Code Review）中占主导地位的失败模式。那些适用于人类编写 PR 的审查直觉——探究作者的意图、寻找他们没想到的 Bug、检查测试是否反映了设计——在 Agent PR 上失效了，因为 Bug 聚集在不同的地方，且审查者看到的产物不再是真正重要的产物。

数据支持这一直觉。CodeRabbit 在 2025 年 12 月对 470 个 GitHub PR 的分析发现，AI 协作编写的代码产生的问题大约是人类编写代码的 1.7 倍，其中逻辑和正确性错误是 1.75 倍，安全发现是 1.57 倍，算法和业务逻辑错误是人类的 2.25 倍。严重问题增加了 1.4 倍，重大问题增加了 1.7 倍。Diff 读起来很流畅，而这种流畅性恰恰就是问题所在。

仪表板显示，你的工程师在上个季度采纳了 45% 的 AI 建议。管理层将其解读为“节省了开发人员 45% 的时间”，并签署了续约合同。与此同时，工程师们正在悄悄重写他们采纳内容的一半，调试另一半，并纳闷为什么他们的 Sprint 看起来还是和以前一样长。双方都在看同一个数字，但只有其中一方看对了数字。

2025 年引用次数最多的这项研究，本应单枪匹马地终结“厂商仪表板时代”。METR 衡量了经验丰富的开源维护者在有无 AI 的情况下，处理自己代码库中真实问题的表现。开发者预测 AI 会让他们提速 24%。实验结束后，他们仍然认为 AI 让他们提速了 20%。但秒表显示他们慢了 19%。故事与数据之间存在 39 个百分点的差距——而季度评审中采用的正是那个“故事”。