1. 从“skills”这个热词说起：它到底是什么，为什么突然火了

最近几个月，不管是在技术社区、开发者群聊，还是各种工具的使用讨论里，“skills”这个词出现的频率高得离谱。如果你只是偶尔刷到，可能会以为它说的是“技能”这个通用词，但在当前的技术语境下，它其实指向一个非常具体的东西——围绕 AI 编程助手（比如 Claude Code、Codex 这类工具）构建的一套可复用、可组合的能力模块。你可以把它理解成给 AI 助手装的“技能包”：装上之后，它就能按照你预设的方式去完成特定任务，而不是每次都靠你从头写一大段提示词。

我最早接触这个概念是在折腾 Claude Code 的时候。当时我的需求很简单：想让 AI 帮我按照团队规范生成代码、自动跑测试、再顺手把变更日志写好。一开始我是在对话里反复贴同样的指令，效率极低，而且每次输出格式还不稳定。后来发现社区里已经有人在用 skills 的方式把这些流程固化下来，我才意识到这东西的价值远不止“省几句提示词”——它本质上是在给 AI 助手建立一套可维护的工作流标准。

这篇文章适合几类人看：第一类是刚接触 Claude Code 或 Codex，还在摸索怎么让 AI 真正融入日常开发流程的；第二类是已经用了一段时间，但每次都要重复交代背景、感觉效率卡在瓶颈上的；第三类是对 agents、plugin 这些概念有耳闻，但没搞清楚它们和 skills 之间关系的。我会从设计思路、核心细节、实操过程到常见问题，把 skills 这套东西拆开讲清楚，尽量让你看完就能动手搭一套自己的。

需要先说明一点：skills 目前并没有一个完全统一的官方标准，不同工具、不同社区对它的实现方式有差异。我下面讲的内容，是基于 Claude Code、Codex 以及相关 agents 生态里比较主流的做法，结合我自己实际踩过的坑总结出来的。你照着做大概率能跑通，但具体细节可能需要根据你用的工具版本做微调。

2. 整体设计思路：为什么是 skills，而不是一堆提示词

2.1 从“每次交代”到“一次定义、反复调用”的转变

在没有 skills 之前，我用 AI 编程助手的典型流程是这样的：打开对话框，先贴一段项目背景，再说明这次要做什么，然后补充代码规范、测试要求、输出格式，最后才进入正题。一次两次还行，但一天下来重复十几次，光是复制粘贴就让人烦躁。更麻烦的是，只要我漏掉某个约束，AI 的输出就会跑偏，我还得回头补一句“刚才忘了说，日志要用中文”。

skills 解决的核心问题就是这个。它把“背景 + 约束 + 流程 + 输出格式”打包成一个独立的模块，你只需要在需要的时候调用这个模块，AI 就会自动按照里面定义的规则来工作。这就像你给一个新同事写了一份标准作业程序（SOP），以后他每次做这类任务都照着 SOP 走，不用你每次口头交代。

从设计角度看，这里面有几个关键决策点。第一个是模块的粒度：一个 skill 应该覆盖多大的范围？我的经验是，一个 skill 最好只解决一类明确的任务，比如“生成符合团队规范的单元测试”或者“把变更整理成发布日志”。粒度太粗，比如“帮我写所有代码”，那里面要塞的规则太多，维护起来很痛苦；粒度太细，比如“给变量命名”，那又没必要单独做一个 skill，直接在提示词里说一句就行。

第二个决策点是skill 的存放和调用方式。目前主流做法有两种：一种是把 skill 定义成文件放在项目目录里，AI 助手在需要时自动读取；另一种是通过 plugin 或扩展机制注册到工具里，通过命令或触发词调用。前者更适合团队协作，因为可以跟着代码仓库一起版本管理；后者更适合个人使用，配置一次到处能用。我自己的做法是两者结合：通用型的 skill 注册到工具里，项目特有的 skill 放在仓库的.skills目录下。

2.2 skills、agents、plugin 三者到底是什么关系

很多人一开始会被这三个词绕晕，我刚开始也是。后来画了一张关系图才理清楚，这里用文字说明一下。

plugin是最外层的概念，它指的是对工具本身的扩展。比如你给 Claude Code 装一个 plugin，可能是增加了一个新的命令，或者接入了一个外部服务。plugin 的安装和卸载通常需要重启工具或者重新加载配置。

