多次修改后仍然出错
连续多次修改仍未解决问题时，保留可观察症状，建立能够直接捕获它的反馈命令。用可重复的信号检查既有修补，替代下一轮猜测。诊断和最终修复都通过同一命令验证，确保处理的是最初报告的故障。
Diagnosing Bugs by Matt Pocock
使用 Matt Pocock 的 Diagnosing Bugs，通过可重复的反馈循环调查故障和性能回退。先复现准确症状、缩小场景，再比较可检验解释，并用最小案例与原始用户流程共同验证范围明确的修复。
修复前先建立能检测故障的信号
提供实际与预期行为、环境和失败输入，让调查围绕可重复信号及不同原因展开。请求中的修复必须回到原流程核对，不能以另一次无关的成功运行代替对最初问题的验证。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: Diagnosing Bugs https://github.com/mattpocock/skills/blob/main/skills/engineering/diagnosing-bugs/SKILL.md 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 用 Diagnosing Bugs 调查重复 webhook 问题，先建立能检测重复扣款的反馈信号，再调查原因并在修复后验证原始场景。 期望交付: 可重复的故障信号、有证据的原因判断，以及原始场景的验证。
关于 Diagnosing Bugs
Diagnosing Bugs 是 Matt Pocock 工程集合中的调试方法，首先投入精力建立针对真实故障、快速可重复的通过或失败信号，再形成原因假设。这个信号可以来自测试、HTTP 请求、CLI 样例、浏览器脚本或适当的临时环境。随后流程缩小复现场景，排列可被证伪的解释，添加有针对性的探针，并验证修复。在存在合适测试边界时，复现案例会转为回归测试；最后清理临时诊断代码，并重新运行原始场景。有效使用仍需访问出现问题的环境，展示日志与捕获资料前也应先移除敏感值。
Diagnosing Bugs Skill的使用场景
持续故障、间歇失败和版本变慢需要不同的反馈信号。了解 Diagnosing Bugs 如何让症状可测量、增加有效复现证据，并用原始输入或工作负载核对修复。
问题间歇出现
间歇性故障需要先增加可用证据，再决定原因。复现报告中的环境，通过受控循环提高出现概率并保留失败样本。说明哪些条件与故障相关、哪些不确定性仍然存在，避免把一次成功运行当作问题已经修复。
发布后性能下降
版本发布后变慢时，使用相同工作负载和计时方法比较前后表现。建立可比基线，定位性能回退，再用原始负载复测拟议修复。保持测量条件一致，才能区分真实改进、环境波动和测试方式变化。
解释只在特定环境出现的故障
相同输入可能在本机成功，却在另一套配置下失败。记录相关版本、设置和可观察差异，通过受控对照复现问题。修改应用逻辑前先验证环境原因，并在两种条件下复测，避免修好一个环境的同时，只是把故障转移到另一个地方。
如何调查复杂缺陷
可靠失败信号能让不同原因有可比较的依据。提供环境和复现输入，缩小案例后检验假设，再用原流程确认局部修复；调查结束时还需清理不再需要的临时探针。
建立失败信号
说明准确症状并运行能检测它的命令，仅保留必要且已脱敏的诊断证据。
缩小案例并检验解释
在保留失败的前提下缩减输入，再用每次只改变一个变量的探针比较假设。
修复、验证并清理
在合适边界测试修复并重跑原始场景，清理诊断代码并记录有证据支持的原因。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
Diagnosing Bugs 常见问题
为什么先建立反馈循环再推测代码原因？
循环先确认真实症状可重复检测。没有它，看似合理的代码解释难以证伪，也难验证修复。
反馈信号必须是单元测试吗？
不必。原文还列出 HTTP 脚本、CLI 样例、浏览器检查、追踪重放等方式，应选择能触达真实故障的信号。
间歇故障怎么办？
通过受控重复触发提高复现率，并控制相关时序或随机性。应说明观察到的概率，不能把单次通过视为确定结论。
无法建立复现信号时怎么办？
原始流程会暂停诊断并说明缺失的访问或证据，再请求适当环境、脱敏资料或另行授权的诊断设置。
什么时候添加回归测试？
能通过真实测试边界触发故障模式时，应在修复前加测试；缺少合适边界时应记录架构限制，不写误导性测试。
完成报告应包含什么？
包含有证据支持的原因、原始复现结果、适用的回归验证，以及临时探针清理情况，并避免证据暴露密钥值。