多次修改后仍然出错
建立能捕获准确故障的反馈命令，替代反复猜测。
Diagnosing Bugs by Matt Pocock
使用 Matt Pocock 的 Diagnosing Bugs，通过可重复的反馈循环调查故障和性能回退。先复现准确症状、缩小场景，再比较可检验解释，并用最小案例与原始用户流程共同验证范围明确的修复。
安装与快速上手
选择你使用的 Agent，查看对应的安装或使用方式。在 Floatboat 中，可复制请求让 Agent 读取原始说明；其他选项会显示该 Skill 的安装命令或发布者提供的原生步骤。
选择 Agent
在 Floatboat 中开始
复制请求，粘贴到 Floatboat 对话
请阅读 https://github.com/mattpocock/skills/blob/main/skills/engineering/diagnosing-bugs/SKILL.md 中的 Diagnosing Bugs 原始说明，介绍它的用途、所需工具和安装方式，再协助我使用。由 Agent 读取原始说明，再确认当前环境的使用方式。
下载 Floatboat ↗试试这样提问
用 Diagnosing Bugs 调查重复 webhook 问题，先建立能检测重复扣款的反馈信号，再调查原因并在修复后验证原始场景。
关于 Diagnosing Bugs
Diagnosing Bugs 是 Matt Pocock 工程集合中的调试方法，首先投入精力建立针对真实故障、快速可重复的通过或失败信号，再形成原因假设。这个信号可以来自测试、HTTP 请求、CLI 样例、浏览器脚本或适当的临时环境。随后流程缩小复现场景，排列可被证伪的解释，添加有针对性的探针，并验证修复。在存在合适测试边界时，复现案例会转为回归测试；最后清理临时诊断代码，并重新运行原始场景。有效使用仍需访问出现问题的环境，展示日志与捕获资料前也应先移除敏感值。
复杂缺陷诊断的使用场景
探索反复出现的缺陷、原因不清的失败，或变更后的性能下降。围绕具体症状建立证据，再使用同一反馈循环比较原因假设，避免把一次命令成功误当作用户问题已解决。
问题间歇出现
先通过受控循环提高复现率，再选择原因解释。
发布后性能下降
建立可比较的计时基线，依据测量调查变化。
如何调查复杂缺陷
提供实际与预期行为、环境和复现输入。先建立可靠失败信号并缩小案例，再通过针对性诊断比较原因假设。实施范围明确的修复后，重跑原始流程并清理临时探针，再确认任务完成。
- 01
建立失败信号
说明准确症状并运行能检测它的命令，仅保留必要且已脱敏的诊断证据。
- 02
缩小案例并检验解释
在保留失败的前提下缩减输入，再用每次只改变一个变量的探针比较假设。
- 03
修复、验证并清理
在合适边界测试修复并重跑原始场景，清理诊断代码并记录有证据支持的原因。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
Diagnosing Bugs 常见问题
为什么先建立反馈循环再推测代码原因？
循环先确认真实症状可重复检测。没有它，看似合理的代码解释难以证伪，也难验证修复。
反馈信号必须是单元测试吗？
不必。原文还列出 HTTP 脚本、CLI 样例、浏览器检查、追踪重放等方式，应选择能触达真实故障的信号。
间歇故障怎么办？
通过受控重复触发提高复现率，并控制相关时序或随机性。应说明观察到的概率，不能把单次通过视为确定结论。
无法建立复现信号时怎么办？
原始流程会暂停诊断并说明缺失的访问或证据，再请求适当环境、脱敏资料或另行授权的诊断设置。
什么时候添加回归测试？
能通过真实测试边界触发故障模式时，应在修复前加测试；缺少合适边界时应记录架构限制，不写误导性测试。
完成报告应包含什么？
包含有证据支持的原因、原始复现结果、适用的回归验证，以及临时探针清理情况，并避免证据暴露密钥值。