最近总有朋友在后台问我同一个问题现在大家都在说“skills”它跟写提示词到底有什么不一样为什么别人用 Clude Code、Codex 一套 skills 下来效率翻倍而我自己反复粘贴长提示词还是经常跑偏这个问题问得特别好。我大概从去年开始大规模接触 agent skills前后在项目里折腾过不少技能包也踩过不少坑。今天这篇文章就想把“skills”这件事从头到尾聊透它到底是什么主流的 Claude Code、Codex 里怎么用跟 MCP 工具怎么配合前端、测试、学术研究这些场景怎么落地以及最关键的——如何从零开发一个自己的 skills。这不是一篇概念科普更像是我个人项目实战经验的完整复盘。如果你已经在用 AI 编程工具但对 skills 还停留在“听说过、没用过”的状态这篇文章应该能帮你省下不少试错时间。1. Skills到底是什么从一段AI对话说起先说个具体场景。以前我让 AI 帮我改前端样式每次都要在对话里贴上一大段要求比如“你要按照 design tokens 来颜色用 CSS 变量间距偏好 8 的倍数不要用内联样式注释写中文”还要把项目规范文件一起贴进去。每次开新对话这套话术就得重新来一遍少贴一句AI 给出的代码风格就跑偏。Skills 解决的就是这个问题。1.1 我的第一个skills是怎么用的我第一次真正意识到 skills 的价值是在一个移动端 H5 项目里。那个项目的代码规范特别细光一个按钮组件就要求区分主按钮、次按钮、文字按钮、危险按钮四种状态每个状态的颜色、圆角、点击反馈都有严格定义。以前我靠复制粘贴规范来约束 AI后来有人提了一句“你可以把规范做成一个 skill”。于是我把这套按钮规范写进一个 skill 文件夹里包含一份说明文档和几个参考示例。之后每次让 AI 生成按钮相关代码它都会自动读取这份技能文档然后用项目内的写法来输出几乎不需要我再重复解释需求。那一刻我真正理解了 skills 的本质它不是某个工具的新功能而是一种把“可复用的专业能力”打包给 AI 的方式。就像一个团队里的老员工把从实践中沉淀下来的经验固化成 SOP新同事来了直接照着执行质量和效率都稳定。1.2 为什么skills比提示词更靠谱很多人会问我把同样内容放在提示词里不行吗答案是不行至少不稳定。提示词是对话级的内容你每次开新会话都要重新提供长度有限而且容易被上下文里的其他信息稀释当对话变得很长模型可能把早期指令忘得差不多。Skills 则是一种文件级的能力注入。它挂在项目目录或用户的全局配置目录下AI 模型会在合适的时候主动读取并执行。优点很明显可复用一次写好多个项目、多次会话都能用。可版本管理技能包随项目走改代码规范只要改 skill不用老人介绍累死。可组合复杂的技能可以拆成多个小技能按需调用。可分享Github 上有大量现成的 skills 仓库拿来即用。更本质的区别在于提示词是在“教”AI 一次性完成任务skills 是在“训练”AI 具备某种稳定的能力。前者依赖模型的临场理解后者依赖结构化的技能沉淀。2. 主流工具里的skills玩法目前市面上主流的 AI 编程工具基本都在往 skills 方向布局。大家的叫法、目录结构略有不同但核心理念一致。我实际用过比较多的是 Claude Code、Codex 和 Cursor下面分别说说我的使用感受。2.1 Claude Code的Skills规范Claude Code 的 skills 机制是这波浪潮里比较早而且规范的。它使用 SKILL.md 作为入口文件放在 .claude/skills 目录下每个技能一个独立文件夹。文件夹里除了 SKILL.md 之外还可以放参考代码、模板、工具脚本等附件。举个例子我在一个项目里放过名为frontend-styles的技能包目录结构大概长这样.claude/skills/frontend-styles/ ├── SKILL.md ├── design-tokens.json ├── button-variants.tsx └── form-input-styles.cssSKILL.md 的开头有 YAML frontmatter用来写技能的名称和描述。描述特别关键因为模型会通过这段描述判断“何时应该调用这个技能”。我一开始写得极其简短结果模型经常瞄不到这个技能。后来把描述改成带有触发场景的完整句子比如“当用户要求生成或修改 React 组件样式时优先查看此技能以复用设计令牌和按钮规范”调用率一下就上来了。在 Claude Code 的使用上官方文档给的建议是所有技能放项目级目录还是用户级目录要看作用范围。项目级目录适合跟大家共享的团队规范用户级目录适合个人常用操作比如我自己的 markdown 排版偏好就放在用户级。2.2 Codex、Cursor等工具里的skills生态Codex 这边的 skills 支持也比较成熟。热词里很多人搜“codex 常用 skills”“codex 分析项目的 skills”说明大家确实有需求。我常用的一个组合是“项目结构分析 测试生成 文档维护”把这三个技能放到 Codex 的技能目录下之后它能快速扫一遍项目结构然后按团队约定格式补测试和文档。Cursor 则更强调配置的轻量性。它没有强制要求某种目录日常使用中用规则文件或者项目说明文件也能达到类似效果。不过我在 Cursor 里依然会把 skills 目录搭起来因为换了新项目可以整体拷贝保持一致的工作流。还有一个值得关注的项目叫 opencode最近在社区里热度上升很快。它支持自定义 skill 的方式很灵活开发者可以灵活定义命令、提示词和工具调用的组合。如果你是个喜欢折腾工作流的玩家opencode 值得关注。而吴恩达在 agent skills 方向发布的教程也让我对技能工程有了更系统的理解。里面最核心的观点是不要指望把公司所有知识塞进一个巨大提示词里而是拆解成多个小技能让 agent 在合适的时机调用合适的技能。2.3 Skills怎么调用MCP工具热词里专门有人搜“skills如何调用 MCP 工具”这说明大家在实际用的时候容易卡在这一步。MCPModel Context Protocol 提供的是外部工具连接能力比如让 AI 能访问数据库、读本地文件、调用浏览器等。而 skills 提供的是任务执行方法和领域知识两者是互补关系。实际操作中技能描述里可以明确指出“在执行本任务时应调用 MCP 工具中的某某工具来完成数据获取”。比如我写过一个报告生成类的 skill它的 SKILL.md 里就写着第一步调用 MCP 的数据库工具拉取近 30 天订单数据第二步使用内置编程工具做聚合分析第三步按照 markdown 模板生成周报。AI 模型读到这份技能后会主动协调外部工具来完成整条链路。要注意的是skills 本身不直接管理 MCP 工具连接它的作用是告诉模型“这个任务应该用什么工具、什么顺序、什么格式来做”。所以如果你的 MCP 服务没配好skill 写得再好也会卡在第一步。排查时先确认工具连通性再怀疑技能配置。3. 实用场景案例拆解Skills 能用的场景远不止写代码。我最近的实践里前端还原设计稿、测试用例生成、数学建模和学术研究这四类场景效果提升是最明显的。逐个拆开讲讲。3.1 前端开发一分钟还原设计稿热词里有“图片还原设计稿给前端开发 好用的 skills”“web 前端 mcp skills”和“cursor 前端使用的 skills”说明前端领域确实是 skills 的主战场之一。我在这块折腾得也最多。有一个很典型的痛点设计师给了一张设计稿截图让我照着还原页面。传统做法是我自己看、自己量、自己写 CSS效率低还容易走样。后来我在项目里挂了一个“design-to-code”的 skill它内置了一套流程先调用图片分析能力提取设计稿的色值、间距、字体大小、布局结构再根据项目里已有的组件库模板映射成业务代码。第一次用的时候效果就超出了预期。导出的页面在色彩、圆角、阴影这些视觉细节上跟原稿的相似度非常高后续只需要手动调整一些响应式细节。可能有人会觉得这不就是“多模态提示”吗但 differences 就在于 skill 里面沉淀了公司组件库的使用规则AI 不会随机猜一个按钮样式而是去找项目里已有的 Button 组件来用。前端 skills 的另一个经典用途是结构图的生成。社区里流行的“结构图 skills”可以帮助 AI 从业务文档、代码逻辑中生成架构图、流程图、类图的源文件格式我再配合查看工具渲染比自己手动画高效得多。3.2 测试用例自动生成测试大概是除了前端之外我受益最多的场景。以前写测试用例尤其是覆盖边界条件时完全依赖个人经验和细心程度。线程多了、状态多了漏测是常态。后来我用了一个“测试用例生成”的 skill里面定义了用例编号规则、必填字段、边界值覆盖策略和可追踪性矩阵模板。用起来之后AI 会先分析目标函数的输入输出然后按照 skill 里的模板输出格式统一的用例表。对于接口测试还能直接生成可执行的测试脚本配合本地测试框架一键跑完。比如某个处理订单状态的函数skill 会主动补上“订单不存在”“金额为负数”“状态流转非法”这些我可能想不到的用例覆盖率明显上去了。这类技能比较好的做法是让 skill 同时包含正向、负向、边界、异常四类用例的模板模型才不会一股脑地写一堆重复的正常路径用例。3.3 数学建模与学术研究热词里“数学建模 skills 推荐”和“academic research skills”也很有意思可能很多人没想到 skills 在学术领域也能发力。我帮一个学弟看过数学建模比赛当时他用的是一个“建模思路生成”的 skill。这个技能里没有存什么答案而是存了常见建模方法的适用场景与判别条件什么时候用回归、什么时候用时间序列、什么时候用规划模型每种方法需要哪些数据、如何检验假设。AI 拿到赛题后会先按这个技能做方法选型再生成建模论文的骨架整个过程逻辑清晰不少。比较关键的是skill 可以有效地防止模型一上来就胡写神经网络。学术研究场景中my research skill 会在阅读文献时自动提取关键信息并在生成综述时明确区分作者观点与我的评价降低“事实幻觉”和“抄袭”风险。如果你经常写论文、整理资料这个领域非常值得投入精力做一套自己的学术工作流技能。4. 手把手开发一个自己的skills讨论完场景我猜不少人已经想自己试试了。其实开发自己的 skills 没有想象中复杂核心就三件事定目录、写文档、放示例。下面我把我的开发习惯完整分享出来。4.1 目录结构怎么设计以 Claude Code 为例技能包建议独立建文件夹文件夹名用短横线命名见名知意。结构上我习惯这么组织skills/my-skill-name/ ├── SKILL.md ├── references/ │ ├── example-1.md │ └── example-2.py └── assets/ └── templates/SKILL.md 是主文件写清楚技能用途、适用场景、执行步骤。references 放参考实现给模型提供“正确长什么样”的示例尤其是代码类技能参考代码比文字描述有用得多。assets/templates 放输出模板方便模型按统一格式产出。需要注意的一点是技能包最好不要塞大量项目专属内容。我在早期犯过的错误是把一个项目里遇到的所有细节都写进 skill结果换一个项目就不适用了。正确的做法是技能里沉淀通用方法和标准具体的项目配置交给项目上下文。4.2 SKILL.md怎么写SKILL.md 是整个技能包的核心。我推荐用这样的骨架--- name: my-skill-name description: 当用户需要XXX时使用此技能。典型场景包括A、B、C。 --- # 目标 清晰说明这个技能用来解决什么问题。 # 执行步骤 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 # 输入要求 需要哪些信息缺少时如何询问用户。 # 输出规范 输出的格式、结构、质量标准。 # 注意事项 哪些边界条件要处理哪些情况下不要使用本技能。描述里有个技巧不要只写“处理CSS相关任务”而要写“当用户要求调整页面样式、还原设计稿、或生成组件样式代码时使用此技能”。描述越具备触发条件模型就越容易在合适的时机调用它。执行步骤部分宁可多写几步也不要含糊。现在模型的理解能力已经不错但技能的本质是把隐性知识显性化步骤写得越具体输出就越稳定。另外我习惯在技术类技能里加上一条“禁止事项”比如“不要使用内联样式”“不要修改公共组件”模型一般会遵守得很到位。4.3 从提示词到技能的流程有一种更省力的开发方式先把一个你做过的、效果特别好的长提示词改造成技能包。我的经验是你日常用着顺手的长提示词往往已经包含了优秀的领域知识和约束条件。这些提示词有几个共同点结构清晰、含步骤、有格式要求、有质量底线。把这些内容迁移到 SKILL.md 里再补充几个输出示例很快就能得到一个可用的技能。具体流程我建议这样做挑一个你经常重复的提示词场景。把提示词里的固定部分提取出来作为技能的执行步骤。把提示词里的条件判断提炼成技能描述里的触发场景。找 2-3 个高质量输出作为 references 里的示例。在真实项目里测试根据效果迭代。这套方法特别适合非研发背景的人。不需要懂代码只要会整理自己的经验就能让 AI 变成你的“领域专属实习生”。5. 常见问题与踩坑实录跟任何新东西一样skills 的使用过程也不可能一帆风顺。这里集中回答一下我在实践中遇到过、以及群里朋友经常问的几个问题。5.1 技能不生效怎么办技能不生效是最常见的问题。通常我会按照这样的顺序排查先确认技能文件夹路径是否正确比如 Claude Code 项目级技能必须放在 .claude/skills 目录下然后确认 SKILL.md 里的描述是否包含触发条件如果描述写得太窄模型可能压根不觉得这技能跟当前任务有关再检查技能文件是否有语法错误比如 YAML frontmatter 是不是写崩了。还有一个很隐蔽的问题技能包里放了大量示例文件但 SKILL.md 没有明确告诉模型“何时应该查看哪些 references”。模型为了节约上下文默认情况下不会主动翻遍所有附件。所以一定要在 SKILL.md 的执行步骤里明确说“在步骤1完成后请阅读 references 里的 button-variants.tsx作为组件写法的参考”。5.2 搜索获不到内容另一个高频问题是当技能依赖外部资料时如说明要搜索网页但模型并没有真正去搜索。这时候要检查两点第一MCP 服务是否配置并且当前会话可用第二技能描述中是否写得足够明确。模型不会因为你说“需要时可以上网查”就真的去查它需要更明确的指令比如“第一步调用 web-search 工具搜索关键词‘最新 React 19 特性’然后从搜索结果中提取官方文档链接逐一打开并阅读”。技能的执行步骤写得越明确模型调用外部工具的概率就越高。如果有人提到“claude code 网页查资料的 skills”通常就是通过这种方式实现的。5.3 什么时候别用skills很多人以为 skills 是万能的但实际上有些场景用 skills 反而会帮倒忙。比如高度一次性、不具备复用价值的任务就不必专门建技能。像是“帮我把这个文件里的TODO注释删掉”这种操作直接在对话里交代就好。又比如需要强实时信息的任务如果技能里的参考资料已经过时模型反而可能拿它当权威而输出错误的信息。再比如涉及安全边界很强的操作像是删库、执行高风险命令等建议始终人工确认不要把一个“自动执行删除”的技能交给 AI 全程托管。所以我现在的原则是如果一个任务我一周至少做两次且每次的要求基本一致才值得做成技能。否则先保持“提示词 手动确认”的方式是最稳妥的。我在实际折腾技能的过程中最大的体会是真正花时间的其实不是写 SKILL.md而是沉淀和梳理自己平时的工作方法。就像老工程师脑子里那些说不清楚的“经验”一旦能结构化地交给 AI它的生产力会远超你的预期。另一个小技巧是每个技能建立后都给自己留一个版本号改过就加一方便对照哪次改动导致效果变化。这个习惯帮我避免了很多次“明明没变怎么效果差了”的困惑。希望这些经验对你也有帮助欢迎在评论区分享你自己的技能实践。