代码写得更快了，人却更累了

摘要：AI 编程工具让代码产出暴增，但瓶颈从"写"转移到了"审"。Stack Overflow 2026 年 5 月下了诊断：coding agents 正在给所有人制造决策疲劳。96% 的开发者不信任 AI 生成的代码，但 46% 的新代码是 AI 写的。Vibe Coding 提出一年后，我们从"写代码的人"变成了"审 AI 代码的人"——这种工作没有更轻松，只是换了一种累法。

---

"现在每天打开 GitHub，等我的不是代码，是一排 AI 生成的 PR。每个都像一张考卷，我得一道一道判。"

这不是他一个人的感受。2026 年 5 月，Stack Overflow 发了一篇分析，标题直接把问题定性了——"Coding agents are giving everyone decision fatigue"。翻译过来：AI 编程工具正在给所有人制造决策疲劳。

你可能会想，AI 写代码不是应该更轻松吗？

答案是你想的那种轻松没有来。来的是另一种累。

"写代码"不再是瓶颈了

先看一组数据，感受一下现在的局面。

Sonar 2026 年开发者调查：96% 的开发者不信任 AI 生成的代码。同一份调查里，46% 的新增代码是 AI 产出的。

一边不信任，一边大量使用。这个裂隙每宽一分，审查的压力就大一倍。

GitLab 的 AI 问责报告也指向同一个方向：78% 的开发者承认，有了 AI 之后自己编码确实更快了。但整体软件交付效率——从需求到上线——没有提升。瓶颈不在"写代码"了，卡在测试、审查、治理。

Sonar 还给这现象起了个名字：Velocity Trap，速度陷阱。AI 把开发速度推上去了，超 40% 的加速，但代价是更大的 PR、更复杂的代码、更多需要验证的东西。速度快了，验证跟不上，反而堵住了。

打个比方：你把工厂传送带加速到原来的两倍，质检站只留了一个人。这个人没变快，产品却翻倍了。结果要么漏检，要么堵死。

决策疲劳：一种新的职业病

Stack Overflow 那篇分析把事儿讲得很清楚。AI 没有替你消除决策，它只是把决策推给了你。

以前你自己写代码，写每一行的时候已经在做决定了——变量叫什么，异常怎么处理，这段逻辑放哪个函数里。这些决策是"写"的一部分，分散在打字的过程中，你不觉得累。

现在 AI 把代码"生成"出来了，你面对的是几百行已经写好的代码，每一行都是一个需要你确认的判断。"这个判断对了吗？""边界条件覆盖全了吗？""这个库的引入合理吗？""它为什么选了这种实现方式？"

决策没有减少。决策被压缩了。

以前花两个小时写代码，决策散在 120 分钟里。现在花二十分钟审查 AI 的代码，同样数量的决策挤在 20 分钟里。密度翻了六倍。

而且这些决策更难做——你不是在审视自己写的东西，你在审视别人写的东西。别人的思路、别人的习惯、别人的隐含假设。你需要花额外的脑力去反向工程它的逻辑。

这就是为什么审查 AI 代码比写代码更累。

MIT 一项研究给出了一个扎心的数字：AI 生成的代码在 PR 阶段被审查者标记"需要提交者补充解释"的比例，是人工代码的 2.7 倍。

2.7 倍。不是 27%，是 270%。

审查者不是在挑刺。他们是真的看不懂——一个人提交了自己也没完全理解的代码，另一个人试图理解这段代码为什么这么写。两个人的认知都悬在半空。

Vibe Coding 一年了

2025 年 2 月，Andrej Karpathy 提出了 Vibe Coding。当时说的是：描述你想要什么，AI 产出代码，人只做审查。理论上，代码从手工业变成了流水线。

一年多过去了，看看实际发生了什么。

得到了什么

原型开发速度，快了 10 倍不止。以前搭一个内部工具 Demo 可能要两天，现在描述清楚需求，喝杯咖啡的工夫就出来了。内部工具的门槛降到了零——运营、产品同事开始自己用 AI 搭小工具，不再等排期。

语言学习成本暴跌。你不会 Rust？没关系，描述清楚逻辑就行。不会前端？也没关系。AI 消除了语法恐惧，跨栈开发从"能不能"变成了"想不想"。

失去了什么

对代码的掌控感。看着一段 AI 写的代码，你能感觉到它"应该是对的"，但你不确定"为什么是对的"。这种感觉很微妙——代码在跑，功能正常，但你缺少那种"我把这块石头翻过来看过下面"的踏实。

写代码的手感。这个更难量化。长期不动手写，你会发现自己对 IDE 的熟悉度在下降，对重构的本能反应在钝化。就像长时间用导航的人，认路能力会退化。

对系统底层理解的自然积累。以前你写代码，每解决一个 bug，就对框架的内部机制多了一层理解。这是痛苦换来的知识。AI 帮你跳过了痛苦——也跳过了知识。

