AI编程助手技能包（skills）实战：从提示词到可复用能力扩展

1. 从“skills”这个热词说起：它到底在解决什么问题

最近半年，不管是在技术社区还是各种开发者群组里，“skills”这个词出现的频率高得离谱。你随便翻翻热搜词列表就能看到：skills、Claude Code、Codex、agents、plugin、find skills、codex skills、claude agent skills、skills推荐、skills开发……这些词扎堆出现，说明一件事：围绕 AI 编程助手的能力扩展，正在从“模型本身有多强”转向“怎么给模型装上可复用的技能包”。

我最早接触这个概念是在折腾 Claude Code 的时候。当时我的理解很朴素：不就是给 AI 写一段提示词，让它按我的要求干活吗？后来踩了几次坑才发现，事情没那么简单。你写一段提示词，今天能用，明天换个项目、换个上下文，效果就崩了。问题出在哪？出在提示词是“一次性”的，而 skills 是“可复用、可组合、可版本管理”的。

打个比方。提示词就像你临时给同事口头交代一件事：“帮我把这个 Excel 里的重复行删掉，然后按日期排序。”同事这次听懂了，下次你不在，他可能就忘了。而 skills 更像是你写了一份标准作业程序（SOP），放在团队共享盘里，谁需要谁拿去用，步骤、参数、注意事项全在里面，甚至还能被其他流程调用。这就是 skills 和普通提示词的本质区别。

那 skills 具体能做什么？我总结下来主要是三件事。第一，把重复性的操作固化下来。比如你每次新建一个前端项目，都要配置 ESLint、Prettier、TypeScript、路径别名、环境变量，这些步骤完全可以写成一个 skill，下次一句话调用。第二，让 AI 助手的行为更可控。你给 AI 一个 skill，它就知道在什么场景下该做什么、不该做什么，输出格式也稳定了。第三，实现能力的跨工具迁移。你在 Claude Code 里写好的 skill，理论上可以适配到 Codex 或其他支持 agents 的工具里，不用重复造轮子。

适合谁来参考？我觉得三类人最需要关注。第一类是日常重度使用 AI 编程助手的开发者，你已经在用 Claude Code、Codex 或者类似工具，但总觉得每次都要重复交代背景，效率上不去。第二类是团队里的技术负责人，你想把团队的最佳实践沉淀下来，让新人也能快速上手。第三类是对 agent 生态感兴趣的技术爱好者，你想搞清楚 skills 的底层逻辑，甚至自己开发 skill 分享给别人。

接下来我会从设计思路、核心细节、实操过程、常见问题四个维度，把 skills 这件事彻底讲透。文章里会涉及 Claude Code、Codex、agents、plugin 这些关键词的具体用法，也会分享我自己踩过的坑和总结出来的技巧。不管你是刚听说 skills 的新手，还是已经写过几个 skill 的老手，应该都能找到对你有用的东西。

2. 内容整体设计与思路拆解

2.1 为什么是“技能包”而不是“提示词库”

很多人第一次接触 skills 的时候，会把它理解成“高级一点的提示词”。这个理解不能说错，但不够准确。我刚开始也这么想，直到我把同一个需求分别用提示词和 skill 实现了一遍，才发现两者的设计哲学完全不同。

提示词的核心是“描述意图”。你告诉 AI 你想干什么，AI 根据它的理解去执行。问题在于，AI 的理解是不稳定的。同一个提示词，今天跑出来是 A 结果，明天可能是 B 结果。你可能会说，那我把提示词写详细一点不就行了？确实，详细提示词能提高稳定性，但代价是提示词越来越长，维护成本越来越高，而且换个模型可能就失效了。

skills 的核心是“封装能力”。一个 skill 不仅仅是一段文字，它包含了触发条件、执行步骤、输入输出定义、依赖项、错误处理这些结构化信息。你可以把它想象成一个函数：给定输入，经过确定的处理流程，返回输出。AI 助手在遇到匹配的场景时，会自动调用这个 skill，而不是靠临时理解。

我举个例子你就明白了。假设你要让 AI 帮你“把一段 JSON 转成 TypeScript 类型定义”。用提示词的方式，你得写：“请把下面的 JSON 转换成 TypeScript interface，注意嵌套对象要单独定义，数组类型要推断元素类型，可选字段用问号标记……”每次都要写一遍。而用 skill 的方式，你只需要定义一个叫json-to-ts的技能，里面写清楚转换规则、边界情况处理、输出格式要求。以后你只要说“用 json-to-ts 处理这段数据”，AI 就知道该怎么做。

