Matt Pocock 的 Skills：让 AI 编码从能跑到可信
Matt Pocock 是一个真实世界的工程师。
他每天用 AI 写代码。他发现了一个问题：
大多数 AI coding 技巧都在教你怎么「用 AI 写得更快」。
但很少有人教你「如何让 AI 写得可信」。
于是他把自己每天用的技能集开源了。
不是为了让 AI 写得更快，而是为了让 AI 写得更可靠、更可维护、更符合工程规范。
这个项目是什么？
GitHub： mattpocock/skills
一句话： 一套让 AI 编码从「能跑」变成「可信」的工程方法。
核心理念： "
"Developing real applications is hard. 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."
"These skills are designed to be small, easy to adapt, and composable. They work with any model. They're based on decades of engineering experience."
不是「一套框架」。
是「一组小而美的技能」，你可以组合使用，也可以修改成你自己的。
它解决的核心问题
问题 1：对齐失败（Misalignment）
"The most common failure mode in software development is misalignment."
你以为 AI 知道你要什么。
AI 写完了，你一看 —— 完全不是你想要的。
核心技能： /grill-me 和 /grill-with-docs
解决方法：
在 AI 开始写代码之前，先来一轮「拷问」：
- 这个功能的具体目标是什么？
- 边界条件是什么？
- 错误场景有哪些？
- 性能要求是什么？
- 安全考虑有哪些？
拷问结束后：
- AI 和你达成一致
- 所有的分支都被覆盖
- 没有模糊地带
这是最流行的技能。 因为它解决了最常见的问题。
问题 2：语言不通（Ubiquitous Language）
"At the start of a project, devs and the people they're building the software for are usually speaking different language."
项目有一堆术语：
- "materialization cascade"
- "lesson section"
- "course real"
AI 不知道这些是什么。
于是它用 20 个词描述一个概念，因为项目里已经有了一个词可以描述它。
核心技能： /grill-with-docs（内置）
解决方法：
创建一个 CONTEXT.md 文档，记录项目的「通用语言」：
# CONTEXT.md
## Materialization Cascade
The process of making a lesson "real" by giving it a spot in the file system.
## Lesson Section
A logical grouping of lessons within a course.
## Course Real
The state when a lesson has been materialized in the file system.效果：
- Before: "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)"
- After: "There's a problem with the materialization cascade"
这不只是简洁。
这是让 AI 和你用同一套语言思考。
变量名、函数名、文件名都会用这套语言。
代码库变得更容易导航。
AI 思考时花的 token 更少。
问题 3：反馈缺失（Feedback Loops）
"Without feedback on how the code it produces actually runs, the agent will be flying blind."
AI 写了代码，但不知道它能不能跑。
没有测试，没有类型检查，没有浏览器验证。
AI 在「盲飞」。
核心技能： /tdd 和 /diagnose
解决方法 1：TDD 循环
Red → Green → Refactor- Red： AI 先写一个失败的测试
- Green： AI 修复测试，让它通过
- Refactor： AI 重构代码
这个循环给了 AI 持续的反馈。
AI 知道代码能跑，因为测试通过了。
解决方法 2：诊断循环
Reproduce → Minimise → Hypothesise → Instrument → Fix → Regression Test当 AI 遇到 Bug：
- Reproduce： 复现问题
- Minimise： 最小化复现步骤
- Hypothesise： 提出假设
- Instrument： 添加日志、断点
- Fix： 修复
- Regression Test： 写回归测试
这是工程级的诊断方法。
不是「试试看」，而是「系统化排查」。
问题 4：设计腐烂（Design Decay）
"Because agents can radically speed up coding, they also accelerate software entropy."
AI 写代码太快了。
代码库的复杂度以空前的速度增长。
三个月后，你的代码库变成了一坨泥。
核心技能： /improve-codebase-architecture
解决方法：
定期（每几天）运行一次架构改进技能：
- 分析现有代码库
- 找出「深化机会」（模块化、抽象）
- 利用
CONTEXT.md的通用语言 - 利用
docs/adr/的架构决策 - 提出重构建议
- 执行重构
这不是「重构工具」。
这是「持续守护代码库质量」的方法。
核心技能清单
工程技能（每天用）：
| 技能 | 用途 |
|---|---|
/diagnose | 系统化诊断 Bug：复现 → 最小化 → 假设 → 工具 → 修复 → 回归测试 |
/grill-with-docs | 拷问计划，对齐通用语言，更新 CONTEXT.md 和 ADR |
/triage | 通过状态机管理 issue 分类 |
/improve-codebase-architecture | 定期改进代码库架构，防止腐烂 |
/tdd | 红绿重构循环，持续反馈 |
/to-issues | 把计划拆分成独立的 GitHub issues |
/to-prd | 把对话上下文合成 PRD |
/zoom-out | 让 AI 从系统层面解释代码 |
/prototype | 快速原型验证设计 |
通用技能：
| 技能 | 用途 |
|---|---|
/caveman | 压缩沟通模式，减少 75% token，保持技术准确性 |
/grill-me | 持续拷问计划，直到所有决策分支都解决 |
/handoff | 把当前对话压缩成交接文档 |
/write-a-skill | 创建新技能 |
为什么这套方法重要？
市面上有太多「AI coding 框架」：
- GSD（Get Shit Done）
- BMAD（Build Me A Dream）
- Spec-Kit
它们的共同问题：
它们试图「拥有整个流程」。
你把需求给它，它返回代码。
但你失去了控制：
- 不知道中间发生了什么
- 出了 Bug 不知道怎么修
- 代码不符合项目规范
- 无法定制化
Matt Pocock 的方法不同：
"These skills are designed to be small, easy to adapt, and composable."
- 小： 每个技能只做一件事
- 可组合： 你可以自由组合
- 可定制： 你可以修改成你自己的
它不拥有流程。
它给你工具，让你拥有流程。
安装和使用
安装：
npx skills@latest add mattpocock/skills选择：
- 选择你想要的技能
- 选择你想要安装的 coding agent（Claude Code, Codex, etc.）
- 确保选择
/setup-matt-pocock-skills
初始化：
在你的 agent 里运行：
/setup-matt-pocock-skills它会问你：
- 你用什么 issue tracker？（GitHub / Linear / 本地文件）
- 你在 triage 时用什么标签？
- 你想把文档保存在哪里？
然后，你就可以开始用了。
实战：一个完整的工作流
假设你要开发一个「用户下单」功能。
第 1 步：拷问对齐
/grill-with-docs
AI 拷问你：
- 下单流程的具体步骤是什么？
- 库存不足时怎么办？
- 支付失败时怎么办？
- 并发下单怎么处理？
- 订单状态机是什么样的？
拷问结束后：
- CONTEXT.md 更新了（通用语言）
- docs/adr/ 新增了架构决策记录
- 你和 AI 完全对齐了第 2 步：拆成 issues
/to-issues
AI 把功能拆成：
- Issue #1：设计订单状态机
- Issue #2：实现库存扣减逻辑
- Issue #3：实现支付集成
- Issue #4：实现订单查询
- Issue #5：实现错误处理第 3 步：TDD 开发
/tdd
AI 开始写第一个 issue：
- Red：写失败的测试
- Green：修复测试
- Refactor：重构代码
循环往复，直到 issue 完成第 4 步：诊断 Bug
/diagnose
遇到 Bug：
- Reproduce：复现问题
- Minimise：最小化步骤
- Hypothesise：提出假设
- Instrument：添加日志
- Fix：修复
- Regression Test：写回归测试第 5 步：定期架构改进
/improve-codebase-architecture
每几天运行一次：
- 分析代码库
- 找出复杂度高的模块
- 提出重构建议
- 执行重构这套方法的底层哲学
哲学 1：工程基础比以往更重要
"Software engineering fundamentals matter more than ever."
AI 加快了编码速度。
但它不改变工程的基本原则：
- 对齐
- 反馈
- 设计
AI 不是跳过工程。
AI 是放大工程。
哲学 2：小而美 > 大而全
"These skills are designed to be small, easy to adapt, and composable."
每个技能只做一件事。
你可以组合使用。
你可以修改它。
它不是框架。
它是工具箱。
哲学 3：控制权在你
"They take away your control and make bugs in the process hard to resolve."
其他框架试图拥有整个流程。
Matt Pocock 的技能给你工具，让你控制流程。
你知道每一步发生了什么。
出了问题你知道怎么修。
写在最后
AI coding 的现状：
太多人在教「怎么让 AI 写得更快」。
太少人在教「怎么让 AI 写得更可信」。
Matt Pocock 的 skills 项目是一个例外。
它不教你「快」。
它教你「靠谱」。
/grill-with-docs—— 确保 AI 理解你要什么/tdd—— 确保 AI 写的代码能跑/improve-codebase-architecture—— 确保代码库不会腐烂/diagnose—— 确保 Bug 能被系统化修复
这不是「AI coding 框架」。
这是「AI 时代的工程实践」。
Matt Pocock 是一个真实世界的工程师。
他把他的工程实践打包成了技能。
你可以直接用，也可以改成你自己的。
这才是 AI coding 该有的样子。
项目地址： https://github.com/mattpocock/skills
Newsletter： 60,000+ 开发者订阅，跟踪最新技能更新