用 Claude Code 写了几个月代码之后，我开始怀疑自己一直在用错误的方式用它。

不是因为出了什么大问题，而是一种隐约的不对劲：agent 跑出来的代码，往往在细节上偏离我的意图；我以为它理解了需求，等看到结果才发现各说各的。于是我开始花大量时间在后期纠偏上，而不是把精力放在真正有价值的事情上。

就在这个时候，Matt Pocock 把自己的 .claude 目录推上了 GitHub。

Matt Pocock 是谁，他为什么会做这件事

如果你在 TypeScript 圈混过，大概率知道他。Total TypeScript 的作者，YouTube 频道超过 10 万订阅，被社区称为"TypeScript 布道者"。他不是那种喜欢蹭热点写博客的人——在这个仓库之前，你几乎找不到他专门写 AI 工具使用技巧的内容。

2026 年 4 月 28 日，他把一个仓库推上了 GitHub，标题只有一句话：

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

没有博客，没有 YouTube 视频，没有 Hacker News 帖子。就这么推了出去。

24 小时后，22000 星。第六天持续登上 GitHub Trending 全球第二。截止目前，85800+ 星，7400+ 个 fork。这是一个在 AI 工具圈很少见的数字——因为大多数"prompt 技巧仓库"的生命周期通常以周为单位，而这个还在持续增长。

这种有机生长的背后，说明社区踩到了同一个痛点。

他说的"不是 vibe coding"到底是什么意思

Vibe coding 这个词现在有点被滥用了，但 Matt 想说的很具体：让 AI 自由发挥，你只是在验收结果——这不是工程，是赌博。

他的仓库 README 里列了四类常见失败模式，我觉得说得相当准：

失败模式一：意图对齐失败。 你心里有一个设计，agent 心里有另一个设计，双方都以为在说同一件事。等代码跑出来才发现南辕北辙。这不是 Claude 的问题，是你没有在开始编码之前把需求逼得足够清晰。

失败模式二：缺乏领域语言，反复解释同一件事。 每次新开一个对话窗口，你都要重新解释"我们的项目里 X 是什么意思"。积少成多，token 浪费是小事，命名不一致才要命。

失败模式三：没有反馈回路，靠直觉走。 没有测试驱动，agent 写代码的方向就像蒙眼走路。它以为过了，你以为过了，上线了才知道没过。

失败模式四：架构腐化是个缓慢的过程，人感受不到。 AI 加速了代码生成，也加速了技术债积累。没有定期的架构审视机制，六个月后回来看自己的仓库会不认识。

这四个失败模式不是 AI 时代的新问题，它们本质上是软件工程里从来没解决好的老问题，只是 AI 让它们的代价来得更快了。

Matt 的 Skill 仓库，就是他用来把这四个问题系统性地塞进日常工作流的方式。

仓库里有什么：18 个 Skill 的全貌

仓库里的 Skill 分三类，我按实用程度排一下：

工程类（10 个）：核心中的核心

Skill	一句话说清楚它干嘛
/tdd	强制红绿重构循环，一次只写一个测试
/diagnose	六阶段调试法，从复现到事后复盘
/grill-with-docs	拷问你的设计，同时更新 CONTEXT.md 和 ADR
/grill-me	穷举决策树，开始编码前逼你想清楚
/to-prd	把对话上下文转成带 User Story 的 PRD
/to-issues	把 PRD 拆成可独立执行的竖切 GitHub Issue
/triage	状态机驱动的 Issue 分类
/improve-codebase-architecture	定期识别模块边界腐化，提炼共享语言
/zoom-out	让 agent 在陌生代码里先建立系统级理解
/prototype	快速脏原型，终端应用或 UI 变体

效率类（4 个）：省 token + 省脑力

Skill	一句话说清楚它干嘛
/caveman	极度压缩通信，token 减少约 75%
/grill-me	同上，设计审查专用入口
/handoff	agent 换窗口时生成紧凑的上下文摘要
/write-a-skill	写新 Skill 的 Skill，元层

杂项（4 个）

git-guardrails（拦截危险 git 操作）、migrate-to-shoehorn（类型断言迁移）、scaffold-exercises（练习脚手架）、setup-pre-commit（Husky + lint-staged 初始化）。

装这整套的命令：

