TS 大神 Matt Pocock 开源自己的 AI Skills，主打反 Vibe Coding

如果你写 TypeScript，应该绕不开 Matt Pocock 这个名字。Total TypeScript、TypeScript 错误翻译器、各种类型体操教学，他几乎一手撑起了英文社区里 TS 教学的半边天。

最近他低调开源了一个新仓库，叫 mattpocock/skills，副标题写得很直白：Skills For Real Engineers。翻译过来就是"给真正干工程的人用的技能"。

这话听上去有点冲，但他确实在 README 里把自己的态度写得很明白：这些 Skills 是用来做真实开发的，不是用来 Vibe Coding 的。

为什么是 Skills，而不是 BMAD、Spec-Kit、GSD？

这两年涌现的 AI 编程方法论不少。BMAD、Spec-Kit、GSD 这类框架都试图把"怎么和 AI 协作写代码"这件事流程化。它们提供完整的工作流，Agent 一步一步按照流程跑。

Matt 在 README 里直接点了名：这些方法论的问题是它们替你拿走了控制权。流程是黑盒，一旦中间某一步出了 bug，你很难钻进去修。

他的思路完全相反。Skills 是一组很小、很容易改、能自由组合的技能片段。你不需要全套接受，挑几个顺手的塞进项目里就能用。它们不绑死特定模型，Claude Code、Codex 都能跑。底层逻辑其实是几十年的工程经验沉淀，不是什么 AI 时代独有的新魔法。

一句话总结：BMAD 那一类是"我帮你定义流程"，Skills 是"我把工程师的好习惯拆给你，你自己拼"。

30 秒装好：一行命令搞定

npx skills@latest add mattpocock/skills

跑完之后会让你勾选要装哪些 Skills、装到哪个 agent 上（Claude Code 或 Codex）。**有一个必选项叫 /setup-matt-pocock-skills**，它是初始化器，会问你三个关键问题：

1. 你想用什么 issue tracker（GitHub、Linear，还是本地 markdown 文件）
2. 你 triage 时用什么 label（默认是 needs-triage、ready-for-agent 这套五态机）
3. 你想把生成的文档放在哪个目录

跑完这一步，剩下的 Skills 才知道这个仓库的"语境"。这个设计挺聪明的，避免了 Skills 之间因为约定不统一而互相打架。

Matt 想解决的四个 AI 编程顽疾

整套 Skills 的设计逻辑，是围绕他观察到的四个 AI 编程失败模式来的。这部分内容是 README 的灵魂，值得展开聊。

顽疾 1：AI 没干你想要的事

这是最高频的失败模式。你脑子里想的是 A，描述出来变成 B，AI 理解成 C，写出来是 D。等你看到产出，往往已经偏离十万八千里。

Matt 引用了《程序员修炼之道》里的一句话："没有人确切知道自己想要什么。"AI 时代这句话依然成立，只是甲方换成了 agent。

他的解法叫 Grilling Session，也就是让 AI 反过来"拷问"你。对应两个 Skill：

• **/grill-me**：让 agent 像面试官一样轮流追问你的设计，每个分支都问到你给出明确答案为止
• **/grill-with-docs**：升级版，会把你的回答和项目里已有的 CONTEXT.md（领域语言文档）做对照，发现术语冲突立刻指出来

grill-me 的核心 prompt 简单到让人意外，就一段话：

“

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

翻译过来就是"一次问一个问题，把决策树每个分支都走完，每个问题都给出你推荐的答案"。Matt 说这是他用得最多的两个 Skill，每次要做改动前都会先来一轮。

这个思路其实在传统软件工程里有个老名字，叫需求澄清。AI 把它自动化了。

顽疾 2：AI 太啰嗦，token 哗哗烧

Matt 引用了 Eric Evans 的《领域驱动设计》：在团队里，开发和领域专家一开始说的不是同一种语言。AI 也是。把 agent 丢进项目里，它要花大量 token 去推断你的"行话"。

举个他自己的例子。在他的 course-video-manager 项目里，有一个概念叫"课程章节里的某节课被赋予真实文件系统位置时出现的问题"，这一长串话每次描述都要烧一堆 token。后来在 CONTEXT.md 里把这个概念命名为 materialization cascade（实体化级联），之后一句"materialization cascade 出 bug 了"就完事。

这个共享语言带来的好处不止省 token：

• 变量、函数、文件命名会更一致
• agent 在代码库里导航更顺
• agent 思考时占用的 token 也更少

/grill-with-docs 在拷问你的同时，会把这些术语沉淀进 CONTEXT.md，硬一点的架构决策则写进 docs/adr/ 目录。Matt 说这可能是整个仓库里最强的一招，"很难解释它有多管用，你试一下就知道"。

ADR 写不写有三个判断标准，三个全满足才写：

1. 决策不容易反悔
2. 之后看代码的人会奇怪"为什么这么搞"
3. 是真有过权衡的结果

少写比乱写强。

