13. diagnosing-bugs 技能

快速开始

npx skills add mattpocock/skills --skill=diagnosing-bugs

npx skills update diagnosing-bugs

源代码

功能说明

diagnosing-bugs 针对棘手的 bug 和性能回归问题运行一套严谨的诊断循环——构建复现用例、最小化它、对假设进行排序、埋点检测，然后用回归测试进行修复。

在拥有紧反馈循环之前，它拒绝提出任何假设——一条可运行的命令，能够针对这个 bug 已经显示为红色（失败）。在存在这样的命令之前，通过阅读代码来构建理论正是这个技能所要防止的错误行为。没有能显示红色的循环，就没有诊断。

何时使用

输入 /diagnosing-bugs，或者当任务匹配时智能体会自动调用它——当你输入"诊断"/"调试这个"时，或者当你报告某些东西坏了、抛异常、失败或变慢时，它会触发。

在疑难问题上使用它：看一眼无法解决的 bug、间歇性不稳定的 flaky test、在两个已知正常状态之间悄悄混入的回归问题。如果是快速的临时性验证，用于检查设计问题而不是追踪缺陷，请改用 prototype。

紧循环就是技能本身

其他一切——二分定位、假设检验、埋点——一旦你有了信号，就变成了机械性的工作。因此这个技能在阶段一投入了不成比例的精力：构建一个通过/失败的命令，驱动实际的 bug 代码路径并断言用户报告的确切症状，然后收紧它，直到它快速、确定性、可被智能体运行。一个 30 秒的不稳定循环几乎不比没有好多少；一个 2 秒的确定性循环则是调试的超级能力。

它为你提供了一组构建该循环的方法阶梯——失败的测试、curl 脚本、CLI 差异、无头浏览器、回放追踪、一次性测试工具、模糊测试循环、git bisect run、差分运行——并且，仅作为最后手段，一个人在回路中的 bash 脚本。对于非确定性的 bug，目标不是干净的复现，而是更高的复现率：循环触发、并行化、增加压力，直到 flaky 问题变得可调试。

成功的标志

• 它在提出理论之前就构建并运行了一个复现命令——并贴出了调用命令及其红色输出。

• 该循环断言的是你实际报告的症状，而不是某个相近的失败。

• 假设以一份排序的、可证伪的列表形式呈现给你，然后才进行任何测试。

• 调试埋点被标记（[DEBUG-...]），并在它宣布完成之前被 grep 移除。

在整个流程中的位置

diagnosing-bugs 是一个随时可调用的独立技能——一旦有东西坏了你就进入它，一旦修复及其回归测试到位你就退出。当真正的发现是"没有好的接缝可以锁定这个 bug"时，它的事后复盘会移交给 improve-codebase-architecture——问题出在代码本身，而不是 bug。当你不确定哪个技能适合时，可以找 ask-matt 帮你导航。