别再让 AI 瞎写了！这套 18 万 Star 的指令集，30 秒把 Claude Code 变成工程老兵

你有没有这种感觉？让 AI 写代码，就像请了一个天才实习生。他手脚快得吓人，但路子野得让你心慌——一口气把所有测试都写完（然后发现全写错了），遇到 Bug 上来就瞎猜乱改，你一眼没盯住，他就把整个模块写得像个意大利面条。

GitHub 上有个叫 **skills** 的仓库，半年不到拿了 18 万 Star。它干的事特别简单，也特别狠：**给这个天才实习生，发一本标准操作手册。**

作者 Matt Pocock 是个前端圈的名人，他把测试驱动开发、代码评审、领域建模这些真实软件工程里的硬功夫，浓缩成了一堆斜杠命令。你在 Claude Code 里敲个 `/tdd`，AI 就老老实实走 Red-Green-Refactor 循环；敲个 `/grill-me`，它就反过来灵魂拷问你。

上个月我把这套东西装进了我们一个内部项目，实测了两周。效果嘛——这么说吧，以前 Code Review 我要改十几处逻辑问题，现在基本只剩下命名风格的讨论了。

这玩意儿凭什么全是 Markdown 还能拿 18 万 Star？

整个仓库几乎全是 `.md` 文本文件，一行代码都没有。它的 Slogan 是 **“Skills for Real Engineers”**——不是给那种“氛围编程”玩的，是给真要交付工程的人用的。

说白了，大多数人用 Claude Code，顶多在 `CLAUDE.md` 里写几句“你是个资深程序员”、“请写干净的代码”。这有用吗？有，但约等于零。AI 还是想到哪写到哪。

Matt 做的事不一样。他把一个需求从模糊到上线的整个生命周期拆开了，为每个关键节点设计了一个 Skill。每个 Skill 就像一个严格的工头，只盯着自己那道工序，死抠质量。

仓库里有大几十个 Skill，正式推荐的 22 个。我挑几个我们团队用下来最狠的讲。

30 秒上车：一行命令，给 AI 套上缰绳

别被“指令集”这个词吓到。安装就一行命令的事：

npx skills@latest add mattpocock/skills

跑完之后，它会让你选想要哪些 Skill，装到哪个工具里。**强烈建议勾上 `/setup-matt-pocock-skills`** 这个初始化技能。装完后在你的 AI 工具里运行一次，它会像个新员工入职一样，问你：你们项目用啥管 Issue？文档扔哪个目录？规则写进哪个文件？

我当时图省事，选了用本地 Markdown 管 Issue，文档丢 `docs/` 目录。几分钟就配好了。如果你不想手动管理这些文件，也可以用 Claude Code 的插件方式装，能自动更新，但就不能自己魔改了。

/grill-me：3 句话的灵魂拷问，比你的架构师还狠

这是整个仓库最火的 Skill。你猜它的核心指令有多长？

就 3 句话。

翻译过来大概是：针对我的计划，一个问题一个问题追问我，直到我们达成共识。沿着决策树的每个分支走下去，一次只问一个问题，等我回答完再问下一个。能自己查到的环境事实直接去查，别问我，但每个决策都要等我拍板。

就这么简单。但第一次用的时候，我被它连着问了 20 多个问题，从“你这个 API 的错误码是返回给前端还是网关？”到“如果缓存穿透了，你的降级策略是什么？”。问完之后我后背有点发凉——好多细节我之前压根没想过。

这玩意儿的设计精髓在于 **“一次只问一个问题”**。它不会像一些“万能提示词”那样劈头盖脸扔给你十个问题，让你直接不想玩了。它像一场耐心的、一对一的结对编程。其实这就是“小黄鸭调试法”的 AI 升级版，只不过这只鸭子现在会啄你了。

如果你的项目已经有代码仓库，用升级版 `/grill-with-docs`。它会把你俩讨论时定下来的术语，比如“物化级联”、“用户画像快照”，自动记到 `CONTEXT.md` 里。以后你跟 AI 说这些黑话，它秒懂。沟通成本直线下降。

/tdd：治一治 AI “一口气写完所有测试”的臭毛病