提示：skills 和提示词不是替代关系，而是互补关系。简单的一次性任务用提示词就够了，重复出现、有固定流程、需要稳定输出的任务才值得做成 skill。

2.2 主流工具对 skills 的支持现状

目前对 skills 支持比较完善的主要是 Claude Code 和 Codex 这两个工具。Claude Code 是 Anthropic 推出的命令行编程助手，它有一套自己的 skill 管理机制，支持从官方市场安装 skill，也支持本地自定义。Codex 是 OpenAI 系的编程助手，它的 skills 体系更偏向于“配置驱动”，通过配置文件来定义 agent 的行为。

除了这两个，还有一些工具也在跟进。比如 Cursor 虽然主打的是编辑器集成，但它也支持通过规则文件来约束 AI 行为，本质上和 skills 的思路是一致的。VS Code 上的 Claude Code 插件也让 skills 的使用门槛降低了不少，你不需要在终端里敲命令，直接在编辑器里就能调用。

这里要特别提一下plugin这个概念。在 Claude Code 的生态里，plugin 和 skill 经常一起出现，但它们是两个层面的东西。plugin 更像是“功能模块”，比如一个 plugin 可能包含多个 skill，还可能有自己的配置界面和依赖管理。skill 则是更细粒度的“能力单元”。你可以理解为：plugin 是工具箱，skill 是工具箱里的具体工具。

2.3 方案选型的几个关键考量

在实际动手之前，有几个选型问题需要想清楚。第一个问题是：用官方市场现成的 skill，还是自己写？我的建议是，先逛一圈官方市场，看看有没有能直接用的。Claude Code 的官方市场里已经有不少高质量的 skill，覆盖了代码审查、文档生成、测试编写、重构建议等常见场景。如果现成的能满足你 80% 的需求，就别重复造轮子。剩下 20% 的特殊需求，再考虑自己写。

第二个问题是：skill 的粒度怎么控制？太粗了不好复用，太细了管理成本高。我的经验是，一个 skill 最好只做一件事，但这件事要足够完整。比如“生成 React 组件”这个粒度就比较好，它包含了文件创建、模板填充、样式引入、导出配置这些步骤，但不会把“生成整个页面”也塞进来。如果你发现一个 skill 的描述超过三句话还说不清楚，那大概率是粒度太粗了，需要拆分。

第三个问题是：怎么保证 skill 的可移植性？如果你只在 Claude Code 里用，那问题不大。但如果你同时用 Codex，或者以后想换工具，就要考虑 skill 的通用性。我的做法是，把 skill 的核心逻辑写成与工具无关的文档，然后用各工具自己的配置格式去“包装”它。这样即使换工具，核心逻辑不用重写。

3. 核心细节解析与实操要点

3.1 skill 的文件结构与关键字段

一个标准的 skill 通常包含这几个部分：元信息、触发条件、执行指令、输入输出定义、示例。不同工具的格式略有差异，但核心要素是相通的。

以 Claude Code 的 skill 为例，它通常是一个 Markdown 文件，放在特定的目录下。文件开头是 YAML 格式的元信息，包括 skill 的名称、描述、版本、作者这些。描述字段特别重要，因为 AI 就是靠这个描述来判断什么时候该调用这个 skill 的。我见过很多人写描述写得很随意，结果 AI 根本不知道什么时候该用，这个 skill 就废了。

触发条件可以写得很具体，比如“当用户提到 JSON 转 TypeScript 时”，也可以写得更抽象，比如“当需要处理数据格式转换时”。我的建议是，描述要具体，但不要过于狭窄。太窄了覆盖场景少，太宽了容易误触发。一个技巧是，在描述里同时写上“做什么”和“什么时候做”，比如“将 JSON 数据转换为 TypeScript 类型定义，适用于前端项目初始化或 API 响应类型生成场景”。

执行指令部分是 skill 的核心。这里要写清楚每一步做什么，遇到分支怎么处理，输出格式是什么。我习惯用有序列表来写步骤，每一步都尽量具体。比如不要写“处理数据”，而要写“遍历 JSON 对象的每个 key，判断 value 类型，如果是对象则递归处理，如果是数组则推断元素类型”。

