做了几十个 Skill 才摸透，真出活的都跑不出这七步

上一篇聊到，。Skill 说白了就是你提前写好的一组规矩，AI 接到活时自己翻出来照着做，省得你每次重复交代。

但“要亲手写”这句话说完，下一个问题就来了：到底怎么写？这事我自己也琢磨了很久。写起来好像不难，让 AI 帮着写更省事。可一项学术测试跑出来的结果挺扎眼：84 个真实任务里，16 个装了 Skill 反而比不装还差。写对了很管用，写不好比不写还糟。

我之前给品牌片拆解视频做 Skill，前后记了 51 个坑。后来拿这套做法对照官方文档、学术测试和一线团队的经验，合并调整，定成了七步。算不上标准答案，能帮你少踩几个坑就值了。

01

先判断：哪些活值得做成 Skill

值得做成 Skill 的活，一般是你平时反复要做、同一句要求已经在对话框里交代过第二遍的事。YC 总裁 Garry Tan 就说过：“同一件事要说第二遍就算失败。”另外，这活 AI 默认做不好，或者你自己有一套独特的交付手法，而且你一眼看到成品就能说出好坏。

反过来，如果是一次性的活，或者 AI 默认给出来的结果就已经够好了，甚至连你自己都还没想清楚到底什么算好，那就先别做。这条线怎么划？AI 博主宝玉的例子很清楚：他平时写长文配图，从选图到排布要耗不少时间，做成配图 Skill 之后，几分钟就能出。但他不是什么都往 Skill 里塞。AI 已经会的、搜一下就会的，不做；反复踩坑、每次都要重新解释的，才做。

同样是“自己能说出好在哪”这件事，设计师、AI 博主歸藏走得更远。他做演示文稿有一套自己的审美，索性把十年的排版习惯做成了 PPT 的 Skill，开源出来，谁都能免费拿去用，在 GitHub 上拿到了两万多个星标。

说到这里，七步的核心其实就一件事：把你心里的“好”掏出来，变成 AI 看得见、能对照、会去查、关键时刻想得起来用的东西。后面的每一步，都在做这件事。

02

带 AI 做对一遍，留下样板

事情挑好之后，先别急着写规矩，先带 AI 实打实走一遍，手里做出一份合格的成品。动手前可以不加 Skill 让它先跑一次，把底稿存下来当对照，后面你会知道这个底稿有什么用。然后一步步带着它做顺，把最终满意的成品留下来当参照。要是自己都没跑顺过，写出来的规矩往往全凭空想。

这个道理听着简单，但真这么做的人不多。视频剪辑工具公司 OpusClip 里有个销售团队，平时几乎不写代码。他们准备客户续约方案时材料散在好几个工具里，每个客户要耗上大半天。后来他们先把材料拖进对话里带着 AI 做，确认做出来能用，再收成 Skill。结果续约简报快了很多，原先只有一小部分销售通话有人复盘，后来基本全覆盖了。他们没做什么高深的事，就是把“带着 AI 做一遍”这个动作，老老实实做了一遍。

卡兹克做写作 Skill 走的也是这条路，但他多了一步：放两三篇代表作让 AI 写初稿，自己动手重写，然后把两版丢回去让 AI 找差别。这个“写、改、对比”的循环重复 3 到 4 轮就够了，改太多轮 AI 反而会僵化，只会照搬。

所以管用的 Skill 不是“写”出来的，是带它做对一遍跑出来的。做完之后检验一下：你自己能不能指着这份成品说清楚它好在哪。说得出，就往下走；说不出，就还没到写规矩的时候。

03

把“好在哪”拆成能打勾的标准

成品有了，但光说“照这个感觉来”，AI 抓不住重点。你得把满意的细节一条条拆开，写成能逐项核对的清单。

歸藏做 PPT Skill 的时候就是这么干的。他带了一张检查表，把问题分成几级，最严重的一档撞上就得改，比如连着好几页都是同一个主题，他会直接判为要重做。他还让 Skill 先问清需求再出大纲，他说这一步拦掉了不少返工。过去他花很长时间手动微调网格、字号和颜色编号，做成 Skill 后，只负责对照清单检查打勾。他的标准是十年排版习惯换来的，别人抄不走，但“把标准拆成能打勾的条目”这个动作，谁都学得来。

