解决 4 大 AI 编码痛点：Matt Pocock 的 Skill 工作流深度拆解

当所有人都在用 AI 写更多代码的时候，TypeScript 之神 Matt Pocock 把自己的 .claude 目录直接推到 GitHub 上，告诉我们：先别急着 vibe coding，把工程基本功捡回来。

一、写在前面：一个让人拍大腿的开源项目

2026 年 3 月，TypeScript 社区的"老熟人"Matt Pocock（你大概率在他的 Total TypeScript 课程下面留过言）干了一件挺有意思的事：

他把自己平时在 Claude Code 里用的 .claude/skills 目录原样推到了 GitHub，仓库名就叫 mattpocock/skills，副标题写着------

Skills for Real Engineers. Straight from my .claude directory.

结果一夜之间冲上 GitHub Trending #1，目前已经累计 49.8K Star、4.1K Fork，被翻译进十几种语言的博客，连 Pulumi 官方博客都把它和 GSD、Superpowers 一起拉出来做对比分析。

第一次看到这个仓库的时候，我以为又是一个"AI 全自动开发框架"。点进去发现------压根不是。它没有花哨的多 Agent 编排、没有 Party Mode、没有所谓的 23 人虚拟团队。整个仓库只有 21 个 Markdown 文件，每个文件就是一段写给 Claude Code 的"工程原则提示词"。

但你跑过几次就会明白：这才是真正在写大型项目的工程师每天该做的事。

这篇文章我会把这套 skills 拆开揉碎，讲清楚三件事：

它到底做对了什么、解决什么问题；
30 秒安装 + 每个 skill 的实战使用攻略；
和 GSD、BMAD、Spec-Kit、Superpowers 这些"重型框架"的对比，到底什么时候该用哪个。

读完你大概率能少踩半年 AI 编码的坑。

二、Matt Pocock 在解决什么？四个真正的痛点

很多人对 AI 编程的认知还停留在"模型够强 + 提示词够好 = 自动出活"，但 Matt 在 README 里直接把刀架在了脖子上：

Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.

翻译过来就是：那些"全包式"框架本质上是把开发流程从你手里抢走了，一旦流程出 bug，你连改的地方都找不到。

他给出的解法不是"做一个更大的框架"，而是把工程师几十年来踩过坑、也救过命的几个"小动作"，每一个都做成 ~50 行的可组合 Skill。这些 Skill 围绕四个老掉牙却始终最致命的问题：

问题 #1：Agent 没听懂我在说啥（Misalignment）

"No-one knows exactly what they want." ------ The Pragmatic Programmer

最常见的 vibe coding 失败模式就是：你以为你说清楚了，Agent 以为它听懂了，等代码生成出来才发现完全是两回事。

Matt 的解法：在写代码前，先让 Agent 反过来"拷问"你。

/grill-me ------ 用于非代码类决策
/grill-with-docs ------ 代码场景的拷问 + 顺手更新领域文档

这是仓库里最受欢迎的两个 skill。每次改动前都先跑一遍，而不是直接喂 Prompt。

问题 #2：Agent 太啰嗦（Verbosity）

"With a ubiquitous language, conversations among developers and expressions of the code are all derived from the same domain model." ------ Domain-Driven Design

Agent 之所以啰嗦，是因为它进入项目时不懂你们团队的"行话"。所以它会用 20 个词描述一个概念，而你们内部一个词就够了。

Matt 给了一个具体例子（来自他自己的 course-video-manager 仓库）：

优化前：There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)
优化后 ：There's a problem with the materialization cascade

一旦你和 Agent 共享了一份 CONTEXT.md，每个 session 都能省下大量 token，变量名、函数名、文件名也会自动变得一致------这是 DDD 老炮儿最会心一笑的部分。

问题 #3：代码不 work（Code Quality）

"Always take small, deliberate steps. The rate of feedback is your speed limit." ------ The Pragmatic Programmer

Agent 写出 bug 不是模型问题，是反馈环没建立。没有类型检查、没有自动化测试、没有浏览器实时验证，模型就是闭眼开车。

对应的 skill：

/tdd ------ 真正的 red-green-refactor 循环（不是"先把所有测试写完再实现"那种伪 TDD）
/diagnose ------ 把"reproduce → minimise → hypothesise → instrument → fix → regression-test"做成 6 阶段的固定流程

问题 #4：项目变成大泥球（Architecture Decay）

"Invest in the design of the system every day." ------ Extreme Programming Explained

AI 让你写代码的速度提升 5 倍，也让代码烂掉的速度提升 5 倍。Matt 给出的解法是把"关心架构"这件事做进每一层 skill：

