一份官方指南，展示如何在不写一行代码的情况下，教会 Claude 按你的方式工作。它里面究竟讲了什么，以及为什么 Skills 正在悄悄让"提示工程"这个词退场。
Anthropic 发布了一份 33 页的文档，标题是 《The Complete Guide to Building Skills for Claude》（《构建 Claude Skills 的完整指南》）。初读，它像是技术文档。再读，它其实是一份宣言：专业人士与 Claude 协作的方式，正在从"找一个更聪明的提示"转向"把可复用的工作流当作代码产物来做版本管理"。
Skills 不是一个新模型。它就是一个文件夹。更准确地说：一个文件夹，里面有一个必需的文件——SKILL.md——以及一小段 YAML 头部，告诉 Claude 何时激活这个技能。核心就是这些。而这种简洁，正是它的关键所在。
技能是什么——精简到最小
一个技能就是一个具有如下结构的目录：
your-skill-name/ ├── SKILL.md # Required: Markdown with YAML frontmatter ├── scripts/ # Optional: executable code ├── references/ # Optional: additional docs loaded as needed └── assets/ # Optional: templates, fonts, icons
SKILL.md 以一段 YAML 块开头，其中有两个必填字段：name 和 description。description 是整个技能里最重要的字段，因为它决定了 Claude 到底会不会加载这个技能。
--- name: contract-risk-review description: Reviews B2B contracts for typical liability, termination, and IP-assignment clauses. Use when the user says "contract review", "risk check", "AGB review", or uploads .pdf/.docx contracts. ---
真正精妙的部分叫做"渐进式披露"
真正的创新不在于格式——而在于 Claude 如何加载这些内容。Anthropic 把它称为渐进式披露（progressive disclosure）：分三个层级，只有当前需要的那一层才会被加载。
始终在系统提示里。每个技能只占几行。刚好足够让 Claude 判断这个技能是否相关——而无需加载其余内容。
只有当 Claude 判断该技能与当前任务匹配时才会加载。包含真正的指令、示例和错误场景。
参考资料、脚本、模板。只有当技能真正需要时才会被拉进来。一个技能可以携带数百页文档，而其中没有一个 token 会触及默认上下文。
实际后果是：你可以同时启用十个甚至二十个技能，而不会撑爆你的上下文。你只为 Claude 真正为手头任务拉进来的那部分内容付出 token。
Skills 不是 MCP——这是整份指南里最重要的区分
Anthropic 用了一个很到位的厨房比喻：
MCP
- • 提供工具
- • 把 Claude 连接到各种服务（Linear、Notion、Stripe……）
- • 提供实时数据和 API 访问
- • 回答：Claude 能做什么？
Skill
- • 提供菜谱
- • 一步一步描述工作流
- • 嵌入领域知识和最佳实践
- • 回答：Claude 该怎么做？
有 MCP 却没有技能，意味着用户手握 30 个工具，却在每隔一句提示时就搞不清该按什么顺序把它们组合起来。而有 MCP 又有技能，意味着用户只描述想要的结果，技能就会按正确的顺序编排出正确的 MCP 调用——而且每次都一样。
三大类别，几乎涵盖一切
指南把富有成效的技能用例归为三类，这三类在实践中都相当站得住脚：
-
文档与素材创建。 那些按固定标准产出一致结果的技能——符合企业设计规范的演示文稿、遵循风格指南的代码、对照模板撰写的技术报告。指南里的例子：
frontend-design技能，它能明显提升 Claude 的设计输出。 - 工作流自动化。 带有明确验证关卡的多步流程。冲刺规划、客户上手、基于 schema 的代码审查。当顺序很重要、各步骤彼此依赖时，这套工作流就该放进一个技能里。
-
MCP 增强。 那些叠加在已有 MCP 集成之上、充当知识层的技能。Sentry 就公开做过这件事：一个
sentry-code-review技能，按正确顺序调用 Sentry MCP 服务器的工具，在拉取请求里根据生产数据自动修复 bug。
description 字段是整个技能里最重要的一句话
Anthropic 用了好几页篇幅来讲 description 字段——这是有充分理由的。就是这一行，决定了 Claude 会不会为某个特定的用户请求考虑这个技能。规则很简单：技能做什么 + 何时触发它。
糟糕
description: Helps with projects.
太笼统。没有触发条件。Claude 没有任何信号知道何时该加载。
优秀
description: End-to-end onboarding flow for PayFlow customers including account creation and subscription setup. Use when the user says "onboard new customer", "create PayFlow account", or "set up subscription".
具体。聚焦结果。有真实的触发短语。
技能正文里真正重要的是什么
这份指南采取了一种令人耳目一新的务实态度：要具体，要可检验，能自动化的就交给代码去检查。
与其写"仔细校验输入"——这句话每个模型的理解都不一样——不如写："运行 python scripts/validate.py --input {filename}。出错时检查：缺失的必填字段、日期格式 YYYY-MM-DD"。脚本是确定的，语言不是。凡是正确性至关重要的地方，脚本更胜一筹。
Anthropic 建议正文采用一个简单的结构：把工作流步骤写成编号列表，为最常见的场景配上示例，再加一个针对那两三个真正反复出现的错误的排错小节。很少需要更多。
没有测试框架，也能测试
这份指南提出了三层测试——全都无需复杂的基础设施就能做到：
- 触发测试。 二十个真实的查询，检查技能什么时候会加载、什么时候不会。加入一些边缘情况（"旧金山的天气怎么样"），确保它不会到处乱触发。
- 功能测试。 跑一遍工作流，检查输出。工单创建出来了吗？属性对不对？有没有哪个 API 调用失败？
- 前后对比。 同一个任务，有技能和没技能各做一遍。要多少轮澄清？花多少 token？重试几次？价值就体现在这里。
Anthropic 为这套循环专门提供了一个 skill-creator 技能——一个元技能，带着你走完定义、YAML、示例和验证的全过程。如果你有一个 MCP 服务器，又清楚自己那两三个最主要的工作流，你可以在 15 到 30 分钟内做出一个能用的技能。
技能在实践中改变了什么
没有技能时，一个熟悉的模式会反复上演：每次冲刺，每个团队成员都要重新向 Claude 解释一遍冲刺规划流程。来回十五条消息。同事之间产出不一致。还有一堆"我到底该怎么正确使用你们的连接器"这类支持工单。
有了技能，知识被存放的位置就发生了转移。它不再只装在个别高级用户的脑子里，而是存在仓库里——有版本、可评审、可在全团队范围内启用。Anthropic 在 2025 年 12 月推出了组织级的技能部署。管理员可以把技能下发到整个工作区。更新会集中落地。新成员上手不再意味着"去读一读我们的提示词"，而是"启用这个技能包"。
技能到哪里为止——CLAUDE.md 从哪里接手
技能并不是万能工具。通用的行为准则——"拿不准就先问"、"别覆盖你还没读懂的代码"、"要贴合仓库的风格"——仍然属于 CLAUDE.md，因为它们适用于每一项任务，而不只是某些特定工作流。
我目前在项目里采用的清晰分工是：CLAUDE.md 负责纪律和风格。Skills 负责具体、反复出现的工作流。MCP 负责工具访问。三层互不重叠，却共同构成了指南所说的"编码后的工作流（encoded workflows）"。
更大的图景
这份指南不只是文档。它标记着一个已经显现了几个月的转变。"聪明提示"的时代正在收尾。"编码后的工作流"的时代正在开启。任何每天都用 Claude、却还没做过哪怕一个技能的人，相比之下都还在手工作业——每次对话都从零开始，每个结果都取决于当天的提示心情。
技能用一个简单到近乎令人尴尬的想法解决了这个问题：一个文件夹，里面放一个 Markdown 文件。但正是这种平凡，恰恰是这个概念会站稳脚跟的原因。它不需要新的技术栈，不需要框架，不需要专门的 SDK。一个文本编辑器加上一个小时，就足以做出第一个有产出的技能。从第二个技能开始，这种改变就变得显而易见了。
来源：
在琢磨技能能在哪里给你的团队带来最大的杠杆——上手流程、代码审查，还是某个多步骤的合规工作流？我们聊聊。我帮忙搭建那些能在真实项目里跑起来、而不只是在演示里好看的技能库。