标准怎么定，每个人不一样。做营销的 Corey Haines 关心的是真假，他要求文案里每句话都得过几道关，其中一道就是能不能证明是真是假，编造数据直接拦掉。我自己给品牌片拆解视频定标准时，一开始只知道“画面要好看”，后来才理出两条明确要求：静态图一次最多停 2 秒（讲的就是这张图时例外），同一个画面不连续挂超过 3 秒，第一条还做成了自动检查。

不管定的是什么标准，有一条是共同的：清单要精简。SkillsBench 测试显示，聚焦、中等长度的 Skill 让通过率提高了 18.8 个百分点，像手册一样大而全的综合文档不升反降，掉了 2.9 个百分点。想知道定得好不好，有个简单的检验办法：把清单拿给没参与这事的人看一眼，看他判出来的对错跟你一不一样。一样，说明标准够清楚；不一样，说明你写的还是太模糊。

04

明知故犯的写禁令，往外发的人把关

打勾清单防住了大部分问题，但有些错 AI 不是做不到，是明知故犯。这种光靠打勾拦不住，得单独列出来写死不准做。

怎么区分禁令和给好样子？其实很简单：它一做出来你就想当场喊停的，写禁令；你只是觉得做得不够好的，给它看对的范例。编造数据、泄露内部信息、自动往外发内容，都属于前者。

我自己就踩过这个坑。做品牌片拆解视频时，AI 自作主张把彩色画面褪成黑白来表达“没意思”，我看到后当场叫停。国内观众看到黑白画面容易联想到不好的事，AI 自己不懂这个，这种事就得在规则里直接写死不准出现。同样，像发微博、发群消息这种往外发内容的动作，我们一律关掉自动调用，什么时候发送全由人工来点。

花叔做去 AI 味的 Skill 时也遇到过类似的事。他拿一篇长文做实验，发现原稿里一段生动的个人经历在作者社交动态里查无出处，疑似以前编造的。他由此定了一条规矩：不能凭空编造，查不到真实背景就直接写“待补”。

05

无意的走样，给它看对的样子

不准做的事讲清楚了，可格式和语气还是会跑偏。这种走样不是故意的，是它根本不知道对的长什么样。光跟它喊“不要”不管用，规矩只会越补越多，改不过来。

向阳乔木做设计 Skill 时验证了这一点。他把前几版优秀的细节合在一起做成融合版，重测后却被评为“没有显著更好”。他后来总结了一句话：禁令只抬下限，不抬上限。意思是，你告诉它不要怎样，它只是不犯那个错了，但也不知道该往哪个方向好。

我自己调配音时就吃了这个亏。一开始在规矩里写“声音浑厚有气场”，模型只是机械地把音调往下压，听起来沉闷无力。后来我不再把形容词翻成参数，改成拿几段样音，用耳朵挑。配音语速太紧像机关枪时，改人设、加省略号全不管用，把旁白换成口语表达后，停顿自然多了，再对照样音调几遍，听着才像那么回事。这个教训让我明白了一件事：AI 听不懂形容词，它只认得你给它看过的东西。你说“浑厚”，它就压低音调；你说“自然”，它就加点停顿。但你拿一段真实的录音放在它面前，它反而能摸到那个感觉。

所以给好样子有两条路。要它每次都输出得一模一样，就给模板，像歸藏那样把代码骨架直接塞进 Skill 里；要它能举一反三，就按宝玉说的，别给死模板，给清目标和规范，再配一两篇样板当参照。

06

拿真话考它，把踩过的坑记下来

规矩和参考都准备好了，先别急着收工。你得拿平时真实干活时常说的话去测它几轮，看它到底听没听懂。

宝玉说过一句话：“好的 Skill 不是写出来的，是用出来的。”OpenAI 官方也建议，准备一批平时会提的真实需求去测它，顺便掺几句意思接近但本来不该用到它的话，看它会不会乱应答。Anthropic 工程师 Thariq 也提到，Skill 里最有用的就是每次的踩坑记录，遇到出错就按“现象、原因、修法、防范”随时补进去。

我自己做视频拆解时，最初是指一处改一处，后来才立下一条规矩：只要被抓出一处问题，就按同一类别把整片筛查一遍。当时截图圈出的静止海报、黑底卡片、黑白画面、虚化太久、字幕黑带这五个毛病，看着五花八门，归拢起来原因差不多，都是画面太暗、静止或者停留时间太长。五个毛病其实是一类，一次就能全改完，比一个一个抠快得多。

