怎么写出一个「真会被用到」的 Skill

写 Skill 这回事，听着挺简单，做起来不少人翻车。最近身边好些朋友开始给自己的 AI 配技能包，想把重复的活儿打包成可复用的能力。装上以后常见两种结局：要么 AI 压根不调用它，要么调用了，产出还是一团乱。今天不聊概念，只讲一件事——日常使用里，一个好用的 Skill 到底该怎么做。

先抛个结论：Skill 好不好用，七成在那段「描述」——它决定 AI 在什么时候想起你写的这套本事；剩下三成，看正文有没有把「怎么做」讲清楚。

先对齐：什么叫「好用」

一个 Skill 有没有用，不看它写得多全，只看两件事：该出手时它出手了吗（触发准）、出手后活儿干对了吗（产出稳）。下面整套方法，都是围着这两点转。

核心标准：触发准与产出稳

大多数 Skill 做出来就吃灰，不是写得不对，而是 AI 压根想不起来用它。触发准，意味着 AI 在恰当的场景下自动调用这个能力；产出稳，意味着调用后输出的结果符合预期。这两条做不到，写得再长也没用。

制作流程：六步，别跳步

顺序很关键。六步里最容易被省掉的，恰恰是第一步和最后一步。

• 从真实重复任务出发
  ：别为「假想需求」造 Skill，挑一件你这周真的重复做过三次以上的事。只有切身经历的痛，才能催生真正好用的解决方案。

• 把触发描述写满
  ：写清「什么时候用、处理什么文件、用户会怎么说」，再补一句「什么时候别用」。这是 AI 判断要不要调用的唯一依据，宁可啰嗦，不能抽象。

• 正文只讲「怎么做」
  ：写步骤、写顺序、写那些踩过坑才知道的约束（路径、依赖、先做 A 再做 B），而不是科普「它是什么」。AI 不缺知识，缺的是你这套具体打法。

• 抽离脚本和模板
  ：把会重复用到的代码和文件单独放好，让 AI 直接拿来用，而不是每次现写。这就像把常用工具箱整理好摆在手边。

• 拿小样本测触发
  ：故意换几种说法去问，看它会不会调用——不调用，就回去改描述。上线前至少测三遍，别等到真干活时才发现它不响应。

• 按反馈迭代
  ：触发不准就改描述，产出不稳就补步骤。Skill 是改出来的，不是一次写成的。第一次跑通只是起点，后续持续优化才是让它变好用的关键。

分层结构：别把所有东西塞进一个文件

好结构是「分层」的，按需加载——AI 平时只读最上面那层，需要细节时才往下翻。这叫渐进式披露：既省上下文，也更稳定。SKILL.md 只放描述和核心步骤，尽量精简；展开的细节、可复用脚本、模板示例，分别放进下面三层，用到才加载。这样结构清晰，AI 执行时也不容易迷失。

一套可直接套用的模板

说了这么多，直接给你一个能跑的骨架。它把上面讲的「触发描述 + 怎么做 + 注意事项 + 可复用资源」都占好了位——复制下来，把【】里的内容换成你自己的任务，就是一个 Skill 雏形。

name: 你的-skill-名字（让人一眼联想到任务）
description: >
  一句话说清做什么，再写清触发条件——
  当用户想做【某类任务】、出现【关键词 / 文件类型】时使用；
  并补一句反例：不要用于【不适用的场景】。

Skill 名称
什么时候用
触发场景：……
不要用于：……

操作步骤（按顺序）
输入从哪来、放在哪
关键约束：路径、依赖、先做 A 再做 B
产出长什么样、放到哪里

注意事项 / 踩过的坑
……（容易出错的地方写在这）

可复用资源
scripts/   可复用脚本
assets/    模板、示例文件

两个地方别糊弄：name 要让人一眼联想到任务，description 是重中之重，宁可写啰嗦也别写抽象——它直接决定 AI 会不会想起来用它。

偷懒法：让 AI 帮你「反向总结」出一个 Skill

其实你不用从零手写。更快的方式，是先让 Claude、ChatGPT 这类工具陪你把任务做一遍，再让它把过程总结成 Skill。具体五步：

• 完整做一遍
  ：在对话里把那件重复任务认真做完一次，过程中把你的要求、纠正、偏好都说清楚。

• 让它复盘成清单
  ：发一句——「把我们刚才完成这个任务的过程，总结成一份可复用的 SKILL.md，包含：触发描述、分步骤、注意事项、需要的模板」。

• 单独打磨描述
  ：再让它写出 3 种不同的触发说法和 1 条反例。描述越具体，以后越容易被自动调用。

• 抽出可复用件
  ：把过程里用到的提示词、表格、文件，让它整理成模板单独存好。

• 换个说法验证
  ：新开一个对话，用一句日常的话描述同类任务，看它会不会照这套流程走；不对，就把差异反馈回去让它改。

说白了，AI 最懂它自己刚才是怎么被指挥着把事做成的——让它把这段经验固化下来，比你凭空写一份说明书准得多。

最常踩的几个坑

• 描述写得太笼统
  ：AI 永远想不起来用它。宁可把触发场景写「啰嗦」，也别写抽象。

• 把 SKILL.md 写成说明书
  ：又长又全，关键步骤反而被淹没。

• 只说「是什么」不说「怎么做」
  ：AI 不缺知识，缺的是你这套具体打法。

• 写完不测就用
  ：上线前，至少换三种说法验证一次触发。

写在最后

写 Skill 不是写文档，而是把你脑子里「这事我习惯这么干」的隐性经验，翻译成 AI 能照着执行的明确指令。真正值钱的从来不是那段 Markdown，而是你那套被验证过的做事方法——Skill 只是它的载体。

所以别急着追求「大而全」。先挑一件你每周都嫌烦的小事，把它做成一个能被稳定触发的 Skill，跑通一次，比规划十个都强。