我扒了 Matt 的 skill 源码:他写好 skill 守着四条铁律(还抓到他删了 caveman)

30 秒速览

写靠谱的 skill,只有一个目标:可预测——同一情形,AI 每次走同一个流程。四条铁律全为它服务,各打一个反例:

怎么触发:模型自动判断该用它,还得为此长期占着上下文;还是只在你明确喊时才触发。选错=白占上下文。

放多少:SKILL.md 只留每条路都用得上的,其余下沉外链。反例:臃肿、沉积。

用什么词:借 AI 脑子里已有的现成概念当「主导词」,一词锚定一片行为。反例:废话词、重复。

怎么收尾:每步给一个可验证的完成标准。反例:没干完就溜号。

四条全来自 Matt Pocock 的 writing-great-skills;四个反例,全是从他自己的改版记录里挖的真例。

我把 Matt 的 skill 源码扒了一遍

同样是 / 一下,有的 skill 每次都把活干完,有的时灵时不灵。差别不在运气,在写法。

没人有空啃 skill 源码——我替你啃了。我盯的是 Matt Pocock,做了一整套 AI 协作 skill 的人。他写过一个很妙的东西:一个专门讲怎么写好 skill 的 skill(writing-great-skills)。我把这篇,加上他几十个 skill 的源码和提交历史一起翻了一遍,扒出四条铁律。

四条而已,但每条我都配了一个反例——而且反例一个没编,全是从 Matt 自己的提交记录里挖的,他亲手犯过、又亲手改掉。连他都要回头改,说明这些坑是真的。

学会这四条:自己写 skill 少踩坑;不写,也能偷到他「把随机 AI 逼出确定性」的那套心法。

好 skill 只有一个标准:可预测

模型是随机的——同一句话问两遍,答得未必一样。skill 的全部意义,是从这台随机机器里榨出确定性:让它每次走同一个流程。

「A skill exists to wrangle determinism out of a stochastic system.」 —— Matt,writing-great-skills

注意是流程,不是输出。头脑风暴该每次蹦不同点子,但展开的方式得稳。

判一个 skill 好坏,就这一个标准:可预测。下面四条,全为它服务。

第一条 · 怎么触发:你明确喊,还是模型自动判断?

写 skill 第一个要拍的板:这个 skill,该由模型自己判断什么时候用它,还是只在你明确喊它的时候才启动? 技术上就一个开关——要不要写 description:

模型自动触发(model-invoked,带 description):AI 自己读得到它、自己决定何时用。代价是这段 description 每一轮对话都挂在上下文里,占 token、占注意力——这叫上下文负载。
用户明确触发(user-invoked,设 disable-model-invocation):description 被摘掉,模型看不见它,只有你手敲名字才启动。不花 AI 一分上下文,代价转到你头上:你得自己记得它存在——这叫认知负载。

原则:只有当模型(或别的 skill)必须自己够到它,才让它自动触发;否则设成手动,白赚零上下文负载。

反例:一个你其实只会手敲的 skill,却留着 description,让它每轮空占你的上下文。

真例:这取舍 Matt 自己都来回称过。grill-with-docs 的 disable-model-invocation 开关,他先删掉了——放手让模型自动触发;到最新版又把它加了回来,改回纯手动。同一个开关,删了又加。这说明「自动还是手动」是个真得权衡的决定,不是随手一设。

自己用:默认手动,先把上下文省下来;只有当你确实需要模型自己判断「现在该用它了」,才给它 description。一句话自检:「这 skill,谁需要够到它?」答案是「只有我」,就手动。

手动 skill 攒多了你自己记不过来,那是认知负载爆了。解法是再写一个路由 skill:一个手动 skill,专门列出其它 skill、告诉你什么时候用哪个。Matt 那个 ask-matt 就是干这个的。

第二条 · 放多少:SKILL.md 只留「每条路都用得上」的

信息阶梯:每条使用路径都用得上的,放进 SKILL.md 正文;只有某些情况才用的,下沉到单独的外链文件,正文里只留一句「需要时去看那个」的指针。目的是让顶层始终清爽——东西堆太多,AI 真正该做的动作就被淹了。

反例两种,都有名字:

臃肿(sprawl):啥都往一个文件里塞,越写越长。哪怕每行都对、都不重复,光是「长」本身就是病——AI 得先趟过一堆字才够到该干的活。
沉积(sediment):旧内容只加不删,一层层积下来,后来人得像考古一样往下刨,才找得到还有效的那部分。

真例:grill-with-docs 早期是个胖单体——盘问逻辑、文档格式、ADR 模板,全塞在一个文件里。Matt 把它一拆为三:盘问那半独立成 grilling,写文档那半独立成 domain-modeling,连 ADR、术语表的格式文件也下沉进 domain-modeling;grill-with-docs 只剩一句话的薄壳,把两者串起来。这就是拿信息阶梯给臃肿 skill 减重。

自己用:写完回头删。每一行问一句「这是每条路都要的吗?」不是的,要么下沉外链,要么直接砍。一个糙但好使的直觉——SKILL.md 越短、越只剩主干,通常越靠谱。

第三条 · 用什么词:借 AI 脑子里已经有的概念

这条最反直觉,我自己也是琢磨了好一会儿才转过弯。

主导词(leading word):一个 AI 在训练时早就学过、自带一身联想的现成概念。不限于专业术语——游戏、军事、医学、日常成语都算,只要 AI 一看就懂。写进 skill,你不用解释,它就把那一整串行为调出来。

例(全是借的,没一个是 Matt 发明的):

