Vibecoding 疲劳：承诺的是少干活，得到的却是零休息

“我有一半时间都在告诉 AI 哪些事情不要做。”这句话来自一位接受 Morgan Blangeois 采访的开发者。Morgan Blangeois 是克莱蒙奥弗涅大学管理科学博士生，这篇采访文章于 7 月 28 日发表在The Conversation上。如果你写代码超过五年，现在大概已经对着屏幕点头了。

当初卖给我们的是一个助手。我们收到的却是一个永不疲倦、速度极快、极度自信、从不睡觉，而且必须逐行检查的实习生。这和原本的合同可不完全一样。

这东西现在有名字了

“vibecoding fatigue”一词于 2025 年 8 月由前 Google 员工 Jorge Raad 推广开来。Vibe coding 指的是用日常语言描述需求，然后让机器生成代码。至于随之而来的疲劳，宣传册里可没提。

2026 年 3 月，《哈佛商业评论》发表了一项研究。该研究由研究人员与波士顿咨询集团合作，对 1,488 名美国雇员进行了调查。他们给这一现象起了一个没那么优雅的名字：“AI brain fry”。也就是大脑被烤糊。定义非常准确：因使用或监控 AI 超出自身心智能力所能承受的范围而引发的认知疲劳。参与者描述说，他们感到头脑混沌、嗡嗡作响，或者觉得脑子里同时开着十二个浏览器标签页。

数据证实了这个问题。报告称出现这种 brain fry 的人，遭受决策疲劳的风险大约高出 33%。他们主动产生辞职念头的风险也高出 40%。研究作者之一 Matthew Kropp 指出，同时操控多个智能体的工程师就是矿井里的金丝雀。换句话说，他们比其他人更早发现危险。成为金丝雀的感觉令人得意——能得意四秒钟，直到你想起金丝雀最后会怎样。

唯一灰掉的标签页，就是你之前正在做的那件事。

这些数字可不怎么好看

Upwork 研究院两年来一直在强调同一个问题。2024 年，77% 使用 AI 的专业人士认为，AI 加重了他们的工作负担。2025 年，在调查了四个国家的 2,500 名劳动者后，结果变得更加荒谬。在那些借助 AI 获得最大生产力提升的人中，88% 表示自己已经陷入职业倦怠。他们考虑离职的人数也多出一倍。更妙的是，62% 的人并不理解自己日常使用 AI 与公司目标之间的关系。

在技术层面，Google 的DORA 2025 报告通过其他指标得出了同样的结论。在受访者中，90% 使用 AI，超过 80% 认为 AI 让自己更高效。然而，30% 的人对 AI 生成的代码完全没有、或几乎没有信心。更重要的是，采用 AI 与更高的交付节奏相伴而来，但也带来了更多不稳定性：变更后失败更多、返工更多，解决事故所需的时间也更长。

总结一下。我们交付得更快，出问题的次数更多，不信任自己交付的东西，而且已经累得精疲力竭。真是出色的一个季度。

这份讽刺已经四十三岁了

这种机制并不新鲜。最有意思的恰恰就在这里。1983 年，Lisanne Bainbridge 以飞机驾驶舱和工业控制室为背景，写下了一篇后来成为经典的文章，讨论“自动化的讽刺”。

他的结论分为两点。首先，自动化接手的是容易的任务，也就是那些可以清晰描述的任务。因此，留给人类的是棘手的情况，恰恰是最需要经验的那些情况。其次，人们还要求他持续监控一台机器，尽管他自己已经不再亲自执行这些任务。他失去了训练，却被留下来参加考试。

一张图说明这笔交易：你赢得了只做困难部分的权利。

在我们的行业里，机制很简单。审查自己没有编写的代码，可能比编写代码本身更费成本。首先必须还原其意图，然后判断结果。编写代码时，你做出一个决定并将其贯彻下去。审查代码时，你必须逐行重新审视这个决定。而且，正如 DORA 所指出的，工具无法指出自己的疑虑。它会用和给出正确答案时一模一样的自信，滔滔不绝地输出一派胡言。根本不可能快速筛选。你必须把所有内容都打开。