输入输出定义经常被忽略，但其实很重要。你定义了输入格式，AI 就知道该向用户要什么信息。你定义了输出格式，AI 就知道该生成什么样的结果。这能大大减少来回沟通的成本。

3.2 触发机制与调用逻辑

skill 的触发机制是我觉得最值得深入理解的部分。它不像函数调用那样有明确的调用语句，而是靠 AI 根据上下文“判断”是否该用某个 skill。这就带来一个问题：AI 怎么知道该用哪个 skill？

答案在 skill 的描述和 AI 的系统提示里。当你安装了一个 skill，它的描述会被注入到 AI 的上下文中。AI 在收到用户请求时，会拿请求和所有可用 skill 的描述做匹配，找到最合适的那个。所以描述写得好不好，直接决定了 skill 能不能被正确触发。

我踩过一个坑：有一次我写了一个叫code-review的 skill，描述写的是“审查代码”。结果我发现 AI 几乎从来不用它，即使我明确说“帮我审查一下这段代码”。后来我把描述改成“对指定代码文件进行静态审查，检查潜在 bug、代码风格问题和性能隐患，输出审查报告”，触发率立刻上去了。原因很简单，原来的描述太笼统，AI 不确定这个 skill 到底能做什么，就不敢用。

还有一个技巧是，在 skill 的描述里加入一些“关键词”。比如你的 skill 是关于 React 组件生成的，那就在描述里写上“React、组件、JSX、前端”这些词。这样当用户提到相关概念时，AI 更容易联想到你的 skill。

注意：不要为了让 skill 更容易被触发而把描述写得太宽泛。我见过有人把描述写成“处理所有编程相关任务”，结果这个 skill 频繁误触发，反而干扰了正常使用。

3.3 参数传递与上下文管理

skill 在执行过程中，往往需要从用户那里获取一些参数。比如一个“生成 API 请求代码”的 skill，需要知道请求方法、URL、请求体格式、认证方式这些信息。这些参数怎么传递给 skill，是一个需要设计的问题。

最简单的方式是让 AI 从对话上下文中提取。用户说“帮我生成一个 GET 请求，地址是 /api/users，需要 Bearer token”，AI 就能从这句话里提取出方法、URL、认证方式。这种方式的好处是自然，用户不需要按固定格式输入。坏处是有时候 AI 会漏掉一些参数，或者理解错。

更可靠的方式是在 skill 里定义明确的参数列表，然后让 AI 主动询问缺失的参数。比如 skill 里写：“需要以下参数：请求方法、URL、请求体（可选）、认证方式（可选）。如果用户未提供，逐一询问。”这样虽然多几轮对话，但参数完整性有保障。

上下文管理是另一个容易出问题的地方。skill 在执行时，会占用 AI 的上下文窗口。如果你的 skill 特别长，或者一次调用了多个 skill，上下文可能会不够用。我的经验是，尽量把 skill 写得精简，把详细的参考文档放在外部文件里，需要时再读取。Claude Code 支持在 skill 里引用外部文件，这个功能很实用。

3.4 版本管理与团队协作

当你写了几个 skill 之后，版本管理就成了一个问题。今天改了一版，明天又改了一版，过段时间自己都忘了哪个版本好用。我的做法是，把 skill 文件纳入 Git 管理，每次修改都写清楚改了什么、为什么改。这样即使改坏了，也能回滚。

团队协作场景下，skill 的共享就更重要了。我们团队的做法是，建一个专门的 skill 仓库，每个人都可以提交自己的 skill，经过 review 后合并到主分支。新同事入职时，直接 clone 这个仓库，把 skill 安装到自己的环境里，就能复用团队积累的能力。这比口头传授或者写文档高效多了。

还有一个细节：skill 的命名要规范。我见过有人用中文命名 skill，结果在某些工具里会出现编码问题。建议统一用英文小写加连字符，比如json-to-ts、react-component-gen、api-request-builder。这样跨工具、跨平台都不容易出问题。

4. 实操过程与核心环节实现

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

在开始写 skill 之前，得先把工具装好。Claude Code 的安装方式有几种，我推荐用官方提供的安装脚本，最省事。在终端里执行安装命令后，你需要配置 API 密钥或者登录账号。如果你在国内，可能会遇到网络问题，这个需要自己想办法解决，我就不展开说了。