Hacker News 上有一个帖子拿了 1600 分，标题是："I haven't handwritten a single line of code in 3 months. Am I still a programmer?"

下面最热门的回复不是"当然算"，也不是"不算"。是——"你觉得更轻松了吗？"

Charlie Marsh 的坦白

Astral 和 Ruff 的创始人 Charlie Marsh，2026 年上半年公开承认：他已经一行代码没读，全交给 AI 发布产品了。

这句话在开发者社区炸了锅。

不是因为夸张。是因为他是 Charlie Marsh。Ruff 是 Python 生态里最重要的工具之一，几百万人在用。你如果是一个不知名小项目的开发者在 AI 上偷懒，别人最多说一句胆真大。但 Ruff 的创始人说"一行代码没读就发布"——性质完全不一样。

同事反应更快。消息传开当天，团队成员开始逐行细审他提交的每一个 PR。不是因为怀疑他，是因为他公开说出的那句话，把所有人的注意力拉到了一个事实面前：如果连创始人都可以不看代码就发布，那这套流程还有什么安全性可言？

这不是 Charlie Marsh 的问题。这是整个行业的问题：当 AI 让"产出代码"变得如此便宜，"验证代码"的成本就成了房间里的大象。

Slopfix：一门靠删 AI 代码赚钱的生意

更黑色幽默的是，有人已经开始靠这个赚钱了。

一家叫 Slopfix 的公司，三位工程师创业，只做一件事：帮你删 AI 生成的垃圾代码。一周收费 1 万美金。

他们的一个案例：一个项目的 AI 代码从 10 万行删到 3.5 万行——功能不变，性能更好，bug 更少。

10 万行删到 3.5 万行。中间 6.5 万行是 AI 写的，人审过的，通过了测试的，合并进了主干的——最后发现是冗余的。

这说明什么？AI 写的代码能跑、能过测试、能通过审查——但不代表它是"对"的代码。它只是能跑的代码。这两者之间差的那段距离，就是累积的技术债务。

Smartsheet 的研究给了另一个视角：80% 的 AI 生成内容在最终定稿前经过人工编辑。也就是说，AI 产出的东西，大部分最后都不是原样保留的。但它占用了你阅读、理解、判断、修改的时间。

DevOps Insights 2026 的调查补充了一笔：42% 的团队在代码审查中冲突增加了，开发者开始出现早期倦怠症状。冲突的来源不是"你写得不好"，而是——"这段 AI 写的，我们俩都看不太懂，但必须做一个合并还是拒绝的决定。"

怎么让自己不累垮

这个问题没有标准答案。但我有几个自己的判断。

该让 AI 写的场景。

原型、Demo、一次性脚本。不需要长期维护，不需要团队理解，不需要任何人深夜被报警电话叫起来改线上 bug。AI 写，跑通就行。

重复性代码。CRUD 接口、表单验证、样板配置。AI 在这些事上几乎没有出错空间，审一眼就能确认。省下来的时间是真省下来的。

探索陌生领域。你用 AI 写了一段不熟悉的语言，跑通了，理解了，然后删掉自己重写——这种用法里 AI 是学习工具，不是生产工具。

该自己写的场景。

核心业务逻辑。系统里如果出 bug 能让你半夜两点被叫起来的那种代码。每一行你都应该能闭着眼讲出"为什么这么写"。

安全敏感代码。认证、授权、加密、数据脱敏。AI 在这方面的创造性是最危险的——它可能引入一种你以为不存在的攻击面。

需要团队长期维护的模块。AI 写的代码，团队每个人都得花额外成本去理解。这个成本随时间累积。如果预期这段代码要活两年以上，自己写反而更划算。

缓解决策疲劳。

把审查时间分段。早上精神状态好的时候审最关键的 PR，下午审不紧急的。不要在疲惫状态下做合并/拒绝决定——那会儿的判断力跟喝了酒差不多。

接受不完美合并。不是每个 PR 都需要逐行审完。低风险模块设一个信任等级：跑通测试、规范检查通过、功能验证没问题，就合。把精力留给真正重要的。

承认决策预算有限。一天能做出的好决定是有上限的。超过上限，后续决策质量会断崖式下降。这不是意志力问题，是认知科学的基本事实。

总结

AI 让我们写代码快了。但它没让我们做软件变快，也没让我们变轻松。

瓶颈只是从"打字的速度"转移到了"判断的密度"。

Vibe Coding 的承诺没有落空——原型确实十分钟就能出来。但承诺背后的假设落空了——"人只做审查"听起来轻松，真干起来比写代码更累。

知道什么时候该让 AI 写、什么时候自己写、什么时候停下来——这本身就是一种新的能力。AI 没法替你做这个判断。

作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。