同一个 bug，AI 修了三轮。
第一轮，没好。
第二轮，换了个地方坏。
第三轮，它信心满满地宣布“已修复”，你点开页面一看还是错的。
只要用过 AI 编程助手，这个场景你一定不陌生。
多数人的本能反应，是给出更具体的指令：现象描述得更精确，期望结果说得更清楚，甚至直接告诉它改哪个文件、哪个属性。
但这条路往往越走越窄。指令越具体，AI 的修补越局部，问题却在原地打转。
真正打破死循环的，不是更用力的指挥，而是换一种提问方式。同一个 AI，同一个问题，前三轮屡修屡败；换了三句话之后，一次通过。
今天把这三句话完整写出来，你可以直接抄。
真实案例：一个动画修了三轮都没修好
起因是遇到一个界面交互动画的问题：一个双栏布局中，右侧边栏的关闭动画是正常的，但打开动画始终不对——主内容区会出现突兀的弹跳，而侧边栏则像是直接“闪现”出来的，毫无过渡可言。
接下来的三轮修复，堪称 AI 调试的经典失败样本。
第一轮，直接描述问题。AI 调整动画时长和缓动，验证后宣布修复，实际效果：关闭顺了，打开依然错。
第二轮，更精确地说“打开时不对”。AI 做了逐帧分析，连试四五种布局方案，每种都有详尽推理，但每种都在真实浏览器里暴露新问题。
第三轮，纠正“动画方向反了”。AI 打上补丁，表面上数据好看了，视觉体验依然不对。
三轮下来，上下文越堆越多，根因始终没被触及。
转折：不再告诉它怎么修，而是让它先“复盘”
打破死循环的做法，是把调试过程拆成界限分明的三步：
第一步：复盘——让它把现状摊开，而不是立刻动手
不给任何修复指令，只问一句：
关键是让 AI 把两边的实现完整并列地摆出来：正常一侧怎么写的，异常一侧怎么写的，共享什么状态，差异在哪。
就像事故复盘前先把所有材料铺在桌上——信息一旦并列，差异自己就会说话。
第二步：思考——只准诊断，不准改代码
紧接着只有一句：
注意：明确不让它改任何代码。 目的是把 AI 从“执行模式”强行切换到“诊断模式”，基于摊开的全部信息给出根因判断。
真正的突破就发生在这一步。AI 指出了一个三轮优化都没触及到的问题：技术上动画一直在执行，但实际的感知顺序是错的——先看到主内容区收缩，后看到侧边栏出现，所以无论怎么调节局部参数，视觉上都像“闪现”。
问题从来不在动画属性，而在整个动画的结构设计。
第三步：授权——确认方向后，再让它动手
诊断清楚了，最后才是那句：
这一次，AI 推翻了此前所有补丁思路，重构了动画结构：不再让两个区域各自为政，而是把运动收敛到一条共享边界上。一次到位，问题终结。
为什么这三步有效
这套改进方法背后，是对 AI 编程助手工作方式的三个判断：
- 反复修不好，说明问题不在执行力，而在上下文。AI 缺的不是修复能力，是全局视野，视野里只有“当前报错”，就只能产出局部补丁。复盘的作用，是强制把全局信息注入上下文。
- 越具体的指令，越容易在错误的诊断上叠加补丁。你告诉 AI“改哪里、怎么改”，等于替它做了诊断——诊断若错，它只会把错误执行得更精确。
- “只思考不动手”是一道必要的闸门。AI 默认以“产出修改”为目标，诊断不充分就急于动手。把“思考”和“执行”拆成两条指令，等于设了一个检查点：诊断先过你的检验，执行再跟上。
什么时候用这套方法？
先说什么时候该用这三步修复法：
- AI 在同一个问题上已经失败两次以上，而且你能感觉到，它的修补越来越局部、越来越跑偏。
- 这是“上下文不足”的典型信号。出现这个信号，就别再下修复指令了，走这三步。
再说什么时候别用：
- 需求本身没说清——先补需求，而不是补上下文；
- 全新功能开发——没有“现状”，就无从复盘；
- 一次就能修好的小问题——直接修就行，不值得走完整流程。
一句话记住：这套方法治的是“反复修不好”的问题，不是包治百病。
可以直接复用的提问模板
这整个方法可以浓缩为三句话，需按顺序使用：
- 复盘：“说说【正常部分】和【异常部分】的代码分别是怎么实现的。”（只要描述，不要修改）
- 思考：“想想【异常部分】的问题出在哪里。”（明确暂不修改代码）
- 授权：“好，开始修复。”（确认诊断方向之后再发出）
AI 编程时代，调试能力的一部分已经从“读代码”转移到了“调度 AI”。当 AI 反复修不好一个问题时，人最该做的不是更用力地指挥它，而是退一步，把节奏拆成三步。
指挥得越具体，它越像一个补丁机器；节奏给得越清楚，它才越像一个调试搭档。