除了新踩的坑，走过的回头路也得记下来。我们曾把转场的“先暗一下再变亮”换成直接硬切，结果切点第一帧比例出错，露出了原片字幕。原来之前的淡入正好盖住了渲染工具的瑕疵。修好之后我们在清单里写明“不要改回直接硬切”，免得以后不知情又把问题改回去。这一步改得顺不顺，就看平时用起来的时候，同一句要求你还要不要再说第二遍。

07

换个没参与的人，从头跑一遍

自己测完虽然改掉不少问题，但看久了难免有漏掉的地方。找个完全没参与的人来跑一遍，最容易看出破绽。

花叔做自动化迭代时定过一条规矩：改 Skill 的 AI 不准自己打分，要换一个没参与修改的 AI 来打分，退步了就撤回。superpowers 作者 Jesse Vincent 更狠，他会模拟线上系统突发故障、损失按分钟计的紧急场景，专门挑手忙脚乱的时候看它守不守规矩。

我自己也靠这一步查出过要命的漏洞。拿一个完全没参与编写的 AI 去测视频 Skill 时，我把配置里的场景直接删掉，系统照样提示生成成功，片子从 35 秒缩水成 24 秒，没有任何报错。一查才发现，当初写的检查只核对台词在不在，根本没查台词有没有全部用完。

让人来测主要看两点：一是对方不问你就能自己跑完流程，二是拿那份打勾清单一条条核对，看结果对不对。

08

开头写清何时用、平时怎么叫它

整套流程就算全跑顺了，最后还有一个容易忽略的环节：Skill 开头那段简短说明。要是没写明白什么时候用，AI 接到任务时根本不知道该把它调出来。

Garry Tan 就吃过这个亏。他自己写过几十个 Skill，其中有好几个从来没被触发过。宝玉解释过背后的机制：AI 启动时只读每个 Skill 的名字和一段很短的说明，全靠它来判断要不要调用。Anthropic 官方也专门优化过一批公开 Skill 的说明，改完后不少被调用的概率明显提升。花叔在批量维护时也发现，说明写得太简略会导致模型根本认不出使用场景。

说明里写清三件事就够了：它是做什么的、什么情况下用、大家平时怎么叫。不要堆砌步骤摘要。superpowers 作者测过，说明里要是顺手写成“任务之间做一次评审”，哪怕正文明确要求两次，AI 也只做一次。测试也简单：拿该用的话和不该用的话各试几句，确认它该调的时候能调出来、不该调的时候别乱跑。

走到这里，整个 Skill 差不多就能拿去日常用了。要是你手头也有常做的活想做成 Skill，可以拿这几条当参考：

一、带 AI 做对一遍，把满意的成品留下当样板； 二、把“好在哪”拆成能打勾的标准，写成可核对的清单； 三、明知故犯的写禁令，往外发的内容由人来把关； 四、无意的走样别光喊“不要”，给它看对的样子； 五、拿平时会提的真需求多测几遍，踩的坑随手记下； 六、换个没参与的人从头跑一遍，看别人照着能不能跑通； 七、开头写清什么时候用、平时怎么叫，AI 才调得出来。

SkillsBench 测试的 84 个任务里，那 16 个装了反而变差的，可能就跟规则写得太死、没讲清楚什么情况下才用有关。七步走完，你留下的不是一份文档，是 AI 下次替你干活时的底气。

参考文章

• 《我写了个 Skill，让 Agent 自动给文章配图》，宝玉，宝玉的分享（博客），2026-01-15

• 《别把整个 GitHub 装进 Skills，Skills 的正确用法》，宝玉，宝玉的分享（博客），2026-01-22

• 《今天，我决定把「卡兹克风格创作.skill」开源了。》，数字生命卡兹克，微信公众号

• 《开源一个 PPT Skill｜压进了我 10 年的设计经验》，歸藏，腾讯新闻，2026-04-24

• 《达尔文.skill正式发布，一个无限进化的skill系统！》，花叔，花叔个人网站，2026-04-13

• 《Improving skill-creator: Test, measure, and refine Agent Skills》，Anthropic，Claude 官方博客

• 《Improving frontend design through Skills》，Anthropic，Claude 官方文章

• 《SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks》，Xiangyi Li 等，arXiv 预印本第一版（2602.12670v1），2026-02-13