# 爆火的 mattpocock/skills 到底说了什么，我们能从中学到哪些

Matt Pocock 用纯 Markdown 文件教 AI 编程代理怎么"好好写代码"，这套技能背后的理念可能是对"AI 编程到底缺什么"最清晰的回答。

Canonical: https://samanhappy.com/zh/writing/mattpocock-skills-deep-dive
Language: zh-CN
作者: 青扬
最后更新: 2026-05-28


最近在 AI 编程圈子里，Matt Pocock 的 `mattpocock/skills` 仓库火了。

Matt Pocock 是谁？如果你写 TypeScript，大概率看过他的教程。但这次他搞的东西跟 TypeScript 无关——他做了一套**纯 Markdown 文件**，用来教 AI 编程代理（比如 Claude Code）怎么"好好写代码"。

是的，没有 JavaScript，没有 Python，没有任何可执行代码。就是一堆 `.md` 文件。

但这些文件背后的思路，可能是我见过的对"AI 编程到底缺什么"这个问题最清晰的回答。

## 一、Vibe Coding 的问题

先说个背景。

自从 AI 编程工具普及以来，一种叫 "vibe coding" 的工作方式流行起来了：你大概描述一下想要什么，AI 哗哗生成一堆代码，跑起来差不多能用，完事。

快吗？快。爽吗？爽。但有个问题——**你不知道你不知道什么**。

代码能跑，但：

- 边界情况没处理，你不知道
- 架构已经腐化，你不知道
- 测试只覆盖了 happy path，你不知道
- 某个决策是错的，等三个月后才发现，你更不知道

Vibe coding 的本质是**用速度换确定性**。短期内看起来效率很高，但债务在暗处累积，直到某天你发现改不动了。

Matt Pocock 的 skills 项目，就是针对这个问题的解药。

他的核心观点很简单：**AI 编程需要的不是更聪明的模型，而是更好的纪律。**

## 二、把纪律编码成工作流

这个项目的 14 个技能（skills），每一个都是一个**结构化的工作流**。你通过斜杠命令调用它们，AI 就会按照预设的流程跟你协作，而不是直接给你一坨代码。

我挑最有代表性的几个讲。

### `/grill-me`：用追问代替猜测

这是整个项目的旗舰技能。

当你有一个方案或计划时，你输入 `/grill-me`，AI 会进入"拷问模式"——它会**一个接一个地问你问题**，逼你把每个决策的分支都走清楚。

不是那种"你觉得怎么样？"的客套问法，而是：

- "这个方案依赖 X，但 X 还没定义，你怎么处理？"
- "你说'大概可以用 Redis'，'大概'是什么意思？你确定了吗？"
- "这个决策一旦做了很难改，你考虑过替代方案吗？"

每个问题，它还会给出**推荐答案**，然后让你确认或否决。

这个技能的理念是：**大多数错误不是在写代码时犯的，而是在写代码之前犯的。** 如果你在对齐阶段就把所有分支想清楚了，写代码反而是最简单的部分。

这让我想起《Pragmatic Programmer》里的一句话："不要用代码去试探问题，要去理解问题。"

### `/tdd`：垂直切片，不是水平切片

TDD（测试驱动开发）大家都知道，但很多人在 AI 辅助下的做法是：先让 AI 写一堆测试，再让 AI 写实现。这叫**水平切片**——先把所有测试铺开，再逐个实现。

Matt 的 `/tdd` 技能明确禁止这种做法。它要求的是**垂直切片**：

1. 写**一个**测试
2. 运行测试，确认它因缺少目标行为而失败
3. 写**最小**的实现，让测试通过
4. 重构
5. 回到第 1 步

为什么？因为水平切片的问题是：你写了 20 个测试，实现到第 5 个时发现前面的假设全错了，那 15 个测试白写了。

垂直切片强迫你**每一步都有反馈**。每写一个测试，你就验证一次假设。错了，代价只是一行代码，不是一下午。

