前言

让我从定义开始，因为这里存在不少混淆。

Skill 这个词现在到处都在用，含义却越来越模糊。有人把它当「给 AI 的一小段提示词」，有人把它当「一个插件」，还有人干脆把它当成 buzzword，碰都不想碰。这种语义扩散我很熟悉，我看过太多好概念在流行过程中失去准头。

这一课不急着夸它，先把它是什么、不是什么、解决什么、不解决什么，划清楚。边界画明白了，后面的课程才好用。

---

一、先定义：Skill 到底是什么

mattpocock/skills 是 TypeScript 专家 Matt Pocock 公开的个人 AI 技能集。他创办了 Total TypeScript（一个很有名的 TypeScript 学习平台），也在 Vercel 工作过。2026 年 2 月他把仓库公开，很快冲到近 20 万星。

它为什么受欢迎？我的理解是，他公开的不是又一个 AI 框架，而是他自己每天都在用的工作流文件。这是从真实项目里长出来的东西，不是演示用的玩具。

每个技能就是一个 SKILL.md 文件，定义了一套结构化的工作流。AI 一旦加载它，就按这套流程走，而不是凭感觉自由发挥。

关键区分在这：

   

prompt：一次性指令，你说这次做什么
skill ：可复用工作流，规定每次该怎么做

prompt 是对话，说完就散；skill 是流程，装进去就持续生效。这个区别很重要，因为它决定了你在跟 AI 的每一次对话中，是「碰运气」还是「走流程」。

这里有个比喻我用了很多年，跟 AI 时代也说得通：你不必是电气工程师才能用电，但你至少得知道开关在哪。Skill 就是流程里的那个开关，你知道什么时候打开它（/grill-me），什么时候它会自己亮起来（写代码时自动启用 tdd），就够了。

---

二、它解决什么问题：AI 编码的四个常见失败

Matt 把 AI 编码里最常见的失败归纳成四类。注意我的用词，是「常见」，不是「全部」。这四类是他的观察，用我习惯的说法，是 anecdotal evidence，来自他自己的实战经验，不是严谨的行业统计。这不妨碍它有用，但你要知道它的来源。

失败一：AI 没做你想要的事
 你脑补了一个订单系统的需求，让 AI 开工。结果它做出来的东西，跟你想的差了十万八千里。解法是 grill-me 这类追问式访谈技能：让 AI 在动手前不停问你问题，直到把需求彻底问清楚。

失败二：AI 太啰嗦
 你让它改一行代码，它给你写三百字解释，还自创一堆术语。解法是建立共享语言：项目里维护一个 CONTEXT.md，把术语、概念、模块关系写清楚，AI 一进来就能说人话。

失败三：AI 写出来的代码不工作
 AI 写得飞快，但没有反馈回路，它根本不知道自己写错了。解法是 tdd 和 diagnosing-bugs：先写会失败的测试，再写实现，让 AI 随时知道自己的代码能不能跑。

失败四：项目被改成一坨浆糊
 AI 提速了编码，也加速了软件熵，代码库以史无前例的速度变复杂。解法是 codebase-design 和 improve-codebase-architecture，强迫 AI 在设计上花心思。

这四大失败模式就是全系列的骨架。本系列后续课程会逐个拆解对应的技能。

---

三、它不是什么：划清边界

定义一件事，最好同时说清它不是什么。这一节很重要，因为我看过太多工具死于「什么都想要」的自我膨胀。

它不是一个能力插件包。仓库里没有「让 AI 会调浏览器」「让 AI 能查数据库」这类技能。它不扩展 AI 的能力边界，只约束 AI 的工作方式。

它不是银弹。装了它，AI 不会自动变聪明，也不会保证代码零 bug。它改变的是流程：动手前先问、写码前先测、提交前先审。流程能降低出错的概率，不能消灭出错的可能。

它不是「替你做决定」。这套东西的哲学是给你可组合的纪律，而不是接管整个项目替你拍板。要不要用某个技能、用多严，决定权还是在你。

一句话总结边界：它约束 AI 怎么干活，不决定 AI 干什么活。

---

四、安装：两种选择，一种权衡

安装方式有两条，代表两种不同的权衡，不是优劣之分。二选一，别都装（都装会让每个技能出现两次）。

方式一：Claude Code 插件（订阅派）

Claude Code 里直接装官方市场插件：

   

claude plugins install mattpocock-skills

或者，在 Claude Code 会话里输入：

   

/plugin install mattpocock-skills

它的特点：只读捆绑。技能以管理包形式装好，Matt 每次更新，你自动收到。你订阅，而不是 fork。

方式二：skills.sh（拥有派）

想自己改、自己 hack 的用这个：

   

npx skills@latest add mattpocock/skills

