Appearance
第 12 篇｜打破死循环：AI 越改越烂、修一个出三个 Bug 的救赎法
导读：
几乎每个用 AI 做项目的人，都有过在深夜对着屏幕砸键盘的经历：
本来只是一个无关紧要的小按钮对齐问题，AI 帮修了一下，导致数据拉不出来了；
你让它修数据，它把页面搞白屏了；你让它修白屏，控制台瞬间炸开 10 行刺眼的红字……
AI 在窗口里一次次卑躬屈膝地道歉：“对不起，是我粗心了，这次一定能跑通！”
结果呢？越改越烂，修一个冒三个，原本半小时能做完的功能，折腾了整整 4 个小时，连项目都起不来了。
这一篇，我们为你揭开 AI “走火入魔”的底层机制，并交给你一套雷霆手段：绝境救赎三板斧，专治一切 Bug 死循环。
一、 真实的“鬼打墙”惨案：沉没成本陷阱
我们先来还原这个让无数人破防的经典心理陷阱：
第 1 轮：界面有个小错 ──► AI 改了一版，引入了新的小 Warning
第 2 轮：你让它修 Warning ──► AI 动了核心文件，导致某个功能失灵
第 3 轮：你急了：“怎么坏了？” ──► AI 慌忙道歉，自作主张删了你的配置
第 5 轮：控制台满屏暴红 ──► 你心想：“我都聊了 5 轮了，再试一次也许就好了吧？”
第 8 轮：代码结构彻底解体 ──► 整个项目编译失败，昨天的努力全打水漂。很多人在第 5 轮的时候，其实已经感觉到不对劲了。但因为前面投入了大量精力，舍不得放弃当前的对话，总觉得“下一次它就能改对”。
这是典型的沉没成本心理。在 AI 原生开发中，这种犹豫是致命的。
当 AI 在同一个问题上连续翻车两次以上，它就已经不是你的智能助手了，它是一只咬住自己尾巴疯狂打转的狂犬。
二、 根因剖析：为什么 AI 会像“喝了假酒”一样越陷越深？
很多人以为是模型“智商不够”，其实根本原因出在大模型的注意力机制与上下文污染：
- 上下文严重中毒（Context Poisoning）：
回顾我们在第 02 篇学到的原理：AI 是根据“桌面上已有的字”来猜下一个字的。当会话里充斥着三轮以上失败的代码尝试、大段晦涩的红字报错时，这些错误信息已经成为了上下文的主流。AI 的注意力（Attention）被大量的垃圾数据彻底带偏，它会把之前写错的废代码当成既成事实，在错误的基础上继续加盖违章建筑。 - 思维定势与概率坍缩（Tunnel Vision）：
模型一旦在第 2 轮走入了一条死胡同（比如引入了一个错误的第三方库），在接下来的对话中，它几乎不可能主动推翻自己，只会竭尽全力在死胡同里撞墙，不断打补丁来掩盖前一个补丁的错误。
三、 终极救赎三板斧：绝境断头术
当你发现 AI 已经连续两次“修东墙补西墙”时，立刻停下手头的一切操作！
收起你的侥幸心理，严格执行以下三板斧：
第一斧：【时光倒流】 ──► 利用版本控制，立刻回滚到最后一次健康基线
第二斧：【物理失忆】 ──► 彻底关闭当前会话，新建一个干干净净的窗口
第三斧：【换裁判破局】──► 切换成另一个高推理模型，只审视最小故障切片第一斧：时光倒流（强制回滚，止损第一）
- 操作：打开代码管理面板，或者直接在终端/可视化工具里，一键撤销（Discard）最近半小时内由 AI 产生的所有改动，退回到上次能跑通的 Git 存档点（Commit）。
- 心智建设：一个跑得通的健康旧代码，价值远大于被 AI 补得千疮百孔的垃圾堆。 宁愿退回 15 分钟前的状态，也绝对不要在被污染的代码基线里继续挣扎。
第二斧：物理断舍离（Clear Context，开新局）
- 操作：直接按快捷键清空上下文（Clear Context），或者新开一个干净的对话会话（New Session）。
- 投喂姿势：不要把刚才那长达 8 轮的争吵历史粘过去！只从你的健康项目里，精准提取两样东西：
- 相关的单个源文件；
- 第一次触发报错时的那唯一一行核心错误日志。
- 为什么有效：新 AI 面对的是一张干净如雪的桌子，它的注意力没有被任何历史垃圾干扰，能以最敏锐的直觉重新看盘。
第三斧：换裁判破局（Model Swap，神仙审题）
如果把上下文清干净后，同一个模型依然解不开这个结，说明该任务触碰到了该模型架构的思维盲区。
- 操作：换一个完全不同血统的模型来当“特约顾问”！
- 如果原本是 Claude 陷进去了，立刻把这段受阻的代码和报错丢给 DeepSeek 或者 GPT；
- 破局 Prompt 模版：
“脱离所有上文。我当前遇到了一个极其顽固的代码死结：
这是我的源文件代码：[代码片段]
在运行某操作时，系统抛出此报错：[单行错误]
之前的模型陷入了死循环，不断通过乱加配置来掩盖问题。
现在严禁重写整个文件，严禁引入新依赖！
请运用第一性原理，用最尖锐的目光帮我找出最底层的‘单点逻辑病因’，告诉我哪一行写反了或漏了什么判断。”
新模型没有单一模型的历史偏见，更没有陷入定势思维。多数情况下，换一个强推理模型来看，往往能一眼看穿真相：“原因很简单，第 18 行的异步函数忘记写 await 了。”
四、 架构师的工作纪律：“三次断火机制”
为了彻底杜绝未来再次被拖入死循环，请在你的工作流中固化这套“三次断火法则（Three-Strike Rule）”：
┌──────────────────────────────────────┐
│ 遇到 Bug，启动 AI 排查 │
└──────────────────┬───────────────────┘
│
▼
【第一次修复失败】 ➔ 提供更精确的日志与复现步骤
│
▼
【第二次修复失败】 ➔ 停下！警惕进入死循环泥潭
│
▼
【第三次依然报错】 ➔ 🚨 触发紧急熔断！
├─ 1. Git 一键回滚撤销代码
├─ 2. 彻底掐死会话，清空上下文
└─ 3. 换一个模型重新单独诊断只要遵循这套纪律，恶性 Bug 就很难把你长时间困在原地。
懂得什么时候“喊停”，是一个总指挥最硬核的成熟标志。
📝 结语与本篇自查
- 当 AI 连续两轮修 Bug 导致控制台冒出了更多新报错时，最危险的做法是什么？
(在当前充满污染报错的长对话里继续求它改，陷入沉没成本陷阱，最终让代码全面崩溃。) - 为什么新建会话并只喂入“核心代码 + 原始单行报错”，往往能秒杀困扰很久的 Bug？
(消除了长对话中大量的失败尝试和垃圾上下文干扰，让 AI 摆脱注意力中毒，重新用清晰的直觉推理。) - “三次断火法则”的核心意义是什么？
(建立止损纪律，在死循环形成的最早期通过回滚和模型对撞强制破局，防止小错误演变成毁灭性工程灾难。)
下一篇预告：
前面我们聊了很多关于如何约束 AI、如何编写 Harness 与 Skills 的内功。
但你有没有想过：如果 AI 能像乐高积木一样，随意插拔现实世界的一切工具呢？
想看数据库？插上插头；想读 GitHub Issue？插上插头；想让 AI 自己开浏览器点点看有无 Bug？再插一个插头！
这个让当今科技界彻底疯狂的“万能通用接口”，就是 MCP（模型上下文协议）。
在下一篇《第 13 篇｜MCP（模型上下文协议）：如何让 AI 插上万能插头？》中，我们将带你亲手玩转这套 AI 时代的“Type-C 宇宙”！