Skill 不是”写出来”的，是”构建出来”的。
“写”暗示了一个线性的、一次性的文本创作过程，但实际上它是一组工程交付物的构建。所谓”写 Skill”，本质上是一项工程——而非一次写作。它需要经历需求分析、架构设计、内容实现、测试验证的完整工程循环，而非某个岗位独自完成的一次性交付。
Skill 也不是”人类技能”的翻版，而是给 AI 输入的 Know-How。人类有岗位边界，AI 没有。一个优秀的 Skill 融合了产品、开发、测试、设计、数据分析等多个专业角色的智慧，而非只反映单一视角。
因此，构建 Skill 的正确方式是：产品定义需求、开发组织架构、测试验证效果——把不同岗位和专业的人类智慧，通过工程化流程给 AI 输入进去。这才是真正的”写 Skill”。
一、Skill 是什么？——官方定义与核心理念
1.1 Anthropic 官方定义
根据 Anthropic 官方文档，Skill 是**“可复用的、基于文件系统的资源，为 Claude 提供特定领域的专业知识：工作流、上下文和最佳实践”**。它们将通用 AI 转变为特定领域的专家，消除了每次对话都重复提供相同指导的需要。
官方类比很形象：Skill 就像给新员工准备的一份入职指南——包含指令、可执行代码和参考资料，按需加载，而非一次性填鸭。
1.2 技术结构
Skill 的核心是一个目录，包含以下关键文件：
| 文件 | 说明 | 是否必须 |
|---|---|---|
| SKILL.md | 主指令文件，包含 YAML 元数据 + Markdown 内容 | 必须 |
| reference.md | 详细参考资料（数据字典、API 文档等） | 可选 |
| examples.md | 示例集，帮助 AI 理解预期输出 | 可选 |
| scripts/ | 工具脚本，提升执行可靠性 | 可选 |
1.3 渐进式加载机制
Skill 采用三级加载架构，避免上下文窗口过载：
- 第一级：元数据（name + description） —— 始终加载，用于触发判断
- 第二级：SKILL.md 正文 —— 触发后加载，提供核心指令
- 第三级：支撑文件和脚本 —— 按需加载，提供深度参考
二、核心观点：为什么 Skill 是工程而非写作
2.1 解构”写 Skill”这个说法
“写 Skill”这个表述容易产生误导。拆解来看：
- “写”暗示了一个线性的、一次性的文本创作过程，但实际上它是一组工程交付物的构建。
- “Skill”容易被映射为”人类技能”，但它实际上是给 AI 输入的 Know-How——是多角色智慧的融合体。
Anthropic 官方的最佳实践也印证了这一点：官方推荐”评估驱动开发”模式——先定义评估用例，再编写最小化指令来通过评估，根据真实使用反馈迭代优化。这完全是软件工程的思路，而非写作的思路。
2.2 Skill 融合多角色智慧
人类因认知和精力的局限，必须划分岗位和专业。但 AI 是”幽灵智能”——它没有岗位边界。一个优秀的 Skill 应该融合多个专业角色的智慧：
| 角色 | 在 Skill 中的贡献 |
|---|---|
| 产品经理 | 定义需求场景、用户意图、验收标准 |
| 开发工程师 | 设计技术架构、组织文件结构、编写工具脚本 |
| 测试工程师 | 设计评估用例、验证输出质量、回归测试 |
| 设计师 | 定义输出格式和排版规范 |
| 领域专家 | 提供业务规则、行业术语、最佳实践 |
这就是为什么 Skill 不应该由某个单一岗位独自完成——它天然是一个跨职能协作的产物。
三、构建 Skill 的工程化流程
3.1 官方推荐流程：评估驱动开发
Anthropic 推荐的 Skill 开发流程与测试驱动开发（TDD）高度匹配：
- 识别差距 —— 先让 AI 裸跑任务，观察失败点
- 创建评估用例 —— 将失败场景转化为可量化的测试用例
- 度量基线 —— 没有 Skill 时的表现作为参照
- 编写最小指令 —— 只写能让评估通过的内容，不多不少
- 迭代优化 —— 基于真实使用反馈持续调整
3.2 工程管理方法
既然构建 Skill 是一项工程，就可以借鉴成熟的软件工程管理方法：
| 方法 | 适用场景 | 典型周期 |
|---|---|---|
| 瀑布式 | 需求明确、范围固定的 Skill（如文档格式转换） | 1–2 周 |
| 敏捷迭代 | 需求模糊、需要持续探索的 Skill（如复杂分析流程） | 每轮 3–5 天 |
| 评估驱动 | 所有 Skill（Anthropic 官方推荐） | 持续 |
3.3 质量检查清单
Anthropic 官方提供了明确的质量检查标准：
- description 足够具体，包含关键词，既说明做什么也说明何时用
- 在多个模型上测试通过（Haiku、Sonnet、Opus）
- SKILL.md 控制在 500 行以内，详细内容拆分到参考文件
- 术语一致，示例具体，工作流清晰
- 关键操作包含验证/确认步骤
四、案例佐证：Anthropic 官方 Knowledge Work Plugins
Anthropic 官方发布的 Knowledge Work Plugins 为上述观点提供了最直接的实证。这套插件包含 15 个职能插件、120+ 个 Skills，覆盖产品、工程、销售、法务、财务等 15+ 个职能领域，是目前已知最大规模的面向知识工作者的 AI Agent 能力库。
4.1 一个 Skill 映射多个人类角色
通过逐一分析每个 Skill 的实际指令内容，可以发现绝大多数 Skill 都映射到 2–4 个人类角色。以下是典型示例：
| Skill | 表面角色 | 实际融合的角色能力 |
|---|---|---|
| feature-spec | 产品经理 | 产品经理（需求定义）+ 用户研究员（用户故事）+ 项目经理（验收标准）+ 技术经理（可行性评估） |
| incident-response | SRE 工程师 | SRE（技术诊断）+ 技术经理（沟通协调）+ 技术写作（事后报告）+ 项目经理（行动跟踪） |
| contract-review | 法务 | 企业法务（合同分析）+ 合规专员（法规对照）+ 商务经理（商业影响评估）+ 风险管理（风险分级） |
| financial-statements | 会计师 | 会计师（账务处理）+ 财务分析师（差异分析）+ 审计师（合规审查）+ CFO（管理报告） |
4.2 关键结论
这组数据验证了我们的核心观点：Skill 是一种”综合能力单元”，它不按人类的岗位边界来组织，而是按任务/工作流来组织。每个 Plugin 平均映射到 4.5 个 O*NET 职业分类——一个 Skill 天然融合了多个角色的能力，因为 AI 没有岗位的能力限制。
这也意味着，如果只让单一岗位的人来”写”Skill，写出来的内容必然是残缺的——它只能反映该岗位的视角，而遗漏了其他角色的关键知识。
五、谁来做、怎么做？——协作模型
基于以上分析，构建 Skill 应采用跨职能协作模型：
| 阶段 | 主负责 | 协作方 | 交付物 |
|---|---|---|---|
| 需求分析 | 产品 | 领域专家、用户 | 场景定义、验收标准 |
| 架构设计 | 开发 | 产品 | 目录结构、加载策略 |
| 内容实现 | 开发 + 领域专家 | 设计 | SKILL.md、脚本、参考文件 |
| 评估测试 | 测试 | 产品、开发 | 评估用例、测试报告 |
| 迭代优化 | 全员 | — | 更新版本 |
关键结论： Skill 不是产品来写、也不是开发来写。它是一个需要多角色协作的工程项目。产品定义需求，开发组织架构，领域专家提供知识，测试验证效果——把不同岗位和专业的人类智慧，通过工程化流程给 AI 输入进去。
六、参考资料
- Extend Claude with Skills — Anthropic 官方文档
- Skill Authoring Best Practices
- Agent Skills Overview
- Equipping Agents for the Real World with Agent Skills — Anthropic Engineering Blog
- anthropics/skills — 官方 Skill 示例仓库