Matt Pocock 的 Skills 仓库，真正厉害的不是 Prompt

大家好，我是若风。

6 月 27 日晚上，我扫 GitHub 仓库数据的时候，又看到一个很夸张的数字。

mattpocock/skills，148,030 stars，12,805 forks。

这个数字放在任何开源项目上都挺猛，更别说它不是数据库、不是前端框架、不是推理引擎，而是一堆 SKILL.md。

你想想看，一个文本仓库，主语言显示是 Shell，项目创建于 2026 年 2 月 3 日，到 6 月 27 日已经冲到 14 万多 star。最新一次 push 是 2026 年 6 月 25 日，最新 release 是 2026 年 6 月 17 日的 v1.0.1。

这事不正常。

我一开始也以为它只是另一个 Prompt 合集。毕竟现在 GitHub 上太多这种项目了，标题写得很大，点进去就是几段提示词，一眼看完，收藏，然后再也不用。

但 Matt Pocock 这个仓库不是这个路子。

README 的第一句话就很硬，Skills For Real Engineers。下面还有一句更刺耳，not vibe coding。

这篇我想拆的不是怎么安装它。

我更想拆的是，为什么这个仓库能把一堆 Markdown 文件，做成一套让工程师愿意相信的 Agent 工作系统。

先说结论

Matt Pocock 的 Skills 真正厉害的地方，不是它写了多少好用提示词，而是它把传统软件工程里的几个硬东西，压缩成了 Agent 能执行的工作纪律。

我看完之后，自己的判断是 4 个点。

坦率的讲，这不是 Prompt 仓库。

它更像一套给 AI Agent 用的工程操作手册。

不是替你写代码，而是先管住失控

README 里 Matt 讲了 4 个失败模式。

Agent 没理解你要什么。

Agent 太啰嗦。

代码跑不起来。

项目越写越乱。

说真的，这 4 个问题几乎就是 AI 编程今天最常见的 4 个坑。很多人第一次用 coding Agent 会很兴奋，觉得自己终于有了无限劳动力。过几天就会发现，真正难的不是让 Agent 生成代码，而是让它在正确的问题上，用正确的节奏，留下正确的结构。

代码本身变快了，混乱也变快了。

这才是关键。

Matt 这个仓库的切入点很聪明，它没有说「我来给你一个更强 Prompt，让 Claude 一次写对」。它反过来承认，Agent 会误解，会废话，会写坏代码，也会把系统搅成一团。

然后它做了一件更工程化的事，把这些失败模式分别做成 Skill。

比如 /grill-me 和 /grill-with-docs，解决的是需求没对齐。它不急着写代码，而是让 Agent 先追问，把模糊需求烤到足够具体。

比如 /tdd，解决的是代码没有反馈回路。它不是让 Agent 一口气写完所有测试，而是强调垂直切片，一次一个行为，一个测试，一个实现。

比如 /diagnosing-bugs，解决的是调试乱猜。它把排查过程压成一条纪律，复现、缩小、假设、插桩、修复、回归测试。

比如 /improve-codebase-architecture，解决的是项目变成泥球。它会扫描代码库，找可以把浅模块变深模块的机会，再做成一个 HTML 报告给人选。

你看，这里面最有意思的地方是，它不是在追求「Agent 更自由」。

它是在给 Agent 上护栏。

17 个 Skill，真正的分界线是控制权

我看了一下 .claude-plugin/plugin.json，当前公开配置里有 17 个 Skill。

工程类占大头，包括 ask-matt、diagnosing-bugs、grill-with-docs、triage、improve-codebase-architecture、setup-matt-pocock-skills、tdd、to-issues、to-prd、prototype、domain-modeling、codebase-design。

生产力类还有 grill-me、grilling、handoff、teach、writing-great-skills。

表面看，这是功能分类。其实吧，更重要的是另一个分类，user-invoked 和 model-invoked。

这个设计很细。