它会问你选哪些技能、装到哪些 agent 上，然后把技能文件复制成你项目里普通可编辑的文件。装完你完全拥有这些文件，想怎么改怎么改。之后想同步作者的更新：

   

npx skills update

对大多数读者我的建议：先走方式一（插件）用起来，等用熟了、想定制了，再换方式二（文件版）。

这跟我看软件许可证的立场很像：订阅还是拥有，取决于你想要便利还是要控制权，没有哪个绝对正确。对多数人，先用起来比先折腾重要。

注意：无论做哪种选择，记得把 setup-matt-pocock-skills 装进去，它是整个系列的初始化入口。

---

五、初始化：跑一次 setup

装完后，在每个仓库里运行一次初始化（就一次）：

   

/setup-matt-pocock-skills

它会问你三个问题：

1. 用哪个 issue tracker： GitHub、Linear，还是本地文件
2. triage 时用什么标签： /triage 技能要用标签来管理 issue
3. 文档存哪里： 生成的 spec、ADR 等放哪个目录

回答完，你的仓库就配置好了，技能系统开始生效。

对 EShop 项目来说，建议：

   

issue tracker：本地文件（个人项目不需要 GitHub 的完整流程）
triage 标签：bug / feature / refactor
文档目录：docs/

---

六、跑通第一个技能：让 AI 先问再做

装好之后，来试最有代表性的一个：grill-me。它的作用是让 AI 在动手前追着你问问题。

在会话里输入：

   

/grill-me

然后告诉它你想做的事，比如：

   

我想给 EShop 加一个下单功能，用户把商品加入购物车后统一结算。

接下来会发生什么：AI 开始不停问你问题，比如订单金额怎么算、优惠券叠加规则、库存不足怎么办、并发下单怎么处理。它会追着你问，直到把决策树的每个分支都问清楚。

这正是解决「失败一」的关键：动手之前，先对齐。

你可能会觉得烦。第一次被问十个问题，确实比「AI 直接甩代码」慢。但慢在这里，是为了不慢在后面。需求没对齐时写出来的代码，返工的成本远超这十分钟。

---

七、技能系统怎么运转：两种触发方式

整个技能集分两类触发方式，理解了这一点，你就掌握了它的骨架。

user-invoked（用户触发）
 必须由你显式输入，比如 /grill-me、/to-spec。它们负责编排：启动一个流程。

model-invoked（模型触发）
 模型自己判断「这个任务该用这个技能」，自动调用。比如你在写代码，模型自动启用 tdd 的纪律。它们承载可复用纪律。

规则只有一条：

   

user-invoked 可以调用 model-invoked，
但 user-invoked 绝不调用另一个 user-invoked。

这条规则防止了「流程套流程」的无限循环。编排类技能负责启动，纪律类技能负责执行，层次清晰。

---

八、这套东西和 Trellis 有什么区别

如果你看过本仓库的 Trellis 系列，这里有个关键对比：

• Trellis： 完整的编码工程化框架（harness），框架接管流程，通过 workflow.md 定制，主要绑特定平台
• mattpocock/skills： 一组可组合的小技能文件，小而灵活完全自控，直接改 SKILL.md，声明任何模型都能用

一句话总结：Trellis 是「给你一套完整的流程框架」，mattpocock/skills 是「给你一堆可以自由拼装的纪律积木」。没有谁更好，取决于你想要框架的省心，还是积木的灵活。

我个人的倾向是后者，因为我从来不相信「一个框架接管一切」的叙事。但这是口味问题，不是真理问题。

---

九、何时不要用

这一节可能是本课最值得你记住的。

mattpocock/skills 设计得很聪明，但它不是万灵药。我列出几个场景，你大概不需要它：

你的 AI 编码只是偶尔玩一下。如果你一周才让 AI 写一次代码，还不写正式项目，那这套技能集的管理成本可能超过收益。它对有持续开发的项目才划算。

你的需求极其简单且稳定。一个「把 CSV 转成 JSON」的一次性脚本，不值得开一轮 grill 访谈。需求简单到没有决策树可问时，直接写更快。

你的团队根本不想要流程。这一点我要强调：你永远不该把流程强加给不想试的团队。这套技能集再好，也是靠纪律吃饭的，团队不认同纪律，装上了也是摆设。我的经验是，先让愿意试的几个人用起来，用结果说服，而不是用指令强推。

你想要的是「AI 替我把一切都搞定」。如果你期待的是输入一句话、拿回一个完整交付物的魔法，这套东西会给你相反的东西：更多的流程、更多的问题、更多的门禁。它是约束，不是解放。

如果你不属于以上任何场景，那这工具值得一试。这也是我说「it depends」之后的真实内容：它适合有持续开发、愿意接受纪律的团队，不适合追求「少做点事」的人。