24.5万 Star、安装超2000万次，这套顶级Skills到底强在哪？

用 AI 写代码久了，你可能会发现一个很反常的现象：

AI 越来越会写代码了，但返工并没有消失。

需求刚说完，Claude Code、Codex 几分钟就能改完十几个文件。

结果一验收：

需求理解偏了、边界条件漏了、为了改一个功能又顺手动了一堆代码，测试虽然全绿，但做出来的根本不是你想要的东西。

问题很多时候不是模型不够聪明，而是：

我们只告诉了 AI“要做什么”，却没有告诉它“应该怎么干活”。

最近，一个专门解决这个问题的 GitHub 项目火得有点夸张。

53 个能力模块、累计安装超过 2030 万次，GitHub Star 已经来到 24 万+。

它就是 TypeScript 圈知名开发者 Matt Pocock 开源的：

mattpocock/skills

我把这套东西翻了一遍以后，最大的感受反而是：

这里面几乎没有什么新技术。

需求澄清、TDD、Bug 复现、Code Review、ADR、领域建模……

全是软件工程讲了很多年的老方法。

但恰恰是这些“老方法”，到了 AI Coding 时代，开始重新变得重要。

一、这套工具真正解决的，不是“AI 会不会写代码”

先解释一下 Skill。

你可以把 Agent Skill 理解成：

给 AI 的专项工作说明书。

比如一个 TDD Skill，会告诉 AI：

先写失败测试，再写最小实现，测试通过以后才能继续。

Bug 排查 Skill 则会规定：

问题没有稳定复现之前，不允许急着猜根因。

所以 Matt Pocock 这套 Skills，本质上不是让 Claude Code、Codex 变得更聪明。

而是给它们增加一套：

软件工程工作规范。

官方 README 对它的定位也很明确：这些 Skills 面向真实工程，而不是单纯的 Vibe Coding；它们强调小型、可组合、可修改，并且可以配合不同模型使用。

这也是它值得关注的地方。

现在 AI Coding 最缺的，可能已经不是代码生成能力，而是：

工程纪律。

二、如果只挑几个，我最推荐这 4 个

53 个 Skill 没必要全研究。

真正值得多数开发和测试工程师先看的，我认为就下面几个。

/grill-with-docs：写代码之前，先把需求问透

这是我最推荐的一个。

平常我们用 AI：

我提需求 → AI 开始写。

它会强行变成：

我提需求 → AI 反过来问我 → 把边界确认清楚 → 再开始写。

比如你说：

做一个用户批量导入功能。

它可能继续追问：

支持 CSV 还是 Excel？

重复用户覆盖还是跳过？

100 条失败 1 条，是整体回滚还是部分成功？

最大支持多少数据？

同步还是异步？

需不需要失败记录？

这些东西，恰恰才是一个需求最容易返工的地方。

而 /grill-with-docs 还会把项目里的领域术语整理到 CONTEXT.md，重要技术决策沉淀成 ADR，让产品、开发、测试和 AI 使用同一套语言。

所以它解决的其实是 AI Coding 最常见的问题：

别急着写，先确认我们说的是不是同一件事。

/tdd：不是“让 AI 补测试”，而是限制它怎么写

很多人现在所谓的 AI + TDD，其实是：

AI 写完功能
↓
让 AI 补测试
↓
测试全部通过

这并不是真正的 TDD。

真正的测试驱动开发是：

Red
↓
Green
↓
Refactor

先写一个失败测试。

确认它真的失败。

然后只写刚好够测试通过的代码。

这对 AI Coding 尤其重要。

因为 AI 最大的特点之一就是：

一次能写太多。

以前工程师一天写几百行代码。

现在 Agent 十分钟能改二十个文件。

代码生成速度越快，就越需要小步开发和快速反馈。

/diagnosing-bugs：没复现之前，别让 AI 猜

这个 Skill 我觉得测试团队尤其值得看。

它最核心的一条规则就是：

先建立稳定的反馈环路，再分析原因。

比如接口偶发 500。

AI 很容易马上告诉你：

可能是 Redis、数据库事务、线程池、网络超时、并发竞争……

听起来都挺合理。

问题是：

可能一个都不是。

diagnosing-bugs 会要求先构造一个稳定的失败信号，比如测试、curl、脚本或者自动化用例，能够反复把问题打出来，然后再做假设和验证。