agents指的是具有自主行动能力的 AI 实体。一个 agent 可以理解成一个“虚拟员工”，它有自己负责的领域，能根据目标自主决定下一步做什么。agents 可以调用 skills 来完成任务，也可以调用其他 agents 来协作。

skills则是 agent 可以调用的具体能力模块。一个 agent 可能拥有十几个 skills，就像一个人会多种技能一样。当你给 agent 下达任务时，它会根据任务类型选择合适的 skill 来执行。

用生活化的类比：plugin 像是给手机装的 App，agents 像是 App 里的虚拟助手，skills 则是这个助手掌握的具体本领。你让助手帮你订机票，它调用的就是“订机票”这个 skill；你让它帮你写周报，它调用的就是“写周报”这个 skill。

理解这个层级关系很重要，因为很多人在配置的时候会把这三者搞混。比如有人想给 Claude Code 加一个自动生成测试的功能，结果去装了一个 plugin，发现根本用不上——实际上他需要的是定义一个 skill，然后让 agent 在合适的时候调用它。

2.3 为什么现在值得投入时间学 skills

有人可能会问：这东西是不是又一个昙花一现的概念？我自己的判断是，skills 背后的逻辑是站得住脚的。AI 编程助手的能力越来越强，但“能力强”和“好用”之间还有很大距离。一个能力很强但每次都要你详细交代背景的助手，实际效率可能还不如一个能力中等但完全懂你规矩的助手。skills 就是在填补这个距离。

而且从趋势上看，越来越多的工具开始原生支持 skills 机制。Claude Code 有它的 skill 体系，Codex 也在往这个方向走，社区里还出现了专门分享和交易 skills 的平台。现在花时间把自己常用的工作流沉淀成 skills，后面换工具的时候迁移成本也会低很多——因为你的核心资产是那些定义好的流程，而不是某个工具的具体配置。

3. 核心细节解析：一个 skill 到底由哪些部分组成

3.1 触发条件：什么时候该调用这个 skill

一个 skill 最容易被忽略但最重要的部分，就是它的触发条件。我见过不少人写的 skill，内容很详细，但没定义清楚“什么时候用”，结果 agent 要么该用的时候不用，要么不该用的时候乱用。

触发条件通常包含几个维度。任务类型是最基本的，比如“当用户要求生成测试代码时”。输入特征也很关键，比如“当用户提供了函数签名但没有提供测试用例时”。上下文状态有时候也需要考虑，比如“当项目根目录存在 pytest.ini 时”。

我自己的做法是给每个 skill 写一段“适用场景”和“不适用场景”的说明。适用场景告诉 agent 什么时候该调用，不适用场景则明确排除一些容易混淆的情况。比如我有一个“生成 API 文档”的 skill，适用场景是“用户提供了路由定义文件”，不适用场景是“用户只是问某个接口怎么用”——后者应该走问答流程，而不是生成文档。

这里有个实操心得：触发条件不要写得太宽泛。我早期写过一个“代码审查”的 skill，触发条件写的是“当用户提到代码质量时”，结果 agent 在我只是随口抱怨一句“这段代码写得真烂”的时候也去调用它，生成了一大篇审查报告，完全没必要。后来我把触发条件改成“当用户明确要求审查指定文件或目录时”，就准确多了。

3.2 执行步骤：skill 内部的流程怎么编排

触发之后，skill 要定义清楚具体怎么做。这部分是 skill 的主体，通常包含一系列有序的步骤。步骤的编排有两种风格：一种是线性流程，一步接一步，适合逻辑固定的任务；另一种是分支流程，根据条件走不同的路径，适合需要判断的任务。

以“生成单元测试”这个 skill 为例，线性流程大概是：读取目标函数的签名和文档字符串 → 分析函数的输入输出类型 → 识别边界条件 → 生成测试用例 → 按照项目规范格式化 → 输出到指定文件。每一步都可以附带具体的操作说明，比如“读取函数签名时，优先使用 AST 解析而不是正则匹配，因为正则容易在复杂签名上出错”。

分支流程则会在某些步骤上分叉。比如“识别边界条件”这一步，如果函数参数是数值类型，就走“检查最小值、最大值、零值、负值”的分支；如果是字符串类型，就走“检查空字符串、超长字符串、特殊字符”的分支。这种分支设计能让 skill 适应更多场景，但也增加了维护复杂度。我的建议是，除非确实有必要，否则优先用线性流程，把分支逻辑放到具体的步骤说明里，而不是在流程层面分叉。

