如何沉淀 Skill：把重复劳动变成可复用的能力

用 Claude Code 越久，会发现一件有意思的事：你真正省下时间的地方，往往不是某次惊艳的对话，而是那些被你固化下来、可以反复调用的「Skill」。

Skill 是 Claude Code 提供的能力沉淀机制——一段 Markdown 文件、一套触发规则、一组参考脚本，写一次，以后每次触发都按同一套标准执行。问题在于：什么任务值得沉淀？沉淀到什么粒度？写出来的 Skill 怎样才算好用？

这篇文章讲讲我沉淀 Skill 的完整方法。

---

一、先想清楚：什么才叫"沉淀"

很多人把 Skill 理解成"再写一个 Prompt"，这是最常见的误区。

Prompt 是一次性指令——每次对话都要重新表述一遍。Skill 是把你反复使用的指令、参考资料、脚本、判断逻辑整体打包，让 Claude 在合适的时候自动触发，并按你规定的流程执行。

判断一个东西值不值得沉淀成 Skill，只看一个问题：

你是否已经做过这件事三次以上，并且每次的做法都大同小异？

三次是一个很好的门槛。做过一次，你可能只是偶发需求；做过两次，你还在摸索做法；做到第三次，重复的部分就开始暴露出来——这些重复的部分，就是可以沉淀的骨架。

---

二、沉淀的四个阶段

从"每次都手写"到"一个 Skill 自动搞定"，中间会经历四个阶段。很多人没有意识到这个过程，总想一步到位写个完美的 Skill，结果写出来没人用（包括自己）。

阶段一：手工重复

你第一次做某件事，所有步骤都靠一条条 Prompt 推进。比如发公众号：

• 上传图片到 CDN
• 替换 Markdown 里的图片链接
• 调用排版工具生成 HTML
• 生成封面图
• 推送到公众号草稿箱

这五步你一条一条地指挥 Claude 完成。这个阶段不要急着写 Skill，先把流程手工走通。你还不知道哪里会踩坑。

阶段二：整理步骤清单

做到第二、三次，你开始意识到有几步是固定的，有几步每次不一样。把它们分开记下来：

• 固定部分：CDN 上传的 API key、排版工具的 MCP 调用方式、封面图的尺寸规格
• 变动部分：文章内容、图片数量、主题风格

这一步的价值是把"流程"和"参数"分离。Skill 沉淀的是流程，参数留给调用时输入。

阶段三：写 Skill 骨架

这时候才开始动手写 Skill。一个好 Skill 有四个必须想清楚的要素：

① 触发词

Skill 靠描述里的关键词自动激活。描述写得越具体，误触发越少。写触发词的诀窍是穷举用户可能说的表达，包括中英文、正式和口语说法：

当用户提到「发公众号」「发布到微信」「推公众号」「一键发布」
「publish to wechat」「推送文章」时触发。

不要只写"发布文章时触发"——这种描述等于没写。

② 边界

Skill 要明确说清不做什么，比说清做什么更重要。比如 xlsx 这个 Skill 里写着：

不要在最终输出是 Word 文档、HTML 报告、独立 Python 脚本、数据库流水线时触发，即便涉及表格数据。

边界清楚，Skill 才不会在不合适的场景乱插手。

③ 步骤

把流程拆成编号步骤，每一步说清楚输入是什么、输出是什么、用哪个工具。步骤之间的依赖关系要显式写出来，不要让 Claude 自己猜。

④ 参考文件

Skill 目录里可以放脚本、模板、示例文件。Claude 执行时会读取这些文件作为参考。把易变的配置和固定的代码分开——配置放在 Skill 外，脚本放在 Skill 内。

阶段四：用了再改

写完 Skill 不是终点，而是起点。第一版 Skill 几乎一定会有问题：触发词不准、步骤遗漏、参数命名别扭。每次用的时候留意：

• 这次触发对了吗？有没有该触发没触发、不该触发却触发的情况？
• 哪一步 Claude 没按预期做？是指令不清还是参考文件不够？
• 有没有出现"我又手动补了一段 Prompt"的情况？如果有，那段 Prompt 该进 Skill。

Skill 是养出来的，不是写出来的。用一次改一次，三个月后它会变得非常顺手。

---

三、什么内容值得沉淀，什么不值得

不是所有重复的事都值得做成 Skill。判断标准有三条：

值得沉淀：有稳定流程的任务

比如：

• 发布公众号文章（流程固定，参数变化）
• 生成视频号封面（尺寸固定，内容变化）
• 写 commit message（看 diff → 看 log 风格 → 生成消息，流程固定）
• 从 PDF 提取内容并总结（流程固定，输入变化）

这些任务的共同特点是：骨架稳定，血肉变化。

不值得沉淀：依赖当下判断的任务

比如：

• 给某段代码做 Code Review
• 回答一个具体的技术问题
• 调试一个奇怪的 Bug

这些任务每次都需要根据当下上下文现场判断，没有固定流程。硬写成 Skill 反而会让 Claude 变死板。

介于两者之间的任务：做子流程 Skill

有些任务整体是灵活的，但其中某个子流程是固定的。这时候把子流程单独做成 Skill，让主流程调用它。

比如 Code Review 整体是灵活的，但"跑完测试并把失败用例总结成报告"这一步是固定的——可以把这步做成独立 Skill。

这种细粒度的 Skill 往往比大而全的 Skill 更好用。

---

四、一个 Skill 沉淀实例

拿我自己的 wechat-article Skill 举个例子，说明沉淀是怎么发生的。

第一次：手工操作，花了 40 分钟，走得磕磕绊绊。我发现图片要先传 R2、公众号 API 需要特定格式、封面图尺寸必须是 900×383。

第二次：把第一次的踩坑点记下来，流程顺了些，花了 25 分钟。意识到"图片上传 → Markdown 路径替换"这两步每次都一样。

第三次：先写了一个简陋 Skill，只包含流程说明，没有脚本。用它省下了思考时间，花了 15 分钟。发现排版那一步每次的参数都要重输，决定把排版默认参数写进 Skill。

第四次：Skill 加入了默认主题、默认封面尺寸、自动调用 r2-image-upload 子 Skill。触发一次，5 分钟完成。

第十次：Skill 已经稳定，我几乎不用操心任何步骤。只需要说"发公众号"，剩下全自动。

从 40 分钟到 5 分钟，省下的时间不在于 Claude 变聪明了，而在于流程被我固化下来了。

---

五、沉淀 Skill 的三个常见误区

误区一：追求大而全

一个 Skill 试图处理十种场景，结果每种都不够深入。宁可拆成三个小 Skill，各自聚焦。

误区二：把配置写死在 Skill 里

把 API key、用户 ID、路径这些易变的东西直接写进 Skill 内容。换台机器就废了。正确做法是把配置放在环境变量或独立配置文件，Skill 里只留读取逻辑。

误区三：写完就不管了

很多人写完 Skill 就束之高阁，下次用的时候发现不好用就放弃。Skill 的价值来自持续迭代，每次用都要问自己"哪里能改"，一个月后它才会真正好用。

---

结尾

沉淀 Skill 的本质，是把自己在大模型使用中积累的流程经验，变成可复用的数字资产。

写 Prompt 是消耗，每次都从零开始。写 Skill 是积累，越用越顺。当你 Skill 库里有了 20 个、50 个稳定的 Skill，你会发现自己和 Claude 的协作效率进入了完全不同的档位——大部分日常任务，一句话就能启动整个流水线。

从今天开始，挑一件你已经做过三次以上的事，把它沉淀成第一个 Skill。