1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词被单独拎出来当项目标题我其实愣了一下。这个词太泛了泛到放在任何技术语境里都能解释得通。但结合热搜词里反复出现的 Claude Code、Codex、agents、plugin 这几个词方向就清晰了——这里说的 skills不是泛指技能这个抽象概念而是指AI 编程助手生态里的技能扩展机制也就是让 Claude Code、Codex 这类命令行 AI 工具具备特定领域能力的可插拔模块。打个比方你就懂了。Claude Code 或者 Codex 本身像一个刚入职的聪明应届生通用能力强但你让它干具体活儿——比如按团队规范生成代码、调用某个内部 API、执行一套固定的部署流程——它就不一定知道该怎么做了。skills 就是给这个应届生发的岗位操作手册一本手册对应一类任务装上就能用不用重新训练模型。这个机制解决的核心痛点是大模型能力通用但不够专精而每个团队、每个人的工作流又高度个性化。你不可能为了让它懂你的项目规范去微调一个模型成本太高。skills 提供了一种轻量级的方案——用结构化的描述文件告诉 AI遇到这类任务时按这个流程、用这些工具、遵守这些约束来做。适合谁来了解这块内容三类人最需要一是已经在用 Claude Code 或 Codex 做日常开发的工程师想把自己的重复劳动自动化二是团队里负责搭建 AI 辅助开发流程的人需要把团队规范沉淀成可复用的技能包三是单纯对 agent 生态好奇、想搞清楚skills 和 plugin 到底啥区别的技术爱好者。不管你是哪类下面这些内容都能让你少走弯路。2. skills、plugin、agents 三个概念的真实边界很多人刚接触这套东西时最容易犯的错就是把 skills、plugin、agents 混为一谈觉得都是给 AI 加功能。实际上这三者在职责、加载方式、使用场景上差别很大搞混了会导致你选错扩展方式白费功夫。2.1 skills 是知识流程不是代码skills 的本质是一份结构化的指令文档。它通常包含几个部分这个技能叫什么、什么时候触发、执行步骤是什么、需要调用哪些工具、有哪些注意事项。它不包含可执行代码本身而是告诉 AI该怎么思考和行动。我自己的理解是skills 更像一份 SOP标准作业程序。比如你写一个生成数据库迁移脚本的 skill里面会写清楚先读现有的 schema 文件、对比目标变更、按项目命名规范生成迁移文件、最后跑一遍校验。AI 读到这份 skill 后就会按这个流程走而不是自由发挥。这种设计的好处是零代码门槛。你不需要会写插件、不需要懂 API只要能把一件事的步骤讲清楚就能做成 skill。坏处是它依赖模型的理解能力如果描述含糊AI 执行起来就会跑偏。2.2 plugin 是可执行扩展能力更硬plugin 就不一样了。它是真正意义上的代码扩展通常包含可执行逻辑、对外部系统的调用、甚至独立的 UI 组件。热搜词里出现的 idea 设置 plugin 中插件仓库地址、eclipse mybatisx plugin 这些说的都是传统 IDE 插件体系里的 plugin和 AI 生态里的 plugin 概念有重叠但不等同。在 AI 编程助手语境下plugin 一般指那些需要注册、需要权限、能主动执行操作的扩展。比如一个 plugin 可以让你在 Claude Code 里直接调用某个云服务的 API或者把生成的内容自动推送到某个平台。它比 skills 重但能力边界也更明确。2.3 agents 是能自主决策的执行体agents 是这三者里最重的概念。一个 agent 通常具备目标理解能力、任务拆解能力、工具调用能力、以及一定程度的自主决策能力。热搜词里的 langchain deep agents、agents anywhere 说的就是这个方向。agent 和 skill 的关系可以这样理解agent 是执行者skill 是它掌握的技能之一。一个 agent 可以加载多个 skills根据任务需要切换使用。而 plugin 更像是 agent 手里的工具是它完成任务时可以调用的外部能力。维度skillspluginagents本质结构化指令文档可执行代码扩展自主决策执行体门槛低会写流程即可中高需要编程高需要设计决策逻辑触发方式按任务描述匹配按注册事件调用按目标自主规划典型场景规范代码生成、固定流程调用外部 API、集成服务复杂多步任务自动化可复用性高跨项目通用中依赖具体环境低通常绑定特定场景搞清楚这个边界之后你在做扩展设计时就不会纠结了能用 skill 解决的别上 plugin能用 plugin 搞定的别硬套 agent。过度设计是这套生态里最常见的浪费。3. 一个 skill 从想法到落地的完整过程光讲概念没意思我拿一个真实场景走一遍给团队做一个按内部规范生成 React 组件的 skill。这个需求很典型几乎每个前端团队都有类似的规范沉淀诉求。3.1 先想清楚触发条件别急着写内容很多人一上来就开始写 skill 正文结果写了一大堆AI 却不知道该在什么时候用它。触发条件是 skill 的第一优先级它决定了这个技能会不会被正确调用。触发条件要写得具体。比如生成 React 组件这个描述就太宽泛AI 可能在你只是问React 组件怎么写的时候也触发。更好的写法是限定场景当用户要求新建一个符合团队规范的 React 函数组件文件时触发。我一般会列一个触发清单把该触发和不该触发的情况都写出来。比如该触发用户说帮我建个 Button 组件、新建一个表单组件文件不该触发用户只是问React 组件和 Vue 组件有啥区别、这个组件为什么报错这个清单不用写进 skill 文件里但你自己心里要有数因为它直接影响你后面正文的措辞。3.2 正文结构步骤、约束、示例三件套一个能稳定工作的 skill正文我建议按这个结构组织第一步是执行步骤。把整个任务拆成有序的动作。还是拿 React 组件举例确认组件名称和用途如果用户没说明主动询问检查项目里是否已有同名组件避免重复创建按团队规范生成文件包括文件头注释、import 顺序、组件结构生成对应的样式文件如果项目用 CSS Modules 或 styled-components生成基础的测试文件骨架输出文件路径清单方便用户确认第二步是硬性约束。这些是 AI 绝对不能违反的规则。比如组件必须用函数式写法、props 必须定义 TypeScript 类型、禁止使用 any、import 必须按第三方库、内部模块、相对路径三组排序。约束要写得斩钉截铁不要用建议尽量这种软词。第三步是正反示例。给一个符合规范的组件样例再给一个反面教材。这一步特别关键因为模型对示例的敏感度远高于对规则描述的理解。我实测下来带正反示例的 skill执行准确率比纯规则描述高出不少。3.3 写完先自测别直接扔给团队skill 写完不等于能用。我踩过的坑是自己觉得描述得很清楚结果 AI 执行时完全跑偏。所以一定要自测。自测方法很简单找几个典型的触发场景实际跑一遍看输出是否符合预期。重点看三个地方触发是否准确该触发的时候触发了没不该触发的时候有没有误触发步骤是否完整有没有漏掉某一步或者顺序乱了约束是否生效那些硬性规则有没有被遵守我一般会准备 5 到 8 个测试用例覆盖正常场景和边界场景。比如组件名重复、用户没给组件名、项目里同时存在多种组件写法等。跑完一轮基本就能发现描述里的模糊地带。提示自测时不要只看结果对不对还要看过程对不对。有时候结果碰巧对了但 AI 走的路径是错的换个场景就会出问题。4. 那些让我踩过坑的细节skills 这东西看着简单真用起来坑不少。我挑几个印象最深的说说都是实打实踩出来的。4.1 描述太长反而失效我一开始做 skill 的时候恨不得把所有细节都写进去一个 skill 文件写了上千行。结果发现 AI 执行时经常选择性失忆前面写的规则后面就忘了。后来我才明白skill 的有效性和长度不是正相关。模型处理长文本时注意力是会被稀释的。一个 skill 如果超过某个长度关键信息反而容易被淹没。我的经验是单个 skill 聚焦一件事正文控制在合理篇幅内。如果一件事确实复杂就拆成多个 skill让它们各司其职。比如生成组件和生成组件测试可以拆开而不是塞进一个 skill 里。4.2 约束要可验证别写写得好一点这是新手最容易犯的错。写约束时用了一堆主观词比如代码要优雅、命名要合理、注释要清晰。这些词对 AI 来说等于没说因为它不知道你的优雅标准是什么。正确的做法是把主观要求翻译成可验证的客观规则。比如命名要合理 → 组件名用 PascalCase文件名与组件名一致工具函数用 camelCase注释要清晰 → 每个导出的函数必须有 JSDoc 注释说明参数类型和返回值代码要优雅 → 单个函数不超过 50 行嵌套层级不超过 3 层这样 AI 执行起来才有明确的判断依据你验收的时候也有客观标准。4.3 skill 之间的冲突要提前排查当你装了好几个 skill 之后冲突就来了。比如你有一个生成组件的 skill 要求用函数式写法又有一个老代码维护的 skill 要求保持原有写法两个 skill 在同一个任务里被同时触发AI 就懵了。我的处理方式是给每个 skill 划定清晰的作用域并且在描述里写明本 skill 仅适用于新建文件场景或本 skill 仅用于维护 2023 年之前的历史代码。作用域不重叠冲突自然就少了。如果实在避不开重叠就在 skill 里加一条优先级说明比如当与其他 skill 冲突时以本 skill 的规范为准。但这招要慎用用多了会让整个 skill 体系变得难以维护。4.4 版本管理别偷懒skill 是会迭代的。团队规范变了、项目结构调了、发现描述有歧义了都得改。如果不做版本管理改着改着就乱了最后没人知道当前用的是哪个版本。我的做法很简单把 skill 文件纳入 Git 管理每次修改写清楚改了什么、为什么改。如果团队多人维护就加一个简单的 review 流程。别觉得这是小题大做skill 是团队资产不是个人草稿该有的管理一样不能少。5. 不同工具生态下的 skills 差异Claude Code、Codex、以及各种 agent 框架虽然都支持 skills 这个概念但具体实现和使用方式差别不小。搞清楚这些差异能帮你少走很多弯路。5.1 Claude Code 的 skills贴近工作流Claude Code 的 skills 设计偏向工作流增强。它更强调 skill 和日常开发动作的结合比如代码生成、重构、审查这些高频操作。热搜词里 claude code 使用、claude code 安装 出现频率很高说明这个生态的用户基数在快速增长。在 Claude Code 里用 skills我的体会是它更依赖上下文。同一个 skill在不同的项目、不同的对话历史下表现可能不一样。所以写 skill 时要把假设条件写清楚比如假设项目使用 TypeScript、假设已有 ESLint 配置。另外 Claude Code 的 skill 触发比较依赖自然语言描述这就要求你的触发条件写得足够精准。我一般会在 skill 开头用一句话概括适用场景让模型快速判断该不该用。5.2 Codex 的 skills偏工程化Codex 生态里的 skills 更偏工程化一些和代码库的结合更紧密。热搜词里 codex 安装教程、codex 接入 deepseek、codex 无法加载组织设置 这些反映出用户在使用过程中遇到的配置类问题比较多。在 Codex 里做 skill我建议多考虑和现有工程规范的对接。比如你的项目有特定的目录结构、构建流程、测试框架skill 里要把这些信息体现出来让 AI 生成的代码能直接融入现有工程而不是生成一堆需要手动调整的东西。Codex 的 skill 还有一个特点是对组织设置比较敏感。如果你在团队环境里用要注意 skill 的共享和权限问题避免出现我这边能用同事那边加载不了的情况。5.3 跨工具复用理想很丰满现实有折扣理论上一个写好的 skill 应该能在不同工具间复用。但实际用下来完全无缝复用基本做不到。不同工具对 skill 格式的支持、对触发条件的理解、对约束的执行力度都有差异。我的策略是核心逻辑复用适配层各写各的。比如生成组件这个 skill核心的步骤和约束是通用的但触发条件的措辞、示例的呈现方式针对不同工具做微调。这样既保证了 skill 的核心价值不丢失又能适配各工具的特性。如果你团队里同时用多个工具建议建一个 skill 仓库把通用部分和工具特定部分分开管理。通用部分改一次所有工具都能受益特定部分各自维护互不干扰。6. 把 skills 用出复利一些进阶思路skills 用熟了之后你会发现它的价值远不止省几次手动操作。用得好它能变成团队的知识沉淀载体和效率放大器。6.1 把隐性知识变成显性 skill每个团队都有一些老员工才知道的隐性知识。比如某个模块为什么不能用某个库、某个接口的调用有什么坑、某类需求的标准处理流程是什么。这些知识平时散落在聊天记录、口头传授、甚至某个人的脑子里。skills 提供了一个把这些隐性知识显性化的机会。你把它写成 skillAI 就能在合适的场景自动应用这些知识新人也能通过 skill 快速上手。这是 skills 最有价值的用法之一比单纯省时间意义大得多。我自己的做法是每次发现这个坑我又踩了一次或者这个流程我又解释了一遍就考虑把它做成 skill。日积月累团队的 skill 库就成了一个活的知识库。6.2 skill 的组合使用单个 skill 能力有限但多个 skill 组合起来能完成相当复杂的任务。比如你有生成组件、生成测试、生成文档三个 skill理论上可以让 AI 一次性完成一个完整的功能模块开发。不过组合使用要注意顺序和依赖。我的经验是先定义清楚 skill 之间的输入输出关系。比如生成测试的 skill 需要知道组件文件路径那它就应该在生成组件之后触发并且能读取到前一个 skill 的输出。这种组合目前还需要一些手动协调但随着 agent 能力增强未来应该会越来越自动化。现在先把单个 skill 做扎实组合的事水到渠成。6.3 定期清理和迭代skill 库和代码库一样会随着时间腐化。过时的规范、不再使用的流程、描述有歧义的条目都会拖累整个体系的效果。我建议每个季度做一次 skill 盘点哪些还在用、哪些已经废弃、哪些需要更新。废弃的及时归档别让它们继续占用触发机会。更新的及时同步别让 AI 按老规范干活。这个习惯看起来麻烦但坚持下来收益很大。一个精简、准确、持续更新的 skill 库比一个庞大但混乱的 skill 库有用得多。7. 关于 skills 的几个常见疑问最后集中回答几个我被问得最多的问题都是实际使用中绕不开的。skills 和 prompt 有什么区别prompt 是一次性的用完就没了skill 是可复用的写一次能反复用。prompt 针对具体任务skill 针对一类任务。你可以把 skill 理解成预置好的高质量 prompt 模板。不会写代码能做 skill 吗完全可以。skills 的核心是流程和规范不是代码。只要你能把一件事的步骤讲清楚就能做 skill。当然如果你懂代码能做的 skill 会更强大。skill 写得好不好怎么判断看三个指标触发准不准、执行稳不稳、结果对不对。三个都达标就是好 skill。有一个不达标就得回去改描述。团队用 skills怎么协作建议建一个共享仓库统一管理 skill 文件。每个人都可以提交新 skill 或改进现有 skill但要有简单的 review 机制避免质量参差不齐。skills 会不会让 AI 变得死板恰恰相反。好的 skill 是给 AI 提供参考框架而不是死命令。它让 AI 在特定场景下有章可循同时保留灵活处理的空间。关键看你怎么写——写得太死AI 就死板写得有弹性AI 就灵活。我在实际使用中最大的体会是skills 的价值不在于让 AI 替你干活而在于把你的经验固化下来让 AI 按你的方式干活。这个区别很微妙但决定了你是把 skills 当玩具还是当工具。前者图个新鲜后者才能真正产生复利。 
长河君 · 2026/10/31 5:36:28 · 阅读 1.2k AI编程助手技能扩展机制：skills、plugin与agents的边界与实践
1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词被单独拎出来当项目标题我其实愣了一下。这个词太泛了泛到放在任何技术语境里都能解释得通。但结合热搜词里反复出现的 Claude Code、Codex、agents、plugin 这几个词方向就清晰了——这里说的 skills不是泛指技能这个抽象概念而是指AI 编程助手生态里的技能扩展机制也就是让 Claude Code、Codex 这类命令行 AI 工具具备特定领域能力的可插拔模块。打个比方你就懂了。Claude Code 或者 Codex 本身像一个刚入职的聪明应届生通用能力强但你让它干具体活儿——比如按团队规范生成代码、调用某个内部 API、执行一套固定的部署流程——它就不一定知道该怎么做了。skills 就是给这个应届生发的岗位操作手册一本手册对应一类任务装上就能用不用重新训练模型。这个机制解决的核心痛点是大模型能力通用但不够专精而每个团队、每个人的工作流又高度个性化。你不可能为了让它懂你的项目规范去微调一个模型成本太高。skills 提供了一种轻量级的方案——用结构化的描述文件告诉 AI遇到这类任务时按这个流程、用这些工具、遵守这些约束来做。适合谁来了解这块内容三类人最需要一是已经在用 Claude Code 或 Codex 做日常开发的工程师想把自己的重复劳动自动化二是团队里负责搭建 AI 辅助开发流程的人需要把团队规范沉淀成可复用的技能包三是单纯对 agent 生态好奇、想搞清楚skills 和 plugin 到底啥区别的技术爱好者。不管你是哪类下面这些内容都能让你少走弯路。2. skills、plugin、agents 三个概念的真实边界很多人刚接触这套东西时最容易犯的错就是把 skills、plugin、agents 混为一谈觉得都是给 AI 加功能。实际上这三者在职责、加载方式、使用场景上差别很大搞混了会导致你选错扩展方式白费功夫。2.1 skills 是知识流程不是代码skills 的本质是一份结构化的指令文档。它通常包含几个部分这个技能叫什么、什么时候触发、执行步骤是什么、需要调用哪些工具、有哪些注意事项。它不包含可执行代码本身而是告诉 AI该怎么思考和行动。我自己的理解是skills 更像一份 SOP标准作业程序。比如你写一个生成数据库迁移脚本的 skill里面会写清楚先读现有的 schema 文件、对比目标变更、按项目命名规范生成迁移文件、最后跑一遍校验。AI 读到这份 skill 后就会按这个流程走而不是自由发挥。这种设计的好处是零代码门槛。你不需要会写插件、不需要懂 API只要能把一件事的步骤讲清楚就能做成 skill。坏处是它依赖模型的理解能力如果描述含糊AI 执行起来就会跑偏。2.2 plugin 是可执行扩展能力更硬plugin 就不一样了。它是真正意义上的代码扩展通常包含可执行逻辑、对外部系统的调用、甚至独立的 UI 组件。热搜词里出现的 idea 设置 plugin 中插件仓库地址、eclipse mybatisx plugin 这些说的都是传统 IDE 插件体系里的 plugin和 AI 生态里的 plugin 概念有重叠但不等同。在 AI 编程助手语境下plugin 一般指那些需要注册、需要权限、能主动执行操作的扩展。比如一个 plugin 可以让你在 Claude Code 里直接调用某个云服务的 API或者把生成的内容自动推送到某个平台。它比 skills 重但能力边界也更明确。2.3 agents 是能自主决策的执行体agents 是这三者里最重的概念。一个 agent 通常具备目标理解能力、任务拆解能力、工具调用能力、以及一定程度的自主决策能力。热搜词里的 langchain deep agents、agents anywhere 说的就是这个方向。agent 和 skill 的关系可以这样理解agent 是执行者skill 是它掌握的技能之一。一个 agent 可以加载多个 skills根据任务需要切换使用。而 plugin 更像是 agent 手里的工具是它完成任务时可以调用的外部能力。维度skillspluginagents本质结构化指令文档可执行代码扩展自主决策执行体门槛低会写流程即可中高需要编程高需要设计决策逻辑触发方式按任务描述匹配按注册事件调用按目标自主规划典型场景规范代码生成、固定流程调用外部 API、集成服务复杂多步任务自动化可复用性高跨项目通用中依赖具体环境低通常绑定特定场景搞清楚这个边界之后你在做扩展设计时就不会纠结了能用 skill 解决的别上 plugin能用 plugin 搞定的别硬套 agent。过度设计是这套生态里最常见的浪费。3. 一个 skill 从想法到落地的完整过程光讲概念没意思我拿一个真实场景走一遍给团队做一个按内部规范生成 React 组件的 skill。这个需求很典型几乎每个前端团队都有类似的规范沉淀诉求。3.1 先想清楚触发条件别急着写内容很多人一上来就开始写 skill 正文结果写了一大堆AI 却不知道该在什么时候用它。触发条件是 skill 的第一优先级它决定了这个技能会不会被正确调用。触发条件要写得具体。比如生成 React 组件这个描述就太宽泛AI 可能在你只是问React 组件怎么写的时候也触发。更好的写法是限定场景当用户要求新建一个符合团队规范的 React 函数组件文件时触发。我一般会列一个触发清单把该触发和不该触发的情况都写出来。比如该触发用户说帮我建个 Button 组件、新建一个表单组件文件不该触发用户只是问React 组件和 Vue 组件有啥区别、这个组件为什么报错这个清单不用写进 skill 文件里但你自己心里要有数因为它直接影响你后面正文的措辞。3.2 正文结构步骤、约束、示例三件套一个能稳定工作的 skill正文我建议按这个结构组织第一步是执行步骤。把整个任务拆成有序的动作。还是拿 React 组件举例确认组件名称和用途如果用户没说明主动询问检查项目里是否已有同名组件避免重复创建按团队规范生成文件包括文件头注释、import 顺序、组件结构生成对应的样式文件如果项目用 CSS Modules 或 styled-components生成基础的测试文件骨架输出文件路径清单方便用户确认第二步是硬性约束。这些是 AI 绝对不能违反的规则。比如组件必须用函数式写法、props 必须定义 TypeScript 类型、禁止使用 any、import 必须按第三方库、内部模块、相对路径三组排序。约束要写得斩钉截铁不要用建议尽量这种软词。第三步是正反示例。给一个符合规范的组件样例再给一个反面教材。这一步特别关键因为模型对示例的敏感度远高于对规则描述的理解。我实测下来带正反示例的 skill执行准确率比纯规则描述高出不少。3.3 写完先自测别直接扔给团队skill 写完不等于能用。我踩过的坑是自己觉得描述得很清楚结果 AI 执行时完全跑偏。所以一定要自测。自测方法很简单找几个典型的触发场景实际跑一遍看输出是否符合预期。重点看三个地方触发是否准确该触发的时候触发了没不该触发的时候有没有误触发步骤是否完整有没有漏掉某一步或者顺序乱了约束是否生效那些硬性规则有没有被遵守我一般会准备 5 到 8 个测试用例覆盖正常场景和边界场景。比如组件名重复、用户没给组件名、项目里同时存在多种组件写法等。跑完一轮基本就能发现描述里的模糊地带。提示自测时不要只看结果对不对还要看过程对不对。有时候结果碰巧对了但 AI 走的路径是错的换个场景就会出问题。4. 那些让我踩过坑的细节skills 这东西看着简单真用起来坑不少。我挑几个印象最深的说说都是实打实踩出来的。4.1 描述太长反而失效我一开始做 skill 的时候恨不得把所有细节都写进去一个 skill 文件写了上千行。结果发现 AI 执行时经常选择性失忆前面写的规则后面就忘了。后来我才明白skill 的有效性和长度不是正相关。模型处理长文本时注意力是会被稀释的。一个 skill 如果超过某个长度关键信息反而容易被淹没。我的经验是单个 skill 聚焦一件事正文控制在合理篇幅内。如果一件事确实复杂就拆成多个 skill让它们各司其职。比如生成组件和生成组件测试可以拆开而不是塞进一个 skill 里。4.2 约束要可验证别写写得好一点这是新手最容易犯的错。写约束时用了一堆主观词比如代码要优雅、命名要合理、注释要清晰。这些词对 AI 来说等于没说因为它不知道你的优雅标准是什么。正确的做法是把主观要求翻译成可验证的客观规则。比如命名要合理 → 组件名用 PascalCase文件名与组件名一致工具函数用 camelCase注释要清晰 → 每个导出的函数必须有 JSDoc 注释说明参数类型和返回值代码要优雅 → 单个函数不超过 50 行嵌套层级不超过 3 层这样 AI 执行起来才有明确的判断依据你验收的时候也有客观标准。4.3 skill 之间的冲突要提前排查当你装了好几个 skill 之后冲突就来了。比如你有一个生成组件的 skill 要求用函数式写法又有一个老代码维护的 skill 要求保持原有写法两个 skill 在同一个任务里被同时触发AI 就懵了。我的处理方式是给每个 skill 划定清晰的作用域并且在描述里写明本 skill 仅适用于新建文件场景或本 skill 仅用于维护 2023 年之前的历史代码。作用域不重叠冲突自然就少了。如果实在避不开重叠就在 skill 里加一条优先级说明比如当与其他 skill 冲突时以本 skill 的规范为准。但这招要慎用用多了会让整个 skill 体系变得难以维护。4.4 版本管理别偷懒skill 是会迭代的。团队规范变了、项目结构调了、发现描述有歧义了都得改。如果不做版本管理改着改着就乱了最后没人知道当前用的是哪个版本。我的做法很简单把 skill 文件纳入 Git 管理每次修改写清楚改了什么、为什么改。如果团队多人维护就加一个简单的 review 流程。别觉得这是小题大做skill 是团队资产不是个人草稿该有的管理一样不能少。5. 不同工具生态下的 skills 差异Claude Code、Codex、以及各种 agent 框架虽然都支持 skills 这个概念但具体实现和使用方式差别不小。搞清楚这些差异能帮你少走很多弯路。5.1 Claude Code 的 skills贴近工作流Claude Code 的 skills 设计偏向工作流增强。它更强调 skill 和日常开发动作的结合比如代码生成、重构、审查这些高频操作。热搜词里 claude code 使用、claude code 安装 出现频率很高说明这个生态的用户基数在快速增长。在 Claude Code 里用 skills我的体会是它更依赖上下文。同一个 skill在不同的项目、不同的对话历史下表现可能不一样。所以写 skill 时要把假设条件写清楚比如假设项目使用 TypeScript、假设已有 ESLint 配置。另外 Claude Code 的 skill 触发比较依赖自然语言描述这就要求你的触发条件写得足够精准。我一般会在 skill 开头用一句话概括适用场景让模型快速判断该不该用。5.2 Codex 的 skills偏工程化Codex 生态里的 skills 更偏工程化一些和代码库的结合更紧密。热搜词里 codex 安装教程、codex 接入 deepseek、codex 无法加载组织设置 这些反映出用户在使用过程中遇到的配置类问题比较多。在 Codex 里做 skill我建议多考虑和现有工程规范的对接。比如你的项目有特定的目录结构、构建流程、测试框架skill 里要把这些信息体现出来让 AI 生成的代码能直接融入现有工程而不是生成一堆需要手动调整的东西。Codex 的 skill 还有一个特点是对组织设置比较敏感。如果你在团队环境里用要注意 skill 的共享和权限问题避免出现我这边能用同事那边加载不了的情况。5.3 跨工具复用理想很丰满现实有折扣理论上一个写好的 skill 应该能在不同工具间复用。但实际用下来完全无缝复用基本做不到。不同工具对 skill 格式的支持、对触发条件的理解、对约束的执行力度都有差异。我的策略是核心逻辑复用适配层各写各的。比如生成组件这个 skill核心的步骤和约束是通用的但触发条件的措辞、示例的呈现方式针对不同工具做微调。这样既保证了 skill 的核心价值不丢失又能适配各工具的特性。如果你团队里同时用多个工具建议建一个 skill 仓库把通用部分和工具特定部分分开管理。通用部分改一次所有工具都能受益特定部分各自维护互不干扰。6. 把 skills 用出复利一些进阶思路skills 用熟了之后你会发现它的价值远不止省几次手动操作。用得好它能变成团队的知识沉淀载体和效率放大器。6.1 把隐性知识变成显性 skill每个团队都有一些老员工才知道的隐性知识。比如某个模块为什么不能用某个库、某个接口的调用有什么坑、某类需求的标准处理流程是什么。这些知识平时散落在聊天记录、口头传授、甚至某个人的脑子里。skills 提供了一个把这些隐性知识显性化的机会。你把它写成 skillAI 就能在合适的场景自动应用这些知识新人也能通过 skill 快速上手。这是 skills 最有价值的用法之一比单纯省时间意义大得多。我自己的做法是每次发现这个坑我又踩了一次或者这个流程我又解释了一遍就考虑把它做成 skill。日积月累团队的 skill 库就成了一个活的知识库。6.2 skill 的组合使用单个 skill 能力有限但多个 skill 组合起来能完成相当复杂的任务。比如你有生成组件、生成测试、生成文档三个 skill理论上可以让 AI 一次性完成一个完整的功能模块开发。不过组合使用要注意顺序和依赖。我的经验是先定义清楚 skill 之间的输入输出关系。比如生成测试的 skill 需要知道组件文件路径那它就应该在生成组件之后触发并且能读取到前一个 skill 的输出。这种组合目前还需要一些手动协调但随着 agent 能力增强未来应该会越来越自动化。现在先把单个 skill 做扎实组合的事水到渠成。6.3 定期清理和迭代skill 库和代码库一样会随着时间腐化。过时的规范、不再使用的流程、描述有歧义的条目都会拖累整个体系的效果。我建议每个季度做一次 skill 盘点哪些还在用、哪些已经废弃、哪些需要更新。废弃的及时归档别让它们继续占用触发机会。更新的及时同步别让 AI 按老规范干活。这个习惯看起来麻烦但坚持下来收益很大。一个精简、准确、持续更新的 skill 库比一个庞大但混乱的 skill 库有用得多。7. 关于 skills 的几个常见疑问最后集中回答几个我被问得最多的问题都是实际使用中绕不开的。skills 和 prompt 有什么区别prompt 是一次性的用完就没了skill 是可复用的写一次能反复用。prompt 针对具体任务skill 针对一类任务。你可以把 skill 理解成预置好的高质量 prompt 模板。不会写代码能做 skill 吗完全可以。skills 的核心是流程和规范不是代码。只要你能把一件事的步骤讲清楚就能做 skill。当然如果你懂代码能做的 skill 会更强大。skill 写得好不好怎么判断看三个指标触发准不准、执行稳不稳、结果对不对。三个都达标就是好 skill。有一个不达标就得回去改描述。团队用 skills怎么协作建议建一个共享仓库统一管理 skill 文件。每个人都可以提交新 skill 或改进现有 skill但要有简单的 review 机制避免质量参差不齐。skills 会不会让 AI 变得死板恰恰相反。好的 skill 是给 AI 提供参考框架而不是死命令。它让 AI 在特定场景下有章可循同时保留灵活处理的空间。关键看你怎么写——写得太死AI 就死板写得有弹性AI 就灵活。我在实际使用中最大的体会是skills 的价值不在于让 AI 替你干活而在于把你的经验固化下来让 AI 按你的方式干活。这个区别很微妙但决定了你是把 skills 当玩具还是当工具。前者图个新鲜后者才能真正产生复利。