Vibe Coding 正在变成 Doomcoding：3 个信号识别死亡循环，5 步逃生

凌晨一点的拉杆游戏：doomcoding 是什么

凌晨一点。应用一小时前还好好的，现在结算页一片空白。你把同一串红色报错第六次粘贴进对话框，agent 每次都用同样的自信说「修好了」。你点接受，再跑——又炸了，换个地方炸。你已经不是在写代码了，你是在拉老虎机：说不定下一次生成就中了。

这就是 doomcoding。这个词来自 Medium 作者 @aliteq.official 近期的文章《Vibe Coding Has Become Doomcoding》（该文标注 Last verified: 4 Oct 2026），它描述的是一种正在蔓延的开发习惯：把刷短视频停不下来的 doom-scrolling，原样搬到了 AI 编程 agent 上——不断再来一次，不是因为你懂问题出在哪，而是因为「下一次没准就行」。

它最狠地打击的是「中间层」：能靠 prompt 做出整个 app，却读不懂 agent 生成的代码。新手卡得早，知道自己卡住了；老手能读 diff，一眼识破自信的胡说八道。只有中间层，手里攥着一个「看起来跑起来了」的成品，于是越陷越深。到真正出事那天，代码库已经有几千行没人读过，而你手里唯一的工具，还是下一条 prompt。

3 个信号：你已经在循环里了

循环刚开始时不疼，疼的时候已经深了。出现下面任何一个，你其实已经在 doomcoding 里——早点认出来，省下的不是时间，是整个项目。

信号一：同一串报错，你第 3 次把它粘贴回去。关键不在于粘贴了几次，而在于你根本没读过它。报错里一半单词你都认不全，你只是把它当祭品献给 agent，指望它替你理解。真正的分水岭是这一句：你能不能用自己的话说出「这行报错到底在抱怨什么」？说不出来，你就是在拉杆。

信号二：「Accept All」变成了肌肉记忆。你闭着眼都能点下接受。上一次改动到底动了哪几个文件、删了什么、agent 有没有顺手改了你没让它碰的地方——你一个都答不上来。接受了你没看过的改动，就等于把 QA 的工作外包给了运气。运气这东西，凌晨一点通常不在线。

信号三：修 A 坏 B，代码开始「自己打架」。越修越碎，一个 bug 修掉，两个新的冒出来；agent 几分钟前删掉的代码，悄悄又被它加了回来；它十分钟前说的话和现在互相矛盾。这说明对话已经失去上下文，agent 在盲修，你也在盲信。这是循环最末期的症状——再往下走，就是线上事故。

研究怎么说：这不是你一个人的错觉

这个循环不是懒人的专利，据该文引述，四方研究都在描述同一件事：

METR 发现，人感受不到自己的真实速度。受试的有经验开发者预期 AI 让自己快 24%，做完后仍相信自己快了 20%，实测却是慢了 19%。METR 后来把这个旧结果标了「已过期」，但没过期的是那个落差：每次生成都秒回，所以整个过程「感觉」很快，真正丢掉的那一小时，只有看表才看得见。doomcoding 就靠这个落差活着。

Stack Overflow 2025 调查：最伤人的是「差一点就对了」。66% 的受访者吐槽 AI 答案「几乎对，但差一点」。差一点是最糟糕的那种错——它长得像成品，于是你直接发布，bug 躲在你追踪不到的地方。同一次调查里，46% 的人不信任 AI 输出的准确性。讽刺的是：最有能力检查输出的老手最不信任它，最没能力检查的新手反而最信任。

Anthropic 的实验：把调试外包出去的人，学得最少。52 名工程师学一个没人见过的库，靠 AI 调试的那组测验平均 50 分，动手那组 67 分，差距最大的恰恰在调试题上。但同一次实验里，要求 AI 讲清概念、解释代码的人，分数跟动手组一样高。同一把工具，习惯不同，结果天差地别——问「为什么」的人爬上去了，只说「修」的人陷下去了。

DORA：循环在团队层面长成「版本返工」。Google 的 DORA 研究估算，AI 采用率每上升 25%，交付稳定性下降 7.2%——稳定性在他们口径里，就是「一次发布引发多少计划外的返工」。这正是「修 A 坏 B」的团队版。DORA 2025 年报告里那句话值得贴在显示器上：AI 是放大器，放大你已有的优点，也放大你已有的毛病。

5 步逃生法：从循环里爬出来

逃生的核心只有一句：改变你在 agent 说「修好了」那个瞬间的动作。下面 5 步按顺序走，循环就断了。

第一步：三振出局，立刻回滚。连续 3 次修复失败，或者每次修复都带出新问题——停手，不准有「再试一次」。回滚到最后一个能跑的版本：git 回退也好，工具自带的 checkpoint 也行。记住这笔账：一次回滚永远比第六次修复便宜。三振的规则要在中午定好，因为在凌晨一点，你永远相信「下一杆就是中的那杆」。

第二步：冻结目标，写三句 mini-spec。回滚之后先别动代码。用两三句大白话写下「它应该是什么样」：点这个按钮应该发生什么、什么算对、什么算错。这三句话就是你的 spec——从此「修好」和「修坏」有了裁判标准，不再是 agent 说了算。你不需要会写代码也能写 spec，你需要的是把想要什么说清楚。

第三步：先问原因，再动手。把 spec 贴给 agent，第一句话不是「修」，而是「用两句话解释为什么会这样，先别改任何东西」。如果它的解释你听不懂、复述不出来，那它的修复你也看不懂——不许它动手。Anthropic 实验里分数最高的那批人，秘诀就是这个：每次都让 AI 先讲「为什么」。

第四步：读 diff，不读报错。接受改动之前，只看三件事：动了哪几个文件、删了什么、有没有碰你没让它碰的地方。你不需要逐行读懂代码，看 diff 的结构就够了——文件清单和增删行数会说话。凡是动了无关文件的修复，一律打回重来，这是 agent 在「随机试错」的铁证。

第五步：缩小复现，强制冷静期。先把 bug 缩到最小复现场景：删掉一切无关代码，只留能稳定触发问题的最小集合——场景越小，agent 乱改的空间越小。如果深夜卡住超过 30 分钟，直接睡觉。明早新开一个干净会话，把 mini-spec 贴进去重来。长对话会丢失早先的决定，agent 会反复推翻自己一小时前的修复——一个干净的开局，几乎永远胜过在烂摊子上打第七个补丁。

防患未然：3 个习惯让循环进不来

逃生是止损，不进循环才是本事。三个习惯，个个不花钱：

习惯一：把「你先解释」写进每条指令。以后每次让 agent 改代码，指令里固定带一句：「先说你打算怎么改，改完告诉我改了哪几个文件。」你不是在审查代码，你是在逼它把思路亮出来——思路一亮，胡说八道就藏不住了。

习惯二：每天留一个「能跑的版本」。收工前 commit 一次，或者打一个 checkpoint。存档点是逃生的地基：没有它，第一步的「回滚」就是一句空话。doomcoding 最惨的受害者，都是那些「想回滚却发现没地方可回」的人。

习惯三：一次只让 AI 干一件事。「顺手把登录也重构一下」这种指令，是循环的邀请函。任务越小，diff 越短，你越看得懂，agent 越不容易在改 A 的时候顺手弄坏 B。小步快走，慢就是快。

最后说一句：vibe coding 本身不是问题，工具也在越变越好。真正要戒掉的，是「接受你看不懂的东西」这个习惯。agent 负责打字，你负责阅读——顺序对了，速度和安全可以兼得；顺序反了，你就是在深夜给老虎机投币的人。别当那个人。