顽疾 3：写出来的代码就是不对

需求对齐了，AI 还是写崩，怎么办？这时候问题不在沟通，在反馈回路。

Matt 的解法很经典：TDD 的红绿重构循环。对应 Skill 是 /tdd。

但他特别强调了一个反模式叫"水平切片"。很多人理解的 TDD 是：先把所有测试写完，再写所有实现。这种做法他认为会产出垃圾测试：

• 批量写出来的测试测的是想象中的行为，不是真实行为
• 你最后只会测到数据结构和函数签名这种"形状"，测不到用户实际能感知的行为
• 改动行为时测试通过，没改行为时测试反而挂

正确做法叫垂直切片或者叫追踪弹：写一个测试，写最少的代码让它通过，再写下一个测试，再写最少的代码。一颗一颗试射，不要把一弹夹一次打完。

错误（水平）：
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

正确（垂直）：
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  ...

另一个相关的 Skill 是 /diagnose，专门用来调难 bug。它把调试拆成六个阶段，最强调的是 Phase 1 反馈回路：

“

这一步是整套技能的核心。其他都是机械操作。如果你有一个快、确定、agent 能自己跑的 pass/fail 信号，你一定能找到 bug。如果没有，再怎么盯着代码看也救不了你。

排序优先级是：失败测试 > curl 脚本 > CLI 调用 > headless 浏览器 > 流量回放 > 一次性 harness > 模糊测试 > git bisect。人肉点击放在最后，不到万不得已不上。

写过几个难 bug 的人会立刻共鸣：90% 的精力其实应该花在"怎么稳定复现"上，剩下的 10% 才是修。

顽疾 4：项目变成一坨烂泥

最后一个问题是架构腐坏。AI 写代码快，烂得也快。代码库的复杂度增长速度比以往任何时候都猛。

Matt 给出的解决方案是从根上重新关心代码设计：

• /to-prd ：把当前对话整理成 PRD，会先问你打算改哪些模块
• /zoom-out ：让 agent 跳出当前文件，给你一张相关模块和调用方的地图
• /improve-codebase-architecture ：在已有代码里找"深化机会"

这里他引用了 John Ousterhout 在《软件设计哲学》里的核心观点：好模块是深的，复杂功能藏在简单接口后面。他把这套理念翻译成了一个具体的判断方法叫"删除测试"：把这个模块假想删掉，复杂度消失了，说明它本来就是个穿透层；复杂度反而出现在 N 个调用方里，说明它在认真干活。

/improve-codebase-architecture 这个 Skill 他建议每隔几天就在项目上跑一次，定期清淤。

几个让人眼前一亮的小工具

除了上面四类核心 Skill，仓库里还有几个有意思的小东西。

/caveman 穴居人模式

让 agent 像穴居人一样说话，删掉所有 a/an/the、客套、缓冲词。Matt 声称能省 75% 的 token。一个对比例子：

普通模式：
"Sure! I'd be happy to help you with that. The issue you're 
experiencing is likely caused by..."

穴居人模式：
"Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"

技术信息一字不少，水分全部蒸发。这个 Skill 出乎意料地实用，尤其是上下文吃紧的长会话里。

/git-guardrails-claude-code

这个戳中很多前端同学的痛点。给 Claude Code 装个 PreToolUse hook，拦截危险的 git 操作：

• git push（包括 --force）
• git reset --hard
• git clean -f
• git branch -D
• git checkout . / git restore .

被拦下来时，AI 会看到一句"你没有权限执行这个命令"，乖乖去找你确认。一行命令安好之后，再也不用担心 agent 一时手抖把 main 分支推飞。

/write-a-skill

写新 Skill 的脚手架。它会引导你产出符合规范的 SKILL.md，描述字段必须包含触发关键词，因为这往往是 agent 选择加载哪个 Skill 时能看到的全部信息。这种"自举"设计很 Matt 风格。

/triage

Issue 五态机：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。每条机器人留言强制带 > *This was generated by AI during triage.* 前缀，避免人类被 AI 评论搞混。这套流程更适合维护开源项目的人，普通业务开发未必用得上。

过去一年，Vibe Coding 这个词被反复提起。它指的是那种"凭感觉跟 AI 聊一聊就把代码生出来"的方式。爽是真爽，但维护起来谁用谁知道。Matt 这次开源 Skills，本质上是给社区一个反 Vibe 的样板：AI 不是用来代替工程纪律的，而是用来强化工程纪律的。

更值得琢磨的是，这套东西出自一个 TypeScript 教育者之手，不是 AI 公司的产品经理。它代表了一线工程师对 AI 协作的真实诉求：可控、可改、可组合，反对任何把流程变黑盒的做法。

如果你最近也在折腾 Claude Code、Codex 或者类似的 agent，建议直接把仓库 clone 下来翻一遍。哪怕你不打算照搬，里面对 TDD、CONTEXT.md、ADR 的工程理解，也值得看几遍。

仓库地址：https://github.com/mattpocock/skills