GitHub 爆火！236K+ Star！一套 Skills 让 AI 按工程师方式写代码

如果你最近一直在用 Claude Code、Codex、Cursor 这类 AI Coding Agent 写代码，你可能已经发现一个非常奇怪的问题：AI 写代码越来越快了，但项目却越来越乱了。

你告诉 AI："帮我加一个用户登录功能。"几秒钟代码就出来了。但真正让开发者头疼的，往往不是代码怎么写，而是：

复制代码

需求到底是什么？
架构怎么设计？
边界条件有哪些？
要不要拆任务？
怎么测试？
代码写完谁来 Review？

如果这些事情全部交给 AI 自己猜，最后很容易变成：

代码越来越多，项目越来越乱。

而现在，一个 GitHub 项目正在把"高级工程师工作流"直接教给 AI。

它叫：Matt Pocock's Skills

目前 GitHub 页面显示，这个项目已经拥有约 23.6 万 Star、1.69 万 Fork ；官方 Skills 页面则显示 GitHub Stars 已超过 23 万，说明项目近期增长非常快。

Matt Pocock's Skills 到底是什么？

很多人第一次看到这个项目，可能会产生一个误解：它就是一个"大 Prompt"集合？

不是。它更准确的定位是 给 AI Coding Agent 安装一套"工程师工作习惯"。 官方对 Skill 的定义非常直接：

Skill 是一组小而明确的指令，让 Coding Agent 按照资深工程师的方式完成某一类工作。

比如你可以给 AI 一个 /implement，让它按规定流程实现功能；也可以给 /code-review，让 AI 按项目规范 Review 代码；还可以给 /to-spec，把讨论清楚的需求整理成技术规格。

这时候 AI 就不只是：

复制代码

你说一句
↓
AI 写代码

而变成：

复制代码

需求
↓
分析
↓
设计
↓
规格
↓
任务
↓
实现
↓
测试
↓
Review

以前我们是怎么用 AI 写代码的？

假设你要做一个新功能。第一步打开 Claude Code，然后写：帮我加一个用户登录功能

能用。但加上需求澄清、架构设计、任务拆分、测试覆盖、代码审查，AI 就开始凭感觉发挥了。

Matt Pocock's Skills 想做什么？

它的思路非常简单：不要让 AI 只学会写代码，要让它学会工程师怎么工作。 而是：

复制代码

先理解
↓
再决定
↓
写 Spec
↓
拆任务
↓
实现
↓
测试
↓
Review

AI 可以提高执行速度，但工程纪律不能丢。

但真正值得关注的，是完整的 Skill 流程

如果只是单个 Skill，其实没那么特别。真正让我觉得这个项目很有意思的是：Skills 可以串起来，形成一条完整的工程流水线。

官方现在把主要 Skills 组织成了一个非常清晰的主流程：

bash 复制代码

想法
 ↓
/grill-with-docs
 ↓
/to-spec
 ↓
/to-tickets
 ↓
/implement
 ↓
/code-review

第一步：先别写代码，先"拷问"需求

第一个很有意思的 Skill：/grill-with-docs

它的思路不是直接帮你写代码，而是先问你问题。

比如你说："我想给系统增加一个权限管理功能。"

AI 不会马上 mkdir permission，而是会继续追问：

复制代码

谁可以使用？
角色有哪些？
权限如何继承？
管理员和普通用户有什么区别？
已有用户体系是什么？
哪些操作需要权限？
异常情况怎么处理？

一直把需求里的模糊部分挖出来，然后把决定记录下来。

官方将这个 Skill 定义为：通过访谈式讨论来澄清计划，同时建立项目的领域模型。

这其实很像一个有经验的产品经理 + 架构师。

第二步：把讨论结果变成 Spec

需求讨论清楚之后，使用 /to-spec。

作用非常简单：把已经达成共识的内容写成规格。

注意，它不是重新采访你。官方明确说明：to-spec 会综合当前对话、代码库、CONTEXT.md 和 ADR 等已有信息，形成一份 Spec。

也就是说：

复制代码

讨论
 ↓
决定
 ↓
Spec

把原本散落在聊天记录里的内容，变成一份可以继续执行的工程文档。

第三步：把 Spec 拆成任务

接下来：/to-tickets

把一个比较大的功能，拆成多个可以独立执行的 Issue。

比如"用户权限系统"可能拆成：