npx skills@latest add mattpocock/skills

然后在项目里跑一次 /setup-matt-pocock-skills，它会问你用 GitHub Issues 还是 Linear，问你文档放哪儿，问你想激活哪几个 Skill——配置完之后你就有了一套相对完整的工程脚手架。

图：四类 AI 编程失败模式与对应 Skill 的映射关系

值得反复用的 Skill：拆开来看看

我把其中几个用了一段时间，说说真实感受。

/grill-me：编码前最重要的一步

这是整套里我用得最多的一个。本质上很简单：你把计划告诉 agent，它开始穷举追问你，直到双方对需求达成精确共识。

第一次用的时候，agent 连续问了我 38 个问题。

你可能觉得这听起来很烦，但我第一次真正意识到：那 38 个问题里，有将近一半是我从来没有认真想过的边界情况。错误处理怎么设计、第三方集成失败的回退逻辑、用户数据隔离的粒度——这些我都以为自己"大概想清楚了"，实际上完全没有。

/grill-me 把这个"幻觉确认"的过程强制外显。你不得不把模糊的想法变成能被质疑的具体描述。

一个实用的使用姿势：不要在「我想做什么」阶段用它，要在「我已经有了第一版方案」之后再用。带着具体的设计去让它质疑，比带着模糊想法去让它帮你发散效率高得多。

/tdd：一次只前进一步

TDD 这件事大家都知道，但用 AI 做 TDD 和传统 TDD 有个不小的差异：agent 天然倾向于一次性写完所有测试，然后再一次性实现，然后你发现测试验证的是想象中的行为，而不是实际需求。

/tdd 的核心约束只有一条：一次只写一个测试，写完了才能动实现代码。

Skill 里还有几个具体规则我觉得很有价值：

• 测试只通过公共接口验证行为，不验证内部实现细节
• 重构只发生在所有测试绿了之后，绝对不在红灯状态下重构
• 代码只写刚好让当前测试过的最少量——不多写一行

这三条规则约束的不只是 Claude，同样在约束你自己。你被迫慢下来，一次处理一件事，而不是用"差不多应该行"的感觉把一大段代码推进去。

/diagnose：你永远不会再靠直觉排查 Bug

这个 Skill 解决的是一个很具体的问题：我们的 Bug 排查往往是跳跃的，"先试试 A，不行再试试 B"，既没有可复现的信号，也没有系统化的假设。

/diagnose 强制走六个阶段：

1. 建立反馈回路：先构造一个快速、确定性的 pass/fail 信号（自动化测试 / HTTP 脚本 / CLI 命令），没有这个信号就不开始排查
2. 复现：确认失败表现和用户描述一致
3. 形成假设：列出 3-5 个可证伪的假设，每个假设预测一个具体现象
4. 工具化：为每个假设打上有唯一 tag 的日志（[DEBUG-a4f2] 这种），方便后期清理
5. 修复 + 回归测试：在正确的架构层写测试，先看它红，修复后看它绿
6. 清理 + 事后复盘：删掉调试日志，记录哪个架构改动能预防类似问题

这套流程和 Google SRE 的事后分析文化很接近，但压缩成了一个可以随时触发的 Skill。真正按这个流程走一遍之后，你会发现自己之前大量时间浪费在了没有信号的蒙眼猜测上。

/to-issues：竖切而不是横切

这个 Skill 帮你把 PRD 拆解成 GitHub Issue，但它有一个核心观点：一定要竖切，不要横切。

横切是这样的：先建一个"设计数据库 Schema"的 Issue，再建"写 API"，再建"做前端"——每个 Issue 只覆盖一个技术层，依赖关系是串行的，任何一层卡住全盘停。

竖切是另一种逻辑：一个 Issue 应该穿透所有层（Schema + API + 前端 + 测试），完成后是一个端到端可验证的功能切片——薄，但完整。

/to-issues 还会把每个 Issue 打上标签：

• HITL（Human In the Loop）：需要人来做决定，agent 不能独立完成
• AFK（Away From Keyboard）：可以完全交给 agent 跑，人去喝杯咖啡

这个分类很有意思，它迫使你在规划阶段就想清楚哪些决策不能外包给 AI。

一个工程师的真正收获：是思维框架而不是快捷键

