现在但凡用 AI Agent 做点正事的人，手上都有几个自己写的 Skill。
但说实话，大部分 Skill 写得跟 Prompt 没啥区别——把背景、规则、注意事项、示例一股脑塞进一个文件，看起来很完整，实际跑起来并不好用。
Skill 和 Prompt 的区别不在于长度，在于架构。
一、先搞清楚 Skill 到底是什么#
三个概念容易混淆：
- 系统提示词 / CLAUDE.md — 常驻上下文，一直在，一直影响模型行为
- Slash Command — 手动触发，用户必须明确输入命令
- Skill — 介于两者之间，按需加载
Skill 的核心机制是 on-demand loading。平时它的完整内容不在上下文里，只有当用户的输入和 Skill 的 description 匹配时，才会被加载进来。
这意味着一件事：description 写得好不好，直接决定 Skill 会不会被正确触发。
反面教材：一个封面图生成 Skill 的 description 只写 “Create an image”。
正面教材：同一个 Skill，description 应该覆盖用户真实会说的各种表达——
帮我做一张封面图 / 给这篇文章配个图 / 做一张小红书封面 / 按这个标题做一张科技感海报
用户不会说"调用封面图 Skill"。他们用自然语言描述需求，你的 description 要能接住这些表达。
低频 Skill 就别自动加载了#
有个实用技巧：如果你有很多 Skill，或者某个 Skill 很长，可以设置 disable，关掉自动加载，降级为 slash command。
为什么？因为自动加载类 Skill 至少要让 description 长期参与匹配。Skill 越多，常驻的匹配成本越高。年终总结 Skill 一年用几次、简历重写 Skill 找工作才用——这类东西没必要一直占着 context。
降级为手动调用的好处是省 context、少误触发。代价是用户必须记得主动叫它。
二、限制工具边界，最小权限原则#
Skill 可以配置允许使用的工具列表。这不是摆设。
整理学习笔记的 Skill，只需要读和写：
allowed-tools:
- Read
- Write
- Grep封面图生成的 Skill，需要读参考、写 prompt、调图片工具：
allowed-tools:
- Read
- Write
- ImageGenerate批量处理数据的 Skill，才需要开放更多权限。
核心原则：只给完成任务所需的最小权限。
让只负责分析建议的 Skill 默认能改文件，让只读 Skill 默认能跑 Bash——这不是灵活，这是给自己埋雷。工具越多不一定越强，有时只是风险更大。
三、不同 Skill 配不同模型#
这一点经常被忽略。
所有任务用同一个模型，要么浪费钱（简单任务用贵模型），要么质量差（复杂任务用便宜模型）。成熟的 Skill 系统应该根据任务类型选模型：
| 任务类型 | 模型选择思路 |
|---|---|
| 写文档 | 表达清楚、结构稳定，中等模型即可 |
| 做图/设计 | 多模态能力，视觉理解强的模型 |
| 数据分析 | 推理不错但成本可控 |
| 信息爬取 | 批量抽取，便宜快的模型更合适 |
| 生成长文 | 写作节奏和观点判断，用写作能力强的 |
模型选择不是炫技，是成本和可靠性的平衡。
四、SKILL.md 是入口文件，不是百科全书#
这是最容易犯的错——把所有内容都塞进 SKILL.md。
结果呢？Context 被瞬间占满，Agent 性能变差，思考时间变长，甚至触发 Compact 导致"失忆"。
SKILL.md 应该只放这些：
- 什么时候触发
- 做事原则
- 执行步骤
- 需要哪些工具
- 其他资料在哪里
- 最后怎么验证
其他的，分层存放：
封面图生成/
├── SKILL.md ← 入口，流程和原则
├── references/
│ ├── 封面图风格参考.md
│ ├── 常见平台尺寸.md
│ └── 好坏案例对比.md
├── scripts/
│ ├── 检查图片尺寸.py
│ └── 导出多平台版本.py
└── assets/
├── 封面图模板.md
└── 字体与配色示例.jsonreferences/ 放长文档——风格参考、平台尺寸、详细案例。
scripts/ 放可执行代码——检查图片尺寸、批量重命名、导出多平台版本。这些确定性操作用脚本比让模型每次现场生成更稳定。
assets/ 放模板和样例——schema、图片示例、输出格式。
Agent 先读 SKILL.md 知道流程，真的需要细节时再去读 reference，执行 script。按需读，按需执行。
这就是渐进式披露（Progressive Disclosure）。SKILL.md 建议控制在 500 行以内。超过通常说明分层没做好。
五、写完不等于能用——Skill 的验证闭环#
很多人写完 Skill 就发布了。但你真的验证过吗？
一个靠谱的 Skill 至少要过三关：
第一关：能不能跑#
最基础的执行能力验证：
- 文件路径对不对？
- 工具权限够不够？
- 脚本能执行吗？
- reference 能读到吗？
- 输出格式符合预期吗？
连真实任务都跑不通，后面谈触发和质量没意义。
第二关：能不能正确触发#
自动加载类 Skill 要测试触发准确性。
不能只测"请运行 XX Skill"——真实用户不会这么说。应该准备一组真实表达：
“把这个想法展开成一篇长推” “帮我写一篇 X 长文” “这个观点能不能写成一条长内容”
该触发的不触发，说明 description 要补关键词。不该触发的触发了，说明 description 要收窄。
第三关：结果是不是真的更好#
最容易被忽略的一步。
同一个任务跑两次——一次不用 Skill，一次用。然后打分（0-10）：
| 分数 | 含义 |
|---|---|
| 0-2 | 完全没完成，方向错了 |
| 3-4 | 勉强相关，漏掉关键要求 |
| 5-6 | 基本可用，有明显问题 |
| 7-8 | 质量稳定，少量细节可改 |
| 9-10 | 非常符合预期，可做示范 |
如果不用 Skill 是 4 分，用了是 8 分——Skill 真的有用。
如果都是 7 分——Skill 可能在做无用功，你只是把 Prompt 保存下来而已，并没有把经验固化进去。
六、根据评分迭代#
评分不是为了好看，是为了定位问题：
- 触发失败 → description 补案例
- 误触发 → description 加排除条件
- 步骤遗漏 → 改 SKILL.md 步骤
- 输出格式不稳定 → 加 assets 模板
- 确定性检查不稳 → 写成 script
- 工具权限不对 → 调整 allowed-tools
- 模型能力不够 → 换模型
然后跑下一轮 eval。写 Skill → 测 → 打分 → 改 → 再测。这个闭环跑通了，Skill 才算真正可用。
七、写 Skill 之前先问自己七个问题#
别急着动笔。先想清楚：
- 用户说出哪些话时，这个 Skill 应该出现？
- 它出现后，应该按什么流程做？
- 它允许用哪些工具，不允许做什么？
- 它适合什么模型？
- 哪些内容留主文件，哪些拆出去？
- 怎么证明它真的有效？
- 后续怎么持续维护让它更好用？
能回答完这七个问题，写出来的才是 Skill。回答不了，大概率只是一个穿了马甲的 Prompt。
Skill 的本质不是"把提示词写长保存下来"。它是把经验固化成可触发、可执行、可测试、可维护的工作流。这两者的差距，就跟脚本和正儿八经的工程一样大。