当初的承诺是减少工作量。实际的合同却是：重复性任务为零，决策占 100%。这就像把拉力赛中的直道全部取消，然后告诉车手这样做刚刚帮他节省了时间。

三天完成演示，剩下的二十七天完成其余工作

我最近读到的、最有数据支撑的反例来自 Luc Bonnin，他把这项实验彻底做到了最后。他构建了 ClearSpot.me，一个用于定位风力涡轮机的地理定位 Web 应用。他完全借助 AI 创建了这个应用，用时 30 天，没有手写一行代码。

第一个版本在 3 天内完成。它需要 105 个 prompts，也就是给 AI 的 105 条指令，最终生成了 80 782 行代码。确实令人惊叹。随后还需要额外 27 天，才能得到一个真正可以用于生产环境的应用。总计：1 117 个 prompts、25 亿个 tokens（模型读取、编写并计费的文本片段），以及最终生成的 206 347 行代码。更重要的是，90% 的 tokens 都消耗在 POC 之后，也就是那个用来验证想法是否站得住脚的原型阶段。

用三种方式衡量同一项工程。三种方式都说明了同一件事，却没有一种说出我们想听到的答案。

他的结论很明确：“帕累托法则非常适合快速完成一个超快的 POC，但如果真的想要达到可以投入生产的应用，它就是海市蜃楼。”数据库从 40 Mo 增长到了 40 Go，还必须编写 40 个数据摄取算法，也就是负责导入和处理数据的机制。随后，第一次让十名用户试用，便暴露出了在单人演示期间完全看不见的性能问题。对他而言，十个人就足以完成一次负载测试。

所有人都会忽略的细节是：最终结果之所以质量良好，具备测试、文档和清晰的架构，唯一原因在于有一位专家全程持续监督这个过程。没有手写一行代码，并不意味着不需要任何技能。技能只是从键盘转移到了代码审查上。却没有人想过问一句：这是否更令人疲惫。

老手们早已在做的事

Blangeois 调查中最有用的部分在于，他没有给出建议。他描述的是最有经验的开发者们早已自行找到的解决方案，而不是等着别人要求他们这样做。最终可以归纳出三种应对方式。

第一种是先打草稿。在打开工具之前，先用简单的话写下自己真正想要的东西。“你把 AI 安置在自己对面，然后对它说：我们要一起处理这份规格说明。”没有这个框架，机器会生成一些看似合理的东西。而“看似合理”是头号敌人，因为它和正确答案非常相像。

第二点是重新掌握。一位开发者说得非常好：「我会重新阅读并理解生成的每一行代码。不是为了检查它能否运行，而是为了理解。」他们给自己设定的测试很简单：如果不看笔记，我能否在同事面前为这一行代码辩护？

第三点是拒绝。我们划出红线，把某些任务留给自己。比如那些会让系统在未来几年都受其影响的架构决策。高风险领域也是如此：支付、医疗数据或客户文件。最后，我们还要保留那些能赋予工作意义的任务。否则，一天里就没剩下多少有趣的事情了。

办公桌上的红色胶带并不在工具的官方文档中。

Blangeois 的那句话让我印象最深：观察经验丰富的专业人士拒绝在哪里使用 AI，就能知道哪些能力仍需要自己掌握。这是我今年读到的最好的职业建议，而且只有一行。

最讽刺的是，这三种应对方式，实际上都是亲手把工具刚刚移除的刹车重新装了回去。

职业没有消亡，消亡的是其中简单的部分

Bonnin 在总结他的经历时引用了经济学家 Jevons 在 1865 年提出的观点：当一种资源的使用成本降低时，人们会更多地使用它，而不是更少。如果我们生产更多代码，就会创建更多系统、更多依赖关系和更多技术债务。因此，需要更多人来维持整个系统的正常运转。这样看来，我们不会缺少工作。真正让我担心的恰恰相反。

所以，我认为真正的问题并不是「我会不会被取代」。而是：我们能否用完全由决策、权衡和审阅组成的工作日坚持三十年？Bainbridge 在 1983 年没有回答这个问题。四十三年后的今天，我们仍在发现这个问题。