安装完成后，你可以通过claude --version来验证是否安装成功。然后运行claude进入交互模式，看看能不能正常对话。如果一切正常，就可以开始配置 skill 了。

Codex 的安装稍微不同，它更依赖配置文件。你需要先下载 Codex 的安装包，然后按照官方文档配置config文件。Codex 的配置项比较多，我建议先用默认配置跑通，再逐步调整。特别要注意的是，Codex 对配置文件的格式要求很严格，一个拼写错误就可能导致启动失败。我遇到过codex is ignoring 1 unrecognized configuration setting这个报错，排查了半天才发现是某个字段名多了一个字母。

如果你同时用 Claude Code 和 Codex，可以考虑用cc switch这类工具来管理配置切换。不过这类工具偶尔会出现local proxy failed的问题，我的建议是，如果遇到代理相关报错，先检查网络配置，再检查工具版本是否兼容。

4.2 从零写一个 skill：以“JSON 转 TypeScript”为例

下面我带你完整走一遍写 skill 的流程。我们以“JSON 转 TypeScript 类型定义”这个需求为例，这个 skill 在前端开发里特别实用，尤其是对接后端 API 的时候。

第一步，确定 skill 的存放位置。Claude Code 默认会从特定目录读取 skill，你可以在配置里查看或修改这个路径。我习惯在项目根目录下建一个.claude/skills文件夹，把项目相关的 skill 放在这里，这样跟着项目走，换电脑也不用重新配置。

第二步，创建 skill 文件。文件名就叫json-to-ts.md，内容结构如下。元信息部分，名称写json-to-ts，描述写“将 JSON 数据转换为 TypeScript 类型定义，适用于前端项目对接 API 时生成响应类型”。版本写1.0.0，作者写你自己的名字。

第三步，写执行指令。我一般会分成几个步骤来写。首先是解析输入，让 AI 确认用户提供的 JSON 是有效的。然后是递归遍历，对每个字段判断类型。接着是生成 TypeScript 代码，注意嵌套对象要提取成独立的 interface，数组要推断元素类型，可选字段要加问号。最后是输出，把生成的代码放在代码块里，并附上使用说明。

第四步，定义输入输出。输入就是一个 JSON 字符串或者文件路径。输出是 TypeScript 代码，格式要求是每个 interface 单独一段，用export导出。

第五步，写示例。给一个简单的 JSON 输入和对应的 TypeScript 输出，这样 AI 能更准确地理解你的意图。示例不用太复杂，覆盖主要情况就行。

写完之后，把文件放到 skill 目录下，重启 Claude Code 或者重新加载配置。然后你就可以测试了。输入一段 JSON，说“用 json-to-ts 转换一下”，看看输出是否符合预期。如果不符合，就调整 skill 里的指令，直到满意为止。

4.3 调试与优化：让 skill 真正好用

写完 skill 只是第一步，调试和优化才是重头戏。我总结了一个“三轮调试法”，分享给你。

第一轮，功能验证。确认 skill 能跑通，能产生输出。这一轮不用太在意输出质量，先保证流程是通的。如果 AI 根本不触发这个 skill，那就是描述的问题，回去改描述。如果触发了但输出不对，那就是执行指令的问题，检查步骤是否清晰。

第二轮，边界测试。拿一些特殊的输入来测试，比如空 JSON、嵌套很深的 JSON、包含特殊字符的 JSON、数组里混合类型的 JSON。看看 skill 能不能正确处理。我就是在这一轮发现，原来的 skill 遇到空对象会报错，后来加了一个判断才解决。

第三轮，效率优化。看看 skill 的执行时间、消耗的 token 数、输出的可读性。如果 skill 太长导致上下文不够用，就精简指令，把详细说明移到外部文件。如果输出格式不够好，就调整输出模板。

这里分享一个我常用的技巧：在 skill 里加入“自检”步骤。比如让 AI 在生成 TypeScript 代码后，自己检查一遍是否有语法错误、是否有遗漏的字段、命名是否规范。这个自检步骤能显著提高输出质量，而且成本很低。

提示：调试 skill 时，建议开一个专门的测试对话，不要在日常工作的对话里调试。这样避免污染上下文，也方便你反复测试。

4.4 组合多个 skill 完成复杂任务