/to-prd 在生成 PRD 前先盘问你影响哪些模块
/zoom-out 强制 Agent 站在整个系统的视角解释代码
/improve-codebase-architecture 周期性地为你"修剪"代码库（建议每隔几天跑一次）

到这里你应该看出来了：这不是 AI 工具，这是工程师的清醒剂。

三、Skill 全清单：每个都讲一遍能拿来干嘛

仓库里目前的 skill 分三大桶：engineering、productivity、misc。我按使用频率从高到低过一遍。

🔥 Engineering：日常开发主力军

Skill	一句话定位	什么时候用
`grill-with-docs`	一边拷问你需求，一边更新 `CONTEXT.md`/ADR	每次开始一个新需求前
`tdd`	强制 red-green-refactor，反对"水平切片"	写新功能 / 修 bug
`diagnose`	6 阶段调试方法论，最先建反馈环	难复现 bug、性能回退
`to-prd`	把当前对话凝练成 PRD 并提交 issue	拷问完成后落地
`to-issues`	把 PRD/计划拆成"垂直切片"GitHub Issue	PRD 落地后准备并行执行
`triage`	Issue 状态机分类，按 label 流转	接手一个新 backlog 时
`improve-codebase-architecture`	找"加深模块"的机会、做架构精修	每隔几天 / 重构周
`zoom-out`	让 Agent 站在系统层面再讲一遍	进入陌生模块
`setup-matt-pocock-skills`	一次性配置 issue tracker / 标签 / 文档路径	装完 skills 第一次跑

重点解剖一下 `tdd` ------ 它真的不一样

绝大多数所谓的 "AI TDD" 都是水平切片：先把所有测试写完，然后让 Agent 把所有实现一次性写出来。Matt 直接把这种做法标成 anti-pattern：

yaml 复制代码

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical, tracer bullet):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

为什么？因为水平切片让你对着想象中的行为写测试 ，结果就是测试只测"形状"（数据结构、函数签名），真正行为变了它都不报警。Matt 强调：只测公共接口的行为，不要 mock 内部协作者。如果你重命名一个内部函数测试就挂，那这个测试本身就是错的。

`diagnose` 的核心金句

"If you have a feedback loop, you will find the cause --- bisection, hypothesis-testing, and instrumentation all just consume that signal."

整个 6 阶段里最重要的是 Phase 1：Build Feedback Loop 。一个 2 秒能跑完的确定性 pass/fail 信号，被 Matt 称为"调试超能力"。如果 bug 不稳定复现，先把复现率提到 50% 以上再继续。这条规则我自己用过，效率拉爆。

🛠️ Productivity：通用工作流工具

Skill	一句话定位
`caveman`	极简通信模式，token 占用立省 ~75%
`grill-me`	不写代码场景下的需求拷问
`write-a-skill`	帮你按规范写一个新 skill

caveman 这个名字非常有梗------"穴居人模式"，Agent 直接把废话和客气话全砍掉，只输出技术结论。开长会议、跑批量任务的时候非常省钱。

🧰 Misc：偶尔用一次

Skill	用途
`git-guardrails-claude-code`	给 Claude Code 装"git 安全护栏"，自动拦截 `push --force` / `reset --hard` / `clean -fd`
`migrate-to-shoehorn`	测试断言迁移到 `@total-typescript/shoehorn`
`scaffold-exercises`	Matt 自己课程的题目脚手架
`setup-pre-commit`	Husky + lint-staged + Prettier + tsc + test 一键配置

git-guardrails-claude-code 我建议所有人都装 。AI Agent 拿到 shell 权限后，最容易翻车的就是误执行 git reset --hard，这个 skill 直接在 hook 层把命令拦下来。

四、30 秒上手：完整安装与首次配置

Step 1 - 一行命令安装

bash 复制代码

npx skills@latest add mattpocock/skills

它会启动一个交互式 CLI，让你勾选：

想装哪些 skill（推荐至少勾上 setup-matt-pocock-skills、grill-with-docs、tdd、diagnose、to-prd、to-issues、improve-codebase-architecture）
装到哪个 Agent（Claude Code、Codex、Cursor 等都支持）

Step 2 - 跑一次初始化向导

text 复制代码

/setup-matt-pocock-skills

它会问你三件事：

Issue tracker 用什么？ GitHub Issues / Linear / 本地 .scratch/ markdown 都支持
triage 用什么标签？ 用于 /triage 的状态机标签词典
领域文档放哪里？ CONTEXT.md 和 docs/adr/ 默认在仓库根

跑完之后仓库里会多出来：

bash 复制代码

