1. 从“skills”这个热词说起它到底是什么为什么突然火了如果你最近在开发者社区、技术群或者社交媒体上频繁刷到“skills”这个词大概率不是指传统意义上的“技能”泛称而是特指围绕Claude Code、Codex、Agents、Plugin这一整套生态里用来扩展 AI 编程助手能力的模块化能力包。简单说skills 就是给 AI 编程助手加装的“技能插件”——你给它一个封装好的 skill它就能按照预设的流程、规则和知识去完成某类特定任务比如写论文、做代码审查、生成前端组件、执行测试用例、甚至帮你处理安卓脱壳这类偏门需求。我最早接触这个概念是在 Claude Code 的生态里。当时社区里有人分享了一个“论文写作 skill”我抱着试试看的心态装上去结果发现它不只是给 AI 加了一段提示词而是把整个写作流程拆成了选题、文献检索、大纲生成、段落撰写、引用格式化、查重预检这几个阶段每个阶段都有对应的工具调用和校验逻辑。那一刻我才意识到skills 的本质不是提示词模板而是可复用、可组合、可版本管理的 AI 工作流封装。为什么它突然火了我的判断有三个原因。第一Claude Code 和 Codex 这类工具已经从“聊天式编程”进化到了“代理式编程”AI 不再只是回答问题而是能直接操作文件系统、执行命令、调用外部 API。这时候单纯靠一段提示词已经管不住它的行为了你需要更结构化的方式来约束和引导。第二社区发现 skills 可以像 npm 包一样分享和复用一个人写好的 skill别人下载下来就能用这大大降低了 AI 编程的入门门槛。第三企业开始意识到把内部的最佳实践封装成 skills可以让团队里的 AI 助手行为一致减少“同一个问题十个人问出十个不同结果”的混乱。所以如果你是一名开发者、技术博主、或者只是想让 AI 帮你干更多活的人理解 skills 的机制、学会安装和配置、知道去哪里找好用的 skills已经变成一项很实际的技能。这篇文章我会从零开始把 skills 的来龙去脉、安装配置、实操流程、常见坑点全部讲清楚尽量让你看完就能上手。2. skills 生态全景Claude Code、Codex、Agents 和 Plugin 的关系2.1 四个核心概念的分工与协作很多人一开始会被这几个词绕晕skills、Claude Code、Codex、Agents、Plugin它们到底谁是谁我用一个生活化的类比来解释。把 AI 编程助手想象成一家餐厅Claude Code 和 Codex 是餐厅的厨房和灶台它们提供了基础的烹饪能力——能切菜、能开火、能装盘。Agents 是厨师它决定今天做什么菜、按什么顺序做、遇到问题怎么调整。Plugin 是厨房里的专用工具比如一个自动切丝机、一个恒温炸锅它们扩展了厨房的硬件能力。而skills 是菜谱它告诉厨师做这道菜需要哪些工具、哪些食材、每一步怎么做、火候怎么控制。这个类比基本能解释它们的关系。Claude Code 和 Codex 是底层平台Agents 是执行主体Plugin 是能力扩展skills 是流程封装。在实际使用中你可能会看到“Claude Agent Skills”这种说法意思就是运行在 Claude 代理体系下的技能包。Codex 也有类似的 skills 机制只是实现细节和目录结构可能不同。这里需要特别说明的是skills 不是某个平台独有的。Claude Code 有 skillsCodex 有 skills甚至一些基于 LangChain 的 deep agents 也在引入类似的概念。它们的共同点是用结构化的方式描述一个任务流程让 AI 代理能够按照预期执行。区别在于不同平台对 skills 的加载方式、目录结构、元数据格式要求不一样。2.2 为什么是“模块化能力包”而不是“提示词”我刚开始也疑惑为什么不直接写一段长提示词非要搞个 skills 目录、放一堆文件后来踩了几次坑才明白提示词有几个致命问题。第一提示词没有版本管理。你今天改了一版明天想回滚只能靠记忆或者手动备份。skills 是一个目录天然可以用 Git 管理谁改了什么、什么时候改的一目了然。第二提示词无法携带资源文件。比如一个“前端组件生成 skill”它可能需要一套代码模板、一份样式规范、甚至几张设计稿截图。提示词里塞不下这些但 skills 目录里可以放templates/、assets/、references/这些子目录。第三提示词难以组合。你想让 AI 先做代码审查再做单元测试再做文档生成如果全写在一段提示词里会非常臃肿且容易冲突。skills 可以拆成三个独立的 skill按需加载、按序执行。所以skills 的设计哲学是“关注点分离”一个 skill 只做一件事做好一件事。需要多个能力时通过组合 skills 来实现。这种设计让整个系统更可维护、更可测试、也更可复用。2.3 当前主流的 skills 来源渠道目前找 skills 主要有几个渠道。第一是官方市场比如 Claude 官方提供的 skills 市场里面有一些官方维护的基础 skills质量比较有保障。第二是社区仓库GitHub 上有很多个人或团队开源的 skills 集合覆盖的场景非常广从写论文到安卓脱壳都有。第三是团队内部沉淀很多公司会把内部的代码规范、部署流程、测试标准封装成 skills供团队成员使用。第四是自己开发当你发现某个任务反复出现就可以把它固化成一个 skill。这里要提醒一句社区来源的 skills 一定要先审查再使用。因为 skills 可以包含可执行脚本、可以调用外部命令如果来源不可信可能存在安全风险。我个人的习惯是拿到一个 skill 先看它的目录结构重点看有没有scripts/目录、有没有执行 shell 命令的逻辑、有没有访问网络的行为。确认安全后再加载。3. 安装与配置实操从零把 skills 跑起来3.1 Claude Code 的安装与 skills 目录初始化先讲 Claude Code 的安装。不同操作系统的步骤略有差异但核心逻辑是一样的安装 CLI 工具、登录账号、初始化配置目录。在 Windows 上你可以通过官方提供的安装包或者包管理器来安装。安装完成后第一次运行claude命令会引导你登录。登录成功后它会在你的用户目录下创建一个配置文件夹通常是~/.claude/或者%USERPROFILE%\.claude\。skills 的存放位置一般是在配置目录下的skills/子目录。你可以手动创建也可以通过命令初始化。我建议手动创建因为这样你能清楚地知道每个文件是干什么的。一个典型的 skill 目录结构是这样的~/.claude/skills/ my-first-skill/ SKILL.md scripts/ helper.py templates/ component.tsx references/ style-guide.md其中SKILL.md是核心文件它用 Markdown 格式描述这个 skill 的名称、触发条件、执行步骤、依赖工具等信息。scripts/放可执行脚本templates/放代码或文档模板references/放参考知识。不是每个 skill 都需要所有这些目录按需创建即可。注意不同版本的 Claude Code 对 skills 目录的路径要求可能不同建议先查看官方文档确认当前版本的默认路径。如果你在 Windows 上使用 WSL路径会是 Linux 风格的不要混用。3.2 Codex 的安装与 skills 接入Codex 的安装流程和 Claude Code 类似但它的 skills 机制目前还在演进中。根据社区反馈Codex 对 skills 的支持更偏向于“配置文件 提示词片段”的组合。你可以在 Codex 的配置目录下创建一个skills文件夹然后在主配置文件里引用这些 skills。Codex 安装过程中常见的一个问题是“无法加载组织设置”。这个通常是因为账号权限或者网络配置导致的。我的经验是先确认你的账号是否属于某个组织如果属于检查组织是否限制了 Codex 的使用权限。如果提示“your organization has disabled claude subscription access for claude code”那说明组织层面关闭了访问需要联系管理员开通。另一个常见问题是“codex is ignoring 1 unrecognized configuration setting”。这通常是因为配置文件里有一个拼写错误或者不支持的配置项。Codex 会忽略它不认识的配置但会给出警告。排查方法是逐行检查配置文件对比官方文档的配置项列表把不支持的项删掉或者修正拼写。3.3 在 VS Code 和 IDEA 中配置 skills如果你习惯在 IDE 里工作VS Code 和 IDEA 都有对应的插件来集成 Claude Code 或 Codex。以 VS Code 为例安装官方插件后你可以在设置里指定 skills 目录的路径。插件会自动加载该目录下的所有 skills并在 AI 对话时根据上下文决定是否调用。IDEA 的配置稍微复杂一点。你需要在插件市场里找到对应的插件安装后进入设置页面找到“插件仓库地址”相关的配置项填入 skills 仓库的地址。有些团队会搭建内部的 skills 仓库这时候就需要把地址指向内部服务器。配置完成后重启 IDE插件会拉取 skills 列表并缓存到本地。提示在 IDE 里使用 skills 时建议把 skills 目录放在项目根目录下的.skills/文件夹里而不是全局配置目录。这样不同项目可以使用不同的 skills 集合避免互相干扰。3.4 本地模型接入的注意事项有些朋友想把 Claude Code 或 Codex 接到本地模型上比如通过 LM Studio 跑一个本地大模型然后让 Claude Code 调用它。这个思路可行但有几个坑要注意。第一本地模型的上下文长度通常比云端模型短如果 skill 的描述文件太长可能会被截断导致 skill 加载失败。第二本地模型的工具调用能力参差不齐有些模型能很好地执行 skill 里的步骤有些则会在中途“跑偏”。第三本地模型的响应速度受硬件限制如果 skill 里包含多轮工具调用整体耗时可能会很长。我的建议是如果你要用本地模型跑 skills先从最简单的 skill 开始测试比如一个只做文本格式化的 skill确认模型能正确执行后再逐步增加复杂度。同时把 skill 的SKILL.md写得尽量简洁把详细逻辑放到脚本里减少模型需要理解的文本量。4. 核心细节解析一个 skill 从设计到落地的完整过程4.1 SKILL.md 的编写规范与技巧SKILL.md是整个 skill 的灵魂。它需要回答几个问题这个 skill 叫什么什么时候触发执行哪些步骤需要哪些工具输出什么格式我见过很多写得不好的SKILL.md要么太笼统AI 不知道具体怎么做要么太琐碎AI 被细节淹没。一个好的SKILL.md应该像一份给新员工的 SOP清晰、具体、有边界。一个实用的结构是这样的# Skill: 前端组件生成 ## 触发条件 当用户要求生成一个 React 组件并且指定了组件名称和基本功能时触发。 ## 输入 - 组件名称必填 - 组件功能描述必填 - 样式要求可选默认使用 Tailwind CSS ## 执行步骤 1. 在 src/components/ 下创建组件文件文件名为组件名称的 PascalCase 形式。 2. 根据功能描述生成组件代码使用函数式组件和 TypeScript。 3. 如果指定了样式要求按照要求生成样式否则使用 Tailwind CSS 类名。 4. 生成对应的测试文件放在 src/components/__tests__/ 下。 5. 运行 npm run lint 检查代码规范如果有错误则自动修复。 ## 输出 - 组件文件路径 - 测试文件路径 - lint 检查结果 ## 依赖 - Node.js 环境 - 项目已安装 React、TypeScript、Tailwind CSS这个结构的好处是AI 能清楚地知道每一步做什么遇到不确定的情况也有默认行为。我实测下来这种写法比一段自由文本的提示词稳定得多。4.2 脚本与模板的配合方式skills 的强大之处在于它可以携带脚本和模板。脚本负责执行确定性强的操作比如文件读写、命令执行、数据转换模板负责提供结构化的输出格式比如代码骨架、文档框架。AI 负责的是“判断”和“填充”而不是“从零生成”。举个例子一个“论文写作 skill”可以包含一个references/目录里面放几篇高质量论文的结构分析一个templates/目录里面放摘要、引言、方法、实验、结论的模板一个scripts/目录里面放引用格式转换脚本、查重预检脚本。AI 在写作时先读取模板确定结构再参考 references 里的风格最后调用脚本做格式化和检查。这样产出的论文结构规范、引用准确、风格统一比纯靠 AI 自由发挥靠谱得多。注意脚本的权限要控制好。不要给 skill 里的脚本过高的系统权限尤其是从社区下载的 skill。我一般会把脚本放在沙箱环境里先跑一遍确认没有危险操作后再正式使用。4.3 触发条件的设置与优先级管理一个项目里可能同时存在多个 skillsAI 怎么知道该用哪个这就涉及到触发条件的设置。触发条件可以基于关键词、文件类型、用户意图、甚至当前工作目录。比如“前端组件生成 skill”的触发条件可以设置为“当用户提到 React 组件、Vue 组件、或者要求生成 UI 代码时”。而“论文写作 skill”的触发条件可以设置为“当用户提到论文、摘要、文献综述时”。如果多个 skills 的触发条件有重叠就需要设置优先级。优先级高的 skill 会先被考虑。我通常会把专用性强的 skill 优先级设高通用性强的设低。比如“安卓脱壳 skill”的优先级应该高于“通用代码分析 skill”因为前者更具体更适合处理特定任务。还有一个技巧是在SKILL.md里明确写出“不适用场景”。比如“前端组件生成 skill”可以写“不适用于生成后端 API 代码”。这样 AI 在判断时能更快排除不相关的 skill减少误触发。5. 实操过程从安装到跑通一个完整 skill5.1 环境准备与依赖检查在开始之前先确认你的环境满足基本要求。你需要一个可用的 Claude Code 或 Codex 安装一个代码编辑器VS Code 或 IDEA以及基本的命令行操作能力。如果你打算用本地模型还需要一个能跑模型的硬件环境比如一台有独立显卡的机器。依赖检查清单依赖项检查方法常见问题Claude Code CLI运行claude --version命令未找到说明没安装或没加入 PATHNode.js运行node --version版本过低建议 18 以上Git运行git --version未安装无法拉取社区 skills网络连接尝试访问官方文档网络不通无法下载 skills磁盘空间检查配置目录所在盘空间不足skills 加载失败这些检查看起来简单但我见过太多人卡在第一步。尤其是 Windows 用户PATH 配置经常出问题。如果你运行claude提示“不是内部或外部命令”先去检查环境变量。5.2 安装一个社区 skill 并验证假设我们要安装一个社区里比较受欢迎的“代码审查 skill”。第一步找到它的仓库地址通常是一个 GitHub 链接。第二步用git clone把它克隆到本地。第三步把克隆下来的目录复制到你的 skills 目录下。第四步检查SKILL.md的内容确认触发条件和执行步骤符合你的预期。第五步重启 Claude Code 或重新加载配置让 skill 生效。验证 skill 是否生效的方法很简单在 Claude Code 里输入一个应该触发该 skill 的请求比如“帮我审查一下这段代码”然后观察它的行为。如果它按照SKILL.md里定义的步骤执行说明 skill 加载成功。如果它还是用默认方式回答说明 skill 没有被识别需要检查目录路径和文件权限。提示有些 skill 需要在配置文件里显式启用不是放到目录下就自动生效。具体要看平台的文档。Claude Code 一般是自动加载Codex 可能需要手动引用。5.3 自己动手写一个最小可用 skill光用别人的 skill 还不够真正提升效率的是写自己的 skill。我建议从最小可用版本开始。比如你想让 AI 每次生成代码时都遵循团队的命名规范就可以写一个“命名规范检查 skill”。SKILL.md可以这样写# Skill: 命名规范检查 ## 触发条件 当用户要求生成或修改代码时触发。 ## 执行步骤 1. 检查变量名是否使用 camelCase。 2. 检查函数名是否使用 camelCase。 3. 检查类名是否使用 PascalCase。 4. 检查常量名是否使用 UPPER_SNAKE_CASE。 5. 如果发现不符合规范的命名自动修正并说明修改原因。 ## 输出 - 修正后的代码 - 修改说明列表把这个 skill 放到 skills 目录下重启工具然后让 AI 生成一段代码。如果它生成的代码命名符合规范并且在有不符合的地方主动修正说明 skill 生效了。这个 skill 虽然简单但能解决一个很实际的问题团队里每个人写代码风格不一致。5.4 调试与日志查看skill 不生效或者行为异常时第一步是看日志。Claude Code 和 Codex 通常会在配置目录下生成日志文件记录 skill 的加载情况和执行过程。日志里会显示哪些 skill 被加载了、哪些被跳过了、跳过原因是什么。常见的跳过原因包括文件格式错误、触发条件不匹配、依赖缺失。如果日志里没有足够的信息可以尝试手动触发。比如在对话里明确说“使用代码审查 skill 来审查这段代码”看看 AI 是否能正确调用。如果明确指定了还是不行那可能是 skill 本身有问题需要检查SKILL.md的语法和路径。另一个调试技巧是简化 skill。把SKILL.md里的步骤减到最少只保留最核心的一步看看能不能跑通。如果能跑通再逐步加回其他步骤定位是哪一步出了问题。6. 常见问题与排查技巧实录6.1 skill 加载失败的原因与解决方法skill 加载失败是最常见的问题表现是 AI 完全不按 skill 的逻辑执行。根据我的经验原因主要有这几类问题现象可能原因解决方法skill 完全不被识别目录路径错误确认 skills 目录在配置目录下且名称正确skill 被识别但不触发触发条件太窄放宽触发条件增加关键词skill 触发但执行中断依赖缺失检查脚本依赖的工具是否安装skill 执行结果不符合预期SKILL.md 描述模糊细化步骤增加示例多个 skill 冲突优先级未设置在配置里调整优先级顺序我遇到过一次很典型的情况一个 skill 在 macOS 上跑得好好的到了 Windows 上就失效了。排查后发现SKILL.md里写了一个 Unix 风格的路径/tmp/Windows 上没有这个路径脚本执行失败。后来改成用环境变量或者相对路径问题就解决了。所以写 skill 时尽量用跨平台的路径和命令避免绑定特定操作系统。6.2 网络与代理相关问题的处理在安装和更新 skills 时网络问题经常出现。比如从社区仓库克隆 skill 时连接超时或者从官方市场下载时速度很慢。这类问题的处理思路是先确认网络连通性再检查 DNS 解析最后考虑换一个网络环境或者使用镜像源。有些团队会搭建内部的 skills 镜像仓库把常用的社区 skills 同步到内网这样下载速度会快很多也更安全。如果你所在团队有这种基础设施优先使用内部仓库。如果没有可以考虑用一些公共的代码托管平台的镜像功能但要注意审查 skill 的内容安全性。注意不要随意从不明来源下载 skills尤其是包含可执行脚本的 skill。我一般只从官方市场或者信任的社区仓库下载下载后先审查再使用。6.3 版本兼容性与升级策略skills 生态还在快速演进不同版本的 Claude Code 或 Codex 对 skills 的支持程度可能不同。我遇到过升级 Claude Code 后之前能用的 skill 突然失效的情况。排查后发现新版本改变了 skills 目录的加载逻辑需要把 skill 迁移到新的路径下。为了避免这种问题我的策略是第一固定使用一个稳定的版本不盲目追新。第二在升级前先备份 skills 目录。第三升级后先在一个测试项目里验证常用 skills 是否正常确认无误后再在全量项目里使用。第四关注官方发布的变更日志了解 skills 机制的改动。6.4 性能优化与资源占用控制skills 多了之后可能会拖慢 AI 的响应速度。因为每次对话AI 都需要加载和判断所有 skills 的触发条件。如果 skills 数量超过几十个判断过程会明显变慢。我的优化方法是第一按项目组织 skills不同项目只加载相关的 skills。第二定期清理不再使用的 skills。第三把一些低频使用的 skills 设为手动触发而不是自动判断。第四优化SKILL.md的长度减少 AI 需要阅读的文本量。还有一个容易被忽略的点是脚本的执行效率。如果 skill 里的脚本执行很慢比如要遍历大量文件或者调用外部 API整体响应时间会很长。这时候可以考虑把脚本改成异步执行或者加缓存机制避免重复计算。7. 进阶玩法把 skills 组合成工作流7.1 多 skill 串联的执行逻辑单个 skill 解决单个问题多个 skill 串联就能解决复杂问题。比如一个完整的“新功能开发”工作流可以拆成需求分析 skill、代码生成 skill、代码审查 skill、测试生成 skill、文档生成 skill。当用户提出“帮我开发一个登录功能”时AI 依次调用这些 skills每个 skill 的输出作为下一个 skill 的输入。串联的关键是接口定义。每个 skill 的输出格式要明确下一个 skill 才能正确解析。比如代码生成 skill 输出的是文件路径和代码内容代码审查 skill 需要读取这些文件路径测试生成 skill 需要读取代码内容。如果格式不统一串联就会失败。我的做法是在SKILL.md里明确定义输入和输出的数据结构尽量用 JSON 或者 Markdown 表格这种结构化格式。7.2 条件分支与异常处理真实的工作流不是线性的经常需要根据情况走不同的分支。比如代码审查 skill 发现严重问题时应该跳过测试生成直接进入修复流程如果只是轻微问题可以继续生成测试最后一起修复。这种条件分支可以在SKILL.md里用简单的 if-else 逻辑描述也可以写一个调度脚本由脚本决定下一步调用哪个 skill。异常处理也很重要。如果某个 skill 执行失败比如脚本报错或者依赖缺失整个工作流应该怎么处理我的建议是在SKILL.md里定义失败后的行为是重试、跳过、还是终止并报告。对于关键步骤比如代码生成失败后应该终止并提示用户对于非关键步骤比如文档生成失败后可以跳过不影响主流程。7.3 团队协作中的 skills 管理在团队里使用 skills管理比个人使用复杂得多。你需要考虑谁有权添加和修改 skills如何保证 skills 的质量如何同步到所有成员的机器上我的经验是把 skills 仓库当成代码仓库来管理。用 Git 做版本控制每次修改都走 Pull Request 流程至少一个人审查后才能合并。定期发布版本成员通过更新仓库来获取最新 skills。另外建议给每个 skill 写一个简短的说明文档放在仓库的 README 里说明这个 skill 是干什么的、怎么用、有什么注意事项。这样新成员加入时能快速了解团队有哪些可用的 skills不用一个个去翻SKILL.md。8. 我踩过的坑与实操心得8.1 不要过度依赖自动触发刚开始用 skills 时我特别喜欢自动触发觉得这样最省事。但实际用下来发现自动触发经常误判。比如我在写文档时提到“组件”这个词结果触发了前端组件生成 skillAI 开始给我生成 React 代码完全跑偏了。后来我改成对于专用性强的 skill尽量用手动触发在对话里明确说“使用 XX skill”。虽然多打几个字但准确率高很多。8.2 SKILL.md 越短越好细节放脚本我早期写的SKILL.md特别长恨不得把每一步的每个细节都写进去。结果发现AI 读到后面就忘了前面执行时经常漏步骤。后来我学乖了SKILL.md只写核心流程和判断逻辑具体的操作细节放到脚本里。脚本是确定性的不会“忘记”也不会“理解偏差”。这样SKILL.md短了AI 的执行准确率反而提高了。8.3 定期清理和重构 skillsskills 用久了会积累一堆不再使用的。有些是当时为了解决某个临时问题写的问题解决后就没用了。有些是社区下载的用了一两次发现不合适。这些僵尸 skill 不仅占用空间还会拖慢 AI 的判断速度。我现在养成了一个习惯每个月花半小时清理一次 skills 目录把不再使用的删掉把功能重叠的合并把写得不好的重构。这个习惯让我的 skills 集合始终保持精简高效。8.4 社区 skill 要先审查再使用这一点怎么强调都不为过。我见过一个社区 skill里面包含一个脚本会在执行时把用户的代码上传到外部服务器。虽然作者可能没有恶意但这种行为本身就有风险。我的审查流程是先看目录结构有没有scripts/再看脚本内容有没有网络请求、文件删除、权限提升等敏感操作最后在沙箱环境里跑一遍观察它的行为。确认安全后才放到正式环境使用。8.5 记录每次失败的排查过程排查 skill 问题很耗时但每次排查都是一次学习。我现在会用一个简单的 Markdown 文件记录每次遇到的问题、排查思路、最终解决方法。比如“某年某月某日代码审查 skill 在 Windows 上失效原因是路径分隔符不兼容解决方法是用path.join替代字符串拼接”。这些记录后来成了我自己的“避坑手册”再遇到类似问题时翻一下就能找到答案不用从头排查。9. 关于 skills 的未来扩展方向9.1 从个人使用到团队资产skills 目前更多是个人在使用但我认为它的真正价值在团队层面。当团队把内部的代码规范、部署流程、测试标准、文档模板都封装成 skills新成员加入后只要装上这些 skillsAI 就能按照团队的标准来辅助工作。这比写一堆文档、开一堆培训会有效得多。而且skills 是可以版本化的团队的最佳实践可以持续迭代不会停留在某个过时的文档里。9.2 与 CI/CD 流程的结合另一个有潜力的方向是把 skills 接入 CI/CD 流程。比如在代码提交时自动触发代码审查 skill把审查结果作为评论发到 Pull Request 上在构建失败时自动触发日志分析 skill定位失败原因并给出修复建议。这样 skills 就不只是开发时的辅助工具而是整个研发流程的一部分。9.3 跨平台 skills 标准的形成目前 Claude Code、Codex 和其他平台的 skills 格式还不统一这给跨平台使用带来了麻烦。但我观察到社区已经在讨论制定一个通用的 skills 描述标准让同一个 skill 能在不同平台上运行。如果这个标准能落地skills 的生态会迎来一次爆发就像容器标准统一了应用部署一样。9.4 安全与权限体系的完善随着 skills 越来越强大安全问题也会越来越突出。一个恶意的 skill 可能删除文件、泄露代码、甚至控制整个开发环境。所以未来 skills 生态一定会引入更完善的权限体系比如 skill 需要声明它需要哪些权限用户在安装时确认授权运行时系统监控 skill 的行为发现异常立即阻断。这些机制目前还不成熟但方向是明确的。我个人在实际操作中的体会是skills 这个方向是对的它把 AI 编程从“碰运气”变成了“可工程化”。虽然现在还有很多不完善的地方比如格式不统一、调试工具少、安全机制弱但这些问题都会随着生态的发展逐步解决。对于开发者来说现在开始积累自己的 skills 库是一件长期有回报的事情。你写的每一个 skill都是在把你的经验和判断固化下来让 AI 帮你重复执行。用得越多省下的时间就越多。