复制代码

Issue 1：用户角色模型
Issue 2：权限数据结构
Issue 3：权限校验中间件
Issue 4：管理后台接口
Issue 5：前端权限控制
Issue 6：测试

这一步非常重要，因为：

AI 最擅长的，往往不是一次性解决一个巨大的问题，而是执行边界清晰的小任务。

所以：

复制代码

大需求
 ↓
小任务
 ↓
逐个实现

整个开发过程会稳定很多。

第四步：真正开始写代码

到了这里，才轮到：/implement

官方把它定位为：按照已经形成的 Spec 进行实现，并采用测试优先的方式完成代码。

也就是说，不是：

复制代码

AI：我觉得应该这么写

而是：

复制代码

Spec
 ↓
代码
 ↓
测试
 ↓
验证

这就是它和普通"帮我写一个功能"最大的区别。

第五步：最后交给 AI Review

代码写完，还有：/code-review

它会对照项目规范 + Spec + 代码 Diff 进行 Review。

这一步很重要，因为 AI 自己写的代码，让 AI 自己检查，先把明显的问题筛出来，把人类的注意力留给真正重要的设计和业务决策。

这其实是一个非常重要的信号

以前：

复制代码

AI 工具
↓
你说一句，AI 写一段

现在：

复制代码

AI 工具
↓
需求澄清
↓
规格定义
↓
任务拆分
↓
实现
↓
测试
↓
Review

这两种设计，已经开始出现区别。因为 AI Coding Agent 的代码能力已经越来越强，但工程能力不一定跟得上。

如果你让 AI"做一个订单系统"，它当然可以开始写。但一个有经验的工程师，第一反应通常不是"我马上开始写"，而是先问清楚需求、边界、结构、验证方式。

这就是 Engineering Process ，而 Matt Pocock 的 Skills 项目，正在尝试把这些过程沉淀成可以被 AI 执行的 Skill。

更有意思的是：Skill 可以串起来

官方明确强调：

一个 Skill 的输出，可以成为下一个 Skill 的输入。

于是：

css 复制代码

Skill A
 ↓
Skill B
 ↓
Skill C
 ↓
Skill D

最终形成一个完整流程。

这就是所谓 Skill Compounding。一个个小能力组合起来之后，AI Agent 的工作方式会发生变化。

还有一个很实用的 Skill：ask-matt

如果你不知道"现在到底该用哪个 Skill"，项目甚至提供了：/ask-matt

官方把它定义成整个 Skill 集合的 Router。你告诉它"我现在遇到一个什么问题"，它会告诉你"应该使用哪个 Skill，或者应该按照什么 Skill 顺序处理"。

而且它的职责是推荐，然后停下来，不会自作主张替你做后续决定。

这个设计其实很聪明。

setup 也很重要

第一次把这些 Skills 放进一个项目，还需要：/setup-matt-pocock-skills

它会先了解这个仓库：

css 复制代码

Issue 在哪里管理？
使用什么 Label？
Domain 文档放在哪里？

然后把这些信息写进 docs/agents/ 下面的配置文件。

官方特别强调：Skill 本身不会被修改来适配不同项目。 而是通过项目级配置告诉 Skill："这个项目应该怎么工作。"

这个设计非常值得学习。

为什么不直接把所有规则写进 Prompt？

因为项目会越来越复杂。比如你告诉 AI"这个项目使用 GitHub Issues"，换一个项目可能用 Linear，再换一个可能用本地 Markdown。

如果把这些信息硬编码进 Skill，维护会非常麻烦。而这个项目选择：

复制代码

Skill + 项目配置

把通用工程流程 和具体项目规则分开。这其实就是非常典型的软件工程思想。

这个项目目前有哪些 Skills？

官方目前将 Skills 按照使用场景进行了分类。比较核心的一组包括：

bash 复制代码

/setup-matt-pocock-skills
/ask-matt
/grill-with-docs
/to-spec
/to-tickets
/implement
/code-review

另外还有：

bash 复制代码

/grilling
/tdd
/research
/teach

等 Skills。

所以它并不是只有几个 Prompt，而是在逐渐形成一个 AI Engineer Skill Library。

还有一个很有意思的 Skill：Teach

比如你遇到一个自己不会的技术，可以使用 /teach。

它不是简单告诉 AI："解释一下 React Server Components。"