AI 写测试有个让人血压飙升的毛病：你让它用 TDD，它就先一口气把所有测试写完，然后再写所有实现代码。看起来效率爆炸对吧？等你一看测试，全废了。因为它在写测试的时候，代码还不存在，它**全靠想象**。等实现的时候 API 长得跟它想的完全不一样。

`/tdd` 这个 Skill 强制 AI 用 **垂直切片** 的方式干活。

就是经典的 Red-Green-Refactor：先写一个测试，看着它失败 ❌，然后只写刚好能让它通过的那一点点代码 ✅，通过了再写下一个测试。一小步一小步走，每一步都是实打实验证过的。

里面还有几条铁律。比如 **只在预先商定的接缝处测试**。接缝就是公开接口，函数的入参和返回值。写任何测试前，AI 必须先跟你确认在哪测，不能到处乱写。

最绝的是它列了几种 AI 写测试的反模式，一旦发现就必须改掉。最常见的一种叫 **“同义反复测试”**，比如 `expect(add(a, b)).toBe(a + b)`。这测试永远能过，屁用没有。正确的做法是用独立数据做期望值，一个手工算好的死数字。

我给一个客户项目跑了两周 `/tdd`，Bug 率降了大概四成。不是 AI 变聪明了，是它没法偷懒了。

/diagnosing-bugs：先别急着猜，给我一个能重现的死循环

遇到 Bug，你和 AI 的第一反应是不是都是：看代码，猜原因，改一下试试？然后往往越改越乱。

Matt 认为问题的根儿在于，AI 跳过了最关键的一步：**建立一个能稳定重现 Bug 的反馈循环。**

什么叫反馈循环？就是一条命令。可以是一个必挂的测试用例，一个 curl 请求，一个 Playwright 脚本。只要你一敲回车，它就能明确告诉你：Bug 还在，或者 Bug 死了。

`/diagnosing-bugs` 把 Debug 拆成了 6 个硬性阶段。**第一步就是“建立反馈循环”**。在这步完成之前，AI 被严格禁止跳到“猜原因”那步。如果它敢在还没有重现命令的时候就开始分析代码，Skill 会直接打断它。

有了这条能稳定重现的命令之后，后面的步骤就顺了：最小化重现场景、提假设、逐一验证、修完写回归测试。这思路跟 Cursor 内置的 Debug 模式有点像，但这个 Skill 更狠，它是用流程强行摁住 AI 那颗躁动的心。先磨刀，再砍柴。反而快得多。

/teach和/wayfinder：当 AI 成了你的私教和导航

除了写代码，这仓库里还有几个让我意外的生产力工具。

`/teach` 是让 AI 当你的私人教师。我本以为也就一句“用傻子都能懂的话教我 XX”，结果它背后藏了一整套教学方法论。AI 会先问你为啥想学，把你的目标记到 `MISSION.md` 里，然后去搜高质量资源，整理成 `RESOURCES.md`，最后给你生成一课一课的精美 HTML 课件。

它甚至会区分“流畅度”（你当场觉得会了）和“存储强度”（你真记住了），然后刻意用间隔重复和有点难度的练习来搞你，让你别产生“我已经学会了”的错觉。这太教育学了吧。

`/wayfinder` 则是解决大项目一个对话装不下的问题。它会跟你一起把一个大需求拆成一张“决策地图”，每个决策是一个独立的 Issue，标好依赖关系。你每次开一个新对话处理一个决策，上下文都是干净的。它甚至引入了“战争迷雾”的概念——你只能看清接下来几步的决策，再远的，等前面做完才会逐渐清晰。避免过度规划。

我最大的感触：这不是提示词技巧，这是工程方法论

玩完这个仓库，我最深的感受是：**这些 Skill 的本质，不是“提示词工程”，而是把经典的软件工程方法论，封装成了 AI 能执行的格式。**

TDD、代码评审、领域建模，这些东西在软件工程里存在了二十多年。以前你得靠一个有经验的团队、靠严格的 Code Review 文化才能落地。现在，你通过一个 Skill 文件，就能让一个 AI 自动按这些方法干活。

这太有意思了。AI 时代，方法论本身变成了可分发、可执行的软件。

如果你厌倦了 AI 那个“又快又野”的天才实习生模样，去试试这个仓库。花 30 秒装上，然后敲下 `/grill-me`，感受一下被 AI 反过来 Code Review 的滋味。挺爽的。