【导读】在 Agent 开发中，过去常见做法是通过 Tools 或 MCP 让模型具备“调用外部能力”的接口，但这往往把“怎么用、何时用、用到什么质量标准”留给对话临场决定。Claude Skills 提供了更轻量的能力封装方式：将领域知识、工作流步骤与约束条件固化为可复用的 Skill 目录结构，并在 Claude.ai、Claude Code 与 Claude API 间保持一致体验，正在改变团队构建与分发 Agent 能力的方式。
一、从 Tools/MCP 到 Skills：Skill 到底是什么、解决什么问题
在 Claude 的能力扩展体系里，Skill 的定位更接近“可分发的任务指南与知识包”。其核心定义可以概括为：
- Skill = 一个文件夹，用于“教 Claude 如何处理特定任务的指令集”，并主要承载可复用的领域知识与流程方法论。
- Skill 的最小形态是一个固定入口文件：SKILL.md，并可以按需配套可执行代码、参考资料与模板资产。
典型目录结构如下：
your-skill-name/ ├── SKILL.md # 必需 - 主文件 ├── scripts/ # 可选 - 可执行代码 ├── references/ # 可选 - 参考文档 └── assets/ # 可选 - 模板、资源
与传统“每次对话手把手教模型怎么做”的方式相比，Skills 的价值点更聚焦在三件事：
- 一次教学，长期复用：把关键指令、边界条件、质量检查清单沉淀下来，避免每次都重复解释上下文与标准。
- 跨环境一致：同一个 Skill 能在 Claude.ai、Claude Code、Claude API 中保持一致行为，降低“换平台重写提示词/流程”的成本。
- 可组合协作：多个 Skills 可同时加载，形成“能力拼装”，从而支持更复杂的端到端任务。
从工程角度看，Skills 更像是对 Agent 行为的“产品化封装”：不仅告诉模型“能做什么”，还明确“何时触发、按什么步骤做、输出要达到什么标准”。
二、三大设计原则：渐进式披露、可组合性、可移植性
1）渐进式披露（Progressive Disclosure）：用三层信息结构控制 token 与专业度
Skills 强调分层加载信息，把“总是需要的最小信息”与“仅在相关任务时才需要的细节”拆开，以减少 token 消耗并提升触发准确性。常见分层包括：
- 第一层：YAML frontmatter（总是加载）：最关键的元信息，通常包含 name 与 description，用于定义 Skill 的身份与触发条件。
- 第二层：SKILL.md 正文（相关时加载）：当对话匹配到触发条件，才进入更具体的 Instructions、约束、输出格式与示例。
- 第三层：链接文件（按需加载）：如 references/ 中的 API guide、规范文档、团队模板等，在需要细节时再引用。
示例结构（保留 YAML frontmatter 形式）：
--- name: project-planner description: Sprint planning automation. Use when user says "plan sprint" or "create tasks" ---
这种分层带来的直接收益是：常驻信息更短、触发更稳，而且不会因为把所有细节一股脑塞进提示词导致成本上升或响应变慢。
2）可组合性（Composability）：Skill 不应假设自己是“唯一能力”
可组合性要求开发者在设计 Skill 时避免强依赖单一上下文，允许用户同时启用多个 Skills。例如：
- frontend-design + docx-creator
- sentry-code-review + github-workflow
- skill-creator + your-custom-skill
这意味着 Skill 的指令要尽量模块化：明确输入输出、对外部能力的依赖边界、以及与其他 Skill 的冲突处理方式（例如当多个 Skill 都想主导输出结构时，谁优先、如何合并）。
3）可移植性（Portability）：一次构建，多端一致
Skills 的目标是让同一份能力包在不同使用场景里“表现一致”：
- Claude.ai（网页版）
- Claude Code（桌面应用）
- Claude API（开发者集成）
可移植性本质上要求：Skill 的指令尽可能环境无关，不把关键能力绑定在某个特定客户端的交互习惯上；同时把可变部分（工具调用、外部系统依赖）清晰地显式化，避免“在 A 环境能跑，在 B 环境就失效”。
三、三类高频场景：文档资产、工作流自动化、MCP 增强
场景 1：文档与资产创建——用嵌入式规范换一致性输出
这类 Skill 的目标是产出“风格统一、质量稳定”的文档/页面/资产，而不是依赖外部工具。示例（节选 YAML）：
--- name: frontend-design description: Create distinctive, production-grade frontend interfaces. Use when building web components, pages, or apps. ---
其关键做法通常包括：
- 嵌入式风格指南（例如组件规范、视觉原则、写作语气）
- 模板化结构（固定章节、固定字段、固定输出顺序）
- 质量检查清单（如可访问性、命名约定、边界处理）
- 明确声明“无需外部工具”的适用范围与限制
这类 Skill 适合内容生产、产品文档、交付物规范化等团队协作场景。
场景 2：工作流自动化——把多步骤流程固化为“分步+验证门”
当任务不是一次性回答，而是包含多个步骤、多个决策点时，Skill 可以把流程固化下来，并通过验证门减少返工。示例（节选 YAML）：
--- name: skill-creator description: Interactive guide for creating new skills. Use when user wants to build a skill. ---
常见“工作流型 Skill”的关键技术点：
- 分步执行（Step-by-step）与关键节点确认（例如收集需求→确认约束→生成草案→校验→迭代）
- 通用结构模板（减少从零开始的设计成本）
- 内置审查与改进建议（如检查触发条件是否清晰、输出是否可测试）
- 迭代优化循环（把“测试—修正—再测试”内化为默认流程）
这类 Skill 更像“组织经验的流程化编码”，适用于研发流程、内容审核、合规检查、交付验收等。
场景 3：MCP 增强——为 MCP 服务器提供“怎么用”的策略层
当团队已通过 MCP 接入外部系统（如错误追踪、仓库、工单、业务系统），Skill 可以补齐“工作流指导”与“领域知识”。示例（节选 YAML）：
--- name: sentry-code-review description: Automatically analyze and fix bugs in GitHub PRs using Sentry error data. Use when reviewing code with errors. ---
这类 Skill 通常强调：
- 协调多个 MCP 调用序列（先取数据→再定位→再生成修复建议→再复核）
- 把用户原本要手动提供的上下文（错误类别、版本、影响范围）写入工作流默认步骤
- 针对常见 MCP 问题提供错误处理策略（失败重试、降级方案、缺少权限时的替代路径）
- 将“最佳实践”固化，让输出可复现、可审计
四、关键技术要求：命名规则、Frontmatter 约束与成功标准
1）文件与目录命名：严格规范减少兼容性问题
关键规则集中在两点：入口文件固定、目录命名固定。
# ✅ 正确 SKILL.md # 必须大写，必须这个名字 your-skill-name/ # kebab-case frontend-design/ # kebab-case # ❌ 错误 skill.md # 小写 - 错误 SKILL.MD # 扩展名大写 - 错误 Your_Skill_Name/ # 下划线 - 错误 YourSkillName/ # 驼峰 - 错误 Your Skill Name/ # 空格 - 错误
同时对 README.md 的位置也有明确约束：**Skill 文件夹内不要放 README.md**，但 GitHub 仓库根目录可以有给人类阅读的 README。
# ❌ 不要在 skill 文件夹内放 README.md your-skill/ ├── SKILL.md # ✅ 正确 └── README.md # ❌ 错误 # ✅ 但 GitHub 仓库根目录可以有 your-skill-repo/ ├── README.md # ✅ 给人类看的 └── your-skill/ └── SKILL.md # ✅ 给 Claude 看的
2）YAML frontmatter：最重要的是“触发条件可执行”
最小必需格式如下：
--- name: your-skill-name description: What it does. Use when user asks to [specific phrases]. ---
其中两条硬要求：
- name 必须是 kebab-case，不能有空格、下划线或驼峰：
# ✅ 正确 name: notion-project-setup name: frontend-design name: sentry-code-review # ❌ 错误 name: Notion Project Setup name: notion_project_setup name: NotionProjectSetup
- description 必须同时包含 “做什么(What)” + “何时用(When)”，并且触发条件要尽量明确（< 1024 字符、不用 XML 标签）：
# ✅ 正确 - 包含"做什么"和"何时用" description: Creates sprint plans from Linear data. Use when user says "plan sprint" or "create tasks for this week". # ❌ 错误 - 只说了做什么 description: Creates sprint plans from Linear data. # ❌ 错误 - 只说了何时用 description: Use when planning sprints.
工程上可以把它理解为：description 不只是文案，而是“触发规则”的一部分；触发条件写得越可测试，Skill 在真实对话中的命中率越可控。
3）成功标准：既看触发率，也看工作流成本与稳定性
衡量 Skill 是否“可用”，通常需要定量与定性两类指标组合。
定量指标示例：
- 90% 相关查询能触发 Skill：可用 10–20 个测试查询统计自动触发率。
- 在 X 次工具调用内完成工作流：对比有/无 Skill 的工具调用次数。
- 每个工作流 0 次 API 调用失败：通过 MCP 服务器日志观察失败率与重试率。
定性指标示例：
- 用户无需提示下一步（减少“你接下来该做什么”的引导成本）
- 工作流无需用户纠正即可完成（多次运行输出一致）
- 跨会话结果一致（新用户首次上手也能成功）
这些指标的共同指向是：Skill 不仅要“能触发”，还要“触发后能稳定把事做完”。
五、MCP + Skills：一个提供能力，一个提供方法
在“模型如何接入外部系统”这件事上，MCP 更像基础设施，而 Skills 更像操作手册与最佳实践集合：
- MCP：连接 Claude 到你的服务，提供工具、数据访问与执行能力。
- Skills：定义工作流步骤、最佳实践、错误处理与上下文补全，让工具调用变成可复用的流程。
如果只有 MCP 没有 Skills，常见问题包括：用户连上集成后不知道下一步怎么走；每次对话从头解释导致结果不一致；支持工单增加（“怎么用你的集成做 X？”）。而 Skills 的意义在于把“可用性与一致性”前置到能力包里，让体验更接近产品而不是临时脚本。
结语：技术背后的管理思考
Claude Skills 把“知识与流程”从对话现场搬进了可版本化、可分发的工程结构里，本质上是在降低组织对“个体经验”的依赖：会写提示词的人不再需要反复口头传授，团队可以用统一的 SKILL.md 把最佳实践固化成标准作业程序（SOP），并通过触发率、工具调用次数、失败率等指标进行持续迭代。对企业管理与 HR 来说，这会带来三个直接变化：第一，岗位能力模型将更强调“可复用工作流设计”与“可测试的知识封装”；第二，培训方式从讲授转向“沉淀可运行的技能资产”，更容易规模化复制；第三，跨团队协作的摩擦降低，输出质量更稳定，组织效能更可量化。正如红海云在探索新一代人力资源管理解决方案时所强调的，技术的终极价值在于赋能组织：把经验变标准、把流程变资产、把协作变系统，才能让数字化转型真正落到效率与人才能力的提升上。
