过去几个月，AI 编程社区聊得越来越少的是「哪个模型更会写代码」，聊得越来越多的是「怎么让 AI 按工程流程做事」。
原因不复杂：代码生成变便宜了，但需求对齐、上下文管理、架构腐化、验证和记忆这些老问题没有消失。AI 写得越快，它们冒头越快。
同类项目大概有几条路线。它们不是谁替代谁，更像是在回答同一个问题：工程师愿意把多少控制权交给流程？按这个轴看，差异会更清楚。
| 项目 | Star 数 | 控制权交给流程的程度 | 本质区别 | 更适合谁 / 什么场景 |
|---|---|---|---|---|
| Matt Pocock Skills | 约 159k | 低：开发者仍是主驾驶 | 小而锋利的开发者工具箱，把盘问、领域建模、handoff、prototype、架构做深这些动作做成可调用模块 | 更适合一线开发者和技术负责人；适合在真实代码库里按需调用，既借助 AI，又保留人的判断权 |
| Spec Kit | 约 119k | 中：把实现前的约束交给文档 | 文档驱动 / 规格驱动，把 spec 放在实现之前，用明确规格约束后续生成和验收 | 适合需求边界清楚、需要可追踪规格和验收标准的项目；尤其适合从 0 到 1 的功能建设 |
| Superpowers | 约 248k | 中高：用 hook 和流程替开发者踩刹车 | 更像一套带 hook 的工程纪律系统，用自动触发的流程约束 agent：先 brainstorm、再 spec、再 TDD、review、verification | 想让 agent 少自作主张、强制按流程走的团队；适合中大型改动和多人协作 |
| BMAD Method | 约 50k | 高：把产品流程交给多角色 agent | AI 原生敏捷流程，强调角色分工和流程剧本，更像把 PM、架构师、开发、QA 组织成 agent 团队 | 适合想用多角色 agent 跑完整产品流程的人；对个人小任务可能偏重 |
| GSD / get-shit-done | 约 65k | 很高：让 runtime 接管持续推进 | 更偏 runtime 和自动执行，用状态机、长期任务、自动推进来接管 agent 工作流 | 适合想把 agent 当持续执行系统的人；优势是自动化强，代价是理解和调试成本更高 |
所以这里没有「最好」的一套，只有哪套更适合手上的工作。想要强流程和自动护栏，Superpowers 更顺；想把需求先写成可执行规格，Spec Kit 更对味；想跑多角色产品流程，BMAD 更完整；想做长期自动执行，GSD 这类 runtime 化路线更像基础设施。
Matt Pocock 这套 skills 放在里面比较特别。它没有急着接管整个流程，而是把工程师每天会做、但经常被 AI 跳过的动作，封装成可以反复调用的小模块：先盘问需求，写领域词表，必要时 handoff，想不清就 prototype，代码库变浅了就做深。
它的默认读者不是「想把一切交给 agent 的人」，而是仍然想亲自掌握代码质量和架构判断的开发者。表面上看，这是一组 Claude Code skills；往下看，它围绕的是一个判断：AI 不是来替代软件工程基本功的，而是在放大这些基本功的杠杆。
AI 协作会悄悄变差
和 AI 写代码久了，会遇到几种熟悉的变差。
第一种是语言变糊。你和 AI 都在说「用户」「项目」「状态」「任务」，但这些词在不同文件、不同人、不同上下文里不是同一个意思。于是 AI 看似理解了，实际只是把模糊翻译成了另一种模糊。
第二种是上下文变胖。窗口越来越长，历史越来越多，模型不是越来越聪明，而是越来越像一个桌面堆满便签的人：什么都在，但注意力开始散。
第三种是纯语言推演失效。有些东西靠说想不清。交互顺不顺、状态机怪不怪、一个流程有没有绕，必须做出来看一眼。
第四种是代码库腐化加速。AI 能把实现速度拉上去，软件熵也会跟着上去。过去人类一周写出的泥球，现在可能半天就堆出来。
第五种是每次从零开始。今天 AI 终于理解了你的偏好、项目里的术语、你卡在哪；明天新开一个会话，很多东西又散了。
Matt 的五个核心 skill，正好分别踩在这些问题上。
先把话说清楚：grill-with-docs
整套体系里最核心的，是 /grill-with-docs。
它的前身是 /grill-me。Matt 先写了几句话，让 LLM 像一个不知疲倦的审稿人，沿着设计决策树往下问。每个问题先给推荐答案，等你反馈，再继续追问。这个 skill 很受欢迎，但 Matt 用久了以后发现，单纯盘问还不够。
问题在于：AI 经常变啰嗦，反复解释一个其实应该有名字的概念；更糟的是，有些概念根本没名字，因为人自己也没想清楚。就算这次聊清楚了，下一次会话也未必记得。
于是他问了一个很好的问题：我能给 AI 加上的、最薄的一层文档是什么？
答案来自领域驱动设计里的 ubiquitous language，也就是统一语言。让领域专家、开发者和代码库使用同一套词。不是为了文档好看，而是为了让「大家说的是同一件事」这件事变得可检查。
/grill-with-docs 做三件事：
- 找到或建立
CONTEXT.md，记录项目里的共享语言； - 在盘问过程中主动打磨术语，并和代码里的真实结构交叉验证；
- 把不显然、难撤销、背后有真实取舍的决策写成 ADR。
Matt 讲过一个 pitch 的例子。他要给课程系统加一个「视频包装」概念，AI 没有立刻写代码，而是先指出一个命名冲突：词表里把「独立视频」定义成 lessonId = NULL 的视频；但如果一个视频挂了 pitch，仍然满足 lessonId = NULL，那它还是独立视频吗？
这不是咬文嚼字。它会影响后面每个变量名、文件名、测试名和分支判断。
AI 给出两条路：要么保持「独立视频」的结构含义，把 pitch 当成正交元数据；要么重新定义独立视频，让它排除 pitch。AI 推荐前者，因为「独立」回答的是结构归属，「提案」回答的是包装关系。两者不是同一维度。
一行代码还没写，但系统已经少了一条未来会踩的坑。
这个例子说清了 Matt 这套东西的底色。它不是给 AI 加玄学提示词，而是把人类协作里最硬的东西搬过去：词要准，边界要清，取舍要留下来。领域驱动设计在人身上管用，在 AI 身上一样管用。
别让上下文变笨：handoff
第二个问题是上下文太长。
「上下文窗口大」很容易被误读成「推理质量一直稳定」。Matt 的体感是，哪怕 Claude Code 标称有很大的上下文窗口，真正聪明的区域也有限。大约过了 12 万 token 后，就会进入他称作 dumb zone 的区域：信息还在，注意力已经散了。
工具内置的 /compact 可以把整段会话压缩一下，把人从 dumb zone 拉回 smart zone。但这解决的是「当前会话太长」的问题，不解决另一个常见场景：你正在做 A，突然发现一个和 A 有关、但范围完全不同的重构机会 B。直接塞进当前会话，A 和 B 都会变脏；现在 compact，又会打乱手头上下文。
/handoff 的做法更窄：只把和 B 相关的一片上下文切出来，压成一份 Markdown，交给另一个干净 session。当前 session 继续做 A。
它的妙处在于这个 handoff 文档只是普通 Markdown。你可以在 Claude Code 里发现问题，把 handoff 丢给 Codex 或 Copilot CLI 做；也可以让另一个 agent 做 adversarial review。session 之间不需要共享整段历史，只需要共享那片经过压缩的、和任务有关的上下文。
Matt 有句话很妙：skills define the flavor of a session。skill 定义一个 session 的味道。
这句话挺准。一个专门做 prototype 的 session，和一个专门做 TDD 的 session，应该有不同的注意力结构、不同的验收方式、不同的输出形状。handoff 不是「换个聊天窗口」，而是把一件事切到更合适的认知容器里。
当然，handoff 文档是临时工作物。它会腐烂，不该进版本库，也不该带密钥和 PII。它的价值是转运上下文，不是成为新的知识库。
原型是手电筒：prototype
/prototype 解决的是另一个老问题：有些事说不清，得看。
Matt 对这个 skill 的定义很克制。prototype 不是产品，不是 MVP，也不是「顺手写个能上线的版本」。它只是用便宜的方式回答一个暂时判断不了的问题。
所以第一步不是写代码，而是弄清楚问题是什么。问题决定原型的形状。
如果你困惑的是逻辑、状态机、业务规则，它就做一个小终端程序，让你交互着跑几遍。如果你困惑的是界面或交互手感，它就在某条路由上做几个视觉变体，用 URL 参数切换。选错了形状，原型就会变成一坨没用但看起来很忙的代码。
好原型不需要精致。便宜、一次性、一条命令能跑、默认本地、少打磨、显式表达状态，就够了。它回答完问题后，要么删掉，要么把答案吸收到正式实现里。不要把脚手架留在仓库里发霉。
原文里那句最适合记下来：
The prototype is not the product. It is a flashlight.
原型不是产品。它是手电筒。
它和前两个 skill 的关系也在这里：grill-with-docs 盘问到一半，遇到一个「不看不知道」的问题，就用 /handoff 切到一个 prototype session；prototype 找到答案，再 handoff 回来，继续推进 PRD、issues 和实现。
这比在同一个会话里一路硬写舒服得多。一个 session 不必什么都懂，也不必什么都做。
修好产出，再修产生它的系统
第四个是 /improve-codebase-architecture。
AI 编程最危险的地方，不是它会写错代码。错代码人类也会写。更危险的是它写得太快，快到系统性问题也一起加速。你让 agent 修一个 bug，它可能修好了这一次，但下一次还会在同一个地方走错路。
Matt 的问法是：它为什么会犯这种错？
答案可能是 issue 写得太薄，也可能是领域语言不清楚，或者架构把正确的改动路径藏得太深。于是 /improve-codebase-architecture 不急着提「重写」，它找 deepening opportunities，也就是把模块做深的机会。
这里借的是 John Ousterhout《A Philosophy of Software Design》里的 deep module / shallow module 区分。深模块把大量有用行为藏在小而稳定的接口后面；浅模块则让调用者知道太多实现细节，接口不少，复杂度没少多少。
这个 skill 会先读项目里的领域词表和 ADR，再扫代码库，列出一组做深机会：哪些模块牵涉其中，复杂度泄漏在哪里，改完后接口会怎样更稳定，测试会怎样更容易写，agent 以后会怎样更不容易迷路。
它背后最重要的一句是：
Fix the output, then improve the system that produced it.
修好产出，再修产生它的系统。
这句话放在 AI 编程工作流里很合适。不能只盯着这次 diff 能不能过测试，还要看这次错误暴露了什么系统性缺口。否则 AI 只是帮你更快地绕过问题，没有让系统更好。
让 AI 记住你：teach
/teach 看起来离写代码远一点，但它延续的是同一条线。
AI 默认是一次性的。今天它终于知道你在学什么、已经懂了什么、哪里容易卡住；明天新开一个会话，又要重新解释。人类老师不会这样。好的老师会记得学生的当前位置，也会记得哪种讲法对这个人有效。
/teach 想把当前目录变成一个有状态的教学 workspace。
它先用 MISSION.md 逼你说清楚学习目标。「想变健康」不算目标，「十月跑完半马」才比较像。然后它按照最近发展区的原则，每次推你刚好够得着的一格。真正理解的关键认知写进 learning records，反复要查的内容沉淀成 reference docs。
它和前面的工程 skill 是同一套方法的教育版：learning record 像教学版 ADR，reference doc 像教学版 CONTEXT.md，MISSION.md 像教学版的「先对齐」。
Matt 这套体系有意思的地方就在这里。它不是给每个场景发明一套 AI 魔法，而是在反复使用同一组基本功：对齐目标，命名概念，留下记录，管理上下文，按刚好可承受的粒度推进。
五个 skill，其实是一套反劣化系统
把这五个 skill 放在一起，形状会清楚很多。
/grill-with-docs 对抗语言模糊。/handoff 对抗上下文膨胀。/prototype 对抗纯语言推演不够。/improve-codebase-architecture 对抗架构腐化。/teach 对抗无记忆。
它们的共同点不是「让 AI 更听话」，而是把 AI 放回一个更像工程实践的结构里。
现在很多 AI 工作流的问题，不是缺少更复杂的 prompt，而是缺少边界。什么时候该问？什么时候该切上下文？什么时候该做原型？什么时候该停下来修系统？这些判断，以前靠资深工程师的手感。skill 做的事，是把这种手感变成可重复触发的动作。
1.0 之后：从工具集合到路由体系
如果只看前面几个 skill，会觉得 Matt 做的是一组各自好用的小工具。到 1.0 之后，它开始有了路由、底座和分层。
第一层是 /ask-matt。你不确定该用哪个 skill，就先问它。它根据当前情境，把你路由到对应流程上。这个入口看起来简单，但很多 workflow 失败并不是工具不好，而是入口选错了。
第二层是共享底座。1.0 把 /codebase-design 和 /domain-modeling 抽了出来。以前深模块那套架构语言藏在 improve-codebase-architecture 里，领域模型那套逻辑藏在 grill-with-docs 里；现在它们变成可复用的底层能力。grilling 也被抽成独立能力，供 grill-me 和 grill-with-docs 共用。
第三层是调用分层：User-invoked 和 Model-invoked。
User-invoked 是你手动敲的编排入口，比如 ask-matt、grill-with-docs、tdd、prototype。Model-invoked 是 agent 在合适时机自动用的底座，比如 codebase-design、domain-modeling、grilling。
这里有条硬规则：user-invoked skill 可以调用 model-invoked skill，但不能互相调用另一个 user-invoked skill。编排层不许套娃。
这其实是 Matt 在实践他自己讲的架构原则：把重复能力抽成共享模块，把模块做深，把调用关系收紧。一个天天教别人别写浅模块的人，自己的 skill 体系也在往深模块演化。
真要用时，从这张图开始
不知道怎么选，直接用 /ask-matt 最省心。
但心里有张图也有用。大多数正经改动，都应该从 /grill-with-docs 开始。先把话说清楚，别急着写代码。盘问过程中遇到「得看到才知道」的问题，就切到 /handoff + /prototype，验证后再切回来。对齐完成后，再走 /to-prd → /to-issues → /tdd。
其他情况走岔路：bug 难定位，用 /diagnosing-bugs；代码越改越乱，用 /improve-codebase-architecture；合并冲突，用 /resolving-merge-conflicts；学习一个新技能，用 /teach。
底下的 /domain-modeling、/codebase-design、grilling 不需要你直接敲。它们是上层流程在需要时自动调用的底座。
这张路由图不是拿来背的。它只是提醒一件事：AI 写代码越快，入口选择越重要。入口错了，后面的每一步都可能看起来很努力，方向却是歪的。
写代码越便宜，基本功的杠杆越大
Matt 这套 skills 不酷炫，甚至有点老派。
先澄清语言。控制上下文。做便宜原型。维护架构。记录学习。听起来都不是新东西。也正因为不是新东西，才让人放心。软件工程里经得起时间的东西，本来就不多。
AI 让实现成本下降，但它不会自动解决语言、上下文、验证、架构和记忆问题。相反，实现越便宜，这些问题越容易被拖延，直到某天用更高的成本回来找你。
Matt 这套体系不靠某个 skill 显得神。它靠的是一个判断：把人类几十年验证过的工程和认知方法，重新封装给 AI。半小时对齐，可能省下几天返工；一次模块做深，可能减少很多次 agent 误入歧途；一次 handoff，可能保住两个 session 的清醒。
这些投入不算大，但能少走很多弯路。
如果要试，入口也简单：
npx skills@latest add mattpocock/skills
更稳妥的方式，是从一个真实项目开始，不要一下子把所有 skill 都用上。先跑通一条小链路：grill-with-docs → handoff/prototype → PRD/issues → TDD。等它真的减少过一次返工，再考虑把它变成团队习惯。
软件工程基本功没有过时，只是被 AI 放大了。