步骤说明里还有一个关键点：要写清楚每一步的输入和输出。这样 agent 在执行的时候才知道上一步的结果怎么传给下一步。我见过一些 skill 写得很笼统，比如“分析代码”，但没说什么算分析完成、分析结果以什么形式存在。结果 agent 要么反复分析同一个东西，要么分析完了不知道怎么用。后来我在每个步骤后面都加上“产出：xxx”的说明，执行效率明显提升。

3.3 输出规范：结果以什么形式呈现

输出规范决定了 skill 执行完之后，你看到的东西长什么样。这部分如果定义不清楚，前面做得再好，最后交付的结果也可能不符合预期。

输出规范通常包含格式、内容结构和风格三个层面。格式是指用 Markdown、JSON、纯文本还是代码块；内容结构是指包含哪些部分、按什么顺序排列；风格是指语言正式还是口语化、详细还是简洁。

我拿“生成发布日志”这个 skill 举例。格式上，我要求输出 Markdown，因为要直接贴到发布说明里。内容结构上，固定包含“新增功能”“问题修复”“性能优化”“破坏性变更”四个部分，每个部分用无序列表。风格上，每条描述以动词开头，不超过 50 字，不包含内部工单号。这些规则看起来琐碎，但正是它们让输出变得可预期。

这里有个容易踩的坑：输出规范写得太死，导致 skill 在某些场景下没法用。比如我一开始要求发布日志必须包含四个部分，结果有一次只改了文档，四个部分里三个都是空的，输出看起来很奇怪。后来我改成“包含有内容的部分，空的部分省略”，就灵活多了。所以输出规范要在“可预期”和“灵活”之间找平衡。

3.4 依赖与约束：skill 运行需要什么前提

有些 skill 不是孤立运行的，它可能依赖某些文件、工具或环境。这部分如果不写清楚，agent 执行到一半发现缺东西，就会卡住或者报错。

常见的依赖包括：文件依赖，比如需要读取某个配置文件；工具依赖，比如需要调用某个命令行工具；环境依赖，比如需要设置某个环境变量。约束则是指 skill 运行时的限制，比如“不要修改指定目录之外的文件”“不要执行网络请求”。

我自己的习惯是在 skill 开头写一个“前置条件”清单，把依赖和约束都列出来。这样 agent 在执行前可以先检查一遍，缺什么就提前告诉你，而不是做到一半才失败。比如我有一个“部署到测试环境”的 skill，前置条件里写了“需要本地已配置好部署凭证”“需要目标环境可访问”，这样如果凭证过期了，agent 会先提醒我更新，而不是尝试部署然后失败。

4. 实操过程：从零搭一个可用的 skill

4.1 环境准备：Claude Code 和 Codex 的安装与基础配置

在开始写 skill 之前，得先把工具装好。Claude Code 和 Codex 的安装方式不太一样，我分别说一下我实际操作的流程。

Claude Code 的安装，我是在 Windows 环境下做的。官方提供了安装包，下载后直接运行安装程序，一路下一步就行。安装完成后需要登录，这里要注意：如果你所在的组织禁用了订阅访问，可能会遇到登录失败的情况，提示“your organization has disabled claude subscription access”。遇到这种情况，需要联系组织管理员确认权限，或者换用个人账号。登录成功后，建议先在设置里把默认工作目录配置好，这样后面写 skill 的时候路径引用会方便很多。

Codex 的安装稍微复杂一点。我是在 Ubuntu 环境下配置的，通过包管理器安装。安装完成后需要配置模型接入，这里有个选择：可以用官方提供的模型，也可以接入本地模型。我试过接入本地模型，配置方式是在设置文件里指定模型服务的地址和端口。如果你也想用本地模型，建议先确认本地服务的接口格式和 Codex 要求的格式是否兼容，不兼容的话需要加一层转换。

VSCode 里配置 Claude Code 是另一个常见需求。我装的是官方扩展，装完之后需要在设置里指定 Claude Code 的可执行文件路径。这里有个坑：如果你同时装了多个版本，路径指错了会导致扩展调用失败。我的做法是在终端里用which claude确认实际路径，再填到设置里。

提示：安装过程中如果遇到 “cc switch local proxy failed while handling codex endpoint /responses” 这类报错，通常是本地代理配置和 Codex 的接口路径不匹配导致的。检查一下代理配置里的路径是否包含了/responses后缀，以及端口是否被占用。

4.2 第一个 skill：从最简单的“代码格式化”开始

我建议第一个 skill 不要选太复杂的任务，从“代码格式化”这种边界清晰、输入输出明确的任务入手，容易跑通，也能帮你熟悉整个流程。

