mattpocock/skills：给真实工程师的技能——反对接管流程，相信工程品味

这是「编码代理技能库」三部曲的第三篇。前两篇讲了Superpowers(给代理立规矩的"纪律派")和ECC(全家桶的"体系派")。 今天这篇讲 mattpocock/skills—— 一个 20.9 万 star、自称 "Skills for Real Engineers"(给真实工程师的技能)的项目， 作者是 Matt Pocock： 知名的 TypeScript 教育者(Total TypeScript)、 前 Vercel / Stately 工程师。

如果说三部曲里有一个项目最值得"照着自己改"，那就是它。这一篇讲讲它是什么、它代表怎样的路线、以及为什么它的设计思路和前两个那么不同。

一、它是什么：从作者自己 .agents 目录里拿出来的手艺

官方描述直白得可爱：

我每天用来做真实工程(不是 vibe coding)的代理技能，直接来自我自己的 .agents 目录。

vibe coding(凭感觉写代码)是 Matt 反对的东西——他要的是有纪律、有品味的工程。 这套技能一共 25 个，分两类：

• Engineering(工程类)——18 个，做代码工作的日常技能；
• Productivity(生产力类)——7 个，不针对代码的通用工作流。

每个技能又分两种调用方式：

• 用户调用的(user-invoked)——只有你打出 /grill-me 这种命令才会触发，负责编排流程；
• 模型调用的(model-invoked)——任务匹配时代理可自动调用，承载可复用的纪律。

最关键的设计规则：一个用户调用技能可以调用模型调用技能，但绝不调用另一个用户调用技能—— 用一层"编排"和一层"复用"把结构理顺，而不是所有技能平铺在一起互相调用。

二、它代表什么路线：反对"接管流程"，相信工程师

要理解这个项目，最关键的是 README 开头那段"为什么存在"：

开发真实应用很难。GSD、BMAD、Spec-Kit 这类方法论试图通过"接管流程"(owning the process)来帮忙。但这么做的时候，它们拿走了你的控制权，并且让流程里的 bug 很难解决。

这句话是整份 repo 的宣言。Matt 的立场很明确：

• 反对那些把整个开发流程封装成"黑盒方法论"的工具——它们替你决定怎么规划、怎么写、怎么交付，你失去了判断力；
• 主张技能应该小、容易改、可组合(small, easy to adapt, and composable)，并且跟任何模型都能用；
• 信奉几十年的工程基本功——TDD、领域建模、代码评审、深度模块——比任何"AI 魔法流程"都重要。

所以这个 repo 的技能文件都是普通 Markdown，可以被你随意 fork、改写、删掉不用的部分。 它甚至设计了两种安装方式，对应两种哲学：

• Claude Code 插件(claude plugins install mattpocock-skills)——作为托管的只读包，跟随作者更新，相当于"订阅"；
• skills.sh 复制到项目(npx skills@latest add mattpocock/skills)——把技能文件拷成你拥有且可编辑的普通文件，相当于"fork"。

两种哲学：订阅 or 自己拥有。装一个就行——两个都装，你会得到双份技能。

三、它解决什么问题：四个真实失败模式

README 把每个技能都挂在四个"代理的典型失败"上，这套框架特别值得学：

失败模式 #1：代理没做你想让它做的事

问题：软件开发最常见的失败是"错位"(misalignment)——你以为代理懂了，结果它做出来完全不是那么回事。

解法：/grill-me——一个"拷问式"技能，让代理对你展开不间断的采访， 把你方案里每个分支都问透，直到设计树的所有分支都被确认，没有任何东西被默默假设。 这是 Matt 最受欢迎的技能，也是整套系统最有名的一个。

失败模式 #2：代理话太多

问题：代理进入项目后不懂术语，于是用 20 个词说 1 个词就能说清的事。

解法：建立一个共享语言。核心是 CONTEXT.md——一份帮代理解码项目术语的文档。 举个例子：