用了一段时间之后，我的感受是：Matt 的 Skill 仓库最有价值的不是那 18 个 /命令，而是它背后的设计哲学。

每个 Skill 的背后都有一个工程原则：

• /grill-me 来自传统的需求澄清会议，只是把它外包给了 AI
• /tdd 来自 Kent Beck 的极限编程，只是把约束显式化
• /diagnose 来自科学方法论，只是适配了软件调试场景
• /to-issues 来自 John Ousterhout 的"Deep Module"理论，以及敏捷开发的竖切原则

这些都不是新东西。新的是把它们打包成 Skill，让 AI 在每次执行时自动执行这些约束——哪怕你累了、哪怕你在赶 deadline。

还有一件事我觉得被忽视了：CONTEXT.md 这个概念。

每个项目维护一个领域词汇表，把项目里那些"说起来要解释半天"的概念定义清楚。Matt 举的例子是：与其每次说"把一个课程分配到文件系统里的实际位置"，不如定义一个词叫 materialization cascade，之后 agent 和人说话都用这个词。

这个思路直接来自 DDD 里的"统一语言"（Ubiquitous Language）。在 AI 协作场景里，它有额外的价值：减少 token 消耗，同时让命名在整个项目里保持一致。

这套方法的局限在哪里

说公道话：这套 Skill 的适用场景是有边界的。

它最适合已经有工程化基础的项目。 如果你在做原型验证，需求每三天变一次，强行套 PRD → Issues → TDD 流程只会让你痛苦。Vibe coding 在这个阶段不是坏事，是合理选择。

它假设你用 GitHub 作为 Issue Tracker。 triage、to-issues 这些 Skill 深度绑定 GitHub Issues 的工作流，用 Linear 或 Jira 的团队需要自己改造。

/grill-me 的成本比你想象的高。 38 个问题不是个玩笑。如果你在一个节奏很快的团队里，每个功能开始前都要做这个流程，会遭到抵触。更实际的做法是：只对高风险、高耦合的功能模块使用，小改动跳过。

Skill 本身不等于能力。 装了 /tdd 不会让你自动变成 TDD 高手。如果你对测试驱动开发没有基本的理解，Skill 只是给你一个形式，填不进去真正的内容。这和学设计模式是一样的道理。

常见问题

Q：这些 Skill 只能用 Claude Code 吗？

不。Skill 文件是标准 Markdown，遵循 Anthropic 的 SKILL.md 规范。Cursor、OpenCode 等支持 SKILL.md 的工具都能用。Matt 自己说，这个规范的好处就是没有厂商锁定。

Q：我需要把这 18 个 Skill 全装上吗？

不需要。你可以单独装某一个：

npx skills@latest add mattpocock/skills/tdd
npx skills@latest add mattpocock/skills/diagnose

建议先装 /grill-me 和 /tdd，用一两周，感受一下工作流的变化。有需要了再加其他的。

Q：/caveman 是什么原理，真的能省 75% 的 token 吗？

它通过极度压缩语言、去掉礼貌用语和冗余修饰词，强制 agent 和你用最短的方式传递信息。理论上是有效的，但 75% 这个数字是 Skill 文件里描述的理想情况，实际效果取决于你原来对话的冗余程度。对于已经很精简的对话，提升有限。

Q：CONTEXT.md 要怎么开始写？

最简单的起点：在项目里创建一个 CONTEXT.md，把你在对话里解释过不止一次的概念写进去。然后用 /grill-with-docs 让 Claude 帮你识别哪些表述不一致、哪些词需要进入词汇表。积累下来，这个文件会成为项目最有价值的文档之一。

Q：这和 Anthropic 官方的 Skill 仓库有什么区别？

Matt 的仓库是他个人的工程工作流，偏向 TypeScript 项目和 GitHub Issues 场景，有强烈的个人风格。Anthropic 官方的 Skill 目录覆盖更广，但相对通用，缺少这种"真实使用后提炼出来"的质感。两者可以同时用，不冲突。

说到底，mattpocock/skills 代表的不是"某个人的 prompt 技巧合集"，而是一个更根本的判断：AI 编程的瓶颈从来不在模型能力上，而在你是否愿意给它一个结构良好的工程容器。这个容器越清晰，AI 能做的事情就越可预期，你需要花在纠偏上的时间就越少。