具体做法是：在项目根目录创建一个.skills文件夹，在里面新建一个format-code.md文件。文件内容大致包含四部分：触发条件、执行步骤、输出规范、前置条件。

触发条件我写的是：“当用户要求格式化指定文件或目录，且文件类型为 Python 或 JavaScript 时”。执行步骤分三步：第一步，读取目标文件内容；第二步，根据文件类型选择对应的格式化工具（Python 用 black，JavaScript 用 prettier）；第三步，执行格式化并输出变更摘要。输出规范要求：“以表格形式列出每个文件的变更行数，表格包含文件名、变更前问题数、变更后问题数三列”。前置条件写的是：“需要本地已安装 black 和 prettier”。

写完之后，我在 Claude Code 里测试了一下。输入“帮我格式化 src 目录下的 Python 文件”，agent 正确识别了触发条件，调用了这个 skill，执行完输出了一个变更表格。第一次跑通的时候还是挺有成就感的，虽然功能简单，但整个链路是完整的。

这里有个细节要注意：skill 文件的命名最好用英文小写加连字符，比如format-code.md，不要用中文或空格。因为有些工具在读取 skill 文件时对文件名有要求，用中文可能导致读取失败。文件内容可以用中文写，这个没问题。

4.3 进阶 skill：让 AI 自动生成符合团队规范的测试

跑通第一个 skill 之后，就可以尝试复杂一点的了。我第二个 skill 是“生成单元测试”，这个任务比格式化复杂，因为涉及到对代码的理解和测试用例的设计。

这个 skill 的执行步骤我分了五步。第一步，解析目标函数的签名，提取参数名、类型注解和默认值。第二步，分析函数体，识别所有的条件分支和循环。第三步，针对每个分支和边界条件生成测试用例。第四步，按照团队的测试规范组织测试代码，比如用 pytest 的 fixture 管理测试数据，用 parametrize 处理多组输入。第五步，运行生成的测试，确认全部通过后再输出。

这里的关键难点在第三步和第四步。生成测试用例的时候，如果只是机械地覆盖分支，很容易生成一堆无意义的测试。我的做法是在 skill 里加一条规则：“优先覆盖业务逻辑相关的分支，跳过纯防御性检查的分支”。比如一个函数里有if not isinstance(x, int): raise TypeError，这种类型检查的分支就不需要单独写测试用例，因为类型系统或者调用方已经保证了。

第四步的团队规范部分，我是把团队的测试规范文档摘要后嵌到 skill 里的。这样 agent 在生成测试时就会自动遵循规范，不需要我每次提醒。比如我们团队要求测试函数名以test_开头，测试类以Test开头，断言用assert而不是unittest的断言方法。这些规则写进 skill 之后，生成的测试代码基本不需要再手动调整。

实测下来，这个 skill 帮我节省了大量写测试的时间。以前写一个函数的测试大概要十分钟，现在 agent 生成加上我审查，两三分钟就能搞定。当然，agent 生成的测试不是百分百完美，偶尔会有遗漏的边界条件，但作为初稿已经足够好了。

4.4 把 skill 接入 agent：让调用自动化

skill 写好了，如果每次都要手动指定调用，那还是不够方便。更好的做法是让 agent 自动判断什么时候该用哪个 skill。

在 Claude Code 里，这通常通过在 agent 配置里注册 skill 来实现。具体做法是在 agent 的配置文件里加一个 skills 列表，把每个 skill 的名称、文件路径和触发条件写进去。agent 在接到任务时，会先匹配触发条件，找到合适的 skill 就自动调用。

我自己的配置里注册了五六个常用 skill，包括代码格式化、测试生成、文档生成、变更日志、依赖检查。配置好之后，我只需要说“帮我给这个新函数加上测试”，agent 就会自动调用测试生成 skill，不需要我指定用哪个。

这里有个经验：skill 注册的顺序会影响匹配优先级。如果两个 skill 的触发条件有重叠，排在前面的会优先匹配。所以我把专用性强的 skill 排在前面，通用性强的排在后面。比如“生成 API 文档”比“生成文档”更具体，就排在前面。

另外，agent 的自动调用不是百分百准确的。有时候它会漏掉该调用的 skill，或者调用了不该调用的。遇到这种情况，可以在对话里直接说“用 xxx skill 来做”，手动指定一次，agent 下次就会记住这个场景。我试过几次之后，自动调用的准确率明显提升了。