这一条我甚至建议测试团队直接写进 Bug 排查规范：

不能稳定复现的问题，不要过早进入根因猜测。

AI 可以帮我们分析。

但没有证据的分析，本质上还是猜。

/code-review：不只看代码对不对，还看需求做没做对

AI Code Review 经常检查：

代码规范、重复逻辑、性能问题、潜在 Bug。

但真实项目还有一种问题更麻烦：

代码写得非常漂亮，但需求做错了。

所以这套 Review 会从两个维度检查：

一边看：

代码是否符合项目规范。

另一边看：

最终实现是否真的符合原始 Spec。

这其实对应软件测试里的两个经典问题：

我们有没有把东西做对？

以及：

我们做的是不是正确的东西？

AI 很容易做好前者。

真正昂贵的返工，很多时候来自后者。

三、真正厉害的是，它们已经能串成一套研发流程

单独看，每个 Skill 好像都没什么神奇。

但连起来以后就不一样了：

需求
↓
grill-with-docs
把需求问清楚
↓
to-spec
整理规格说明
↓
to-tickets
拆分任务和依赖
↓
implement
开始开发
↓
tdd
小步实现 + 持续验证
↓
code-review
检查代码 + 对照需求
↓
handoff
上下文过长时交接给新会话

这其实已经非常接近一套完整的 AI Coding 工程流程。

但它和一些“大而全”的 Agent Workflow 又不太一样。

Matt Pocock 没打算让框架接管整个研发流程。

每个 Skill 都很小。

需要哪个就用哪个，不需要就不用。

这点我反而比较认同。

真实公司的研发流程千差万别。

很难存在一套 Workflow 可以适合所有团队。

未来更现实的方向，可能不是：

让 AI 接管整个软件研发流程。

而是：

把优秀工程实践拆成一个个 AI 可以稳定执行的能力模块。

四、测试工程师尤其应该关注 Agent Skills

看到这里，如果你是测试或者测试开发，别觉得这是纯开发工具。

其实把 Skill 名字去掉以后，会发现里面很多东西，本质上都在做：

质量保障。

比如：

grill-with-docs → 需求评审

tdd → 质量左移

diagnosing-bugs → 缺陷复现与定位

code-review → 代码质量和需求一致性检查

未来测试团队甚至完全可以沉淀自己的 Skills：

/review-requirement

/generate-test-strategy

/design-test-cases

/check-api-change

/analyze-production-bug

/check-release-risk

把高级测试工程师脑子里的经验：

什么时候该补异常场景？

接口改动要检查哪些上下游？

什么情况下必须增加回归？

哪些风险应该阻止上线？

慢慢写成 AI 可以执行的 Skill。

我觉得这件事情，比一直研究：

“哪个大模型生成测试用例更好？”

重要得多。

因为模型会一直换。

今天 Claude Code。

明天 Codex。

以后还会有新的 Coding Agent。

但企业真正应该留下来的，是：

自己的工程经验。

五、别一次全装，先解决一个最痛的问题

如果你想试这套 Skills，我不建议第一次直接研究 53 个。

先看自己现在 AI Coding 最大的问题是什么。

需求经常理解错：

用 /grill-with-docs

Bug 总靠猜：

用 /diagnosing-bugs

希望真正做 TDD：

用 /tdd

代码写得越来越快，但仓库越来越乱：

试 /improve-codebase-architecture

如果使用 Claude Code，可以直接安装插件；Codex 和其他 Agent 也可以通过 skills installer 安装需要的 Skill。官方同时建议每个仓库先运行一次 /setup-matt-pocock-skills 完成基础配置。

写在最后

我觉得这个 24 万 Star、2000 多万次安装的项目，最值得看的其实不是某一个 Skill。

而是它透露出了 AI Coding 的一个变化。

过去大家一直在追：

更大的模型。

更长的上下文。

更强的推理。

更高的 Coding Benchmark。

但当 AI 真正进入软件工程以后，我们开始重新发现：

写代码，从来不是软件开发最难的部分。

需求理解错了，写得越快，返工越快。

架构没有边界，写得越快，技术债积累越快。

Bug 没有复现，模型推理再强，也可能只是高级猜测。

所以 AI Coding 的下一阶段，竞争的可能不只是：

谁的 AI 更会写代码。

而是：

谁能让 AI 按真正的软件工程方式工作。

而 Agent Skills，可能正是其中非常重要的一环。