这个技能里还有一条很有意思的规则：**禁止为了测试而扭曲设计**。如果一个东西很难测，那可能是设计有问题，不是测试框架的问题。它会引导你去思考"为什么这个接口这么难用"，而不是教你怎么 mock。

### `/diagnose`：构建反馈循环本身就是技能

调试疑难 bug 时，大多数人的做法是：看报错信息，猜一个原因，改一下试试，不行再猜。

`/diagnose` 把调试变成一个**6 阶段的结构化流程**：

1. **构建反馈循环** — 先确保你能稳定复现问题
2. **复现** — 写一个最小的复现步骤
3. **假设** — 列出 3-5 个可能的原因，按可能性排序
4. **插桩** — 加日志、断点、检查点来验证假设
5. **修复** — 找到根因后修复，并写回归测试
6. **清理** — 移除调试代码，写个简短的事后复盘

这里面最有冲击力的理念是第一步：**构建反馈循环本身就是技能。**

很多人调试时直接跳到"猜原因"，但如果你连稳定复现都做不到，你所有的猜测都是在黑暗中开枪。先确保你能"看到"问题，再去"修"问题。

这跟软件工程里的一条基本原则一致：**你无法优化你无法测量的东西。**

## 三、轻量，但不随意

你可能会问：这些不就是些 Markdown 吗？谁都能写啊？

是的，谁都能写。但 Matt 的设计有几个很巧妙的地方值得学。

**第一，每个技能都是一个结构化的对话协议，不是一堆建议。** 它不是告诉你"记得写测试哦"，而是定义了 AI 在每一步应该问什么、做什么、检查什么。这种"把流程编码"的思路，比写一堆 best practice 文档有效得多。

**第二，模型无关。** 这些技能不依赖任何特定 AI 的能力。它们是纯文本指令，换到 Claude、GPT、Gemini 上都能用。这让这套东西的生命周期比任何特定工具都长。

**第三，可组合。** 你可以先用 `/grill-me` 对齐方案，再用 `/tdd` 实现，最后用 `/diagnose` 调试。每个技能独立，但可以串成完整的工作流。

## 四、我们能学到什么

读完整个项目，我觉得有 3 个模式可以直接带走，用在你自己的 AI 编程实践中：

### 1. 先对齐，再动手

在让 AI 写代码之前，花 5 分钟把方案想清楚。不一定要用 `/grill-me`，但至少问自己：

- 这个方案的核心假设是什么？
- 哪些决策一旦做了很难改？
- 有没有我没考虑过的边界情况？

这 5 分钟能省你 2 小时的返工。

### 2. 用结构化流程代替随意试探

不管是写代码、测试还是调试，定义一个清晰的步骤序列，然后严格执行。不要"想到哪写到哪"。

垂直切片 TDD、6 阶段诊断——这些流程看起来"慢"，但实际上每一步都有反馈，出错的代价最小。

### 3. 把知识编码成可复用的指令

如果你发现自己在反复告诉 AI 同样的事情（"记得处理错误"、"不要用 any"、"先写测试"），那就把它写成一个结构化的技能文件。

一个 50 行的 Markdown 文件，比你每次手动输入 10 遍同样的话有效得多。这也是 Matt 这个项目最核心的启示：**最好的工具不是帮你写代码的，是帮你建立习惯的。**

## 五、试试看

如果你想体验一下：

```bash
# 安装
npx skills@latest add mattpocock/skills
```

然后在 Claude Code 里试试 `/grill-me`，给它一个你正在考虑的方案，看看它怎么"拷问"你。

你也可以直接去 GitHub 看源码——全是 Markdown，没有任何门槛：`github.com/mattpocock/skills`

不需要全部用上。挑一个最痛的场景，装一个对应的技能，用一周试试。你会发现，AI 编程的质量上限，不取决于模型有多强，而取决于你的流程有多清晰。