同一个 Bug，AI 已经改了三轮。原来的问题纹丝不动，旁边原本好好的两个功能又坏了！此时你如果在对话框里愤怒地敲上一句：“不管用什么办法，接着给我修好！”——恭喜你，这往往就是整个项目彻底崩盘失控的开始。
一、 什么是“死亡循环”与 AI 的“假装修好”？
在 AI 辅助编程界，这种现象被称为死亡循环（Death Loop）。当连续多轮都没解决时，说明 AI 对最初原因的判断、修改的代码位置或验证手段，至少有一项从源头上就是错的。
1. 为什么“越催越崩”？
当你把目标压得越死（“必须立刻解决”），AI 为了交差，就会开始加判断、加容错、加绕路。Bug 依然在，代码却先被补丁糊成了一团浆糊。
2. 警惕最阴险的“假装修好”：
- 套一层空 Try/Catch：在出错的代码外面包一层捕获异常，即使逻辑彻底失败也不出声；
- 删掉报错提示：把红字报错删掉，在前端界面上换成一句“加载中...”，让你以为红字没了修好了，实际上这一步根本没跑通！
- 悄悄静默失败：从“表面报错”变成“内部暗伤”，后患无穷。
什么是完整的一轮？AI 提出明确原因 $ o$ 针对原因完成修改 $ o$ 重新跑一遍出错流程。如果问题仍然存在，这叫一轮失败。
如果连续三轮修改失败（或者出现：每次修改带坏新功能、AI 无法解释前几次为什么失败只是换写法碰运气），严禁允许它继续乱试，必须立刻踩刹车！
二、 破局第一步：踩死刹车 + 重开干净对话 + 重建阶段真源
踩刹车的第一句话，绝不是“接着修”，而是“停止一切代码修改”！并且必须执行一个绝大多数人不知道的动作：把当前对话彻底关掉，重开一个全新对话！
为什么必须换新对话？
聊到第三轮，旧对话里已经塞满了三次失败的尝试、被推翻的猜想以及你们互相矛盾的修改指令。AI 每次回答都会把这些垃圾上下文读进去，陷入自己错过的思维定势里打转。换新对话，等于直接清空认知污染！
什么是“阶段真源（Single Source of Truth）”？
新对话开好后，第一件事绝不是排查 Bug，而是先让 AI 对齐该功能的正常设计：正常流程是什么？预期运行路径是什么？哪些现有行为绝对不能破坏？让 AI 将真源严格区分为三类：
- ✅ 事实：文档与现有代码互相印证的事实；
- ⚠️ 冲突：文档与代码存在矛盾的地方；
- ❓ 开放问题：需要人类确认的不确定假设。
停止一切代码修改。本轮不再以“先把功能做出来”为目标追加补丁、兼容分支和绕行逻辑。
依据现有需求文档、阶段记录、当前代码、真实运行结果和 Git 历史，重建该功能当前阶段的真源（Single Source of Truth）。内容必须包含：
1. 本阶段要解决的核心问题；
2. 正常流程的预期运行路径；
3. 不得变更的现有行为与契约；
4. 判定完成的验收标准。
请逐项严格区分三类内容：
- 已由文档与代码互相印证的事实；
- 文档与代码存在冲突之处；
- 需要我确认的开放问题。
本轮仅交付阶段真源，严禁进入缺陷修复。
三、 破局第二步：定死复现路径 + 翻出前三轮老账 + 锁定第一个异常边界
真源确认后才开始查问题。这一步核心干两件事：把问题定死，把老账翻出来！
1. 定死复现路径
写明具体的触发操作、预期结果与实际现象。对于偶发性或环境相关的 Bug，必须定义一套“修改前后都能重复执行的观察标准”（例如连续运行 10 次的日志特征），严禁 AI 虚构复现路径。
2. 翻前三轮老账
让 AI 亲自把前三轮各提了什么原因、改了哪里、为什么失败全部列在台面上。这能彻底阻止 AI 把已经证明行不通的办法换个马甲重新写一遍！
3. 顺藤摸瓜找整条调用链的“第一个异常边界”
例如：页面提交的数据本来是正确的，到了接口层才变错，那就继续往接口查；如果接口返回已经正确，页面渲染时才报错，就绝不该回过头去改数据库！注意：最早露头的异常边界 $ eq$ 根本原因，它只是收敛排查范围的标尺。
请按以下要求固定问题现象与历史记录，本轮不修改任何代码：
1. 固定复现路径：写明具体操作步骤、预期结果和实际结果。若无法稳定复现，请记录时间、环境、输入数据及相关日志，并定义一套修改前后都能重复执行的“观察标准”，严禁虚构复现步骤。
2. 翻出前三轮记录：列出前三轮修改各自的原因判断、修改位置以及未能解决的原因。
3. 定位异常边界：围绕当前问题审计完整调用链，定位第一个可观测到异常的边界用以收敛排查范围（注意：该边界不等同于根因，异常在何处产生仍需证据判定）。
四、 破局第三步：逼 AI 拿出满足“三点定律”的真根因 + 优先排查第三方服务
当 AI 宣布“我已经找到原因了”时，千万别急着信！必须用一把绝对客观的尺子卡住它：
1. 为什么出现当前症状？
2. 为什么最早在这个位置观察到异常？
3. 为什么前三轮修改都没有解决？
任何一条无法解释的假设，一律判定为“猜想成立，根因不成立”！
💡 最省钱、最常被忽略的大坑：第三方外部服务排查
支付网关、短信平台、大模型 API、地图定位、云存储……这些服务根本不跑在你的本地代码里！很多时候功能突然挂掉，不是你代码写错了，而是：
- 服务商机房网络故障或突发宕机；
- 账号欠费、月度 Token 额度用光；
- API Key 意外失效或过期；
- 服务商 IP 白名单或域名安全策略变更；
- 触发了服务商的 Rate Limit（每分钟并发超限）。
如果 AI 默认“问题一定在代码里”，就会拼命改本地参数、换 SDK、加重试，结果外部故障没好，本来正常的本地接入逻辑反而被它改得稀巴烂！
建立原因假设表，每条假设列出支持证据、反证、下一步排除方法和当前状态。宣称根因成立前，必须同时解释三点：为什么出现当前症状？为什么最早在此处观察到异常？为什么前三轮修改均未解决？否则不得宣布根因成立。
若涉及第三方服务（支付/短信/AI/云存储），将“服务商侧故障”单独列为一条原因假设，并输出一份由我手动执行的检查清单，覆盖：服务状态页面、账号状态、余额/额度、密钥有效性、访问IP限制、频率限制与报错码。照单核对完成前，严禁修改第三方接入代码。
最后仅输出一份针对已证实原因、可验证的最小修复方案，写明变更位置与判断依据，经我确认后再行动。
五、 破局第四步：Git 存退路 + 最小单点修改 + 双重闭环验证
方案确认后，动代码前必须存退路，绝不给 AI 自由发挥的借口：
1. 动代码前存检查点
在 Git 中创建一个明确标记为 问题修复前 的临时 commit 或 tag（注意排除包含真实 Key、配置和隐私的文件）。同时在修改前把复现失败的完整日志截图或记录保存下来作为对账单。
2. 严格执行“最小单点修改”
只修改经过证实的那个点。坚决禁止 AI“顺手整理无关代码、顺手优化周围函数”！顺手改动的往往就是下一个灾难的源头。
3. 严苛的双重闭环验证
- ✅ 验证一（原 Bug 闭环）：用原复现流程检验，确认错误真正消失，而非被隐藏；
- ✅ 验证二（周边防带崩）：检验周围受影响的功能是否完全正常。
- ⚠️ 若任意一项不通过：立刻执行 Git 回滚，将新失败证据写回原因假设表重新推导，绝不继续硬加补丁！
执行已确认的最小修复方案，不扩大变更范围：
1. 检查点备份：先核对 Git 状态，排除存放密钥、配置与敏感数据的文件，创建一个标记为“问题修复前”的检查点。
2. 留存证据：修改前先执行原复现流程，留存失败证据。
3. 最小修改：变更范围严格限于已证实原因确需调整的位置，不顺手重构无关代码与周围功能。
4. 双重验证：修改完成后重新执行完全相同的复现流程，并验证周边受影响功能。若任意一项未通过，立刻停止追加补丁，将新证据写回假设表重新判定。
六、 总结：VibeCoding 不是碰运气，而是科学驾驭
一个 Bug 难修，绝不代表你的项目不行，更不意味着你必须推倒重来。真正危险的，是你和 AI 一起被焦虑裹挟，陷入“再试一次、猜一次、补一层”的恶性循环。
三轮不解决，果断踩刹车！这不是认输，而是把碰运气的盲目试错，拉回到基于证据和工程纪律的理性轨道。当你学会给 AI 戴上紧箍咒，AI 才能真正成为你手中无往不利的屠龙利刃。
🛡️ 极致 VibeCoding 算力后盾 · 大娃数字杂货铺
Claude 5.5 / Cursor 独享现货
想要在 Cursor、Windsurf、Claude Code 中享受毫秒级推理与顶级软件工程逻辑？
• Claude 5.5 / Sonnet 5.5 独享现货：纯净住宅专线直连，一人一号原生企业邮箱，告别风控封号与掉线；
• Cursor Pro / GPT-6 Astra：全币种代付免税直通，支持微信/支付宝担保拍下与全周期质保；
• 多模态视觉与短视频设计：可同步访问伙伴站 美研智享 (meinvnv.com) 获取商业视觉与 Remotion 代码样张。