Anthropic 新发布的《The Complete Guide to Building Skills for Claude》，非常值得学习一下。
学习要重信息源。到信息的源头去学习。
想学习 Claude Skill，当然得看看 Anthropic 的官方文档。
Skill 是什么？不是提示词库
很多人听到 "Claude Skill" 第一反应是"又一个提示词模板集合"。
其实不然。
Skill 是一个文件夹，包含：
- •
SKILL.md（必须）：YAML 前置元数据 + Markdown 指令 - •
scripts/（可选）：Python、Bash 等可执行脚本 - •
references/（可选）：按需加载的参考文档 - •
assets/（可选）：模板、字体、图标
它解决的核心问题是：你只教 Claude 一次，以后每次它都记得。
官方文档里有个厨房比喻，我觉得相当准确——
MCP 是专业厨房：提供了刀具、食材、灶台，Claude 能"接触"到一切。
Skill 是食谱：告诉 Claude 用这些工具，按什么顺序，做出什么东西。
有厨房没食谱，厨师每次都在即兴发挥，结果不稳定。有食谱有厨房，出品才能标准化。
渐进式披露：一个被低估的设计决策
这是整份指南里我最感兴趣的部分，也是大多数人建提示词时根本不会考虑的问题。
官方把 Skill 的加载机制设计成三个层级：
第一级：YAML 前置元数据，永远加载进系统提示。这里只放最关键的信息——Skill 叫什么名字、什么情况下触发。字符数严格控制，因为它要一直占用 context。
第二级：SKILL.md 正文，当 Claude 判断当前任务和这个 Skill 相关时才加载。完整指令、工作流程、注意事项都在这里。
第三级：链接文件，放在 references/ 目录里，只在 Claude 真正需要时才按需读取。
这个设计的聪明之处在于：不是把所有东西都塞进 context，而是让 Claude 自己按需取用，最大程度降低 token 消耗，同时保留专业深度。
类比一下——这就像一个有经验的医生看病。问诊时只要知道症状，不需要把医学院所有教材都翻出来，但当遇到罕见病例时，他知道去哪里查，能拿出详细资料。
普通提示词工程师的思路是把所有东西都塞进 system prompt，然后抱怨 Claude 忘事。Anthropic 的解法是设计分层架构，让信息按需流动。
三类用例，覆盖 80% 场景
官方把 Skill 的应用场景归纳成三类，这个分类方式值得记下来：
类别一：文档与资产创建。 生成一致的输出物——文档、前端界面、演示稿、报告。典型触发词是"帮我写"、"生成一份"。核心技术是嵌入式风格指南和质量检查清单。
类别二：工作流自动化。 多步骤流程，顺序执行，每步有验证。Sprint 规划、客户入职、竞品分析——凡是你能把步骤写下来的流程，都可以变成 Skill。
类别三：MCP 增强。 这是最有意思的一类。已经有了 MCP 工具连接，Skill 的作用是告诉 Claude"在这个工具上，怎么干最好"。Sentry（哨兵） 的代码审查 Skill 就是例子——MCP 给 Claude 接入了错误监控数据，Skill 教会它怎么用这些数据分析 PR 里的 bug。
官方指南的整体知识结构可以用下面这张图来概览：
写一个好的 Skill description，比你想的难
YAML 前置元数据里的 description 字段，是 Claude 判断"这个任务需不需要加载这个 Skill"的唯一依据。
写得太宽泛，Skill 会过度触发，打扰不相关的对话。
写得太窄，该触发时不触发，Skill 成了摆设。
官方给出的公式很简单：[它能干什么] + [什么情况下用它] + [关键能力]
好的写法是这样的：
description: Analyzes Figma design files and generates developerhandoff documentation. Use when user uploads .fig files, asks for"design specs", "component documentation", or "design-to-code handoff".
差的写法：
description: Helps with projects.
区别在于：前者包含了具体的触发短语（用户真实会说的话），后者只有功能描述。Claude 需要知道的是"什么时候该想到我"，不是"我是什么"。
还有一个安全要求值得注意：description 里不能包含 XML 尖括号，因为这段内容会直接出现在系统提示里，恶意内容可能注入指令。Skill 的名字里也不能包含"Claude"或"Anthropic"。
开放标准，不只是 Anthropic 的玩具
这是我读完整份指南最意外的一点。
Anthropic 明确表示，Skill 是一个开放标准——就像 MCP 一样，他们希望同一个 Skill 文件夹，在 Claude 和其他 AI 平台上都能正常工作，不需要修改。目前他们已经在和生态系统伙伴合作推进这个标准。
这意味着如果你现在花时间把自己的工作流做成 Skill，它的价值不会绑定在 Claude 上。
同时，Skill 已经可以通过 API 调用——/v1/skills 端点，可以在 Message API 请求里通过 container.skills 参数挂载 Skill，配合 Claude Agent SDK 构建自定义智能体。企业版还支持管理员统一部署工作区级别的 Skill，自动更新，集中管理。
从个人工具到团队标准，再到 API 级别的程序化调用，这条路是通的。
我打算怎么用
读完之后，我的第一反应是把我在 Claude Code 里用的几十个提示词重新整理一遍。
那些反复用的写作风格指令、图片生成的 provider 优先级、表格格式规范——原来可以做成 mufeng-writing 这个 Skill，一次写好，以后每次自动加载，不用再每个对话开头念一遍咒语。
事实上，这个 Skill 我已经在经常使用了，如今我的很多技术博客都是通过 mufeng-writing 这个 Skill 写的，只是之前对 Skill 的认识不够深刻。
今后我还打算把我常用的 Skill 好好优化下，然后上传到 github 做开源项目。
朋友圈和公众号的信息太碎了，刷完就忘。
知识星球是我把真正有用的东西沉淀下来的地方——学习路径、工具清单、实战复盘，全部分类整理，随时可以翻。
里面有我整理的 AI 实战笔记、可直接复用的 Prompt 模板、PDF/PPT总结、语音分享等学习资料。
如果你也在认真学 AI，长按识别下方二维码，欢迎加入。
官方说一个功能性 Skill 的构建时间大约是 15-30 分钟。我测试了一下，如果工作流已经清晰，确实差不多。难的不是写文件，是想清楚：这件事真正的触发条件是什么，用户会用什么词来描述它。
这才是提示词工程的核心——不是把话说得越多越好，而是让 AI 在正确的时候想起正确的事。
2026.03.10 18:30 沪 · 汇金路KFC
📌 声明：本文由 AI 辅助完成