fog of war(战争迷雾,来自游戏/军事)→ AI 立刻懂「前方看不清,凭手头局部信息行动」。
tracer bullets(曳光弹,来自《程序员修炼之道》)→「先打通一条最薄的端到端,看准方向再加料」。
triage(分诊,来自医院急诊)、caveman(原始人=省话)、grilling(拷问)——拎现成概念就用。

去哪找:先把你要的行为说清楚,再倒着问「哪个现成的词、典故,本身已经就是这个意思?」往成语、名著、方法论、游戏军事、医学体育里捞。AI 读过的东西,就是你的词库。

怎么验——no-op 测试:把这个词单独写进去、不加解释,AI 就照你要的做了吗?做到了=真主导词,在白赚 AI 的先验;还得你解释半天它才懂=它没在出力,落进了反例:

废话(no-op):写了、但 AI 本来就会照做的话。比如「be thorough(要细致)」——AI 默认就有点细致,这行约等于没写。修法不是加解释,是换个更狠的词:「be thorough」→「relentless(穷追不舍)」。
重复(duplication):同一个意思写了好几遍。既费维护(改一处得改全部),又把这个意思的分量在 AI 眼里抬过了头。

真例:Matt 对这俩是真动刀的。他收紧 review skill,提交说明白纸黑字写着「single-sourced rules, no-op cuts」——归并重复规则、砍掉废话行。他甚至回头对 writing-great-skills 这篇本身下手,专门「把 no-op 猎杀到句子级」。

自己用:别用一整句话去描述你要的行为,找一个现成的词去钩它;然后把每个形容词、副词拎出来做 no-op 测试——删了它,AI 行为会变吗?不变的,就是水,删。

第四条 · 怎么收尾:每步要有可验证的完成标准

skill 常是一串步骤。每一步到底干完没有,靠**完成标准(completion criterion)**判定。

好的完成标准有两条讲究:一是可验证——AI 能客观判定「做完了」还是「没做完」,而不是凭感觉拍板;二是该穷尽就穷尽——比如「每一个改动过的模型都要交代到」,而不是含糊的「列个变更清单」。

反例 · 提前收工(premature completion):完成标准定得糊(「达成共识」「理解到位」),AI 够不着一条明确的边界,注意力就从「把活干完」滑向「赶紧算完」,没真干完就溜到下一步。

还有个连带机制:AI 要是看得见后面还排着哪些步骤,那股「快点做完往下走」的拉力会更强。对治之一,是把后续步骤藏到另一个 skill 里,别让当前这步惦记着赶路。

真例:grilling(从 grill-with-docs 拆出来的盘问那半)的招牌动作,就是一题一题问、你答完一题才问下一题——它的主导词正是「relentless(穷追不舍)」。当初把盘问和写文档拆成两个 skill,也是这道理:别让 AI 盘你的时候惦记着「问完赶紧去写文档」,那样它会草草收尾。拆开,盘问这一步就只剩盘问。

自己用:把每步的收尾条件写成可验证、最好可穷尽的(「每个 X 都……」,而不是「差不多了」);要是发现 AI 老在某步抢跑,就把后面的步骤挪到别的 skill 里去。

用这四条,看一件怪事:他为什么删了 caveman?

拿这四条去看个真实的案发现场。

我们第一篇讲的 caveman(让 AI 闭嘴、只说重点),现在去 Matt 的原始仓库找不到了——被删了。删除记录很朴素:

5 月底,他删掉了整个 caveman SKILL.md,提交说明就一句「精简产力类 skill」。
半个月后,又清掉 README、插件清单里残留的引用。
没有任何新 skill 来接班。 直接删。

为什么?用四条一量就懂:caveman 是个手动 skill,占的是你的认知负载——你得记得它在。可它干的那点事(省话、去客套),一句指令、或者一个全局输出风格就能要到,不值得单独占一个「你得记住的格子」。删它,正是在整个 skill 集合层面剪枝,砍掉不划算的负载。

声明一句:Matt 的提交说明只写了「精简」,没展开,这是我用这套框架做的解读。但框架能给出一个自圆其说的解释——这恰恰是它的用处。

四条不只是写 skill 的清单,它还能解释真实世界里一个 skill 为什么活、为什么死。

速查卡

铁律	该做	反例	一句话自检
怎么触发	只有要被模型自动够到才带 description,否则手动	白占上下文负载	「这个 skill,谁需要够到它?」
放多少	SKILL.md 只留每条路都要的,其余下沉外链	臃肿 / 沉积	「这行是每条路都要的吗?」
用什么词	借 AI 已有的现成概念当主导词,一词锚定一片行为	废话词 / 重复	「删了这行,AI 行为会变吗?」
怎么收尾	每步给一个可验证、能穷尽的完成标准	提前收工	「这步做完没,AI 能客观判定吗?」

唯一标准:可预测——同一情形,AI 每次走同一个流程。四条全为它服务。

最后

四条,写 skill 直接照着用。就算你这辈子不打算写 skill,它背后那套「怎么把随机的 AI 逼出确定性」的思路,照样能让你平时调 AI 调得更稳——说到底,这才是偷师高手真正的好处:你拿到的不是几条规则,是他脑子里那套判断。

出处:本文拆解 Matt Pocock 的 writing-great-skills(及其 GLOSSARY.md),仓库 mattpocock/skills,MIT 许可,版本 6eeb81b。文中「真实案例」都能在该仓库的提交历史里查到(已附 commit 链接)。

同系列:第一篇 · caveman · 第二篇 · grill-with-docs