2026 年 4 月，一个叫 mattpocock/skills 的仓库悄然登顶 GitHub Trending。几周内，star 数从 1.8 万飙到 7.7 万。不是新的 LLM，不是框架，不是 SDK——只是一个文件夹，里面装着 20 多个 Markdown 文件。

Matt Pocock，这位以 TypeScript 教学闻名的开发者（Total TypeScript 作者，前 Vercel 工程师），把自己每天都在用的 AI 编程 agent 配置全盘开源。每条 skill 不超过 200 行，用 YAML frontmatter 描述行为，MIT 协议，一行命令装到 Claude Code 或 Codex 里就能用。

听起来像锦上添花。实际上它可能正在回答一个更根本的问题：当 AI 编程工具能写出整个仓库的代码时，开发者还剩下什么价值？

vibe coding 的终结？

2025 年的关键词是 “vibe coding”——靠感觉编码，把需求扔给 LLM，看它飞出一堆代码，差不多就行。Andrej Karpathy 造了这个词，一年后回头看，它更像是对一种短暂自由的深情告别。

vibe coding 的问题不在代码质量——LLM 写的代码通常比初级工程师工整——而在方向。没有工程约束的 AI 编程就像没有红绿灯的城市十字路口：每辆车都能跑，但谁也到不了想去的地方。

Matt Pocock 在 README 里写得很直白：

“Code isn’t cheap. In fact, bad code is the most expensive it’s ever been.”

这不是故作惊人之语。他用自己九年的工程经验观察到，当 AI 能快速生成大量代码时，方向性错误的代价被放大了。以前写一周的坏代码，现在 AI 一天就能写出来同样的量。

skills 不是什么

说清楚 mattpocock/skills 不是什么，比说它是什么更关键。

不是另一个 GSD 或 BMAD。 过去一年，行业内涌现了一批试图 “own the process” 的框架。GSD、BMAD、Spec-Kit 这些名字听起来很酷，但它们有一个共同的问题：它们想要接管整个开发流程。一旦出了问题，开发者很难定位是流程的 bug 还是代码的 bug。

不是系统 prompt 大合集。 市面上有很多 “claude-code-prompts” 类仓库，塞一个 5000 字的 system prompt 进去，指望 AI 记住一切。但 LLM 对长 prompt 的执行并不稳定，尤其是当多个行为规则互相冲突时。

不是 MCP 工具。 MCP（Model Context Protocol）擅长和外部系统交互：读数据库、调 API、操作文件系统。但 MCP 不擅长"规定做事的方式"。skills 恰好填补了这个空白——它不是让你做什么，而是规定你怎么做。

每一条 skill 就是一个独立的 SKILL.md 文件，本质上是一套严格的指令集，告诉 agent 在特定场景下应该以什么流程执行任务。因为每条 skill 都很小，你可以只装需要的，也可以自己 fork 改（MIT 协议），互相之间不冲突。

五条核心 skill，一条开发链

在 Matt 自己的开发流程里，有五条 skill 构成了每日工作的闭环链条。

1. /grill-me — 拒绝哑巴 agent

“AI 做的不是我想要的”——这是工程经理们最常抱怨的一句话。Matt 的解法听起来反直觉：在 agent 开始写代码之前，先让 agent 拷问你。

/grill-me 的运作方式是：agent 会自动沿着"设计决策树"逐层追问，每层只问一个问题，推荐一个答案，然后从代码库中搜索可验证的信息来确认。这不是简单的"你确定吗？"，而是一个系统性的设计审核。它把你在编码开始前的模糊想法，变成一系列经过推敲的明确决策。

/grill-with-docs 更进一步——它会把整个探讨过程写入一个 CONTEXT.md，建立项目专用的共享词汇表。每个后续 session 都可以直接引用这份上下文，避免了 agent 每次重启后都要重新理解一遍项目的尴尬。

这解决了 AI 编程中最隐形的成本：上下文丢失。每个新 session，agent 带着对你需求一无所知的"纯洁性"开始，而你重复解释的 15 分钟，乘以每天 10 次，就是每天 2.5 小时的纯浪费。

2. /to-prd — 让 agent 自己写需求文档

“没人确切知道自己想要什么”——这是 Matt 在 README 里引用《程序员修炼之道》的一句话，也是九年来他最认同的经验法则。

/to-prd 会在 /grill-me 的结果基础上，把整个对话综合成一份结构化的 PRD，然后直接写入 GitHub issue。它做的事情其实很简单：把模糊的对话翻译成精确的需求描述。但正是这个"翻译"步骤，在传统开发流程里需要花掉 PM 和 tech lead 半天的时间。

3. /to-issues — 从 PRD 到可执行的任务网格

/to-issues 把一份 PRD 拆解成一系列的 vertical-slice tracer bullet issues。每个 issue 都是一个端到端的垂直切面：从前端到后端到数据层。这种切法不是随便分的——它遵循 tracer bullet 模式（来自《The Pragmatic Programmer》），每颗"曳光弹"都贯穿整个系统，确保进度不是来自非集成的"深井"。

这意味着你看进度的方式变了：不是"前端 80% 后端 60% 数据库 20%"，而是"第 3 个功能端到端走通了"。

4. /tdd — 让 agent 先写测试

/tdd 是整个 skill 集里技术含量最高的一条。

它会强制 agent 遵循红绿重构循环：先写一个会失败的测试 → 确认测试失败的原因正确 → 写最少代码让它通过 → 重构。这条规则层层加了约束：agent 不允许跳过写测试的环节，不允许一次提交大量代码后再补测试，不允许不验证测试失败原因就直接写实现。