5. 常见问题与排查技巧实录

5.1 skill 不生效：从触发条件到文件路径的排查顺序

skill 写了但 agent 不调用，这是最常见的问题。我遇到过的原因有好几种，按排查顺序说一下。

首先检查触发条件是否匹配。有时候你写的触发条件和实际输入对不上，比如你写的是“当用户要求生成测试时”，但用户说的是“帮我写点测试用例”，语义上是一回事，但字面不匹配。解决办法是把触发条件写得宽泛一些，或者用同义词列表覆盖多种表达方式。

其次检查skill 文件是否被正确加载。有些工具需要重启或者重新加载配置才能识别新加的 skill 文件。我一开始不知道这一点，写完 skill 直接测试，发现没反应，折腾了半天才发现是没重启。后来养成习惯，每次加完 skill 先重启工具再测试。

然后检查文件路径是否正确。如果 skill 文件放在.skills目录下，但 agent 配置里写的路径是skills（少了点），那就找不到。这种低级错误我犯过不止一次，现在每次配置完都会用绝对路径确认一遍。

最后检查是否有语法错误。skill 文件如果是 Markdown 格式，一般不会有语法问题；但如果是 YAML 或 JSON 格式，一个缩进错误就可能导致整个文件解析失败。我建议写完 skill 后用工具自带的校验功能检查一下，或者先用最简单的 skill 测试，确认机制没问题再写复杂的。

5.2 输出不符合预期：如何调整 skill 的约束

skill 被调用了，但输出不是你想要的，这个问题也很常见。原因通常是 skill 里的约束不够明确，或者 agent 对约束的理解有偏差。

我遇到过一个典型情况：我要求生成的测试用例“覆盖所有边界条件”，结果 agent 生成了几十个测试，把每个参数的每种可能取值都组合了一遍，测试文件长得没法看。后来我把约束改成“覆盖业务逻辑相关的边界条件，每个参数最多生成三个测试用例”，输出就合理多了。

调整约束的时候，有几个技巧。用具体数字代替模糊描述，比如“不超过 50 字”比“简洁”更有效。用正例和反例说明，比如“输出格式参考这个例子：xxx；不要输出成这种：yyy”。把约束按优先级排序，如果约束之间有冲突，agent 知道该优先满足哪个。

还有一个技巧是分阶段约束。如果一次性给太多约束，agent 可能会顾此失彼。我的做法是先让 agent 生成初稿，然后再用第二个 skill 对初稿进行精修。比如先生成测试用例，再用一个“测试审查”的 skill 检查覆盖率和规范性。这样每个 skill 的约束都更聚焦，效果也更好。

5.3 性能问题：skill 太多导致响应变慢怎么办

当你注册了十几个 skill 之后，可能会发现 agent 的响应变慢了。这是因为 agent 在接到任务时，需要遍历所有 skill 的触发条件来匹配，skill 越多，匹配耗时越长。

我的解决办法是分层注册。把最常用的三五个 skill 注册为“常驻”，agent 每次都检查；其余的注册为“按需”，只有在特定条件下才加载。比如“代码格式化”是常驻的，因为几乎每天都要用；“数据库迁移”是按需的，一个月可能才用一次。

另一个办法是合并相似 skill。我一开始把“生成 Python 测试”和“生成 JavaScript 测试”做成了两个 skill，后来发现它们的执行步骤有八成是重合的，只是工具不同。合并成一个“生成测试”的 skill，内部根据文件类型分支，既减少了 skill 数量，又方便维护。

如果响应慢的问题还是存在，可以检查一下 skill 文件的大小。有些 skill 里嵌了大量的示例代码或规范文档，导致文件很大，加载和解析都慢。我的做法是把大段的参考资料放到单独的文件里，skill 里只保留引用路径，需要的时候再读取。

5.4 常见问题速查表

5.5 几个我踩过的坑和对应的避坑技巧

第一个坑是skill 文件编码问题。我有一次在 Windows 上写 skill，保存的时候默认用了 GBK 编码，结果在 Ubuntu 上跑的时候中文全是乱码，触发条件匹配不上。后来统一用 UTF-8 编码保存，问题就没了。如果你跨平台使用 skill，编码一定要统一。

第二个坑是skill 之间的命名冲突。我有两个 skill 都叫“生成文档”，一个生成 API 文档，一个生成用户手册。注册的时候没注意，后注册的覆盖了先注册的，导致 API 文档的 skill 一直不生效。后来我把名字改成“生成 API 文档”和“生成用户手册”，就清楚了。命名的时候加上领域限定词，能避免大部分冲突。

