最近在 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 步
为什么？因为水平切片的问题是：你写了 20 个测试，实现到第 5 个时发现前面的假设全错了，那 15 个测试白写了。
垂直切片强迫你每一步都有反馈。每写一个测试，你就验证一次假设。错了，代价只是一行代码，不是一下午。
这个技能里还有一条很有意思的规则：禁止为了测试而扭曲设计。如果一个东西很难测，那可能是设计有问题，不是测试框架的问题。它会引导你去思考”为什么这个接口这么难用”，而不是教你怎么 mock。
/diagnose：构建反馈循环本身就是技能
调试疑难 bug 时，大多数人的做法是：看报错信息，猜一个原因，改一下试试，不行再猜。
/diagnose 把调试变成一个6 阶段的结构化流程：
- 构建反馈循环 — 先确保你能稳定复现问题
- 复现 — 写一个最小的复现步骤
- 假设 — 列出 3-5 个可能的原因，按可能性排序
- 插桩 — 加日志、断点、检查点来验证假设
- 修复 — 找到根因后修复，并写回归测试
- 清理 — 移除调试代码，写个简短的事后复盘
这里面最有冲击力的理念是第一步：构建反馈循环本身就是技能。
很多人调试时直接跳到”猜原因”，但如果你连稳定复现都做不到，你所有的猜测都是在黑暗中开枪。先确保你能”看到”问题，再去”修”问题。
这跟软件工程里的一条基本原则一致：你无法优化你无法测量的东西。
三、轻量，但不随意
你可能会问：这些不就是些 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 这个项目最核心的启示：最好的工具不是帮你写代码的，是帮你建立习惯的。
五、试试看
如果你想体验一下：
# 安装
npx skills@latest add mattpocock/skills然后在 Claude Code 里试试 /grill-me，给它一个你正在考虑的方案，看看它怎么”拷问”你。
你也可以直接去 GitHub 看源码——全是 Markdown，没有任何门槛：github.com/mattpocock/skills
不需要全部用上。挑一个最痛的场景，装一个对应的技能，用一周试试。你会发现，AI 编程的质量上限，不取决于模型有多强，而取决于你的流程有多清晰。