用 Claude Skills 固化重复工作流程

反复让 Claude 写同一种报告、按同一套口径回复客户，麻烦往往不在模型能力，而在每次都要重新交代流程。原文给出的办法是：把这些要求整理成 Claude Skills，让已有的 agent 按需读取，而不是每多一项任务就搭一个新 agent。

这篇值得读的地方，是把 Skills、MCP 和 agent 的分工讲清楚了。不过，它更像入门指南，没有提供效果对照实验。程序员可以拿走一套整理重复任务的方法，也需要分清：写进文件的流程，并不会自动变成可靠执行的保证。

Skill 保存的是做事方法，描述决定它何时被调用

Claude skill 首先是一个文件夹，最简单时只有一个 SKILL.md。文件顶部用 YAML 声明 name 和 description，下面写任务步骤，还可以附带模板、参考资料和脚本。

原文把模型比作处理器、agent 比作操作系统、Skills 比作应用。这个比喻方便入门，但 Skill 不一定提供新能力。很多时候，它只是把过去散落在提示词里的要求，整理成可重复使用的工作说明。

Skill 最适合保存反复执行、标准相对固定的任务流程。

按照原文的介绍，Anthropic 在 2025 年 10 月推出 Skills，2025 年 12 月将其作为 Agent Skills 开放标准发布。支持该标准的其他工具也能使用同一个技能目录，但具体安装方式仍要看工具本身。

它也不是每轮对话都把所有说明全文塞进上下文。原文介绍了三层加载方式：

1. 开始时只加载每个 Skill 的名称和描述。
2. 请求与描述匹配时，再读取完整的 SKILL.md。
3. 任务需要模板、价目表或脚本时，再读取或运行相关文件。

这叫渐进式披露（progressive disclosure），也就是先看工具目录，真正干活时才打开对应抽屉。

因此，description 不是装饰性的简介。它承担任务匹配的作用，应该同时说明「做什么」和「什么时候用」。只写「帮助处理业务」太宽泛；写清「回复客户评价」及常见表达，才方便 Claude 判断是否调用。

原文给出的格式限制是：name 最多 64 个字符，只能使用小写字母、数字和连字符；description 最多 1,024 个字符。分层加载能减少一次性占用的上下文，但原文没有性能测试，不能由此推导出安装多少 Skill 都不会影响速度或选择准确率。

一个可用的 Skill，要把输出边界也写进去

原文用一家虚构牙科诊所举例。它需要按店主的口吻起草 Google 评价回复，同时限制字数、优惠承诺和隐私披露。

下面这份 SKILL.md 展示了如何把笼统的「帮我回复」写成有分支、有边界的流程：

---
name: review-reply
description: "Drafts replies to Google reviews for Bright Smile Dental in the owner's voice. Use when asked to reply to, answer or respond to a customer review."
---

## Replying to reviews

1. Read the review and note the star rating and the main point.
2. Start with the reviewer's first name if it is shown.
3. 5 and 4 stars: thank them for one specific thing they mentioned.
4. 3 stars or lower: thank them, say sorry once, and invite them to
   call the office on (555) 010-0199. Never argue or share details
   about their treatment.
5. Keep it under 80 words. Sign off as "Dr. Maria, Bright Smile".
6. Never offer discounts or free treatment in a reply.
7. Show the draft. Do not post anything.

要看最后一条：Show the draft. Do not post anything. 它把交付结果限定为草稿。前面的星级分支、80 词上限、不透露治疗信息、不提供折扣，也都比「保持专业友好」更容易检查。

不过，这只是教学示例。原文没有展示它处理真实差评的结果，更没有证明这些文字能替代实际的发布权限控制。

创建方式有三种：手写目录和文件，打包成 zip 上传到 Claude，或放进 Claude Code 的 skills 文件夹；使用 Anthropic 的 skill-creator，通过问答生成；安装已有 Skill。

作者推荐日常使用 skill-creator，因为它会追问输入、输出、禁区和合格标准。原文引用的视频中，演示者口述回答了大约十几个问题，几分钟内得到一个研究 Skill。这是单次演示，不是所有任务的制作耗时承诺。

更实用的建议是提供一份合格成品。旧报告、已确认的回复，往往比「简洁、有洞察、符合品牌风格」更能说明预期。但样例仍需配合规则，避免模型照搬其中不适用于新任务的细节。

Skills、MCP 和 agent，分别解决什么问题

MCP 提供工具和数据连接，Skill 描述拿到这些能力之后怎么完成任务。

原文的月报例子很直观：Skill 要求获取上个月的流量，与前一个月比较，再用通俗语言写出三条要点；MCP 连接负责提供获取数据的通道。

一个描述流程，一个连接外部能力。只有 Skill，不代表 Claude 就能访问业务系统；只有 MCP，也不代表它知道团队采用什么比较口径、报告需要写到什么程度。

agent 则负责推进任务。原文转述 Anthropic 的主张：不必为邮件、内容、外联分别搭建 agent，可以让一个 agent 配备多项专业技能。示例是从五个训练不足的 agent，转向一个 agent 加五个 Skills。

这个方向能减少重复配置，但原文没有比较维护成本、成功率或故障隔离效果。「不要构建 agent，改为构建 Skills」更适合作为对过度拆分的提醒，不能据此判断所有多 agent 设计都多余。

现成 Skills 可以从 Claude 设置、Anthropic 的公开仓库和社区目录寻找。原文列举了生成 Word、Excel、PowerPoint、PDF 的技能，并称官方示例技能可用于付费 Claude.ai 套餐；具体可用范围仍需以实际产品为准。

安装时要按代码依赖来审查。Skill 可能包含脚本，除了 SKILL.md，还要检查目录里的其他文件、安装和下载行为，以及是否向外部服务器发送数据。让 Claude 帮忙审阅可以辅助检查，但不能作为安全证明。

我的判断

我认同这篇文章对任务复用的判断：如果一件事重复出现，输入输出又比较稳定，把要求整理成文件，通常比每次临时补充提示更容易维护。

但它对「记住流程」的表达有些乐观。文件能够持久保存，不等于模型每次都会选对技能、读全材料、遵守每条要求。原文也没有交代技能冲突、执行失败、缺少输入时如何处理。

和保存一份提示词模板相比，Skill 的优势是有明确的描述入口，能组织附加文件，并支持按需读取。只有一段短要求的偶发任务，未必需要增加这层结构；涉及确定计算、固定格式校验的步骤，也可以交给脚本，再由 Skill 说明调用时机。

作者提出「同一个任务解释三次，就该做成 Skill」，我会把它当作发现候选任务的经验线索，而不是硬门槛。真正要判断的是：任务是否稳定、产物能否验收、维护说明是否比反复解释更划算。原文没有对照数据，这些仍是工作方法上的建议。

能拿来做什么

• 从每周重复的报告、客户回复或内容整理里选一个任务，先明确输入、输出和禁区，再决定是否做成 Skill。原文举出的价目表报价、通话记录转跟进邮件，也都适合按这个顺序梳理。
• 在日常 AI 编程中反复交代同一套交付要求时，可以先保留一份合格产物，再让 skill-creator 追问并整理规则。生成后要检查描述能否准确触发，以及说明是否遗漏异常情况。
• 如果任务需要业务数据，把「从哪里取数据」和「取到后怎么处理」分别落实到工具连接与 Skill 中，并写清缺少数据时应如何处理。
• 安装社区 Skill 前，阅读整个目录，尤其检查脚本、下载动作和对外发送数据的指令。涉及发布的流程，可以参考示例先限定为输出草稿，再通过实际权限控制执行范围。