user-invoked Skill 只能由人主动输入名字触发，通常负责组织一个流程。model-invoked Skill 可以由人触发，也可以被模型在合适任务里自动拿来用，通常沉淀的是可复用纪律。

这个边界解决了一个很现实的问题。

哪些动作应该由人决定，哪些动作可以交给模型判断？

比如 grill-with-docs 是 user-invoked。因为「现在要不要进入追问流程」，这件事最好由人决定。可它里面会调用 /domain-modeling，这类模型可复用的能力可以自动参与，把术语、上下文和 ADR 写进去。

这套设计背后有一个挺清醒的判断，Agent 不是越自动越好。

自动化必须有层级。

最硬核的部分，是把老工程学翻译给 Agent

这个仓库让我觉得有价值的地方，不是它发明了什么新概念。

恰好相反。

它一直在把老概念重新包装给 Agent。

/tdd 里最重要的观点，是测试行为，不测实现。测试应该从公共接口穿过去，描述系统能做什么，而不是盯着内部函数怎么写。

更关键的是，它强烈反对横向切片。不要先写 5 个测试，再写 5 段实现。那样很容易测到想象中的行为。它要求一条 tracer bullet 走到底，一个测试，一个实现，再下一个测试。

老实说，这个判断挺重要。

人类做 TDD 都容易写飞，更别说 Agent。Agent 最擅长一次生成一大坨东西，最不擅长在真实反馈里慢慢校准。/tdd 这个 Skill 的价值，就是强迫它减速。

/codebase-design 更典型。它把模块、接口、实现、深度、接缝、适配器这些词重新定义了一遍，而且明确要求不要乱换词。比如它说模块可以是函数、类、包，甚至跨层切片。接口也不只是类型签名，还包括调用者必须知道的约束、错误模式、配置和性能特征。

这个词汇统一有什么用？

你想想看，人和 Agent 最大的问题之一，不就是词不对齐吗。你说「service」，它理解成一层薄 wrapper。你说「API」，它只看函数签名。你说「边界」，它可能想到 DDD，也可能想到文件夹。

Matt 的做法是，先把词钉住。

然后再让 Agent 用这些词做判断。

比如深模块，不是看实现代码有多少行，而是看调用者用很小的接口，能拿到多少行为。比如 deletion test，删掉这个模块，如果复杂度只是平移到各个调用者，那它没赚到钱。如果复杂度会重新散落到 N 个地方，那它就有存在价值。

这话听着有点学术，但落到 Agent 上很实用。

因为 Agent 写代码太容易制造浅模块。抽个文件，包一层函数，看起来结构清楚，实际上复杂度没有减少，只是换了个地方放。

它不是魔法，安装后还要先做项目配置

这个仓库还有一个很反直觉的点。

你装完不是直接开用，它还让你跑 /setup-matt-pocock-skills。

这个 setup 会问 3 类问题，issue tracker 用 GitHub、GitLab、local markdown 还是别的，triage 标签怎么映射，领域文档是单上下文还是多上下文。

说真的，我挺喜欢这个设计。

很多 Agent 工具最爱假装自己无需上下文。你一装上，它就说我懂你，然后开始在仓库里乱跑。

Matt 这里反而慢了一步。它承认每个项目的工作流不同，issue 在哪，标签叫什么，ADR 放哪，CONTEXT.md 是一个还是多个，这些都不能靠猜。

这其实是工程里的常识。

只是到了 AI Agent 这里，很多人忘了。

如果一个 Skill 要处理 issue，它就必须知道 issue tracker。如果一个 Skill 要做架构建议，它就必须知道项目的领域语言和历史决策。如果一个 Skill 要做 triage，它就必须使用项目真实存在的标签，而不是凭空发明一套。

这就是为什么我说它像工具，不像文章收藏夹。

工具要接入你的现实世界。

为什么它能突然爆

