一、引言：Skill 不是更长的 Prompt，而是可复用的能力包
原文链接：How to create Skills for Claude: steps and examples
来源：Claude Blog / Anthropic
发布时间：2025 年 11 月 19 日
当团队开始高频使用 Claude 处理文档、代码、数据分析、审查流程或企业知识时，一个很快会出现的问题是：同一套背景、规则和输出要求，需要反复解释给模型听。
例如，法务团队每次都要说明 NDA 审查标准；市场团队每次都要说明品牌色、字体和语气；工程团队每次都要说明代码生成规范；运营团队每次都要说明报告模板和字段口径。短期看，这些都可以靠 prompt 解决；长期看，它们会变成重复劳动、上下文噪音和质量不稳定的来源。
Claude Skills 的价值就在这里：它把某类重复任务所需的说明、流程、示例、资源和边界条件封装成一个可复用能力模块。用户提出相关需求时，Claude 可以根据 Skill 的描述判断是否加载它，并在执行时遵循其中的操作手册。
用一句话概括：Skill 不是“更长的提示词”，而是面向 Agent 的专业能力包。
图注：创建 Skill 的核心链路可以拆成五步：明确任务、命名、编写触发描述、编写执行说明、上传并测试。真正影响长期效果的不是某一句提示词，而是任务边界、触发质量和持续迭代。
图注：这张图用三层结构说明 Skill 的定位：Prompt 更像一次性沟通，项目文档负责沉淀背景，而 Skill 把触发条件、执行流程、示例和资源组合成 Agent 可复用的能力包。
二、Claude Skills 解决的核心问题
官方文章对 Skills 的定义很直接：Skills 是一种自定义指令，用来扩展 Claude 在特定任务或领域中的能力。它们可以编码组织知识、标准化输出，并处理复杂的多步骤工作流。
这一定义里有三个关键词。
2.1 编码组织知识
很多高价值知识并不在通用模型参数里，而存在于团队内部：
- 某家公司品牌色的精确色值；
- 某类合同条款的风险判断标准；
- 某个业务指标的计算口径；
- 某种报告的固定结构；
- 某个代码仓库的工程约定。
这些知识如果每次靠用户手工输入，不仅低效，还容易遗漏。Skill 适合把它们从“隐性经验”变成“显性说明”。
2.2 标准化输出
模型默认会根据上下文自由组织回答。但很多业务场景恰恰需要稳定格式：表格列名不能乱、报告章节不能缺、审查结论要有风险级别、生成代码要符合项目规范。
Skill 可以把输出结构、判断标准和验证方式写清楚，让 Claude 不只是“回答得像”，而是按约定交付。
2.3 承载多步骤工作流
有些任务不是一步问答，而是一套流程。例如处理 DOCX：先识别需求，再读取文档结构，必要时解包 OOXML，修改内容，保留格式，最后验证生成文件是否可打开。把这种流程全部塞进用户 prompt 会很脆弱；写成 Skill，才更像一个稳定的操作手册。
三、创建 Skill 的五个关键步骤
官方文章把创建 Skill 拆成一组非常务实的步骤。它们看似简单，但每一步都决定了 Skill 后续是否好用。
3.1 第一步：明确核心需求
在写 SKILL.md 之前，先回答四个问题：
- 这个 Skill 要完成什么具体任务？
- 哪些用户请求应该触发它？
- 成功结果长什么样？
- 有哪些输入、场景或任务不属于它？
一个弱目标是：
Help with my finance stuff.
它太泛，既不知道输入是什么，也不知道输出是什么，更不知道 Claude 应该采取什么流程。
一个强目标是：
Extract financial data from PDFs and format as CSV.
这个目标明确了输入、动作和输出：输入是 PDF，动作是提取财务数据，输出是 CSV。这类目标更适合被 Skill 化。
3.2 第二步：编写清晰的名称
Skill 通常包含三个核心部分：name、description 和 instructions。其中，官方文章特别强调：真正影响 Skill 是否被触发的只有 name 和 description。
命名建议很简单：
- 使用小写；
- 使用短横线；
- 简短、具体、可读；
- 直接表达用途。
例如：
pdf-editor
brand-guidelines
frontend-design
nda-review
不要把名称写得像一句口号。名称的作用是让人和模型都能快速知道这个 Skill 管什么。
3.3 第三步：写好 description
description 是整个 Skill 中最关键的字段。官方文章的表述是：description 决定 Skill 何时激活，因此是最关键的组成部分。
它不是单纯的关键词列表，而是一段帮助 Claude 判断“什么时候应该用这个 Skill”的语义说明。
一个过弱的描述是：
This skill helps with PDFs and documents.
问题在于太宽。它没有说明是读取、生成、合并、拆分、表单填写还是批处理，也没有说明不适合什么场景。
一个更好的描述应该包含：
- 具体能力：提取文本、创建 PDF、合并拆分、处理表单；
- 触发场景：需要程序化处理、生成或分析 PDF；
- 使用范围：文档工作流和批量操作；
- 排除边界：不用于简单查看或基础转换。
图注：Skill 的触发不是关键词匹配，而是语义判断。description 过宽会误触发，过窄会漏触发。一个实用写法是：动作 + 输入对象 + 输出结果 + 使用场景 + 不适用边界。
3.4 第四步：编写可执行的 instructions
如果说 description 决定“是否加载”，那么 instructions 决定“加载后怎么做”。
好的 instructions 应该像 SOP，而不是愿望清单。推荐包含：
# Overview
## Prerequisites
## Execution Steps
## Decision Rules
## Examples
## Error Handling
## Limitations
具体来说，它应该回答：
- 第一步做什么，第二步做什么；
- 遇到不同输入时如何分支；
- 输出格式是什么；
- 什么情况要向用户澄清；
- 什么情况应该拒绝或说明超出范围；
- 任务完成后如何自检。
如果 Skill 很复杂，不要把所有内容都塞进 SKILL.md。官方文章建议采用类似“菜单”的方式：主文件只说明有哪些能力和路径，详细流程拆到独立文件中，让 Claude 按需读取。
图注：一个复杂 Skill 往往不只有 SKILL.md，还包括示例、脚本、参考资料和模板资产。主文件负责触发和导航，细节文件负责承载复杂流程，避免上下文窗口被不必要内容占满。
3.5 第五步：上传、测试与迭代
官方文章列出了不同使用环境中的 Skill 使用方式：
- 在 Claude.ai / Claude apps 中，可以通过设置上传自定义 Skill；
- 在 Claude Code 中，可以在项目或插件中放置
skills/目录； - 在 Claude Developer Platform 中，可以通过 Skills API 管理。
但上传不是结束。一个 Skill 是否可靠，要靠测试验证，而不是靠作者感觉。
图注：运行时可以把 Skill 想象成按需装配线：Claude 先用 name 和 description 做语义匹配，再加载 SKILL.md，必要时读取示例、模板或脚本，最后按照流程执行并验证输出。
四、测试方法：至少覆盖三类请求
官方文章建议为 Skill 建立测试矩阵。最低限度也应该覆盖三类请求：正常请求、边界请求和越界请求。
图注：测试 Skill 时，不仅要验证“该触发时能做好”，还要验证“输入不完整时能处理”和“不该触发时不会误用”。后者往往决定 Skill 在真实团队环境中的可靠性。
4.1 正常请求：验证主流程
正常请求用于确认 Skill 的核心路径能跑通。
例如金融分析 Skill 可以测试：
Analyze Microsoft's latest earnings and summarize the key financial trends.
或者：
Build a datapack from this 10-K filing and export the extracted tables as CSV.
这类测试的重点是：Claude 是否正确加载 Skill、是否遵循流程、输出是否符合格式、关键字段是否完整。
4.2 边界请求：验证异常输入
边界请求用于测试不完整、模糊或异常场景。
例如：
- 用户上传的文件缺页；
- PDF 中表格无法直接提取；
- 用户只说“帮我处理这个报告”，但没有说明目标；
- 文档格式与 Skill 预期不完全一致。
一个好的 Skill 不一定要强行完成所有边界任务，但应该能给出明确反馈：哪些信息缺失、哪些部分可以处理、哪些部分需要用户补充。
4.3 越界请求：验证不误触发
越界请求用于测试 Skill 的边界是否清楚。
例如一个 NDA 审查 Skill，应该处理保密协议，但不应该自动套用到雇佣合同、租赁合同或采购合同上。它们都属于法律文件，但风险点、条款结构和审查标准不同。
很多 Skill 的失败不是因为它能力不够，而是因为它太积极：在相似但不适用的场景中被错误触发。
五、局限性分析：Skill 不是万能封装
Claude Skills 很有用，但它不是万能抽象。理解限制，反而能帮助我们更好地设计它。
5.1 触发质量高度依赖 description
description 写得不好，Skill 就可能出现两类问题：
| 问题 | 表现 | 常见原因 |
|---|---|---|
| 漏触发 | 该用 Skill 时没有用 | 描述过窄、缺少典型场景、输入输出不明确 |
| 误触发 | 不该用 Skill 时用了 | 描述过宽、边界缺失、与其他 Skill 重叠 |
因此，description 不是“简介”，而是触发策略。它需要持续根据真实使用情况调整。
5.2 主文件过大会污染上下文
Skill 的目标是提高效率，不是把所有知识一次性塞进模型上下文。过大的 SKILL.md 会带来几个问题：
- 模型要阅读更多无关内容；
- 关键信息被淹没；
- 上下文成本上升；
- 多个 Skill 同时加载时更容易互相干扰。
更好的做法是：主文件写清楚能力菜单和选择规则，复杂细节放到独立文件中。只有任务需要时，才加载对应材料。
5.3 不适合一次性任务
官方文章提醒，不要投机式创建 Skill。一个实用判断标准是：
- 这个任务是否已经做过至少 5 次？
- 未来是否还会再做至少 10 次？
如果答案是否定的，直接写 prompt 可能更简单。Skill 的优势来自复用；没有复用，就只剩维护成本。
5.4 Claude.ai 中的自定义 Skill 仍偏个人级
官方文章提到，在 Claude.ai 中上传的自定义 Skill 当前主要是个人级能力，不是完整的组织级治理系统。这意味着团队使用时还需要自己补上：
- Skill 版本管理；
- 所有者和维护责任；
- 共享文档库；
- 更新记录；
- 废弃机制；
- 安全和权限审查。
对于企业团队来说，Skill 不只是“上传一个文件”，而是会逐渐变成知识资产管理问题。
5.5 粒度过宽或过窄都会影响效果
Skill 的粒度需要适中。
| 粒度 | 示例 | 问题 |
|---|---|---|
| 太宽 | content-marketing-helper |
什么都管，触发边界模糊 |
| 太窄 | add-meta-descriptions |
复用面太小，维护收益有限 |
| 合适 | seo-optimization-for-blog-posts |
目标明确，同时有稳定复用价值 |
一个好的 Skill 应该围绕单一目标展开，但这个目标要足够常见，值得被沉淀。
六、具体示例：从文档处理到品牌规范
官方文章给了几个典型 Skill 示例。它们的共同点是：都不是单纯让 Claude “更聪明”，而是把某类任务中的专业知识、流程和输出标准显式写出来。
图注：不同 Skill 封装的对象并不相同：PDF 和 DOCX 更偏文件格式与工具流程，品牌规范和前端设计更偏组织知识与质量偏好。只要任务足够重复、规则足够稳定，就可以被 Skill 化。
6.1 PDF 处理 Skill：把文档工作流变成工具箱
PDF 处理 Skill 的重点不是“能看 PDF”，而是面向程序化文档工作流：
- 提取文本和表格；
- 创建新的 PDF；
- 合并或拆分文档；
- 填写 PDF 表单；
- 批量分析文档内容。
一个可用的 description 可以写成：
Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging or splitting documents, and handling PDF forms. Use when Claude needs to programmatically process, generate, or analyze PDF documents in document workflows or batch operations. Not for simple PDF viewing or basic format conversion.
这段描述之所以有效，是因为它同时说明了能力、场景和排除边界。
6.2 DOCX Skill：复杂任务需要决策树
DOCX 处理看似只是“改 Word 文档”，实际很复杂：读取纯文本、保留格式、插入批注、处理修订痕迹、修改 OOXML、重新打包验证，每一步都可能出错。
因此，一个好的 DOCX Skill 不应该只写：
Help edit Word documents.
而应该包含决策树：
- 如果只是阅读或摘要，优先提取文本；
- 如果要创建新文档，使用模板和结构化生成流程；
- 如果要编辑已有文档，先备份再定位内容；
- 如果涉及 tracked changes，只标注真正变化的片段；
- 最后验证文档是否能被正常打开。
这类 Skill 的本质是把“文件格式经验”写成 Claude 可执行的流程。
6.3 Brand Guidelines Skill：封装模型不知道的精确信息
品牌规范 Skill 很适合说明 Skills 的另一个价值：它可以补充模型本身不知道、但组织内部非常重要的精确信息。
例如：
- 品牌主色和辅助色的 hex code；
- 标题字体、正文字体和 fallback 字体；
- 不同场景下的字号和间距；
- 哪些颜色组合不能使用；
- 图形、按钮、背景和图标的视觉风格。
这类信息不是推理能力问题，而是事实和规范问题。Skill 可以让 Claude 在生成海报、网页、幻灯片或品牌文案时遵循统一标准。
6.4 Frontend Design Skill：把审美判断写进流程
前端设计 Skill 的价值不只是“生成 React 组件”，而是把设计判断显式写出来，例如：
- 必须先选择明确的视觉方向；
- 避免通用、模板化的 AI 生成界面；
- 关注排版、色彩、动效、空间布局和背景细节；
- 产出应接近生产级界面，而不是 demo。
这说明 Skill 不只适合结构化任务，也适合封装“风格偏好”和“质量门槛”。只要这些偏好足够稳定，就可以从口头要求变成可复用能力。
七、一个可落地的 SKILL.md 模板
下面是一个简化模板，适合创建初版 Skill 时参考：
---
name: seo-blog-optimizer
description: Optimize technical blog posts for SEO, readability, metadata completeness, and internal linking. Use when asked to improve a draft blog post before publication. Not for writing unrelated marketing copy or generating social media posts.
---
# SEO Blog Optimizer
## Overview
Use this skill to review and improve technical blog drafts before publication.
## When to Use
- The user provides a draft blog post.
- The task is to improve title, subtitle, description, headings, readability, or internal links.
- The expected output is an edited post or a structured review checklist.
## Workflow
1. Identify the target keyword and reader intent.
2. Check title, subtitle, description, and URL slug.
3. Review heading hierarchy and section transitions.
4. Improve readability without changing technical meaning.
5. Suggest internal links and image opportunities.
6. Return a concise change summary.
## Output Requirements
- Preserve the author's technical claims.
- Do not invent facts or references.
- Keep the tone professional and easy to understand.
- Highlight any uncertain claims that require source verification.
## Limitations
Do not use this skill for non-blog marketing copy, legal review, or fact checking that requires external authoritative sources.
这个模板有几个值得注意的点：
description写清楚了适用场景和排除边界；Workflow是可执行步骤，而不是抽象原则；Output Requirements定义了质量标准；Limitations防止 Skill 被错误外推。
八、最佳实践清单
结合官方文章和实际工程经验，可以把创建 Skill 的原则总结为七条。
8.1 从真实重复任务开始
不要为了“有 Skill”而创建 Skill。先观察哪些任务反复出现，哪些规则每次都要解释，哪些输出经常不稳定。
8.2 让 description 负责触发，而不是宣传
description 不需要写得漂亮，需要写得准确。它应该帮助 Claude 判断：这个请求是否真的属于我？
8.3 instructions 写成 SOP
把隐性经验拆成步骤、分支、示例和检查点。不要只说“高质量”“专业”“准确”，要说明如何判断高质量、专业和准确。
8.4 用示例压住输出风格
示例比抽象要求更容易让模型对齐。尤其是格式、语气、风险判断和文件处理类任务，应该给出好例子和反例。
8.5 大 Skill 使用菜单式结构
主文件只保留导航和关键规则，复杂材料拆成独立文件。这样既节省上下文，也方便维护。
8.6 建立测试矩阵
至少保留正常、边界、越界三类测试。每次修改 description 或核心流程后，都应该重新验证。
8.7 团队使用要有治理
一旦 Skill 被多人使用，就需要所有者、版本号、变更记录、审查流程和退役机制。否则 Skill 会像失控的共享文档一样逐渐过时。
图注：团队里的 Skill 应该被当作知识资产管理：先从重复任务中发现需求，再创建、测试和发布；上线后持续观察触发质量与输出质量，必要时更新或退役。
九、总结：把经验产品化，而不是把 Prompt 写长
Claude Skills 的核心价值，不在于让提示词变长，而在于让重复出现的专业流程变成可维护、可测试、可复用的能力资产。
创建一个好 Skill，可以用三句话概括：
- 触发准确性靠
description：写清楚适用场景、输入输出和排除边界。 - 执行稳定性靠
instructions：把流程、示例、错误处理和验证标准写成可执行 SOP。 - 长期可用性靠测试和治理：通过正常、边界、越界测试持续迭代，避免 Skill 过宽、过窄或过时。
如果说 prompt 是一次性沟通，Skill 就是把沟通沉淀成能力。对个人用户，它能减少重复解释；对团队，它更像一套轻量级的 Agent 知识工程机制。
写完 Skill 之后，下一步问题是：如何证明它真的有效、如何持续改进它。这个方向可以继续参考：Agent Skills 工程化深度解析：用 skill-creator 测试、度量并持续改进技能。
参考链接
- How to create Skills for Claude: steps and examples
- Improving skill-creator: Test, measure, and refine Agent Skills
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
