Appearance
Debugging 技能解决的是 AI 遇到报错后凭经验乱改的问题。它要求先停止新增功能，保留错误输出和复现步骤，再按复现、定位、缩小、修根因、防复发的顺序处理。
AI 修 bug 老是靠猜怎么办：Debugging 技能怎么用
下载 debugging-and-error-recovery 中文版 Skill ZIP
构建失败了，AI 说可能是依赖问题。
测试挂了，AI 说可能是 mock 没配好。
页面白屏了，AI 说可能是状态为空。
这些话听起来都合理，但合理不等于正确。
debugging-and-error-recovery 这个技能最重要的规则是：出错后先停线。不要继续加功能，不要连续试十个猜测。先保留证据，再找根因。
出错时先停下来
很多 AI 修 bug 会变成这样：
- 改一处。
- 报另一个错。
- 再改一处。
- 引入第三个错。
- 忘了最初要修什么。
这时你要打断它：
md
先停止新增改动。
请保留当前错误输出，说明能否稳定复现。
不要继续猜测修复，先定位根因。这一步看似慢，其实是在防止错误叠加。
调试顺序：复现、定位、缩小、修根因
一个稳的调试流程通常是这样：
- 复现：能不能稳定触发问题？
- 定位：问题发生在哪一层？前端、后端、数据库、构建工具，还是测试本身？
- 缩小：能不能做一个最小失败例子？
- 修根因：修真正原因，不只盖住表面症状。
- 防复发：补测试、补日志，或者补验证步骤。
AI 最容易跳过的是复现和缩小。
它看到错误消息就想改代码。可有些错误消息只是结果，不是原因。
根因和症状不要混在一起
比如用户列表出现重复数据。
症状修复可能是：前端展示前去重。
根因修复可能是：后端 JOIN 写错，查询返回了重复行。
如果你让 AI 只看前端，它很可能写一个去重函数。页面看起来好了，但接口仍然返回脏数据，其他页面继续出问题。
给 AI 的要求应该是：
md
不要只修显示层症状。
请说明重复数据是从哪里产生的：前端状态、接口响应、数据库查询，还是测试数据。
定位到来源后再修。不能复现怎么办
有些 bug 很讨厌：偶发、只在线上出现、只在某个环境出现。
不能复现时，不要装作已经修了。
可以做几件事：
- 收集环境信息：浏览器、系统、Node 版本、数据状态。
- 加临时日志：只记录定位需要的信息，不记录敏感数据。
- 缩小范围：找最近变动、相关接口、相同错误签名。
- 建监控点：等它再次出现时能拿到更多证据。
如果只是猜了一个修复，应该明确标记为“降低风险”，不能说问题已经根治。
修完后要留下防线
一个 bug 修完后，最好的结果不是“这次好了”。
而是以后它再出现时，测试会失败，监控会报警，或者日志能看出问题。
纯逻辑 bug 适合补回归测试。
环境、构建、外部服务问题适合补检查脚本或排障说明。
线上偶发问题适合补有边界的日志和监控。
AI 修 bug 的质量，往往不在那几行代码，而在有没有防复发证据。
给 AI 的 Debugging Prompt
可以直接这样写：
md
我们按调试流程处理这个问题。
错误现象：
[贴完整错误或复现步骤]
要求：
1. 先确认是否能稳定复现。
2. 定位问题发生在哪一层。
3. 缩小到最小失败例子。
4. 修根因，不要只修表面症状。
5. 修完后给出验证方式和防复发措施。
在定位完成前，不要连续尝试多个猜测性改动。这段话的关键是限制 AI 乱试。
你可能还需要
同类技能：
如果现在已经有真实报错，先把错误输出和复现步骤交给 AI，再让它按流程定位。