用了 AI，程序员为什么更忙了？

代码确实写得更快了。

但很多程序员的感受却是：需求更多，PR 更大，Review 更累，出了问题还得自己收拾。

这不是一句“AI 不好用”就能解释的事。更准确的说法是：<u>AI 大幅压低了编码成本，却同步拉高了团队对交付效率的预期。</u>

于是，效率提高了，工作量也跟着涨了。

代码写得更快，需求为什么更多了

1856 年，英国经济学家威廉·杰文斯观察到一个反直觉现象：蒸汽机提高了煤的利用效率，煤的总消耗量却没有下降，反而增加了。

原因并不复杂。煤变得更便宜、更好用之后，更多地方开始使用煤，新增需求超过了效率带来的节省。

这就是“杰文斯悖论”。微软 CEO Satya Nadella 近年谈 AI 时也提过它，意思很直白：成本一旦降下来，大家通常不会少用，而是会拿它去做原来嫌麻烦、嫌贵的事。

放到开发里，其实很容易理解。

以前一个内部小工具要在评审会上争半天，现在很可能变成“先做个版本看看”；以前说下个季度再补的配置页，现在也会被顺手加进来。

<u>AI 挤出的效率红利，很少能变成你的喘息空档。</u>

它往往只是给下一张需求单腾了位置。

写得更快，不等于交付更快

演示 AI 编程工具时，最让人兴奋的总是生成速度：一句话搭出页面，一次补全几十个文件。

可在真实项目里，最花时间的往往不是把代码写出来。

你还得读 diff、补边界、查依赖、跑构建、过 Review。线上一出问题，还是得回到这段代码上。

METR 在 2025 年做过一项随机对照实验，邀请 16 名熟悉自己开源项目的开发者完成 246 个真实任务。参与者主观上认为用了 AI 会快约 20%，但实验记录显示，任务完成时间反而增加了 19%。

这个结果不能直接推广到所有程序员，也不能证明 AI 在所有任务上都会拖慢速度。但在熟悉、复杂、历史包袱很重的仓库里，AI 经常能把 80% 做完，剩下那 20% 要靠人一点点补。

而那 20%，往往藏在权限、异常、兼容和回滚里。

最忙的，往往不是写代码的人

这件事已经开始出现在行业新闻里。

据报道，Amazon 在多起涉及 AI 辅助变更的故障之后，加强了高级工程师的审批要求。代码可以一下生成很多，能认真看完、敢对结果负责的人却不会跟着变多。

另一个有意思的例子是 Daemons。这个团队原本在做 Agent，后来转而做一类“清理 Agent 产出”的工具：处理过时文档、没人维护的 PR、重复代码和持续堆积的工程杂物。

这听起来有点讽刺，但很像真实的开发现场：

Agent 越能产出，团队越需要有人判断哪些产出值得留下。

程序员当然还在写代码，只是现在多了一层活：判断哪些改动值得合进去，哪些得及时撤回。

真正增加的，是验收的工作

AI 能把一个模糊想法很快变成代码，但它不会替你判断：这个功能到底值不值得做，需求边界是不是清楚。

生成的改动一多，Review 也不能只看命名和格式。数据怎么流、权限有没有放大、异常能不能兜住、失败后能不能回滚，这些还是得有人逐项确认。

尤其是 Agent 能读文件、改代码、跑命令之后，它已经不只是聊天工具了。生产环境、数据库、支付和用户隐私这类地方，权限给到哪一步、谁来确认，都应该提前说清楚。

那程序员该怎么用 AI？

我更倾向于把 AI 当成一个“加速器”，而不是一个“自动交付部门”。

适合交给它的，是边界清楚、容易验证、失败成本低的任务：补测试、整理重复代码、生成脚手架、解释陌生模块、做一次小范围重构。

不适合直接放手的，是权限很大、影响范围不清楚、出了问题难以恢复的任务。尤其是生产环境操作，最好让 Agent 在测试服务器或隔离环境里先跑一遍。

可以用一个简单的标准判断：

如果你无法在几分钟内看懂它改了什么，也无法快速恢复，就不要让它直接拥有最终执行权。

写在最后

<u>代码交给 AI 生成，判断只能自己兜底。</u>

功能更容易做出来以后，难的反而成了另一件事：它值不值得做，能不能安全上线，出了问题谁来收场。