第三个坑是过度依赖 skill 的自动调用。有一段时间我完全依赖 agent 自动判断该用哪个 skill，结果发现有些任务它判断得不准。后来我养成了一个习惯：对于重要任务，手动指定 skill；对于日常小任务，才让 agent 自动判断。这样既享受了自动化的便利，又保证了关键任务的准确性。

第四个坑是skill 更新后没有同步。我改了一个 skill 的执行步骤，但忘了在 agent 配置里更新对应的文件路径（因为我改了文件名），结果 agent 还在调用旧版本。后来我定了个规矩：改 skill 文件名的同时，立刻更新 agent 配置，并且重启工具验证。这个规矩帮我省了不少排查时间。

6. 关于 skills 生态的一些观察和后续扩展思路

6.1 社区里有哪些值得关注的 skill 方向

目前社区里分享的 skill 主要集中在几个方向。代码生成类是最多的，包括生成测试、生成文档、生成样板代码等。代码审查类也不少，比如检查代码规范、检查安全漏洞、检查性能问题。工作流类的 skill 相对少一些，但价值很高，比如自动生成变更日志、自动更新依赖、自动部署到测试环境。

我个人比较关注的是跨工具协作类的 skill。比如一个 skill 可以同时操作 Claude Code 和 Codex，让两个工具协同完成一个任务。这种 skill 目前还不多，但随着 agents 生态的发展，应该会越来越多。

另外，领域特定的 skill 也值得关注。比如专门针对前端开发的 skill、专门针对数据处理的 skill、专门针对移动端开发的 skill。这类 skill 因为针对性强，往往比通用 skill 更好用。我看到有人在分享“Flutter 项目专用 skill”，里面包含了 Flutter 项目的目录结构规范、测试规范、构建流程等，对于做 Flutter 开发的人来说直接就能用。

6.2 怎么把自己的经验沉淀成可复用的 skill

如果你已经在某个领域积累了不少经验，把这些经验沉淀成 skill 是一个很好的知识管理方式。我的做法是从重复性最高的任务开始。想想你每天或每周都要重复做的事情有哪些，挑一个出来，把它的流程写清楚，就是一个 skill 的雏形。

写的时候注意把隐性知识显性化。很多经验老手觉得“理所当然”的步骤，对新手来说可能是完全不知道的。比如你在做代码审查时，会下意识地先看变更范围再看具体实现，这个顺序就是隐性知识。把它写进 skill 里，agent 执行的时候就会遵循同样的顺序。

还有一个技巧是从失败中提炼规则。每次 agent 输出不符合预期的时候，不要只是手动改一下就算了，而是想一想：能不能加一条规则到 skill 里，让下次不再犯同样的错误？我现在的 skill 里有很多规则都是这么来的，比如“生成测试时不要 mock 被测函数本身”“生成文档时不要包含内部实现细节”等。

6.3 后续可以怎么扩展这套东西

如果你已经把基础的 skill 用起来了，可以考虑几个扩展方向。一是做 skill 的组合，把多个 skill 串成一个工作流。比如“生成代码 → 生成测试 → 运行测试 → 生成变更日志”可以串成一个完整的 skill 链，一次调用全部完成。二是做 skill 的版本管理，像管理代码一样管理 skill，每次修改都记录变更原因，方便回滚和对比。三是做 skill 的分享和复用，把团队里好用的 skill 整理出来，新成员入职的时候直接导入，能省很多培训时间。

我目前在做的是第二个方向，给每个 skill 加了一个简单的版本号和变更记录。虽然目前还是手动维护，但已经能感觉到好处了——有一次改了一个 skill 之后发现效果变差了，靠变更记录很快定位到是哪条规则改坏了，回滚之后问题就解决了。

提示：skill 的版本管理不需要搞得太复杂，在文件开头加一个“版本历史”小节，记录每次修改的日期、修改内容和修改原因就够了。关键是坚持记录，而不是追求格式完美。

最后分享一个我个人的小习惯：每次用 skill 完成一个任务之后，如果觉得哪里可以改进，就立刻花一分钟改一下 skill 文件。这个习惯看起来不起眼，但积累下来，我的 skill 库越来越贴合自己的实际需求，用起来也越来越顺手。skills 这东西，本质上就是把你的工作方式固化下来，让它变成可复用、可传承的资产。花时间在这上面，长期来看是划算的。