官方设计是让它把当前目录变成一个持续学习空间。它会先寻找高可信资源，把资源记录下来，再在后续课程中引用这些资料。

这其实意味着：

复制代码

AI Coding + AI Learning

也可以连接起来。

这个项目还有一个特别值得关注的地方

就是：它不鼓励 Vibe Coding。

AI 时代最容易出现的一个问题就是：

复制代码

想法来了
↓
直接让 AI 写
↓
能跑
↓
继续加
↓
越来越乱

这就是大家常说的 Vibe Coding。

而 Matt Pocock 的这套 Skills，核心思想恰恰相反。它希望 AI：

复制代码

先理解
↓
再决定
↓
写 Spec
↓
拆任务
↓
实现
↓
测试
↓
Review

官方也明确将这个项目描述为：让工程师使用 AI，同时不放弃自己的工程标准。

一个命令就能安装

如果你已经在使用支持 Agent Skills 的工具，安装非常简单：

sql 复制代码

npx skills@latest add mattpocock/skills

也可以安装到全局：

bash 复制代码

npx skills add mattpocock/skills -y -g

或者只安装某一个 Skill：

css 复制代码

npx skills add mattpocock/skills --skill=to-spec

如果你使用 Claude Code，官方还提供了插件安装方式：

复制代码

claude plugins install mattpocock-skills

这种方式会把完整 Skills 集合作为受管理的只读插件安装，并自动更新。

它到底适合谁？

其实非常明确。

第一类：AI Coding 重度用户

如果你每天都在使用 Claude Code、Codex、Cursor，这套 Skills 很值得研究。因为你真正需要的已经不是"AI 会不会写代码"，而是"如何让 AI 按我的工程标准写代码"。

第二类：团队开发者

团队里最麻烦的事情之一就是每个人的开发习惯不一样。而 Skill 可以把一些团队共识，逐渐沉淀成可执行的流程。

第三类：独立开发者

一个人开发项目，最缺的往往不是代码能力，而是产品经理、架构师、测试、Code Reviewer。现在可以让 Agent 在不同阶段承担不同角色。

但它也不是"装完就自动变强"

这一点一定要说。Skills 本质上还是给 Agent 的指令和工作流程。 它不能 magically 解决：

复制代码

业务理解
架构判断
产品决策
技术取舍

这些问题。而且 AI 依然可能犯错。

所以正确理解应该是：

复制代码

Skill ≠ AI 自动变成高级工程师

而是：

ini 复制代码

Skill = 把优秀工程方法，变成 Agent 可以重复执行的流程

这才是它真正的价值。

写在最后

Matt Pocock's Skills 这条路线到底能不能成为 AI 工程化的标准方案，现在下结论还太早。毕竟它仍在快速迭代中。但它正在做的事情，已经越来越清晰：

复制代码

需求澄清 + 规格定义 + 任务拆分 + 实现 + 测试 + Review + Skill Compounding + 项目配置分离

最终统一成：一套 AI 可以执行的工程师工作流。

开发者只需要面对一个入口，AI Agent 也只需要面对一个更加结构化的工程流程。而这可能才是这个项目真正的价值：

不是让 AI 写更多代码，而是让 AI 按照更好的工程流程写代码。

所以整个开发过程正在从：

复制代码

人想需求
↓
人写代码

慢慢变成：

复制代码

人做决策
↓
AI 澄清
↓
AI 整理 Spec
↓
AI 拆分任务
↓
AI 实现
↓
AI 测试
↓
AI Review
↓
人最终确认

这才是 AI Coding 真正值得关注的下一阶段。

以前我们讨论：AI 能不能替程序员写代码？

现在可能应该换一个问题：我们能不能把优秀程序员的工作方法，也教给 AI？

Matt Pocock 的这套 Skills，正在尝试给出一个答案。

GitHub：github.com/mattpocock/...

AI Hero 官方 Skills 页面：www.aihero.dev/skills

你平时用 Claude Code、Codex 或 Cursor 写代码时，有没有遇到过"AI 写得很快但项目越来越乱"的情况？你觉得给 AI 装上"工程纪律"这种思路，未来会成为 AI Coding 的标配吗？评论区聊聊～

各位互联网搭子，要是这篇文章成功引起了你的注意，别犹豫，关注、点赞、评论、分享走一波，让我们把这份默契延续下去，一起在 AI 编程的海洋里乘风破浪！