让 AI 修对 Bug，先拆开调试步骤

AI 修 Bug 最让人头疼的，是补丁看起来合理，错误却不断换地方，几轮下来连问题起因都说不清。作者认为，直接要求「修好它」，会把复现、定位、解释原因和检查影响混在一起，模型容易跳过证据，先猜一个补丁。

他的建议是把调试拆成四个阶段，每次只索取当前阶段的答案。这套方法值得借鉴，但原文没有对照实验，后半段也带有他们团队的产品推广，需要分开看。

先证明问题存在，再让 AI 缩小范围

第一阶段要的是复现步骤，而不是原因分析。

作者要求模型从干净状态出发，给出最短操作路径，并为每一步说明：有 Bug 时会看到什么，没有 Bug 时又会看到什么。如果缺少版本、环境、输入数据，就先列问题，不能自行补齐条件。

这一步的价值，是把模糊描述变成可核对的现象。比如「偶尔提交失败」还不足以支撑修改；输入是什么、从什么状态开始、失败的判断标准是什么，都得先明确。否则，模型可能在一个猜出来的环境里解决另一个问题。

确认能够复现之后，才进入定位。下面这段提示词要求模型设计排查顺序，并明确禁止提前修复：

The bug reproduces with the steps below. Here is the code I think
is involved.

Suggest a sequence of checks that halves the search space each
time: what to comment out, log, or hard-code, and in what order.
For each check, say what result would rule a part in or out.

Don't propose a fix yet.

最关键的是最后一行 Don't propose a fix yet.。它把回答限制在「下一步查什么」，避免模型看到可疑代码就直接改动。

每项检查还必须说明，什么结果能排除或保留某个范围。注释代码、加日志、临时写死值，都只是手段；真正有用的是检查结果能否让候选原因变少。

修复之前，要能解释哪个假设失效了

找到出问题的代码，不等于知道它为什么出错。

作者第三阶段的提示词，要求把排查结果转成一条完整的因果解释：

Here is the code where the bug lives, and what I found while
isolating it.

Explain the cause in plain language: what the code assumes, where
that assumption breaks, and why it only shows up under these
conditions. Then give one sentence I could use in a code comment.

要关注的是 what the code assumes：代码默认什么条件成立，这个条件在哪里被打破，又为什么只在特定情况下暴露。

例如，代码可能默认某个值一定存在。解释不能停在「访问了空值」，还得说明这个值为什么会缺失，以及哪些输入会走到这里。作者还要求生成一句可用于代码注释的说明，让这条约束能够留下来。

解释必须经得起定位阶段观察结果的检验。

如果解释无法覆盖已经看到的现象，就还没有完成诊断。语言通顺不代表因果成立。

第四阶段放在修复之后：把修复方案和原因交给模型，让它寻找其他可能依赖同一错误假设的代码，并逐项给出会触发问题的输入或条件。这里同样有限制：不要重写代码，只指出该去哪里检查。

这样，排查对象就从一处报错扩展到了共享的错误前提。

我的判断

我赞同这套方法对回答范围的约束。复现步骤、排除依据、因果解释，都是可以被人核对的产物，比一句「已经修好」更容易评估。

但作者所说的「模型通常不是问题」，原文没有提供证据。拆分任务可以减少跳步，仍然无法保证模型理解了代码，也无法补上它没有拿到的运行信息。

「每次把搜索范围减半」也更适合作为排查目标。真实问题可能涉及异步时序、共享状态或多个条件叠加，未必能整齐二分。强求减半，可能让模型给出看似规整、实际无效的检查。

还有一个缺口：开头提到了检查修复是否影响邻近代码，最后提供的却主要是同类风险扫描。**指出哪里可能出错，不能替代实际执行验证。**原文没有给出完整的修复验证流程。

后半段推荐的 PromptAlo 是作者团队的 Chrome 扩展，原文称它能通过 AI 标签管理提示词，并一键发送到 ChatGPT、Claude 或 Gemini。保存模板确实能降低重复使用的成本，但文章没有提供效率对比；普通文档或团队仓库也可以承载这些提示词，没有必要把方法和产品绑定。

能拿来做什么

• 遇到前端或 Node 报错时，先整理版本、环境、输入和干净状态下的操作步骤，让 AI 明确区分已知事实与待补信息。
• 定位时要求 AI 给出有顺序的检查方案，每项都写清排除条件，并加上 Don't propose a fix yet.，执行检查后再反馈结果。
• 接受补丁之前，要求模型说明代码依赖的假设，并用实际观察核对解释；修复后再检查其他依赖同一假设的位置。
• 把四阶段提示词保存到随手可取的位置，每次只提供当前阶段需要的材料，避免下一次又从一句「帮我修好」开始。