别再靠猜修 Bug 了——Matt Pocock 这个思路让我服气

做 AI 编程开发一段时间了，我发现一个挺有意思的规律：越是厉害的开发者，遇到 bug 越不急着动手。

为什么？因为他们心里有一套严格的诊断流程。而普通开发者（包括用 Claude Code 的我）最大的问题，就是上来就想”试一个解法”，结果改了三处还是没修好，白白浪费一堆时间。

最近我在翻 Matt Pocock（TypeScript 圈大名鼎鼎的 Total TypeScript 创始人）的 Skills 集合，发现了一个叫 diagnosing-bugs 的技能，安装量高达 438K，几乎是被用得最勤的几个 skill 之一。看完它的逻辑，我意识到——这就是我想找的那套”不猜解法”的诊断方法论。

它到底怎么工作的？

diagnosing-bugs 遵循一个六阶段循环，每一步都强制执行，不许跳步：

Reproduce（复现） → Minimise（最小化） → Hypothesise（假设） → Instrument（插桩验证） → Fix（修复） → Regression-test（回归测试）

听起来像教科书，但关键是它把每一步做成了 Claude Code 可执行的指令约束——你不能跳过前面的步骤直接到 Fix 阶段，Claude 会强制你先复现 bug，再找最小可复现场景，再形成假设，再验证假设，最后才动手修。

这比大多数人（包括我）在 terminal 前做的事情要严谨得多。我们通常的做法是：看到报错 → 脑子里蹦出”可能是什么问题” → 直接改 → 不 work → 再改 → 再试。

而这个 skill 的逻辑，相当于给你的 AI 编程过程装了一个”行为规范”——先诊断，再动手，fix only root cause。

适用场景

这个 skill 特别适合以下几类场景：

• 间歇性 bug：本地能复现但线上偶发的玄学问题，必须先稳定复现才能定位
• 性能回归：跑着跑着慢了，用最小化复现确认慢在哪个模块
• 数据不一致：前后端数据对不上的问题，需要先追踪数据流向
• 多人协作的遗留代码：接手别人写的项目，先用诊断流程摸清楚问题根源再动手

说白了，只要你不想被”感觉可能是这个原因”这种思路带偏，这个 skill 就能派上用场。

为什么 438K 安装量值得关注？

Matt Pocock 的 Skills 集合在 GitHub 上有 20K+ stars，是这个生态里最被认可的开发者工具包之一。diagnosing-bugs 能在这个量级的库里拿到 438K 安装，说明它被高频使用，而且是真实解决开发者痛点的能力，不是花架子。

对比大多数 Skills 偏向”扩展能力”（比如做 PPT、生成图片），diagnosing-bugs 属于”流程约束”型——它不给你新能力，但让 Claude Code 做事更有章法。这其实更符合工程团队需要的价值：减少 AI 编程中的随机性和无效迭代。

怎么安装使用

# 直接安装整个 mattpocock/skills 集合
npx skills@latest add mattpocock/skills

# 或者单独安装 diagnosing-bugs
npx skills@latest add mattpocock/skills/diagnosing-bugs

装好之后，在 Claude Code 里遇到 bug，直接让它”用 diagnosing-bugs 走一遍”，它就会按六阶段流程开始工作。

GitHub 仓库：github.com/mattpocock/skills

GitHub: https://github.com/mattpocock/skills