单个 skill 的能力是有限的，真正强大的是把多个 skill 组合起来用。比如你要做一个“从 API 文档生成前端请求代码”的任务，可以拆成几个 skill：一个负责解析 API 文档，一个负责生成 TypeScript 类型，一个负责生成请求函数，一个负责生成 Mock 数据。然后在一个主流程里依次调用这些 skill。

Claude Code 支持在 skill 里调用其他 skill，这叫做“skill 编排”。你可以在一个 skill 的执行指令里写“调用 json-to-ts 处理响应数据，然后调用 api-request-builder 生成请求代码”。AI 会自动按顺序执行。

不过要注意，skill 编排会增加上下文消耗，也更容易出错。我的建议是，先从简单的两三个 skill 组合开始，跑通了再增加复杂度。另外，每个子 skill 的输出格式要统一，否则下一个 skill 可能解析不了。

Codex 在 skill 编排方面有自己的机制，它更偏向于用配置文件定义 agent 的行为链。如果你同时用两个工具，可以考虑把核心逻辑写成通用的，然后用各自的配置去适配。

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

5.1 skill 不触发或误触发怎么办

这是最常见的问题，没有之一。我统计了一下，我遇到的 skill 问题里，大概有六成是触发相关的。

不触发的典型表现是：你明明说了相关的话，但 AI 就是不用你的 skill。原因通常有三个。第一，描述写得太笼统，AI 不确定这个 skill 是否匹配。解决办法是把描述写具体，加入场景关键词。第二，skill 没有被正确加载。检查一下文件路径对不对，文件格式是否符合要求。第三，有多个 skill 的描述相似，AI 不知道该选哪个。这时候需要给每个 skill 更独特的描述，或者合并相似的 skill。

误触发的典型表现是：你只是随口提了一句，AI 就兴冲冲地调用了 skill，结果做了一堆你不需要的事。原因通常是描述写得太宽泛。解决办法是收紧描述，加入更明确的触发条件。比如把“处理代码”改成“对指定代码文件进行静态审查并输出报告”。

下面这个表格是我整理的触发问题速查表，你可以对照排查。

5.2 输出格式不稳定的处理思路

即使 skill 触发了，输出格式也可能不稳定。今天生成的 TypeScript 代码用interface，明天可能就用type。今天缩进是两个空格，明天变成四个。这种不一致在团队协作里特别让人头疼。

我的解决办法是在 skill 里明确指定输出模板。不要只说“生成 TypeScript 代码”，而要给出一个具体的模板，包括用什么关键字、缩进多少、是否加分号、导出方式是什么。模板越具体，输出越稳定。

另一个技巧是加入“格式检查”步骤。让 AI 在输出前自己检查一遍格式是否符合要求。这个步骤虽然增加了一点开销，但能显著提高一致性。

如果格式问题依然存在，可以考虑在 skill 里嵌入一个格式化脚本的调用。比如生成代码后，自动调用 Prettier 格式化。Claude Code 支持执行 shell 命令，这个能力可以用来做后处理。

5.3 上下文超限与性能优化

skill 用多了之后，上下文超限是个绕不开的问题。尤其是当你同时加载了十几个 skill，每个 skill 的描述和指令都占用上下文，留给实际任务的上下文就少了。

我的优化策略是按需加载。不是所有 skill 都需要一直可用。你可以把 skill 分成“常用”和“备用”两类，常用的放在默认加载目录，备用的放在另一个目录，需要时再手动加载。Claude Code 支持这种动态加载机制。

另一个策略是精简 skill 内容。把详细的参考文档、示例代码、边界情况说明移到外部文件里，skill 本身只保留核心指令和触发条件。需要时让 AI 去读取外部文件。这样 skill 的上下文占用能减少一半以上。

还有一个容易被忽略的点是对话历史的管理。长对话会积累大量上下文，即使 skill 本身很短，对话历史也可能把上下文撑爆。我的习惯是，完成一个阶段性任务后，开一个新对话，把必要的背景信息重新交代一下。虽然麻烦一点，但能避免上下文超限导致的性能下降。

5.4 跨工具兼容的注意事项

如果你同时用 Claude Code 和 Codex，或者以后打算换工具，跨工具兼容就是个必须考虑的问题。我踩过的坑包括：skill 文件格式不兼容、描述字段名称不同、调用语法有差异。

