如果你最近刷 GitHub、看技术推文一定绕不开一个词skills。尤其是 Anderj Karpathy 把 Agent Skills 这个概念推火之后Claude Code、Codex、OpenCode 这些主流 AI 编程工具几乎都在往这个方向靠拢。老实说我最早觉得 skills 就是“提示词套壳”直到自己拆了几套社区里的 skill 包、又动手写了几个之后才明白它解决的是大模型真正落地时最头疼的“怎么稳定复用经验”的问题。这篇东西不聊虚的直接讲清楚三件事skills 到底是什么、主流工具里长什么样、以及你怎么从零做出一个能用的 skill。我会把社区里传得很火的 Superpower Skills、Codex skills、Claude Code skills 这些概念都串进来也会给出可复现的目录结构和命令适合正在用 AI 编程、但还没搞懂 skills 该怎么沉淀和分类的开发者参考。1. 为什么“Skills”成了大模型应用的新关键词1.1 Karpathy和社区在讨论的“Skills”到底是什么先说结论skills 是给 AI 智能体准备的“可复用能力模块”。它不只是一段提示词也不只是工具的说明书而是把“模型在这个场景下应该怎么思考、按什么步骤执行、调用哪些工具、最终输出什么格式”这整条链路打包成的一个文件或一组文件。Andrej Karpathy 在多个场合聊过类似观点模型本身是“脑”但真正让模型高效工作的是那套外挂的“肌肉记忆”。你在对话里反复教 AI 怎么写某个项目的代码、怎么排查某个框架的问题其实存在大量重复劳动。skills 要解决的就是把这种反复出现的“经验”固化下来让模型下一次遇到同类任务时不需要再从零思考直接按照 skill 里定义的步骤和方法去做。社区里还有很多衍生概念比如 “Superpower Skills” 这类合集本质就是把几十个常见场景的 skill 文件打包到一起。安装之后你写前端、写脚本、做数据分析时模型会自动选择对应的 skill 来指导自己的行为。但这里有个容易混淆的点很多人以为 skill 就是一个 Markdown 说明文件告诉模型“你应该做 XX”。其实这只是最基础的形态。真正好用的 skill 会包含多个文件有描述任务场景的 prompt有写死的代码模板或脚本有校验输出的规则还可能自带依赖清单。它像一个微型项目而不是一段提示句。1.2 从Prompt到Skills的逻辑演进在 skills 概念火起来之前我们的做法是把经验写进系统提示词。比如你经常用 Cursor 或 Claude可能会在项目根目录放一个.cursorrules或者CLAUDE.md告诉 AI 这个项目的命名规范、代码风格、常用命令。这确实有效但也有几个问题。提示词越长模型丢失上下文的概率就越大。你把 50 条约束塞进系统提示词模型可能一开始记得聊到后边就忘了。而且提示词没有结构很难区分“全局规范”和“单任务专用指令”。更麻烦的是不同的任务可能需要不同的经验包但系统提示词只能做加法很难做动态加载。Skills 的思路是“按需挂载”。每个 skill 只在对应任务出现时才被激活。模型先判断当前任务属于哪个 skill 的适用范围再读取那个 skill 的详细内容。这样既不会把无关信息塞进上下文也能让单个 skill 写得足够详细、足够专注。你可以把它类比成人的工具箱。Prompt 是待在身上的便签写再多也只能是短句Skill 是抽屉里的一份完整作业指导书用的时候才拿出来翻。这就是为什么大模型应用的社区里越来越多团队开始从“写 Prompt”转向“沉淀 Skills”。1.3 Skills和插件、工具调用的边界很多人也会问skill 和 plugin插件、MCP、function calling 有什么区别这个问题不搞清楚后面设计自己的 skill 时会非常混乱。MCP 或 function calling 解决的是“模型怎么调用外部工具”的问题。它们提供接口、传输参数、返回结果是执行层。而 skill 更偏向“认知层”和“流程层”它告诉模型为什么要做这一步、按什么顺序做、做完后要输出什么。一个完整方案通常是这样的模型按照 skill 里定义的流程执行过程中需要查询数据库或调用 API 时再通过 MCP 或函数调用来完成。二者不是替代关系而是上下游关系。插件这个说法更泛不同产品里指的东西完全不一样。有些插件只是一层 API 封装有些插件本身也包含提示词。但在我看来skill 的关键特征是“可以被单独创建、单独安装、单独复用”而且它的主要载体是文件不是需要编译的代码。这就让 skill 的门槛比插件低得多也更容易在团队内通过 Git 来共享和迭代。2. 主流AI编程工具里的Skills落地形态2.1 Codex、Claude Code、OpenCode中的Skills包现在几乎每个主流 AI 编程工具都支持 skills但具体形态略有差异。以 OpenAI 系生态为例Codex 近期引入了比较灵活的 skills 机制允许你通过命令行安装社区发布的 skills。常见格式是仓库目录里放一个SKILL.md里面写清楚这个 skill 的适用场景、执行步骤、注意事项还可以在同一个目录下附带脚本或模板。Claude Code 则把自定义指令和技能都统一收敛到项目级配置里。社区里大量claude code skills其实是在.claude/skills目录下放一组结构化的 Markdown 文件。工具启动时会扫描这些文件并在合适的时机让模型参考对应内容。你看到的npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这类命令就是通过 npm 生态直接从 GitHub 仓库把一组 skill 文件安装到目标 agent 的配置目录里。OpenCode 是另一个很受极客欢迎的开源终端编程工具它的 skill 机制高度文件化用户可以在配置目录里手动创建 skill 文件夹。这种方式的好处是透明所有 skill 都是可读、可 diff、可篡改的纯文本团队审查起来非常方便。我自己的体会是不要太纠结于某个工具原生支持什么格式因为它们都在快速收敛。目前社区里已经出现了一些通用的 skills 仓库格式最核心的文件名基本就是SKILL.md再配合一个声明元数据的头部。学通了一套换个工具也就是路径和安装命令上有所差别。2.2 前端开发、通用编码场景的Skills推荐热词里反复出现“前端开发 skills”“coding skills github”说明这是需求量最大的场景。前端开发的痛点在于技术栈杂、构建工具多、UI 还原要求细。一个写得好的前端 skill至少应该包含项目技术栈判断、文件结构规范、组件写法约定、样式处理策略以及常见构建报错的排查路径。比如我见过一个社区里的“React 项目重构 skill”它要求模型先列出当前项目的 package.json、tsconfig、组件目录再决定是迁移到函数组件还是保持类组件。这个 skill 里甚至内置了一个 checklist一步步检查状态管理、异步请求、样式方案最后才输出改动的代码。比起直接跟模型说“帮我重构一下”这个 skill 的完成质量明显高出一截因为它把人的经验转化成了穷举式的检查动作。通用编码 skills 更推荐从“工作流”角度去选。比如 code review skills、单元测试生成 skills、git 提交信息规范 skills。这些场景本身有明确的标准很适合用 skill 来约束模型的输出。你未必需要一次性下载一个大而全的技能包刚开始用两三个覆盖高频场景的小 skill性价比最高。安装路径上最方便的还是通过 GitHub 搜索“awesome skills”或“agent skills”这类关键词找到维护较活跃的仓库然后复制对应的安装命令。不推荐把所有热门的 skills 一股脑装进环境里装得越多、激活冲突的概率越大反而会让模型不知道该听谁的。2.3 数学建模、文档写作等非编程场景怎么用Skills不要以为 skills 只能写代码。热词里出现了“数学建模 skills”“发明专利写作的 skills”这类需求说明很多非程序员也在用这个思路。数学建模的场景其实很适合 skill 化因为建模竞赛的流程高度固定理解问题、假设条件、建立模型、求解、灵敏度分析、写成论文。一个数学建模 skill 可以把这套流程拆成五个阶段每个阶段告诉模型该做什么、需要产出哪些内容、计算过程用什么工具验证。这样 AI 就能从“给你一段对话让你直接写模型”变成“先带你拆问题、定假设、再逐步建模型”的靠谱队友。文档写作类的 skill 更有意思。比如研究报告、产品说明书、专利交底书这类文本的结构和法规要求非常严格。一个写作 skill 可以先约束文章整体框架再分别规范各章节的用词、示例、引用格式。写专利相关的材料时还能把背景技术、发明内容、实施例的结构要求内置进去避免模型写出“看起来像论文但不符合专利格式”的内容。我自己用 UI/UX 相关的 skills 也踩过一些坑。社区里像 uiuxpromax 这类冲高点赞数的技能包下载量很大但不一定适配你的业务场景。最理想的做法是参考资料自己来改把它内置的提示模板当作起点再把你团队的设计规范、组件库文档、验收标准加进去变成自己的 skill。3. 从零开发一套自己的Skills3.1 Skills的标准文件结构与设计原则真正要开发一套自己的 skill先从最小结构做起。当前社区主流格式大致如下my-skill/ ├── SKILL.md ├── scripts/ │ ├── validate.py │ └── generate_report.py └── templates/ └── report_template.mdSKILL.md是整个 skill 的入口里面最好用 YAML frontmatter 写元数据然后是正文。一个典型的示例--- name: code-review description: 对当前代码变更执行一次结构化代码审查适用于 MR/PR 阶段 version: 1.0.0 license: MIT tools: - git - text-parser --- # Code Review Skill ## 适用场景 当用户要求“审查代码”“检查 MR/PR”“找出 bug 风险”时激活。 ## 执行步骤 1. 读取本次变更涉及的 diff 或文件列表 2. 按照以下维度检查 - 可读性命名、复杂度、注释必要性 - 边界条件空值、超时、并发等 - 错误处理是否吞异常 3. 输出审查结果表格式见 templates/review_result.md ## 注意 - 只关注真实问题不要为了凑数提出无意义建议 - 对高复杂度函数必须给出重构建议设计原则我只强调几条。第一description里一定要写清“何时激活”这是模型判断命中是否的关键。第二执行步骤一定要具体到可以执行的粒度宁可每一步很小也不要写“认真分析代码”这种废话。第三能外置脚本就外置脚本比如校验逻辑写在scripts/里skill 正文只负责告诉模型“什么时候去跑脚本、怎么解读脚本输出”。3.2 实现一个可复用的Skill从需求到输出下面用一个具体例子完整过一遍。假设你要做一个“批量提取前端组件并生成测试用例”的 skill。需求拆解模型需要对一个组件目录中的.tsx文件做静态分析提取 props、事件、渲染条件然后生成对应的测试骨架。如果把这个需求直接甩给模型它可能会凭“感觉”写测试覆盖率忽高忽低。所以 skill 要做的是把提取和分析方法固定下来。SKILL.md 部分内容--- name: react-component-test-gen description: 分析 React 组件文件并生成可运行的 Vitest 测试骨架。当用户指定组件路径或整个 components 目录时激活。 --- 1. 扫描 src/components 下所有 .tsx / .ts 文件 2. 对每个文件执行 a. 使用 grep 提取从 interface / type 导出的 Props 定义 b. 找 useState / useEffect 等 hooks记录状态与副作用 c. 找 onClick / onChange 等事件处理器记录绑定元素 3. 根据模板生成测试文件放到 __tests__/ 对应目录 4. 若缺少模板文件则调用 scripts/create_test_from_template.py 生成再配一个简单的 Python 脚本用来从组件源码里提取 props 列表并输出 JSON。这样模型在编码过程中可以实跑脚本而不是“猜”哪个 prop 是必填的。验证的时候我会故意选一个包含多个可选 prop、有复杂条件渲染的组件跑一次这个 skill。重点看模型有没有主动调用脚本有没有按照步骤先分析再生成。如果它跳过了某一步通常是因为 SKILL.md 里的 description 不够精准或者步骤顺序和模型的行为分布冲突。这时候就要回头改。3.3 安装、分发与npx命令行自己的 skill 写好后最直接的安装方式就是本地放置。以 Claude Code 为例放到.claude/skills/目录下重启会话就能被扫描到。Codex 和 OpenCode 也类似无非是目标目录名称不同。如果希望分发到团队或社区比较推荐的方式是推到 GitHub 仓库然后通过 npx 命令安装。社区里广泛传播的格式类似npx skills add owner/repo --agent claude-code -g -y这条命令做的事情其实是用npx下载一个安装脚本脚本读取 GitHub 仓库中的 skill 清单并把对应目录复制到本机的 agent 配置目录。-g是全局安装-y是跳过确认。由于 skill 本质是文件这种方式比传统插件系统轻量很多不需要注册 API key也不需要复杂的权限配置。但这里也有一个安全提醒不要盲目执行网上 copy 来的安装命令尤其是要求你加sudo或者自动修改 shell 配置文件的。安装前先打开仓库看一下要执行的install.sh或package.json脚本确认它只复制文件、不做什么奇怪的网络请求。用npx skills add如果指向的仓库是知名作者风险相对可控。想卸载 skill大多数工具就是直接删除对应目录没有锁文件也不涉及依赖树。这个特性对我来说是双刃剑——简单是真简单但团队协作时会遇到“一个人装了另一个人没装”的情况。所以涉及团队项目更建议把 skill 文件直接提交进项目仓库而不是每个人单独安装。4. Skills调试、避坑与进阶技巧4.1 调试Skills时的几个典型翻车现场第一个翻车现场是“description 写得太大而全”。比如你写“适用于任何编码任务”结果模型几乎在所有场景都尝试激活这个 skill导致其他更精准的 skill 被挤掉。这种情况在调试时会发现模型行为突然变得不稳定回答之前先绕进去一大堆用不上的流程。解决办法是收敛激活条件明确指定任务类型、输入文件格式、触发动词等。第二个翻车现场是“步骤描述和实际模型能力不匹配”。比如你让模型“运行 shell 命令”但当前 agent 并没有启用命令行工具这样 skill 会在第三步卡死。写 skill 时必须了解目标 agent 具备哪些工具权限。我见过有人在 skill 里写了一大串要调用的函数结果 agent 根本没装对应的 MCP server整个流程就断了。第三个典型问题是“输出格式没有强制校验”。模型即使读了 skill也可能因为上下文太长忘记了最终要输出表格漏掉了某个字段。强烈建议在 skill 里明确写“最终输出必须包含以下字段”的检查块甚至附一个脚本让模型自检格式。如果工具支持自定义命令还可以让模型输出前跑一遍脚本不通过就修正。调试时最有效的工具其实是自动化测试。准备几个代表性输入样本每次改完 SKILL.md 就重跑一遍对比输出结果和预期是否一致。这种测试很容易让整个团队都对“这个 skill 是有效的”这件事建立信心而不是靠“感觉这次回答还不错”。4.2 参数设计与上下文管理的几个心得skill 文件不宜过长。一个 skill 的 SKILL.md 最好控制在 150 行以内超出这个阈值模型读取和遵循的成本都会急剧上升。如果真的有非常多的细节拆成多个子 skill或者把细节放进模板文件里按需引用。参数的传递也要刻意设计。不要让模型自己决定“是否需要上下文里的所有信息”。好的 skill 会明确指出需要读哪些文件、忽略哪些目录、以哪个变量作为主要输入。比如做代码审查的 skill应该先在激活时输出一句“我将重点分析这几个文件的变更”再进行后续操作。这个显式声明可以让用户提前纠偏也让模型专注在目标文件上。上下文管理上有个很实用的技巧把重复出现的固定内容作为常量写死在 skill 里比如公司统一的 lint 规则、测试命名规范、文档头模板。这些东西没必要让模型去项目里搜索直接给出来最省 token。而经常变化的项目路径、分支名、依赖版本则写成需要模型动态识别的变量。4.3 让多个Skills协作的进阶思路单个 skill 能覆盖的场景终究有限。当你积累了一定数量之后就会自然地想让 skill 之间协作。这个方向目前社区还在早期探索但已经有相对有效的模式在 skill 的“参考其他 skill”字段里显式声明依赖。比如“技术方案设计 skill”会引用“代码架构 review skill”和“接口文档生成 skill”让模型在方案定稿前先自检再生成配套文档。另一种协作方式是“流程编排型 skill”。它本身不执行具体任务而是把多个 skill 按照一个工作流串起来。举例来说一个新的“功能开发全流程 skill”可能是先调用“技术方案设计 skill”确定思路后调用“编码实现 skill”完成后再调用“MR 描述生成 skill”。这很像我理解的 Agent Skills harness——一个用来承载和驱动多个技能包的运行框架。具体到实现就是在 SKILL.md 里把每一步明确写成“调用以下 skill名称 预期输出”并要求模型在切换时简要汇报上一环节的结论。这样既保持了连贯性又能在多个技能之间保留审计痕迹。我自己测试下来这种组合方式对“从需求到交付”的长链路任务特别有效因为它把每个阶段模型该做的事重新变回小步骤天然适合大模型一步步执行。如果你手里已经有三五个实战过的 skill完全可以试着写一个这样的编排型 skill那种“整个团队的经验都沉淀下来”的感觉是单纯积累知识点完全比不上的。最后分享一个小经验所有 skill 的迭代都要建立在真实需求之上。不要为了写一个“通用的超级 skill”而憋大招从日常工作中最重复、最容易被模型搞砸的小任务开始拆一个场景就固化一个。等你攒到十几个这种短小精悍的 skill再把它们串成流程那时候就会明显感觉到AI 编程这件事终于从“靠聊”变成了“靠体系”。