有了 Tools，LLM 能做具体的事情。但工具太多怎么办？用户说"帮我写一篇关于 AI 的文章"，涉及的工具可能有搜索、阅读、写作、格式化——LLM 可能跳过搜索直接瞎编，或者调用错误的工具顺序。

Skill 就是一组工具的说明书：告诉 LLM 遇到什么场景该用什么工具、按什么顺序、注意什么坑。

一、Skill 不是一个文件，是一个文件夹

很多文章把 Skill 说成"一个 .md 文件"，这个理解不够。一个生产级 Skill 的结构是这样：

skill-name/
├── SKILL.md        ← 主体指令 + 坑点清单（最值钱的部分）
├── references/     ← 参考文档（按需加载，不占上下文）
├── scripts/        ← 可执行脚本（确定性执行，不走 LLM 推理）
├── assets/         ← 模板、资源文件
├── outputs/        ← 输出目录
└── config.json     ← 跨会话记忆（可选）

SKILL.md 的核心不是"写一段提示词"，而是包含：

• 名称和 description：告诉 LLM 在什么场景下用——不是形容词堆砌，而是 if 判断条件
• 执行步骤：详细的 Tool 调用链路和参数
• 坑点清单：不写 LLM 默认就会的东西，只写真摔过跟头才知道的
• 约束规则：什么不能做比什么能做更重要

设计原则：信息要满，但指令要松。给出足够的信息让模型理解上下文，但留下空间让模型自己判断。

二、为什么需要 Skill

实验数据：可用工具从 10 个扩展到 200 个时，模型工具选择准确率从 95% 跌到 41%。

原因来自 Transformer 的 O(n²) 复杂度——几十万 token 塞进上下文，注意力稀释，关键指令被淹没。

Skill 就是解药——把"一组工具的调用顺序"打包成一个命名概念。LLM 不是从 200 个工具中选 4 个排好序，而是直接选 1 个 Skill。

三、渐进式披露

当有几十上百个 Skill 时，不可能一次全塞进上下文。生产环境的答案是渐进式披露：

L1 元数据索引 → 技能名 + 一句话描述（几十个 token）
     ↓ 命中
L2 意图理解 → 动态注入 Schema + 参数 + Few-shot（按需）
     ↓ 复杂报错或长文档
L3 深水执行 → 全文加载（低频率）

这套架构能把 token 开销削减 90% 以上。

四、一个 Skill 的四阶段演化

一个有价值的 Skill 会经历四个阶段：

阶段一：不被触发。 description 写成了形容词堆砌（“非常好用的 Skill”），LLM 不知道什么时候该用。改成 if 判断条件：“当用户要求写代码并需要单元测试时使用”。

阶段二：活干不对。 缺验证关卡。加一条"跑起来→收集输出→断言结果"的验证步骤，质量立竿见影。

阶段三：反复翻车。 缺坑点清单。实战案例——一个动画 Skill 前期只有 3 条坑点，随着反复翻车喂到 22 条：等 30 帧后再截图、CDN 手动刷新缓存、从 assets token 取配色。

阶段四：Skill 间抢资源。 缺度量。用调用埋点区分主力 Skill 和化石 Skill——配色 Skill 月调 4 次、动画 Skill 月调 100+ 次。把精力集中砸在高频 Skill 上。

五、技能路由

Skill 过多时最关键的问题是：Agent 如何知道该用哪个？

场景	建议
二三十个 Skill	前置语义过滤 + 经典提示词
上百个 Skill 的生产系统	渐进式加载 + 语义路由是唯一解法

语义路由不是大模型做的事，是 CPU 级别 μs 级完成的轻量分流。

六、Skill vs Tool vs MCP

概念	类比	说明
Tool	螺丝刀、锤子	单个工具能力
Skill	组装说明书	多个 Tool 的组合流程
MCP	万能转接头	标准化 Tool 的接入协议
Prompt	口头交代	模型可选不遵守
Skill	详细操作手册	按步骤执行，更可靠

设计原则：Tool 越底层越好，Skill 越上层越好。

七、从零开发 Skill 的实战要点

1. 一个 Skill 聚焦一个场景，不做多件事
2. description 是 if 判断条件，不是形容词堆砌
3. 步骤要具体可执行：不是"分析数据"，而是"用 search 查文档→用 calculator 统计→用 write 输出"
4. 必须有验证关卡，确认 LLM 做了正确的东西
5. 坑点清单持续迭代，每次翻车就加一条
6. 加埋点度量调用频率，区分主力 Skill 和化石 Skill
7. 约束规则不能省：什么不能做比什么能做更重要