用 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 初始化）。
装这整套的命令：
bash
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 强制走六个阶段：
- 建立反馈回路：先构造一个快速、确定性的 pass/fail 信号（自动化测试 / HTTP 脚本 / CLI 命令），没有这个信号就不开始排查
- 复现：确认失败表现和用户描述一致
- 形成假设：列出 3-5 个可证伪的假设，每个假设预测一个具体现象
- 工具化 ：为每个假设打上有唯一 tag 的日志（
[DEBUG-a4f2]这种），方便后期清理 - 修复 + 回归测试：在正确的架构层写测试，先看它红，修复后看它绿
- 清理 + 事后复盘：删掉调试日志，记录哪个架构改动能预防类似问题
这套流程和 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 全装上吗？
不需要。你可以单独装某一个：
bash
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 能做的事情就越可预期，你需要花在纠偏上的时间就越少。