如果你觉得这听起来太死板，那正是目的所在。TDD 对于人类开发者来说是一种"纪律"，需要长年训练才能变成肌肉记忆。但对于 AI agent——它默认没有任何纪律——/tdd 就是那个把工程纪律写进工作流的东西。

一位在 Devtalk 论坛上使用了一周的工程师说：

“When tdd is active, Claude Code does not write implementation before tests — full stop.”

当 AI 能轻松绕过所有最佳实践时，唯一让这些实践不形同虚设的办法就是——直接禁止绕过。

5. /improve-codebase-architecture — 识别架构债务

大多数 AI 编程的架构方法都是"你说拆，它就拆"。问题是，你怎么知道该拆哪里？

/improve-codebase-architecture 做的事情是扫描代码库，识别出"太浅"的模块（那些已经偏离了领域语言、但尚未严重到崩溃的 module），然后用一个固定的 8 词词汇量来描述问题。这个限制是有意为之的——更少的词汇意味着更少的歧义，对 agent 行为的可预测性是一个巨大的提升。

它给你一份"架构债务地图"：哪些模块已经长成了你不想看到的形状，应该从哪开始重塑。

技能包设计的底层哲学

理解 skills 为什么火，需要看到它背后的工程哲学。

小即是美

每条 skill 不到 200 行。你可以读完、理解、修改它。如果你觉得某个 behavior 不合适，不需要开 PR，不需要等发布——直接改自己的 fork 就行。

这和 GSD 那种动辄上千行的 mega-sketch 形成鲜明对比。当一个工作流定义文件超过千行，几乎没人真的读完过，更没人改过。最后它变成了一个"你不太清楚它在做什么，但去掉它又怕出事"的玄学组件。

可组合性

skils 不互相依赖。你可以只装 /tdd，也可以装上全套餐，还能自己写一个新 skill 和它们配合。

这种设计在传统软件里叫"Unix 哲学"——每个工具做好一件事，通过管道组合。Matt 把同样的思路用在了 agent 工作流定义上。

模型无关

这是一个经常被忽视但异常重要的点。skills 不绑定 Claude Code、不绑定 Codex、不绑定 Gemini CLI。它们只是结构化的 Markdown 文件，任何能阅读 Markdown 的 agent 都能执行。

这意味着你的工作流投资不会因为换了一个 agent 工具就作废。这在 2026 年的 AI 编程市场格外重要——模型提供商每个月都在推出新工具，锁定在某一个生态里是危险的。

从"提示词"到"协议"

这可能是 skills 最深远的影响：它把 AI 编程的行为准则从"一段话"变成了"一组文件"。提示词（prompt）是输入时的一次性指令；协议（protocol）是代码库的一部分，版本化管理，团队共享，持续演进。

mattpocock/skills 里的每条 skill 在本质上都是一条"约束"——它不是在告诉 AI"你可以做什么"，而是在说"你必须这样做"。对于没有内置开发纪律的 AI 来说，这些约束恰恰是良性的。

社区的反应与讨论

仓库在几周内飙到 7.7 万 star，但它引发的讨论远不止数据。

在 Devtalk 论坛上，一位工程师分享了一周的使用体验。他推荐优先装的是 /grill-with-docs——初次使用后，agent 自动生成的 CONTEXT.md 文件显著改善了后续每次 session 的质量。他提到的 /caveman 是一个堪称艺术的作品：如果你已经明确知道自己要什么，这个 skill 能把 agent 的输出压缩到极致——对，就是不废话模式。

另一位用户在 Reddit 的 r/vibecoding 板块分享了更激进的用法：他每小时跑 5-7 个任务，通过 /grill-me + /prd-to-issues 的 pipeline，把每个功能请求都变成了可追踪的 issue 列表，然后逐个解决。

当然也有批评声。有人指出 Claude Code 的 Auto Mode 会静默注入系统提示覆盖掉 skills 的行为。也有人质疑 TDD 在超大项目中的实用性——当测试编译就需要 5 分钟时，“先写测试"的效率增益会被稀释。

不过这些讨论本身已经说明了 skills 切入的痛点有多真实。如果只是又一个 prompt 合集，不会有人愿意花一周去测试它。

开发者还有多少价值？

最后一个问题回到开发者自身。

当 AI 能写测试、写需求、拆任务、重构架构——开发者还做什么？

Matt 给的答案是：定义过程。

skills 教会我们一件事：在 AI 时代，最有价值的不再是写代码（AI 比你写得好），也不再是写 prompt（prompt 太不稳定），而是制定规则——把工程方法论编码成 agent 能理解、能执行的格式。

能写下 /tdd 的人不需要自己盯着 AI 先写测试还是后写测试，因为规则已经在那里了。能写下 /improve-codebase-architecture 的人不需要每天凌晨三点做架构评审，因为 agent 每天都在扫描。

这就像泰勒的科学管理应用到编程上——不是替代工匠，而是把工匠的经验提炼成可以复用的流程。

因此，Matt Pocock 的 skills 还有另一层意义：它是一份开放的现代 AI 编程工程师手册。每一个想要在 AI 时代依然做"真正的工程"的人，都应该读一读这些 Markdown 文件——不是为了照搬它们，而是为了学习如何把自己的方法论，变成 agent 能懂的协议。

当每个人都能"雇佣"一支由 AI agent 组成的开发团队时，真正拉开差距的，将不再是你能写多快的代码，而是你能否设计出让 agent 高效工作的流程。

这也许是 skills 冲上 GitHub 热榜第一，背后最真实的原因。

项目地址: github.com/mattpocock/skills 开发团队: Matt Pocock（Total TypeScript 作者，前 Vercel/Stately 工程师） 开源协议: MIT 使用条件: 需要 Claude Code、Codex、Gemini CLI、Cursor 等支持 .claude/skills 目录的 AI 编程工具