.
├── CONTEXT.md              # 共享领域语言
├── docs/
│   └── adr/                # 重要决策记录
└── docs/agents/
    └── triage-labels.md    # 标签字典

Step 3 - 第一次实战流（推荐打法）

text 复制代码

1. /grill-with-docs     ← 先让它拷问你，把领域语言落到 CONTEXT.md
2. /to-prd              ← 把对话凝结成 PRD 提交 issue
3. /to-issues           ← 拆成垂直切片 issue，可以并行干
4. 选一个 issue：
     /tdd              ← red-green-refactor 实现它
     /diagnose         ← 遇到难 bug 切到这个
     /zoom-out         ← 走进陌生模块时
5. 每周跑一次：
     /improve-codebase-architecture

这个顺序就是我自己摸出来的"标准打法"------先对齐、再 PRD、再切片、再实现，最后周期性精修架构。

五、最佳实战攻略：4 个我亲测有效的套路

套路 1：`grill-with-docs` 是省钱第一神器

很多人忽略 grill-with-docs 的副作用：它会把每次澄清的术语自动 commit 到 CONTEXT.md 。坚持几周，你的 CONTEXT.md 就会成为整个团队（包括人和 Agent）的"行话词典"，之后所有 session 启动 token 立省 30%-50%。

套路 2：让 `to-issues` 学会"垂直切片"

垂直切片 ≠ 按文件拆。每个 issue 应该是端到端可独立验收 的最小用户能感知到的改动（比如"在登录页加 Github OAuth 按钮"），不是 "加一个 OAuth utils 文件"。to-issues 内置了这条原则，强制你按行为拆。

套路 3：调试时先建 2 秒反馈环

遇到 bug 的本能反应是------读代码、加 print、改一改。diagnose 让你先停下来问：我现在有没有一个能在 2 秒内吐出 pass/fail 的命令？ 没有就先建。这一条改变了我对调试的认知。

套路 4：每周给项目"修剪"一次

improve-codebase-architecture 不是一次性 refactor，它的设计就是周期性使用 。每周五跑一次，让它根据 CONTEXT.md 和 ADR 找"可加深模块"的机会，给出小步快跑的清单。坚持一个季度，你会发现项目竟然没有变成大泥球。

套路 5：`caveman` + `git-guardrails` 长期开着

caveman 在长任务里能直接砍掉 75% 的 token。git-guardrails 帮你拦住所有"删库跑路"级别的命令。这俩装上忘掉就行。

六、横向对比：mattpocock/skills vs GSD vs BMAD vs Spec-Kit vs Superpowers

这是大家最关心的部分。我做了一张定位对比表：

维度	mattpocock/skills	GSD (Get Shit Done)	BMAD-METHOD	Superpowers	Spec-Kit
Star 数（写稿时）	49.8K	51K	---	149K	---
核心理念	不接管流程，给你工程基本功	接管 context window	接管 SDLC，模拟敏捷团队	接管 TDD 纪律	接管 spec → impl 的转换
抽象单位	Skill（.md 提示词）	Phase + Slash command	Agent 角色（PM/Architect/Dev/SM/QA...）	单 orchestrator + 子 agent	Spec 文档
典型命令	`/grill-with-docs` `/tdd` `/diagnose`	`/gsd auto` `/gsd discuss` `/gsd status`	`bmad-help` + 角色对话	TDD 7 阶段流	`specify` `plan` `tasks`
交付物	`CONTEXT.md` + ADR + issues	`.gsd/` 状态机 + HTML 报告	PRD + 架构文档 + Story	测试 + 实现	可执行 spec
可定制度	⭐⭐⭐⭐⭐ 一个 .md 一改	⭐⭐⭐ 改 PREFERENCES.md	⭐⭐ 受 agent 角色约束	⭐⭐⭐	⭐⭐⭐
学习成本	🟢 低	🟡 中	🟠 高	🟡 中	🟡 中
适用场景	日常工程，需要保留控制权	跨天/跨周的多文件长任务	真要按敏捷流程跑的产品/团队	单人 + 强 TDD 信仰	需求驱动型企业项目

三句话讲清楚每个的"性格"

mattpocock/skills ------ 像一套瑞士军刀 。你愿意每个动作前手动选工具，但每把刀都磨得很锋利。最大优点：你完全 own 流程，每一步都能改。

GSD ------ 像一套全自动流水线 。它把 context window 当成核心约束来管理：每个 phase 一个全新的 200K 上下文，状态全部落盘到 .gsd/，崩了能恢复，超预算会停。最大优点：长任务零 context rot；缺点：杀小项目。

