Matt Pocock 开源 skills v1，把技能描述的 Token 成本砍掉 63%
这两天刷 GitHub，看到 Matt Pocock 把自己天天在用的那套 Agent Skills 开了源，版本号直接打到 v1。
发布说明里有一行字，我盯着看了好几秒。
把技能描述的 Token 成本砍掉了 63%。
我第一反应不是「哇好厉害」，而是「等等，砍的是啥」。因为你要是熟悉这帮做工具的人，就知道「降本」这词在 AI 圈早被用烂了，十有八九是砍功能、砍上下文、砍精度，换个说法叫优化，体验掉一截。
结果我把仓库扒开看了一圈，发现这哥们砍的不是功能。
砍的是废话。
这事儿我觉得值得跟你唠唠，因为它戳到的不是某个工具的小聪明，而是现在一大批人用 AI 写代码时，那种说不清道不明的别扭。
先说这哥们是谁。Matt Pocock，写 TypeScript 的人大概都认识，Total TypeScript 的作者，邮件列表里挂着六万多开发者。他不是那种炒概念的网红，是真在一线敲代码、被各种 agent 坑过来的工程师。他这套 skills 仓库的副标题起得特别直白，Skills for Real Engineers，给真正干活的工程师用的，不是给你 vibe coding 用的。
vibe coding 这个词得解释一下，怕有朋友不熟。大概就是你也不太管代码怎么写，全凭感觉跟 AI 聊，它生成啥你就用啥，跑通了就行，跑不通就再骂它两句让它改。爽是真爽，翻车也是真翻车。Matt 这套东西，某种程度上就是给被 vibe coding 反噬过的人准备的解药。
那 63% 是怎么来的？
这就得说到 Agent Skills 这个机制本身了。简单讲，skill 就是一段给 AI 的说明书，告诉它「遇到这类活儿，按这个流程来」。每个 skill 都得有一段描述，让模型判断「现在这个场景该不该用我」。问题在于，这段描述是要常驻在上下文里的，模型每次思考都得把它读一遍。你 skill 攒得越多，这些描述堆起来占的 token 就越夸张，还没开始干活呢，光是「自我介绍」就把预算吃掉一大块。
Matt 干的事，就是把这些描述全部重写了一遍，该合并的合并，该删的废话删掉，能用一个词说清的绝不用一句话。最后整体压下来 63%。
听着是个抠细节的小活儿对吧。但我作为一个平时就在给大模型搭运行脚手架的人，对这种事特别敏感。token 预算这玩意，在生产环境里是真金白银，是延迟，是模型能不能在有限窗口里把正事想明白的关键。你前面塞一堆冗余的元信息进去，模型注意力就被稀释，真正该关注的代码反而看不清。所以「砍废话」在我这儿不是节俭，是让 AI 脑子更清醒。
不过真正让我没绷住的，不是这个数字，是他在 README 里把整套设计的来龙去脉摊开讲的那部分。
他说，我做这套东西，是为了修复我天天在 Claude Code、Codex 这些 agent 上看到的几个老毛病。然后他一条条列出来，每一条我看的时候都在点头，因为这些坑我也全踩过。
第一个毛病，AI 没干我想要的。
他引了《程序员修炼之道》里一句话，没有人能完全说清自己想要什么。然后他说，这事儿在 AI 时代一模一样。你以为 agent 听懂你了，等它把东西吐出来，你才发现它压根没理解你的意图。
这种感觉太熟了。你噼里啪啦敲一段需求，它信誓旦旦说「明白了」，然后给你造了个方向完全跑偏的东西。你和它之间有一道沟，叫沟通鸿沟。
Matt 的解法挺出乎意料，他不是教你怎么把需求写得更清楚，而是反过来，让 AI 来拷问你。他做了个 skill 叫 grill-me，grill 就是烤，架在火上烤的那个烤。这玩意干的事就是，在你动手之前，让 agent 一个接一个地问你问题，把你那个含含糊糊的想法里所有没想清楚的分支全给你逼出来。
我看到这设计的时候笑了一下。因为这跟我们做需求评审是一个道理，最贵的 bug 永远是需求阶段埋下的，你越往后改代价越大。但人就是懒，总想跳过那个「想清楚」的环节直接开干。Matt 干脆把这个纪律塞进了 AI，让它当那个烦人的、非要把你问明白的产品经理。他自己说这是他最受欢迎的 skill，每次要做改动都用。
第二个毛病，AI 太啰嗦了。
这块就直接连到那 63% 了。他说 agent 通常是被空降进一个项目，对里面的黑话一无所知，只能边干边猜。结果就是，一个词能说清的事，它非要用二十个词。
他的解法是给 AI 一份共享语言，一个叫 CONTEXT.md 的文档，把这个项目里那些只有内部人才懂的术语翻译给 AI 听。他举了个特别妙的例子。同一件事，啰嗦的说法是「当一个课程的某个章节里的某节课被变成真实的、也就是在文件系统里给它分配了一个位置时，会出现一个问题」。而有了共享语言之后，这句话变成「物化级联那块有个问题」。
物化级联，materialization cascade，一个内部约定俗成的词，一下子把一长串描述压成了四个字。
他说这可能是整个仓库里最酷的一个技巧，还专门加了个提示，说共享语言的好处远不止省字数。变量、函数、文件的命名会变得一致，代码库对 agent 来说更好导航，而且 agent 思考时花的 token 更少，因为它手里有一套更精炼的语言。
读到这儿我是真服气。这不就是领域驱动设计里那个 ubiquitous language 嘛，统一语言。Eric Evans 二十年前在书里讲的东西，开发者和领域专家得说同一种话，否则代码和现实永远对不上。Matt 把这个老掉牙但极其重要的原则，原封不动搬到了人和 AI 的协作里。AI 不是不会精炼，是你没给它精炼的本钱。
第三个毛病，代码不工作。
他说，就算你和 agent 对齐了要做啥，它还是可能给你产出一坨屎。这时候你得回头看你的反馈循环。没有反馈，agent 就是在闭着眼睛飞。
他的药方是老三样，静态类型、浏览器访问、自动化测试。其中自动化测试这块，他做了个 tdd 的 skill，强制走红绿重构那一套，也就是先写一个会失败的测试，再去写代码让它通过。这是 TDD 的经典节奏，红灯，绿灯，重构。
我得说，TDD 这东西在人身上推行了这么多年，一直叫好不叫座，因为它反人性，谁愿意先写测试再写功能啊。但放到 AI 身上，逻辑完全变了。AI 没有惰性，它不嫌烦。你让它先写测试，它就老老实实写，然后这个失败的测试就成了一个明确的、机器可验证的目标。它有了一个稳定的反馈信号，产出的代码质量直接上一个台阶。
好家伙，一个人类坚持不下来的纪律，到了 AI 这儿反而成了它的天然优势。这个反转我觉得挺有意思的。
第四个毛病，我们造了个烂泥球。
烂泥球，ball of mud，软件工程里专门形容那种结构混乱、谁都不敢动的屎山代码。Matt 说，因为 agent 能极大加速写代码，它也同时在加速软件的熵增。代码库以前所未有的速度变复杂。
这句话我得停下来重复一遍，因为它太重要了。AI 让你写得快了，但它也让你烂得快了。
你想想，以前一个烂设计，限于人手速度，它腐化得慢，你还有时间察觉、有时间重构。现在 AI 一天能给你糊出过去一周的代码量，那它一天也能给你糊出过去一周的技术债。速度是双刃的，往哪边砍取决于你有没有在管设计。
Matt 的解法是一种他称之为激进的新方法，在 AI 驱动的开发里，重新开始关心代码的设计。他做了个 skill 叫 improve-codebase-architecture，专门用来抢救已经变成烂泥球的代码库，还建议你每隔几天就在自己项目上跑一次。他引了 John Ousterhout 在《软件设计的哲学》里那句话，最好的模块是深的，让大量功能通过一个简单的接口来访问。
聊到这儿，其实你能看出来一条暗线了。
这整套 skills，从拷问需求、建共享语言、到 TDD、再到模块设计，没有一个是 AI 时代的新发明。全是软件工程几十年沉淀下来的老规矩。Matt 自己在总结里写得很直白，软件工程的基本功，现在比以往任何时候都更重要。
我特别认同这句。现在满世界都在说 AI 要取代程序员，说写代码这件事要消失了。但 Matt 这套东西反而在说，恰恰相反，正因为 AI 把「敲代码」这个动作变得几乎免费了，那些「敲之前该想清楚什么」「敲之后怎么保证它不烂」的功夫，才变得空前值钱。
会拷问需求的人，会建模的人，懂模块设计的人，在 AI 时代不是被淘汰，是被放大。
说到这儿，我还想聊聊 v1 这次更新在结构上的一个小心思，因为它特别能体现这帮人的思路。
这次他把所有 skill 沿着一个维度劈成了两类，谁能触发它。一类叫用户触发，user-invoked，只有你亲手敲斜杠命令才会唤醒，比如 /grill-me，它们的活儿是编排流程，当总指挥。另一类叫模型触发，model-invoked，除了你能叫，AI 自己判断当前任务对得上的时候也能自动伸手去够，它们装的是那些可复用的纪律，比如 tdd、domain-modeling。
规则还挺讲究，用户触发的 skill 可以去调模型触发的 skill，但绝不能去调另一个用户触发的。翻译成人话就是，总指挥可以调动小兵，但两个总指挥不能互相瞎指挥，免得乱套。
这个设计为啥重要？因为它解决了一个我天天头疼的问题，什么时候该让 AI 自己做主，什么时候必须人来摁。流程编排这种牵一发动全身的事，必须人来发起，你不能让 AI 自作主张地给你启动一整套开发流程。但像 TDD 这种局部的、可复用的纪律，就该让 AI 在合适的时机自己捡起来用，你不用在旁边一直盯着喊。
v1 比 v0 更狠的地方，那条推文里说得挺传神，AI 可以自己判断时机触发技能了，你不用盯着喊停，有点像一个老钳工，把「动手前先划线」这个习惯，灌进了 AI 的身体里。
老钳工划线这个比喻我太喜欢了。划线是什么，是动手切割之前，先在工件上把基准线画好，确保你切下去的每一刀都有依据。好的工程师身上都有这种肌肉记忆，不是规章逼出来的，是长进骨头里的。Matt 干的事，就是想办法把这种肌肉记忆，移植给 AI。
当然我也得泼点冷水，免得显得我在吹。
这套东西不是银弹。它说到底是一套观点很强的工作流，强到有点固执。你要是习惯了天马行空地跟 AI 聊，突然让你每次动手前先被烤一遍、先建共享语言、先写失败测试，你大概率会嫌烦，会觉得这不就是把敏捷开发那套繁文缛节又搬回来了嘛。
这个吐槽是合理的。我非常理解那种「我就想快点把东西做出来，别整这些虚的」的心情。尤其你只是想搓个周末玩具项目，上来就给自己套四道工序，确实有点重。
Matt 自己其实也意识到了这点。他在 README 里专门把自己这套和 GSD、BMAD、Spec-Kit 这些更重的方法论做了切割，说那些框架试图通过接管整个流程来帮你，但代价是夺走了你的控制权，流程里一旦出 bug 你很难解。而他这套的设计原则是小、易改、可组合，跟任何模型都能配，你可以随便拆开改成自己的。
所以我的建议是，别把它当成一套必须全盘照搬的圣经。把它当成一个工具箱，里面那几个核心的 skill，grill-me 拷问需求，tdd 守住质量，improve-codebase-architecture 定期给代码库做体检，你挑你当下最缺的那一两个先用起来。光是动手前被 AI 烤一遍需求这一项，我赌它就能帮你省下后面好几轮返工。
写到这儿，我想起那个 63% 其实是整件事一个特别好的隐喻。
我们现在用 AI，太容易陷进一种囤积的心态。prompt 越攒越长，上下文越塞越满，工具挂得越来越多，总觉得给 AI 喂得越多它就越聪明。但 Matt 这次更新在反着来。他在做减法，在砍废话，在用更精炼的语言换更清醒的判断。
现在有人把 prompt 当咒语攒，攒得越多越安心。有人把 prompt 当流程拆，拆得越清越踏实。那条推文里这么分的，v1 显然是后者。
我越来越觉得，未来真正会用 AI 的人，拼的不是谁的咒语长，是谁更清楚自己到底要什么，谁能用最少的话把这件事说明白。这事儿对人是这样，让 AI 替你干活，也是这样。
毕竟，你连自己想要什么都说不清的时候，再聪明的 AI 也只能陪你一起在迷雾里打转。
仓库我放下面了，感兴趣的可以自己扒一扒，全是这哥们每天真在用的东西，不是 PPT 上的概念。
skills 仓库 https://github.com/mattpocock/skills
grill-me 拷问需求 https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md
tdd 红绿重构 https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md
domain-modeling 领域建模 https://github.com/mattpocock/skills/blob/main/skills/engineering/domain-modeling/SKILL.md
improve-codebase-architecture 代码库体检 https://github.com/mattpocock/skills/blob/main/skills/engineering/improve-codebase-architecture/SKILL.md
writing-great-skills 怎么写好一个 skill https://github.com/mattpocock/skills/blob/main/skills/productivity/writing-great-skills/SKILL.md