我的应对方法是分层设计。把 skill 的核心逻辑写成一份通用的 Markdown 文档，不依赖任何特定工具的语法。然后针对每个工具，写一个薄的“适配层”，把通用文档转换成该工具要求的格式。这样核心逻辑只需要维护一份，适配层的工作量很小。

另外，不同工具对 skill 的触发机制也有差异。Claude Code 更依赖描述匹配，Codex 更依赖配置规则。在写通用文档时，要把触发条件写得足够清晰，这样不管哪个工具都能正确识别。

注意：跨工具兼容不是必须的。如果你只用 Claude Code，那就按 Claude Code 的最佳实践来写，不用考虑其他工具。兼容性是有成本的，只在真正需要时才做。

5.5 安全与权限的边界控制

skill 在执行时，可能会读写文件、执行命令、访问网络。这些操作如果不受控制，可能会带来风险。我建议在 skill 里明确声明它需要哪些权限，然后在工具层面做限制。

比如一个只负责生成代码的 skill，就不应该给它文件写入权限。一个只负责读取配置的 skill，就不应该给它网络访问权限。Claude Code 支持在配置里设置权限白名单，我强烈建议开启这个功能。

另外，从官方市场安装 skill 时，要看一下它的权限声明。如果一个简单的格式化 skill 要求网络访问权限，那就要警惕了。自己写 skill 时，也要遵循最小权限原则，只申请必要的权限。

6. 我个人的实操心得与进阶建议

6.1 从“能用”到“好用”的关键跨越

写了十几个 skill 之后，我最大的体会是：skill 的质量不取决于它有多复杂，而取决于它有多稳定。一个简单的、每次都能正确执行的 skill，比一个功能强大但时灵时不灵的 skill 有价值得多。

怎么做到稳定？我的经验是三点。第一，指令要具体到近乎啰嗦。不要假设 AI 能理解你的意图，把每一步都写清楚。第二，边界情况要提前处理。空输入、异常输入、超大输入，这些都要在 skill 里写明怎么处理。第三，输出格式要固定。给一个模板，让 AI 照着填，不要让它自由发挥。

6.2 建立自己的 skill 库

我建议每个重度使用 AI 编程助手的人，都建立自己的 skill 库。不用一开始就追求大而全，从你最常做的任务开始，一个一个积累。我最初只有三个 skill：代码审查、提交信息生成、JSON 转 TypeScript。后来慢慢增加到十几个，覆盖了日常工作的大部分场景。

skill 库要定期整理。过时的、不好用的、重复的，该删就删。我每季度会花半小时过一遍自己的 skill 库，把用不上的清理掉，把常用的优化一下。这个习惯让我的 skill 库始终保持精简高效。

6.3 关注社区动态与 skill 分享

skills 这个领域变化很快，新工具、新玩法层出不穷。我建议关注几个渠道：Claude Code 的官方市场、GitHub 上的 skill 仓库、技术社区的讨论。看到好的 skill，可以下载下来研究一下它的写法，往往能学到新的技巧。

我自己也从社区里受益很多。有一次看到一个 skill 用了“分步确认”的机制，就是每执行一步都让用户确认一下，特别适合那些高风险的操作。我把这个思路借鉴到了自己的 skill 里，效果很好。

6.4 给新手的三个建议

如果你刚开始接触 skills，我给你三个建议。第一，先从用别人的 skill 开始。官方市场里有很多高质量的 skill，先拿来用，感受一下 skill 能做什么。第二，从最简单的 skill 写起。不要一上来就写复杂的编排，先写一个只做一件事的 skill，跑通了再扩展。第三，不要追求完美。skill 是迭代出来的，第一版能用就行，后面根据实际使用情况慢慢优化。

我见过太多人卡在“想写一个完美的 skill”这一步，结果什么都没写出来。先写出来，再改好，这个顺序不能反。

6.5 后续可以扩展的方向

如果你已经能熟练写 skill 了，可以考虑几个进阶方向。一是skill 的自动化测试，写一套测试用例，每次修改 skill 后自动跑一遍，确保没有回归。二是skill 的版本发布，把你的 skill 打包分享给团队或社区，收集反馈持续改进。三是skill 与 CI/CD 的集成，让 skill 在代码提交、构建、部署等环节自动执行。

这些方向我自己也在探索中，有些已经跑通了，有些还在试验。等有成熟的经验了，再找机会分享。skills 这个生态还在快速演进，现在投入时间学习，后面应该会有不错的回报。