Skill 不是更长的 Prompt——如何让 AI 按流程稳定完成复杂任务

我的立场：这篇官方最佳实践里，渐进式披露和最小权限两条我完全认同，是实打实能落地的工程原则。但「验证 + 打分 + 基线对比」这套流程说起来轻巧，真正照做的团队成本不低——文档里没有正面回答这笔账划不划算，这也是我认为整套方法论里最薄弱的一环。

Skill 是可复用的工作流，不是更长的 Prompt

Prompt 是一次性指令，Skill 是可复用、自主触发、可维护、可进化的工作流。官方用厨房比喻：MCP 提供「专业厨房」——通向 Notion、飞书等服务的接口；Skill 提供「食谱」——告诉 AI 怎么用工具做出有价值的东西。MCP 决定 AI 能做什么，Skill 决定 AI 该怎么做。这个比喻我认为是这篇文档里最清晰的一句话，比后面大段的规则条目都更能一次讲明白两者的分工。

动手之前，先定 2-3 个具体用例

先回答四个问题：用户想完成什么？需要哪些多步流程？需要哪些工具？应该嵌入哪些领域知识？每个用例写清四件事——用例、触发、步骤、结果。定不出 2-3 个具体用例，说明你需要的可能只是一段 Prompt。

Anthropic 把 Skill 归成三类：文档与资源创建（重点是质量检查和模板结构）、工作流自动化（重点是步骤衔接和关卡验证）、MCP 增强（服务提供方写给用户的「怎么用」说明书）。开工前想清自己在哪一类，写法重点完全不同。

按需加载：Description 决定成败

Skill 的特点是 on-demand loading（按需加载）——平时不会把整个 SKILL.md 塞进上下文，只有当用户输入与 description 匹配时才加载。关键细节：Skill 正文不常驻，但 description 会长期参与匹配，直接决定 Skill 会不会被正确触发。Anthropic 公式：[做什么] + [什么时候用] + [关键能力]，不超 1024 字符，必须用第三人称。

好的描述示例：拆解小红书爆款笔记的封面、标题、开头、结构、关键词，输出可复用的模板。当用户说「拆解一下这条笔记」、「分析这个爆款」，或贴一条小红书链接时，使用这个 skill。

— Anthropic Skill 最佳实践

最小权限 + 匹配合适模型

核心原则：只给完成任务所需的最小权限。不要让只负责生成建议的 Skill 默认能修改文件，甚至可以细致到子命令级别——发布文章的 Skill 只允许跑发布脚本，不能动其他文件。不同任务对模型要求不同：写文档用写作强的；数据分析用推理不错但便宜的；信息爬取用快而便宜的。配合 effort 字段控制思考深度：简单任务低思考省钱，复杂决策高思考换准确率。

图解 15 渐进式披露：Skill 的三级加载，各级付的成本不同 工程师向

← 图片可左右拖动查看 →

渐进式披露：SKILL.md 不承载所有内容

这是最容易被忽略的原则。三级加载：Description（始终加载）→ SKILL.md 正文（匹配时加载）→ 捆绑文件（按需读取，放在 references/、scripts/、assets/）。SKILL.md 建议 500 行以内——超过通常说明你把太多东西混在一起，拆完还长可能说明这不是一个 Skill 而是几个。

渐进式披露的目的是「在保持专业知识的同时，最小化 token 用量」。省钱看得见，省上下文空间看不见——但长对话里后者影响更大。

— Anthropic 官方文档

两个原因：省 token（一个月几万次调用就是真金白银的 API 账单）与省上下文空间——内容太多会挤占对话历史、埋没关键指令（「中段迷失」）、触发自动压缩导致模型表现下降。

写完必须验证、打分、迭代——但这笔账没那么好算

Skill 写完不代表能用。至少做三类验证：能不能跑、能不能正确触发（该触发的触发、不该触发的不触发）、结果是否比不用 Skill 更好——最容易被忽略的一点。每个用例 0-10 分打分，主要测试至少 5 分以上。想更专业可以做基线对比：同一个测试跑两次，7 分变 7 分说明没增益，4 分变 8 分才说明经验真正被固化了。