Appearance
diagnose 技能把“修 bug”拆成可验证流程：先建立能反复运行的反馈回路，再复现问题、缩小范围、提出可证伪假设、按假设插桩，最后修复并补回归验证。它最反对的是 AI 看一眼错误就开始猜。
AI 修 bug 前为什么要先建立反馈回路：Diagnose 技能怎么用
AI 修 bug 最危险的动作，是看到错误消息以后立刻改代码。
有时它猜对了。
更多时候，它只是把问题从一个地方挪到另一个地方。
diagnose 这个技能要求先建立反馈回路。没有稳定信号，就不要进入修复。
什么叫反馈回路
反馈回路就是一个能告诉你“问题还在不在”的检查方法。
可以是：
- 一条失败测试。
- 一个 curl 请求。
- 一个 CLI fixture。
- 一个 Playwright 脚本。
- 一段可重放的请求或日志。
- 一个最小复现 harness。
关键不是形式，而是它能反复运行，结果清楚，速度足够快。
如果每次都要人手动点十分钟页面，AI 很难稳定调试。
复现比假设更早
很多 AI 会先列原因：可能是缓存，可能是依赖，可能是状态没更新。
diagnose 要求先复现。
复现要确认三件事：
- 触发的是用户描述的那个问题，不是旁边另一个错误。
- 多跑几次仍然能看到相同现象。
- 已经记录了错误输出、请求、输入或时间数据。
复现失败时，不要装作可以修。应该明确说缺什么信息。
假设必须能被推翻
建立反馈回路后，AI 可以提出假设。
但假设必须可证伪。
不好的假设是：“可能是状态问题。”
更好的假设是：“如果问题来自前端状态重复追加，那么刷新页面后重复数据会消失；如果来自接口返回，刷新后仍然重复。”
这种假设能指导下一步插桩和验证。
插桩不要变成到处 console.log
diagnose 里的插桩是为了区分假设，不是把所有东西都打出来。
每个日志或探针都应该回答一个问题：这个假设成立吗？
如果确实要加临时日志，最好打唯一标记，修完后能一次性搜索删除。
性能问题更不适合乱打日志。应该先建立基线，再做对比和二分。
修完后要回到原始反馈回路
修复不是最后一步。
修完以后要做三件事：
- 新增或保留能防回归的测试。
- 重新跑最初复现问题的反馈回路。
- 删除临时插桩和调试脚本。
如果没有合适的测试 seam，也要写清楚。这本身就是架构问题，后面可以交给 Improve Codebase Architecture。
你可能还需要
同类技能：
遇到真实 bug 时，先问 AI：你的反馈回路是什么？如果没有，先别让它改代码。