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

解决 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 拆开揉碎，讲清楚三件事：

1. 它到底做对了什么、解决什么问题；
2. 30 秒安装 + 每个 skill 的实战使用攻略；
3. 和 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：日常开发主力军

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

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

1WRONG (horizontal):
2  RED:   test1, test2, test3, test4, test5
3  GREEN: impl1, impl2, impl3, impl4, impl5
4
5RIGHT (vertical, tracer bullet):
6  RED→GREEN: test1→impl1
7  RED→GREEN: test2→impl2
8  RED→GREEN: test3→impl3
9

为什么？因为水平切片让你对着想象中的行为写测试，结果就是测试只测"形状"（数据结构、函数签名），真正行为变了它都不报警。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：通用工作流工具

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

🧰 Misc：偶尔用一次

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

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

Step 1 - 一行命令安装

1npx skills@latest add mattpocock/skills
2

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

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

Step 2 - 跑一次初始化向导

1/setup-matt-pocock-skills
2

它会问你三件事：

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

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

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

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

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

这个顺序就是我自己摸出来的"标准打法"——先对齐、再 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 —— 像一套瑞士军刀。你愿意每个动作前手动选工具，但每把刀都磨得很锋利。最大优点：你完全 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。适用：大公司有强需求评审文化的团队。

选型决策树

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

我个人的搭配方案

我现在的工作流是：

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 的混乱、又不想被一个全包式框架绑死，强烈建议今天就跑一遍：

1npx skills@latest add mattpocock/skills
2

把 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 工作流深度拆解》 是转载文章，点击查看原文。