怎么写出一个「真会被用到」的 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，跑通一次，比规划十个都强。