BMAD-METHOD ------ 像一支虚拟敏捷团队 。你不是和一个 Agent 对话，而是和 PM、Architect、SM、Dev、QA 这些 persona 轮流开会。Party Mode 还能让多个 persona 一起讨论。最大优点：把"敏捷流程"内化进了工具；缺点：流程重，新手会被淹没。

Superpowers ------ TDD 警长 。一个 orchestrator 调度子 agent，所有产品代码必须先有失败测试。最大优点：纪律性最强；缺点：单 orchestrator 在超长 session 里 context 会爆。

Spec-Kit ------ 规格驱动开发 。先写正式 spec，然后 plan、tasks、implement。适用：大公司有强需求评审文化的团队。

选型决策树

bash 复制代码

你的项目是？
├── 一个长期演进的真实产品（>3个月）
│   └── 团队人多 / 需要敏捷流程 → BMAD
│   └── 单人/小团队，但要 own 控制权 → mattpocock/skills
│   └── 长任务多文件，怕 context rot → GSD
│
├── 一次性的小项目 / 学习项目
│   └── 想培养工程纪律 → mattpocock/skills（推荐入门）
│   └── 强信仰 TDD → Superpowers
│
└── 企业级，需求评审重 → Spec-Kit

我个人的搭配方案

我现在的工作流是：

mattpocock/skills 做"日常打法"，GSD 用于跨天长任务。

grill-with-docs 把领域语言沉淀下来，然后用 to-issues 切成垂直切片。单个切片如果预计能在 1 个 session 内做完，就直接用 /tdd + /diagnose；如果是跨天的大切片（比如改造 5+ 文件的迁移），就开 /gsd auto 让它自己跑，崩了恢复也方便。

BMAD 我只在新启动的产品项目里用------那种真的需要 PM/Architect 角色感的场景。日常 CRUD 用 BMAD 属于杀鸡用牛刀。

七、几个值得细嚼的设计决策

1. 为什么选 Markdown 而不是 DSL？

整个仓库就是一堆 SKILL.md，没有自己的语法、没有插件 API、没有运行时。这种克制本身就是一种设计------任何 LLM 都能读 Markdown，任何编辑器都能改 Markdown，任何工程师都能贡献。Matt 完全没想做 lock-in。

2. 为什么强调"composable"？

每个 skill 都很短（~50 行），每个 skill 都假设其他 skill 也存在。grill-with-docs 写完会喂给 to-prd，to-prd 写完会喂给 to-issues，to-issues 写完会喂给 tdd。它不强迫你跑全套，但配合起来就是完整工作流。

3. 为什么把 ADR 放在第一线？

这点最反直觉。一般框架要么完全不管文档，要么把文档当成事后产物。Matt 把 ADR 当成 grill-with-docs 的副产品------只在决策"难以反转、缺少上下文会让人困惑、有真实 trade-off"时才写。这个判断标准值得抄走。

4. `caveman` 的存在透露了什么？

它说明 Matt 真的在乎 token 成本。一个连"穴居人模式"都开发出来的人，对工程实用主义的关注是写在 DNA 里的。

八、写在最后：为什么这套 Skills 能打动我

我用过 BMAD、试过 GSD、抄过 Superpowers 的 prompts。它们都很厉害，但都让我有一种"在被框架推着走"的感觉。

mattpocock/skills 给我的感觉完全不一样：它没有取代我的判断 ，而是把我十几年来好不容易养成的习惯（先对齐、先建反馈环、先关心架构）固化成 Agent 也能执行的提示词。当我说 /grill-with-docs 的时候，我清楚地知道接下来会发生什么、为什么这么做、出问题该怎么改。

AI 不是来替你做工程师的，是来放大你工程能力的。

但前提是------你得真的有工程能力。

如果你也受够了 vibe coding 的混乱、又不想被一个全包式框架绑死，强烈建议今天就跑一遍：

bash 复制代码

npx skills@latest add mattpocock/skills

把 grill-with-docs、tdd、diagnose 三件套先用起来，一周后你会回来给这篇文章点赞的（笑）。

参考资源

项目地址：github.com/mattpocock/...
BMAD-METHOD：github.com/bmad-code-o...
GSD-2：github.com/gsd-build/g...
Pulumi 框架对比博客：www.pulumi.com/blog/claude...
Matt Pocock Newsletter：aihero.dev/s/skills-ne...

如果这篇文章对你有帮助，欢迎在评论区聊聊你目前的 AI 编码工作流是什么样的，或者你最想看哪个 skill 的逐字解读。

Happy Coding !

解决 4 大 AI 编码痛点：Matt Pocock 的 Skill 工作流深度拆解