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

一年前，你的团队采用了 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 个百分点的差距——而季度评审中采用的正是那个“故事”。

某公司在向整个工程团队全面推广 AI 编程助手三个月后，发现了一个令人不安的现象：代码审查通过率下降了 18%，迭代速度有所提升，但生产故障数量却在攀升。当他们在一次事后复盘中要求开发者解释最近一个由 AI 生成的模块时，在场的所有人都说不清楚——就连提交合并的那位工程师也不例外。

这就是认知外包陷阱。问题的根源不是 AI 工具本身，而是团队整合它们的方式。

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。

每个曾将模块委托给外包的工程师都知道那种感觉：代码交回来了，测试通过了，演示也能跑——但你完全不知道它到底好不好。你没有写它，你不完全理解其中蕴含的决策，而你即将进行的审查更像是走过场而非真正的实践。现在把这种动态乘以你代码库中每一个AI辅助的提交。

AI委托悖论很容易表述，却很难逃脱：你最需要用来评估AI生成工作的技能，恰恰是你停止亲自动手后退化最快的技能。这不是未来的风险，而是正在发生的事实，在那些拥抱AI编码工具的工程组织中已经可以量化测量。

你团队中的一名初级工程师刚刚在一周内交付了三个功能。而你的资深工程师只完成了半个。仪表板显示初级工程师的效率是资深工程师的 6 倍。仪表板在撒谎。

这就是 AI 技能反转 —— 一种度量错觉。AI 编程助手让初级工程师在表面指标上看起来生产力惊人，却掩盖了更深层次的问题。功能交付得更快了，但架构却在退化。PR 成倍增加，但系统的连贯性却在瓦解。那些比起判断力更相信仪表板的组织，正在助长错误的行为，并流失掉正确的人才。

每个工程团队都有这样的故事：AI 编码代理在全新项目中能产出完美代码，但在你的生产代码库中却像没有地图的游客一样跌跌撞撞。代理没有坏。你的代码库是不可读的——不是对人类，而是对机器。

几十年来，"可读性"只意味着一件事：人类开发者能否浏览这个文件并理解其意图？我们通过命名、文件大小、文档和抽象深度等约定来为这个读者做优化。但你代码库增长最快的消费者不再是入职第一周的初级工程师。它是一个 LLM 驱动的代理，每天阅读、推理和修改你的代码数千次。

越来越多的证据表明，代码库结构是 AI 辅助开发速度的最大杠杆——比模型选择更重要，比提示工程更重要，比你使用哪个 IDE 插件更重要。拥有良好结构代码库的团队在使用 AI 助手时报告迭代周期减少了 60-70%。问题不再是是否要为机器可读性优化，而是如何优化。