我写了十几个 AI Skill 才想明白：难的不是让它聪明，是让它别飘
哈喽，我是飞飞。
先撇清一下。上一篇我聊 Every 的「复利工程」，讲的是怎么让 AI 越用越懂你、把解法一点点沉淀下来。这篇不是那个，这篇更往下沉一层：怎么把单独一个 skill 本身，写得稳、写得不飘。
我这个号从选题、调研、写稿、润色、配图到分发，背后挂着十几个 skill，全是我自己一行行写出来、天天串起来跑的。写了这么多我最深的一个体会是：写 skill 最花功夫的地方，从来不在让它多聪明，在让它别飘。
昨天刷到 Matt Pocock（写 Total TypeScript 那位）开源的 skill 库，GitHub 十三万多 star，里面有份专门讲「怎么写好一个 skill」的东西。我对着自己踩的那些坑读了一遍，很多话戳得我一激灵。这篇就把他那套原则，和我这十几个 skill 磨出来的血肉，掺一块儿讲给你。
飘到底是什么意思
先说清楚什么叫「飘」。
Pocock 那套的核心词就俩字：可预测。他给的定义我很认同。一个好 skill，是 agent 每次跑都走同一套流程，不管这次具体产出是什么。
反过来，飘就是同一个 skill、同一句话调它，今天这么干、明天那么干，你永远猜不准它这回会不会给你整个花活出来。
这事对偶尔用一次的人不痛不痒。可我是把 skill 挂上流水线天天自动跑的人，飘一次，我就得回去擦一次屁股。所以对我来说，可预测这事没得商量。它就是这条流水线能不能自己转起来的地基。下面这四招，全是围着「让它别飘」来的。
先定谁来触发它
写一个 skill，第一个要拍板的往往不是它干啥这么直白。得先想清楚：谁来触发它。
Pocock 把它分成两类，还说这是头号决定。一类叫 user-invoked，只有用户手打命令才触发，平时不占 agent 的脑子；另一类叫 model-invoked，任务一匹配模型自己就调，靠的是那行 description 当触发器。他自己更偏爱手打那种，因为最可控。
这条我太有体会了，因为两类我都亲手写过。
我那个发公众号的 skill，就故意做成手打触发的：默认跳过，只有我明说「发到公众号」它才动。为啥？怕误推。一篇还没审的稿子被 agent 自作主张推出去，那事故就大了。而我拉资讯、选题那几个 skill 是自动触发的，我还在 description 里专门写了「别 undertrigger」，就怕它该出手时不出手，把过时的老数据当今天的新闻喂给我。
所以动笔前先问自己：这活儿，是我想什么时候用什么时候喊，还是让它自己看着办。答案不同，skill 的写法就两条路。
该写死的别留模糊
定完触发，第二招最实在：该确定的步骤，写死，别给模型留模糊。
Pocock 的说法是每一步尽量确定、把没用的步骤剪掉。我的翻译更糙：skill 里每留一处含糊，agent 就多一处自由发挥的空间，而自由发挥，就是飘的起点。
我在配图那个 skill 上栽过一个大跟头。最早我没把「图怎么处理」这步写死，只笼统说了句配图。结果 agent 可来劲了：有时候自作主张把图床链接直接塞进正文，有时候干脆漏图，说好三张出两张。我查了半天才反应过来，它不笨，是我这步留白留太多，它只能自己猜。
后来我把这条抠死成一句硬规则：写稿的 skill 只许写「截图 N」这种占位符，绝不许自己上传、绝不许自己塞链接，上传和替换是配图 skill 的活。边界一划清，这毛病再没犯过。
规则太宽也会反咬
但你别以为把规则写得越严越死就万事大吉，那是另一个坑。
规则写太宽、太一刀切，它会反过来咬你。我有一条专门扫 AI 味的 grep 规则，本意是揪出那种工整的对仗腔，结果它写得太宽，把正文里「它是不是天天重复、规则是不是清晰」这种正常疑问句，也当成对仗给揪出来了。这叫假阳性，规则没帮上忙，还得我回头一条条人工排除。
所以这招的分寸在于：精准，比严格更重要。你要的是那条规则不多不少正好圈住该圈的东西，而不是宁可错杀一千。写完一条硬规则，我现在都会拿几个正常句子过一遍，看它会不会误伤。
主文件瘦身细节外挂
第三招，是关于 skill 怎么排版的：主文件瘦身，细节外挂。
Pocock 管这叫渐进式披露，说人话就是把主 SKILL.md 保持精简、只放核心流程，那些又长又细的规则挪到外部参考文件里，用到了再加载。他们测出来这样能把常驻的上下文砍掉六成多。
我的写稿 skill 就是这么长起来的。主文件 SKILL.md 只放「先干啥再干啥」的骨架，真正那本又臭又长、迭代到一百多次的写作规则清单，我全塞进旁边的 references 文件里。好处是双份的：主文件不会被撑成一本书没法读，agent 每次也不用把所有细则背一遍才动手，用到哪条翻哪条。
一句话记：主文件是目录，不是全书。
给它配个自动改错
前面四招都是怎么把一个 skill 写好，最后这条是我自己琢磨出来、比原文更进一步的：给它配一个能自己改错的回路。
因为再周全的 skill，也是一个坑一个坑踩出来的，不可能一次写对。我专门做了个叫 content-training 的 skill，它的活就是每写完一篇，把这回润色时暴露的新毛病自动提炼成一条规则，回写进那份规则清单。等于这套 skill 每被用一次，就顺手把自己又收紧了一点。
这才是我敢让这条流水线天天无人值守跑的底气：它不光执行得稳，还能在犯错里自己变得更稳。我那份规则清单能滚到一百多次还没散架，全靠这个回路兜着。skill 不该是写完就冻在那儿的死文件，得是一个会自己长的东西。
今天先改哪个 skill
四招讲完，给你个今天就能上手的最小动作，别一上来就重构。
挑你手头最常用的那一个 skill，只干两件事。一件，想清楚它到底该用户手打触发还是模型自动触发，把这事定死；另一件，回去翻一遍，找出最容易被 agent 自作主张的那一步，把它从模糊改成一句写死的硬规则。就这两下，你多半就能感觉到它稳了一截。别嫌小，我这十几个 skill，也是从把一步步含糊抠成确定攒起来的。
说到底，写 skill 这事，真正难的不在让它显得多聪明，在让它每次都规规矩矩走同一条路、不飘。聪明是锦上添花，可预测才是能挂上流水线的前提。
你那些 skill 里，最爱飘的是哪一步？有没有被 agent 自作主张坑过一次让你哭笑不得的经历？评论区讲讲，我们对对坑。