• 改写前："课程里的 lesson 被 made 'real'(即在文件系统里被分配一个位置)时有 bug"
• 改写后："materialization cascade 有问题"

这不止让对话简洁——它让变量、函数、文件命名一致，代码库更易导航，代理思考时花的 token 也更少。 这个"先立术语、再谈问题"的技巧由 /grill-with-docs 承载，Matt 说 "这可能是我这个 repo 里最酷的一个技巧"。

失败模式 #3：代码不工作

问题：就算对齐了需求，代理产出的还是垃圾。原因往往是反馈循环缺失—— 代理不知道它写的代码跑起来什么样。

解法：配齐反馈循环——静态类型、浏览器访问、自动化测试。 其中核心是 /tdd(红绿重构)，还有 /diagnosing-bugs(分阶段门控的调试循环)。

失败模式 #4：我们建了个泥球

问题：代理大幅提速了写码，也大幅加速了软件熵——代码库以空前的速度变得复杂、难以修改。

解法：一个"激进"的新主张——在意代码的设计。/to-spec 会在建 spec 前拷问你要动哪些模块；/improve-codebase-architecture 定期扫描代码库找"加深的机会"。 但注意它的定位——"它是调查，不是救援"：它找出候选，但不会替你拆开泥球。

四、设计精髓：质量藏在细节里

这个 repo 真正让我佩服的是技能文件本身的质量。比如 tdd 技能，它不只是说"先写测试"， 而是把测试的反模式讲透了：

• 实现耦合(Implementation-coupled)——mock 内部协作者、测私有方法、通过旁路验证，导致重构就挂；
• 同义反复(Tautological)——断言用和代码一样的方式重算期望值(expect(add(a,b)).toBe(a+b))，永远不会失败，等于没测；
• 水平切片(Horizontal slicing)——先写完全部测试再写全部实现，测的是"想象中的行为"而不是真实行为。

它甚至引入了 seam(接缝) 的概念：测试只写在预先和用户商定的公共边界上， "写测试前先写下要测的接缝，和用户确认"——把有限的测试精力花在关键路径上。

同样精彩的还有 /code-review：沿两个轴审查——标准轴(是否符合仓库编码标准 + Fowler 代码坏味道基线)和规格轴(是否忠实实现了原始 issue/spec)，用两个并行子代理跑，互不污染上下文。 它还内建了 Fowler 坏味道清单，即使仓库没有任何文档也有审查基准。

这些内容不是"AI 教程式的泛泛而谈"，而是引用了一整排经典：《程序员修炼之道》、《领域驱动设计》、《极限编程》、John Ousterhout《A Philosophy of Software Design》—— 把二十年的工程智慧浓缩成了可重复执行的实践。

五、三部曲怎么选：三条路线

写到这里，把三个项目放在一起，你就能看清这个领域正在分化出的三条路线：

怎么选，取决于你的风格：

• 想要现成的纪律——装 Superpowers，它替你立好规矩；
• 想要全家桶(记忆 + 学习 + 安全)——上 ECC；
• 想要照着自己改的底料——用 mattpocock/skills，把它当参考实现，理解后改成你自己的。

我的收获

1. "接管流程"和"教你手艺"是两种相反的设计——前者让你依赖工具，后者让你拿走工具。Matt 选了后者，这是我见过的最清醒的立场。
2. 共享语言可能是被低估的杠杆——为项目建 CONTEXT.md 术语表，一次投入，每次会话都省 token、省对齐、省返工。
3. 技能质量取决于工程功底——同一个"TDD 技能"，泛泛的和引用 Fowler、讲透反模式的，效果天差地别。读技能文件本身就是学习。
4. 三部曲合起来是完整的答案——Superpowers 教纪律，ECC 教体系，mattpocock 教品味。真正的做法或许是：读这三个，然后写你自己的。

想深入了解，推荐 GitHub 仓库、aihero.dev/skills，以及 Matt 的newsletter(约 6 万开发者订阅)。 如果你只读一个技能文件，我推荐 tdd—— 那是整套系统质量的一个缩影。