截至我抓取数据时，这个仓库有 97 个 issues、1 个 PR、941 watchers。最近打开的 issue 里，有人讨论 /tdd 是否该用 subagent，也有人指出 teach 找不到正确工作目录，还有人提到 /implement 在 README 和 plugin 配置里缺失。

这些问题挺有意思。

一方面说明它很热，社区真的在用。另一方面也说明它还在快速成形，很多边界没有完全稳定。

但它能爆，我觉得不是偶然。

第一，Agent Skills 这层生态刚好到了爆点。Claude Code、Codex、Cursor、Gemini CLI、Cline 这些客户端越来越多，大家开始意识到，单个聊天窗口里的技巧不值钱，可迁移的 Skill 值钱。

第二，Matt Pocock 自带开发者信任。他不是突然冒出来写 Prompt 的营销号，而是长期做 TypeScript、课程和工程教育的人。README 里引用 The Pragmatic Programmer、DDD、Extreme Programming、A Philosophy of Software Design，这些不是装饰，是在告诉你这套东西的根不是玄学。

第三，它反 vibe coding 的姿态非常适合现在的情绪。

过去半年很多人试过「一句话生成 app」，爽是爽，但留下来的往往是不可维护的代码。这个仓库给出的答案不是别用 AI，而是把工程纪律塞回 AI 流程里。

这很准。

诚实的边界

当然，它不是银弹。

第一个边界，Skills 仍然是文本协议。它能约束 Agent，但不能保证 Agent 一定遵守。你把 /tdd 写得再好，模型如果上下文爆了、任务太大、工具反馈不完整，照样可能跑偏。

第二个边界，setup 依赖人的判断。issue tracker、标签、领域文档这些配置，看起来只是几道问题，实际上要求你对自己的团队流程有清晰认识。流程本来就乱的项目，装上它不会突然变有序。

第三个边界，依赖关系开始变复杂。v1.0.0 release 里已经出现 breaking changes，比如新增 codebase-design 和 domain-modeling 后，部分 Skill 会依赖它们。Skills 从文件夹变成生态之后，版本、依赖、兼容性就会变成真实问题。

第四个边界，它强烈偏向工程纪律。对原型探索、内容创作、视觉发散这类任务，它未必总是最舒服。不是所有 Agent 工作都应该被 TDD 和 ADR 管起来。

最后还有一个更现实的边界。

它适合已经知道自己想要严肃工程的人。

如果你只是想让 Agent 快速试一个 demo，它可能显得有点重。但如果你想让 Agent 长期参与真实项目，这套东西的价值会越来越明显。

我真正学到的东西

我看这个仓库，最大的感受不是「原来 skill 可以这么写」。

而是，AI 编程正在从单次生成，走向可运营的工程系统。

以前我们优化 Prompt，像是在优化一句咒语。现在这些仓库在做的事，是把工作拆成多个可调用的流程，把流程背后的判断写成文档，把文档接入项目上下文，再让 Agent 在反馈环里执行。

Prompt 是一句话。

Skill 是一套工作习惯。

这两个东西差得很远。

如果你只收藏一个 Prompt，它会在下一次复杂任务里失效。可如果你把需求澄清、领域建模、TDD、调试、架构复盘都变成 Skill，你其实是在训练一个可复用的工程环境。

我一直觉得，未来的 AI 编程竞争，不会只比谁的模型更强。

还会比谁的工作流更稳。

Matt Pocock 这个仓库给我的启发就是，真正有价值的 Agent Skills，不是让模型显得更聪明，而是让模型更像一个被好团队带过的工程师。

会追问。

会小步走。

会等反馈。

会尊重已有词汇。

会知道什么时候该停下来，让人做决定。

写在最后。

如果你只是想找几个酷炫命令，这个仓库可能没那么刺激。

但如果你已经被 Agent 写出来的泥球折磨过一次，再回头看这 17 个 Skill，会有一种很熟悉的感觉。

它不是在卖魔法。

它是在把工程基本功，重新装进 AI 时代的工具箱里。