75K Star 的 Skills 仓库到底凭什么
这两周 GitHub 上有个 SKILL 仓库刷屏了。mattpocock/skills，75K star。
我点进去之前以为是又一个「agent 工程大作」。进去之后愣了一下，这哪是什么仓库，里面就是十几个 markdown 文件，每个几十行，规则朴素得不像话。
什么「先理解再设计」「先验证再实现」「提交前跑测试」，这种话谁不会说？
但 75K star 不会注水啊。
所以我花了几天，把这十几个 skill 全拆了一遍，就想搞明白一件事：这玩意儿到底凭什么？
看规则
我先把每个 skill 当独立 prompt 看，挨个翻。
比如 caveman，规则就一条——压缩所有语言，删掉客套，删掉「我现在要做 X」之类的导言，回答尽量短到像穴居人说话。
比如 grill-me，规则更简单。你给我一个方案，我就一个问题一个问题地反过来追问你，把方案里所有靠默认假设撑起来的地方都挖出来。
再比如 diagnose，调试 bug 的时候不许凭感觉乱试，必须按六个阶段走，从复现到搭反馈循环到提假设到证伪，一步都不能跳。
每个都是几十行 markdown，规则朴素到甚至有点土。
没有「魔法 prompt」，没有「咒语模板」，没有那种你期待在爆款仓库里看到的「卧槽这一段我得抄下来」的瞬间。
看完之后我有点失望。这要是放在国内技术博客，大概就是「程序员日常 best practice 整理」那种被刷过去的东西。
但 75K star 真的不像撒谎。
所以我没敢下结论，又往后看了一层。
看共性
我合上 caveman.md，把所有 skill 的标题一起列在一张表上。
不再一个一个看规则，看它们放在一起是什么样子。
这一退，眼睛开始亮起来。
十几个 skill，覆盖从理解、设计、实现到维护的完整工程流程。但仔细看，它们底下其实只有几个反复出现的信念。
第一个：反馈优先。 调试 bug 之前先搭好反馈循环，写代码之前先让测试 RED 再 GREEN。Matt 在 diagnose 里写：「反馈循环搭对了，bug 就修完 90% 了。」
第二个：行为优于实现。 测试只测公开接口的行为，不测内部代码长什么样。PRD 描述「用户能做什么」，不绑定具体文件路径。
第三个：垂直切片。 每个工作项必须从用户输入端到端打穿到数据库再打回来，像曳光弹一样。反对「先把所有 model 写完，再写所有 controller」那种水平拆分。
第四个有点反直觉，叫显式优于隐式。 隐性约定全写下来，写成 ADR，写成 CONTEXT.md，写成 skill。不许靠「团队默契」撑着。
第五个：删除优于保留。 原型用完就删，不要恋恋不舍。判断一个模块该不该留的方法叫「删除测试」，删掉它，剩下的系统还能工作吗？能，就删。
5 个信念底下其实是同一句话，让 AI 跟着规则跑，不要凭感觉。
到这里我开始有感觉，这仓库可能不一样。
但我意识到这一层之后，反而开始觉得不对。
这 5 个信念，怎么一个都不新？
我好像在哪儿见过。。。
我到网上一搜，好家伙。
纯正血统
反馈优先 + 行为优于实现，来自 Kent Beck 那本《Test-Driven Development》。整本书的核心就是这个，「测行为不测实现」是 TDD 区别于「写完代码补单测」的根本判断。
垂直切片 / 曳光弹，来自 Hunt 和 Thomas 1999 年的《The Pragmatic Programmer》。「Tracer Bullets」那一章里逐字写过。
显式优于隐式，一头是 Python 之禅那句 Explicit is better than implicit，另一头是 Eric Evans 2003 年的《Domain-Driven Design》，反复强调「显式建模」。
深模块（简单接口包裹复杂行为），来自 Matt 反复引用的 John Ousterhout 2018 年那本《A Philosophy of Software Design》。这本书更狠，第一章就在骂，为什么我们的代码越来越复杂？因为我们不肯定义清楚接口。
也就是说，那个 75K star 的爆款仓库，骨子里就是这 4 本书。
最早的 1999 年，最新的 2018 年。最早那本，到今年正好 27 年。
Matt 没有发明任何东西，他萃取了精华。这位大佬是做 TypeScript 教学出名，办过 Total TypeScript 课程，最近又搞了个 AI Hero。在这之前他在 Vercel 和 XState 都做过开发，开源代码和踩过的坑都不少。他做的事，是把这几本书讲了 30 年的方法论 + 自己这些年沉淀的判断，融会贯通后压成几十行 AI 能看懂的招式。
为什么火爆？
那 4 本书每本都是经典，几十万人读过。但读完之后，绝大多数人的反应是「啊，受教了，写得真好」，然后合上书，回去继续凭感觉编码。
Matt 不是。他读完之后逐条问自己一个问题，这条方法论怎么变成 AI 在工作时会自动遵守的规则？
所以他做的事不是翻译。翻译是字对字搬运，谁都能干，读过书对照着抄就行。他做的是举重若轻～把几本经典 + 多年写代码 + 上百个项目踩过的坑，融会贯通后压成几十行朴素的 markdown。
看着波澜不惊，背后汹涌澎湃。
那 4 本书讲的其实是「心法」，是道理、原则、判断，活在认知层。读过的人都懂，懂了之后大多数人合上书继续凭感觉编码。Matt 做的事，是把心法变成了「招式」，具体的、按表执行的、AI 能跟着跑的协议，活在执行层。
真正稀缺的不是发现这些原则，是有能力把这些原则压成「朴素到没人愿意承认它复杂」的样子。
这种能力还反 AI。AI 能记住信息，但不能沉淀判断。
学到什么
第一，表面规则你能抄，「汹涌澎湃」抄不到。 5 分钟你就能 fork 一份十几个 skill 回去。但你抄到的是招式的形，抄不到背后的心法和判断。这是为什么大部分人抄完之后还是用不起来。
第二，回到你工作里那些「心里都懂但写不出来」的东西。 不一定要是 Matt 那 4 本书。可能是《人月神话》，可能是产品经理读的《Inspired》，也可能就是你工作 5 年踩过的那些坑。那些才是你的心法。
第三，试着把一条心法变成 10 行招式。 选你工作里一个反复出现的场景，把你心里那套「我会这么干」的判断，压成 10 行 AI 能跟着跑的 markdown。不是写十几个，是先写 1 个。试一次你就知道，把心法变成招式，比「翻译」难得多。
Matt Pocock 不是在写 prompt。
他是把读过的书、写过的代码、踩过的坑，举重若轻地压成了几十行让 AI 能跟着走的路。
参考
- mattpocock/skills 仓库
- 4 本书原典（按文中出现顺序）：
- Kent Beck《Test-Driven Development: By Example》
- Hunt & Thomas《The Pragmatic Programmer》
- Eric Evans《Domain-Driven Design》
- John Ousterhout《A Philosophy of Software Design》