让 AI 调试不再靠猜：Matt Pocock 的 diagnosing-bugs 技能

你有没有过这种感觉——让 AI 帮你写了个功能，一跑，崩了。然后 AI 开始”修复”：改一行，报错；再改，还是错；它开始重写整个模块；再报错……你们俩就在黑暗里来回碰撞，半小时没了。

这不是你的问题，也不一定是 AI 蠢。是调试方法论的问题。

AI 调试的通病：先开枪再瞄准

人类工程师遇到 bug，教科书式流程是：复现 → 定位 → 假设 → 验证 → 修复 → 确认。但 AI 编程 Agent 天生被训练成”快速给答案”，它会跳过前面的步骤直接冲进去改代码，然后根据报错再改，一遍遍猜。

Matt Pocock（Total TypeScript 作者，253k stars 仓库维护者）开源了一个叫 diagnosing-bugs 的 Skill，就是专门治这个的。

六个阶段，把调试变成流水线

diagnosing-bugs 把调试拆成六个强制阶段，每个阶段有明确的退出条件，Agent 不能跳过：

• Phase 1 – 复现：先让 bug 可观测。不接受”应该没问题”——必须拿到一个能红的信号
• Phase 2 – 最小化：把复现场景压到最小——最少的代码行数、最干净的环境、最确定的触发路径
• Phase 3 – 假设：提出可证伪的假设，不是猜测。比如”问题应该出在第 14 行的异步回调里”——然后用插桩来验证，不是靠猜
• Phase 4 – 插桩：加日志、对比输出、做 bisection——所有手段都用来喂给那个”变红的信号”
• Phase 5 – 修复 + 回归测试：写回归测试先于写修复代码，确保这个 bug 以后不会再漏
• Phase 6 – 清理：删掉调试代码、删掉临时产物、确保代码库比你动手前更干净

核心原则就一句话：先构建一个精确的反馈回路，再动手分析。没有回路就修复，等于盲人摸象。

两个细节值得特别注意

一是 “红队思维”——skill 要求在展示任何日志或产物前，先把所有密钥和敏感信息脱敏，用 [REDACTED] 占位。这是故意的：调试时养成的安全习惯，能防止你在修 bug 过程中无意泄露凭证。

二是对非确定性 bug的处理——这类 bug 没法干净复现，skill 的策略是”提高复现率”而不是”追求完美复现”。把 30% 复现率的 bug 提到 80%，已经足够调试了。

怎么安装

一行命令搞定：

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

支持 Claude Code、Codex、Cursor 等所有读 SKILL.md 的 AI 编程工具。

Matt Pocock 的 Skill 体系

diagnosing-bugs 是 Matt Pocock 开源的”工程肌肉记忆”Skill 体系中的一员。这个体系包括：grill-me（需求审讯）、to-prd（PRD 生成）、request-refactor（重构规划）等，覆盖从需求到代码到调试的完整链路。全都来自他多年做大型 TypeScript 项目的工程经验，不是纸上谈兵。

GitHub：mattpocock/skills

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