程序员调试总在 “读代码” 卡住？试试这个结构化诊断法

你有没有过这种经历——一个 bug 看了两小时，代码读了几十遍，最后发现是个低级错误？

不是你不厉害，是方法错了。

Matt Pocock 的 diagnosing-bugs 是目前最系统的调试 Skill。它把「调试」拆成了一套可以复用的流程：

第一步：先建反馈循环

这是整个 Skill 的核心。大多数人调试上来就读代码，Pocock 说「停，先给我一个能复现 bug 的命令」。

反馈循环有 10 种构建方式，从简单到复杂：
1. 失败的测试用例（最推荐）
2. curl 脚本打你的接口
3. CLI 命令带 fixture 输入
4. Playwright 脚本跑 UI
5. replay 抓包日志
6. 写一个最小化 harness
7. 模糊测试跑 1000 次
8. git bisect 自动定位引入版本
9. 旧版 vs 新版 diff 输出
10. 人工点击脚本化（最后兜底）

有了一个 2 秒能跑完、明确 red/green 的命令，bug 就解决了 90%。

第二步：reproduce + minimise

跑你的循环，确认它真的在触发你描述的那个 bug。然后把复现场景压到最小——最少的代码、最小的输入、最简单的路径。

第三步：hypothesise → instrument → fix

有了可重复的验证手段后，再去读代码、提假设、加日志、修复。不要在有反馈循环之前就开始「我觉得应该是……」。

安装方式

npx skills add https://github.com/mattpocock/skills --skill diagnosing-bugs

装完跟 AI 助手说「diagnose this」，它就会按这个流程引导你。

这个 Skill 来自 mattpocock/skills 仓库——这个仓库本身在 GitHub 有 132k+ stars，常年霸榜 GitHub Trending。Pocock 本身是 TypeScript 知名布道师（totaltypescript.com），他的 Skill 哲学是：AI 编程很强，但缺乏工程纪律，这套 Skills 给 AI 加上专业开发者的思维框架。

如果你经常被「这个 bug 为啥跑不出来」卡住，诊断 loop 是你需要的第一个 Skill。

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