最近一两个月我身边几乎所有在用 AI 编程助手的同事都不约而同地在折腾同一个东西skills。一开始我以为又是什么新的提示词技巧结果研究了一圈才发现这玩意儿正在悄悄改变我们使用 AI 的方式——过去你每次都要反复交代背景、规则、偏好现在只需要说一句“用 XXX skill 处理”AI 就知道该按什么流程、调什么工具、输出什么格式。这篇文章我就结合自己这段时间的实测把这个“skills”到底是什么、怎么用、怎么自己开发一套一次讲透。文章不会太长篇大论讲概念重点放在怎么上手、怎么避坑以及不同工具Claude Code、Codex、Cursor 这些之间用起来到底差在哪。1. Skills 机制的本质解构从“一次性提示词”到“可复用能力包”1.1 Skill 到底是什么它和普通 Prompt 的区别在哪很多第一次接触 skills 的人第一反应是这不就是高级一点的 Prompt 吗我第一次看到 skill 文件的时候也这么觉得——里面写的确实是给模型看的指令、步骤、示例。但真正用下来你会发现Skills 和 Prompt 有本质区别它是“一套完整的、带固定入口和路由机制的能力模块”。打个比方普通 Prompt 就像你每次去餐厅都要跟服务员把忌口、口味、分量从头到尾说一遍Skills 则像你干脆办了一张会员卡你的偏好和套餐组合全记在卡里了服务员一刷卡就知道怎么给你配餐。Skills 把“怎么干一件事的方法论”封装成了文件AI 在碰到对应任务时会主动去读这个文件然后按里面定义的工作流来执行。我在项目里做得最多的事情是让 Claude Code 根据设计稿还原前端页面。以前每次都得在对话里贴一大堆约束条件设计稿在哪个路径、组件用什么方案、样式怎么组织、兼容性要到什么程度。后来我把这套流程写进了一个 skill放在项目的.claude/skills/design-to-code/目录下接下来只需要跟 AI 说“用 design-to-code 处理一下这个 Figma 链接里的页面”它就会自动去加载 skill 里定义好的步骤、工具调用规则和技术规范输出质量明显比“临场交代”稳定得多。这种体验上的差别背后其实是 skill 文件里藏了一个东西入口路由规则。AI 不是傻乎乎地每次都读所有 skill而是根据任务内容自动判断应该激活哪个。这个机制直接决定了 skills 可以做到“量大不乱”——哪怕你的技能库里有几十个 skillAI 也只会精准加载跟当前任务相关的那一个。1.2 Skills 与 MCP、Agent、目录结构之间的关系聊 skills 就绕不开 MCPModel Context Protocol因为这是它在工具调用层面的基础设施。Skill 解决的是“怎么做”的方法论问题MCP 解决的是“用什么工具去做”的能力接口问题。最直观的理解方式是这样MCP 服务就像你给 AI 接上了各种外部设备查数据库的、操作浏览器的、访问文件系统的而 skill 则是一份“操作手册”——它告诉 AI 遇到什么场景该用哪个设备、按什么顺序操作、操作完怎么检查结果。我自己实际开发的流程里经常是两者一起用。比如我有个拉取网页资料做调研的 skill里面就配好了让 AI 调用一个专门做网页抓取的 MCP 工具。skill 文件里会写清楚“遇到需要获取实时网页内容的任务使用 MCP 的 web_fetch 工具”AI 读到以后就会自己发工具请求整个过程不需要我手动指定 MCP。再说 Agent 的关系。Skills 并不等于 Agent更像 Agent 的“能力插件包”。现在很多工具提供了 Agent 模式让 AI 自主规划、自主执行但很多 Agent 跑到一半会“飘”因为缺少约束。Skill 就是在 Agent 运行过程中提供约束和行为框架的东西——它定义了任务在什么时候算完成、中途遇到分支该怎么决策、最终输出要符合什么规范。所以好的做法永远是“Agent Skills”组合而不是单纯依赖 Agent 自己发挥。还有一个非常容易被忽略的东西skills 在项目里的目录结构。通常不同的 AI 工具会约定不同的加载位置比如 Claude Code 默认是.claude/skills/有的工具则放在.cursor/skills/或者独立配置目录里。写 skill 的时候不光要把文件写对还得放对地方否则工具根本不会识别。2. 核心使用场景与 Skills 调用原理拆解2.1 主流的 Skill 文件格式与 Writing 规范现在业界对 skill 文件格式基本形成了一个默认标准就是 markdown。文件命名统一叫SKILL.md放在以 skill 名称命名的目录下。这个文件里面包含两大部分YAML 格式的 frontmatter元信息以及 markdown 格式的主体执行指南。frontmatter 部分最关键的是name和description。name是 skill 的唯一标识description是入口路由的关键——模型会根据 description 描述的内容来判断当前任务是否跟这个 skill 相关。这一点特别重要description 写得好不好直接决定了 skill 能不能被 AI“自动想起来”。我在调试 skill 的时候发现如果 description 写得太泛比如“处理前端开发任务”AI 就很容易绕开它但如果写得太细比如“仅适用于 Ant Design Pro 项目的 Table 组件页面还原”AI 的匹配又会太窄。写 description 是个需要反复调优的活儿需要在通用性和专一性之间找平衡。主体部分就是给 AI 看的行为指南。我在参考 baoyu 那套 skills 框架以及官方文档之后总结了一个非常实用的写法先给“任务定义”再列“执行步骤”然后补“约束规则”最后放“输入输出示例”。顺序不要乱。AI 是顺序敏感型的越靠前的内容优先级越高所以关键任务目标和禁止事项要放在最前面示例放在最后作为输出格式参考。2.2 不同工具Claude Code、Codex、Cursor调用 Skills 的差异现在市面上支持 skills 工具逐渐多了起来但各家实现思路还有不小差别。我把自己的实测体验列一下方便大家选型参考。Claude Code支持度最完整可以直接把 SKILL.md 放进.claude/skills/目录使用。它有两种触发方式自动触发根据任务语义和显式触发在对话里直接写“使用某 skill”。Claude Code 还允许在 skill 里通过allowed-tools字段限制 AI 能调用的工具安全边界做得很清晰。CodexOpenAI 的方案目前更偏向在对话里把 skill 作为附加上下文传入无论你是通过 CLI 还是 IDE 插件使用主要是以“注入 prompt 压缩包”的形式工作自动路由的感知能力相对弱一些。如果想把 skill 作为独立能力模块用需要在命令行里带上指定参数或者通过配置文件定义好。Cursor主要走“规则 指令”路线它把类似能力挂在了项目规则文件和自定义指令下面而不是完整的 skill 模式。好处是触发直接坏处是缺少自动定位和条件逻辑复杂一点的场景就得靠多条规则组合。我自己主力使用的组合是 Claude Code 做复杂任务因为它的 skill 路由能力最成熟Codex 做代码生成和补全类工作。如果你只想在 Cursor 里体验 skills 的能力可以把 SKILL.md 内容改写成它的 rule 文件也能达到七八成效果只是少了一些自动化逻辑。2.3 Skills 的上下文压缩机制与 token 成本优势很多人担心一个问题如果项目里装了二十个 skill每次对话是不是都要把所有 skill 内容读一遍那 token 消耗不得爆炸实测下来这个担心是多余的。现代 AI 工具在处理 skills 时做了优化一般不会把全部 skill 内容直接灌进上下文窗口而是先读所有 skill 的“元信息层”也就是 frontmatter根据任务语义做相关性排序只把命中的 skill 完整加载。这个机制跟“搜索引擎先看索引再拉取正文”的思路很像。所以即使你装了一大堆 skill只要 description 写得准确最后进入上下文的通常只有一两个相关文件。不过这里也有个隐蔽的坑如果你在同一个项目里放了多个描述特别相似的 skillAI 在做相关性排序时可能会把不该加载的那个拉进来。我踩过一次项目里有“vue page builder”和“vue component generator”两个 skill描述里都提到了“创建 vue 页面组件”结果 AI 总是搞混每次都得靠我显式指定。后来我把两个 skill 的边界描述彻底改清楚一个专注整页搭建一个专注单组件生成情况才好转。所以设计 skills 库时克制很重要——每个 skill 需要有独特定位别做一堆功能重叠的东西。3. 从零开发一套能被 AI 真正“用起来”的 Skill3.1 确定边界与设计入口描述最容易被忽视的环节我看过不少开发者的 skill代码逻辑写得头头是道还配了脚本但实际用的时候 AI 就是不触发。排查到最后发现问题几乎都出在入口描述上。所以我想先说说怎么把 description 写好。写 description 有一个非常实用的句式结构触发场景 任务对象 预期输出。举个例子我写过一个“图片还原设计稿”的 skill一开始的 description 写的是“将图片转换为前端代码”结果 AI 触发率不到三成。后来改成了“当用户提供 UI 设计图或高保真原型图片需要还原成可运行的响应式 HTML/CSS 页面时使用此技能输出包含完整样式的单页实现”。改完之后触发率明显提升原因就是 AI 能明确识别到“什么时候该用”。边界也很重要。skill 不需要把所有相关任务都包进去反而要在 description 和正文中写清楚“什么情况下不要用”。我会刻意加上一句“如果输入不包含图片或设计稿请勿使用此技能。”这样可以避免 AI 误触发。很多开发者不敢写这种限制语句担心影响匹配但实测下来好处大于坏处——因为误触发带来的纠错成本远高于偶尔漏触发。3.2 SKILL.md 的正文结构步骤、约束、示例三段式写法在正文部分我强烈建议按下面三层来组织。第一层是执行步骤。这里不要写“高质量地完成前端开发”这种废话要写可执行、可检查的具体步骤。以“图片还原设计稿”为例我会写成分析图片中的布局结构和组件层级输出 HTML 骨架按设计规范补齐 CSS 样式检查响应式断点和移动端适配输出最终代码和实现说明。每一步都是一个可验证的动作AI 在执行过程中能自己检查“这一步是否完成了”。第二层是约束规则。要明确告诉 AI 哪些能做、哪些不能做。比如“不得使用外部图片链接所有图标使用内联 SVG”“样式类名遵循 BEM 命名规范”“不得依赖任何 UI 框架使用纯 CSS 实现”。约束规则写得越具体AI 的输出就越稳定。如果让 AI 自由发挥很可能每次生成出来的风格都不一样。第三层是输入输出示例。这里不是说给 AI 看一段代码就够了而是要给“完整链路”的示例——输入长什么样处理流程怎样输出长什么样。尤其是 output 示例AI 会非常严格地模仿结构。我通常会放两到三个示例覆盖从简单到复杂的场景确保 AI 有足够多的“模板记忆”可用。3.3 如何给 Skill 挂载脚本、工具和 MCP 服务如果你的 skill 不只是“教 AI 生成文本”这么简单而是需要实际操作那你得学会给 skill 挂载脚本和工具。在 Claude Code 中skill 可以声明一个allowed-tools列表只有列表内的工具才允许被调用。这个设计很实用既安全又清晰。比如我做过一个“批量图片压缩”的 skill里面就只允许调 bash 工具来运行 ImageMagick 命令不允许调用网络类的 MCP 工具避免 AI 瞎折腾。如果想要让 skill 能调用 MCP 工具做法是在 SKILL.md 正文中用非常明确的指令告诉 AI“这个工具叫什么、在什么情况下调用、调用时会传入什么参数”。因为 AI 本身不知道 MCP 工具的参数接口skill 要充当中间说明书。我写过最简单的例子是这样的正文里写明“当流程进入第三步时若需要获取实时网页内容调用 mcp__web-fetch 工具参数 url 为目标网页地址”。AI 读到这段就知道该发什么。实际项目里更平滑的做法是把脚本固化下来。比如一个 skill 每次都依赖一个 python 脚本做数据分析我就把脚本直接放在 skill 目录的scripts/子目录里然后在 SKILL.md 中明确写明“使用python scripts/analyze.py 输入文件命令执行分析”。这样 skill 就真的成了一个自包含能力包丢到任何项目里都能用。3.4 开发流程完整复盘从测试到迭代开发 skill 不是一次写文件就完事的真实过程至少需要三轮迭代。第一轮先用最简单的场景测试 skill 是否被触发。我会手动构造一个输入然后观察 AI 的思考过程有没有读到 skill 文件读到了哪个部分的指令如果没触发回去改 description。第二轮测试执行效果。让 skill 完成一个中等复杂的任务检查流程是否完备、输出格式是否符合预期。这一轮通常会发现很多问题比如步骤顺序不合理、某个环节缺少工具调用说明、约束没有生效等。第三轮边界和异常处理测试。故意给一些超出设计范围的输入看 AI 能否正确拒绝或提示而不是硬着头皮执行。skill 里没有写“任务不明确时先向用户确认”的话AI 就可能自己瞎猜最后输出完全跑偏的东西。所以我每条 skill 里都会加一条兜底规则“如果输入缺少关键信息须先向用户提问不得擅自假设。”我在一次迭代里还发现skill 正文里如果出现太多“可选”“可以尝试”这种模棱两可的表述AI 就会选择偷懒走捷径。后来我要求自己用“必须”“不得”这类词来写关键节点AI 的输出稳定性提高了不少。所以写 skill 的时候语气该强硬的就要强硬这不是给人看的文档而是给模型下指令。4. 实战案例拆解两个高频场景的 Skill 完整实现4.1 前端开发图片还原设计稿 Skill 的实现细节这个 skill 是我用得最顺手的一个完整拆解一遍大家可以直接复制这套思路去做自己的版本。skill 文件放在.claude/skills/design-to-code/SKILL.mdfrontmatter 大概长这样--- name: design-to-code description: 当用户提供 UI 设计图或高保真原型图片需要还原为可运行的 HTML/CSS 页面时使用。输入需包含图片路径或图片内容。 allowed-tools: - bash - read - write - glob ---正文部分我按照步骤、约束、示例三层来写。步骤大概是先识别图片的整体布局和组件构成然后输出 HTML 文件接着写 CSS最后做响应式和细节检查。约束里我写明了不得使用外部图片链接、必须使用语义化标签、样式要符合设计稿的间距和颜色还有一条比较个性化——字体大小要用 rem 而不是 px这样移动端适配会方便很多。这里有个细节值得提一下我觉得“输出 HTML 文件”和“把 HTML 内容直接贴在对话里”是两种不同的执行路径。我在 skill 里明确写了“生成完整 HTML 文件并按用户指定的项目路径保存”因为很多时候我们需要的不是一段聊天里的代码而是一个能直接运行的文件。把这个写清楚AI 就会主动创建文件而不是在对话里吐一大段代码。用完这个 skill 之后我的日常工作流变成了设计师给我一张设计稿图片 → 我把图片扔进项目 → 跟 AI 说“用 design-to-code 处理” → 不到一分钟就得到一个可运行的静态页面。虽然复杂交互逻辑还得自己写但纯静态还原这块效率提升了大概三四倍。4.2 调研分析让 AI 按结构化流程抓取网页并输出报告第二个案例是做调研分析的 skill。写这类 skill 有一个核心难点AI 的即时知识是有限的它需要自己去找实时资料但找资料和整理资料是两个逻辑混在一起容易乱。我的调研 skill 把流程拆成了四步确认调研问题和范围 → 调用网页抓取工具收集至少三个独立来源 → 对比验证信息一致性 → 按固定结构输出报告。在正文里我会明确告诉 AI如果收集到的信息有冲突要在报告里直接标注“信息来源存在不一致”而不是自作主张选一个可信的。这个 skill 里最大的亮点是输出模板。我定义了一套固定的报告结构结论摘要、事实清单、关键数据、信息来源、补充说明。有了这套模板AI 每次输出的调研报告都是同一格式后续对比、归档都很方便。我甚至会把输出格式用代码块示例写出来AI 会精准照着格式来。做这类 skill 时对 MCP 工具的依赖很强。我在描述里直接写了“当需要获取网页实时内容时调用 web-fetch MCP 工具”。如果用户的运行环境里没配这个 MCP 工具skill 就会在执行过程中“卡住”AI 会主动告诉用户缺工具。这其实是好事——skill 把依赖关系显式化了踩坑和排错都更清晰。4.3 测试用例生成 Skill让 AI 按规范批量输出可维护用例测试用例生成是测试工程师用 AI 的高频场景。我见过太多人直接让 AI“帮我写测试用例”出来的东西要么是模板话术要么是完全没有边界值的废话。我自己写的测试用例生成 skill核心是定义一套用例设计方法论。步骤是分析需求描述提取功能点列表 → 针对每个功能点设计正向、反向、边界三类用例 → 每个用例按编号、标题、前置条件、测试步骤、预期结果、优先级六个字段输出 → 所有用例汇总成 markdown 表格。这套流程写进 skill 之后AI 不会再随口编用例而是会按照这套设计方法论来推演。约束部分特别重要比如“不得重复覆盖相同逻辑路径”“边界值必须包含上下限数据”“异常场景至少要覆盖参数为空、格式错误、超长输入这三类”。没有这些约束AI 生成的测试用例全都是同一套模子。我给这个 skill 加的兜底规则是如果需求文本过于模糊导致无法设计用例直接输出“需求不明确需补充以下信息”而不是强行生成。现在我在给项目写测试方案时已经习惯把原始需求文档哪怕只有几句话喂给 AI让它先按 skill 的流程生成初版用例我再人工补充业务场景。初版命中率大概有七成剩下的三成主要靠人工对业务规则的理解去弥补。5. 常见问题与排查技巧实录5.1 Skill 不被触发问题基本都出在描述和放置位置这是被问得最多的问题。我遇到技能不被触发的情况通常有三种原因。第一种是文件放错位置。不同工具识别 skill 的路径是不一样的Claude Code 认.claude/skills/而如果你用的是 Cursor 上类似的功能可能就是.cursor/下的规则目录。我在最开始踩过这个坑把 skill 放到了项目的根目录AI 根本读不到。第二种是 description 写得太差。这句话我说多少次都不嫌多description 是 AI 判断“该不该用这个 skill”的唯一依据。描述要包含明确的任务触发场景、输入形式和目标别写“用于帮助用户完成前端工作”这种放之四海而皆准的话。第三种是项目里的其他配置干扰了 AI 的判断。比如 CLAUDE.md 里写了一大堆项目规范AI 在处理任务时优先响应了这些规范而没有意识到有更专业的 skill 可用。遇到这种情况我一般会在对话里显式说一句“使用 XX skill 处理”同时检查描述文本是否足够具体。5.2 Skill 执行过程“跑偏”如何通过规则约束拉回 AIAI 执行 skill 时经常会出现一种情况流程是对的但结果跟预期有偏差。比如让 AI 做一个前端页面HTML 结构没问题CSS 里却用了内联样式而不是类名。这种“跑偏”往往不是因为 AI 能力不足而是 skill 里的约束写得不到位。解决思路是反向补充。每次 AI 生成结果之后我会有意识地看一眼结果跟我预期“哪里不对”然后把不对的地方作为一条新的约束补进 skill 中。这种“错误注入法”其实是最快的 skill 迭代方式。比如我补过一条“所有样式必须统一放在style标签内或外部 CSS 文件中禁止 style 属性内联样式”就是因为 AI 连续两次用了内联样式。还有一种“跑偏”是流程步骤被跳过。AI 常常为了“偷懒”而少做步骤尤其当步骤多且复杂时。这个问题的解决办法是在 skill 里明确写“执行完每一步后需要输出当前步骤的结果摘要再进入下一步”。当 AI 每一步都要产出结果时它就没法轻易跳过。这个技巧我测试过很多次效果非常明显。5.3 Skill 冲突与依赖管理项目级 vs 用户级配置当你的 skills 多了以后一定会遇到冲突问题。最常见的是项目里有多个 skill 对同一个场景给出了相反的指令。我遇到过最离谱的一次项目同时装了“代码优化”和“代码重构”两个 skill一个要求“保持现有代码结构最小化改动”另一个要求“必要时可重构模块划分”。AI 在执行任务时不知道听谁的最后输出的代码改了不该改的地方。解决思路是给 skill 分层。用户级的 skill 放通用能力项目级的 skill 放定制规范并且要在 skill 中明确“本项目专属规则优先于通用规则”。Claude Code 的机制也支持这种做法系统会同时读取不同层级的配置但优先级有差异。我在写项目级 skill 时都会放一句“本项目所有前端改动必须遵循本 skill 的描述若与其他通用 skill 冲突以本 skill 为准”这样就消除了大部分冲突。依赖管理也不容忽视。如果你删除了某个 skill 依赖的 MCP 服务AI 执行相关步骤时会卡住。我建议在每个 skill 的 frontmatter 里声明required-mcp字段这样 AI 在激活 skill 时就能提前感知到依赖是否满足而不是执行到一半才发现工具不可用。6. 关于 Skills 生态的一点个人观察6.1 为什么“人人都在做 Skills”从单点指令到能力复用的转变最近 GitHub 上出现了一堆优秀的开源 skills 项目包括 baoyu 那套 agent skills、吴恩达在教程里提到的 skills 框架以及社区流行的“skills 官网推荐”清单。这背后的趋势是——大家逐渐意识到AI 真正能稳定提升效率的方式不是靠临场写提示词而是把成熟的做事流程固化下来变成可复用、可分享、可演进的能力模块。对我来说skills 最大的价值在于“知识沉淀”。以前一个团队里某个成员掌握了“用 AI 写测试用例”的独门技巧效率很高但这份经验是存在于他个人脑子和聊天记录里的其他人享受不到。现在把这个技巧写成 skill放到共享目录里全团队都能用。这种从个人技巧到团队资产转化的能力是我最看好 skills 的原因。另外skills 天然是数据驱动的。我开发 skill 的过程本质上是把自己对某个任务的理解转化为 AI 可执行的规则。随着 AI 能力升级skill 的写法也会变但核心方法论和流程设计会一直有用。就像一套优秀的接口设计底层实现换了不要紧接口稳定才是关键。6.2 动手开发自己的第一个 Skill从模仿开始是最快路径如果你想体验 skills 开发我建议不要去读太多理论文档直接找三个你在实际工作中最高频的任务比如“写代码 review”“生成测试用例”“做技术调研”然后用我刚才讲的三段式写一个最小可行版本。不需要写得完美先把流程走通再在真实使用中反复迭代。推荐一个我自己的实践路径先去 GitHub 上下载几个社区评价较高的 skills 项目比如从 baoyu 的仓库里挑一个跟你工作最相关的 skill仔细读它的 SKILL.md 长什么样然后照葫芦画瓢改成你自己的版本。模仿不是抄而是理解写法背后的设计逻辑。等你改了三个以上基本就掌握套路了。我最后想说的是skills 这个方向还在非常早期各家工具的规范还不完全统一但核心思路已经比较清晰——让人把自己的经验和标准借由 AI 能力变成可复用的工具。这不是一个短暂的玩具我更愿意把 skills 看作提示词工程的下一个形态。趁现在生态还没固化早点动手把自己的能力沉淀成 skills后面会形成巨大的复利效应。
AI编程助手Skills机制：从提示词到可复用能力包的实践指南
最近一两个月我身边几乎所有在用 AI 编程助手的同事都不约而同地在折腾同一个东西skills。一开始我以为又是什么新的提示词技巧结果研究了一圈才发现这玩意儿正在悄悄改变我们使用 AI 的方式——过去你每次都要反复交代背景、规则、偏好现在只需要说一句“用 XXX skill 处理”AI 就知道该按什么流程、调什么工具、输出什么格式。这篇文章我就结合自己这段时间的实测把这个“skills”到底是什么、怎么用、怎么自己开发一套一次讲透。文章不会太长篇大论讲概念重点放在怎么上手、怎么避坑以及不同工具Claude Code、Codex、Cursor 这些之间用起来到底差在哪。1. Skills 机制的本质解构从“一次性提示词”到“可复用能力包”1.1 Skill 到底是什么它和普通 Prompt 的区别在哪很多第一次接触 skills 的人第一反应是这不就是高级一点的 Prompt 吗我第一次看到 skill 文件的时候也这么觉得——里面写的确实是给模型看的指令、步骤、示例。但真正用下来你会发现Skills 和 Prompt 有本质区别它是“一套完整的、带固定入口和路由机制的能力模块”。打个比方普通 Prompt 就像你每次去餐厅都要跟服务员把忌口、口味、分量从头到尾说一遍Skills 则像你干脆办了一张会员卡你的偏好和套餐组合全记在卡里了服务员一刷卡就知道怎么给你配餐。Skills 把“怎么干一件事的方法论”封装成了文件AI 在碰到对应任务时会主动去读这个文件然后按里面定义的工作流来执行。我在项目里做得最多的事情是让 Claude Code 根据设计稿还原前端页面。以前每次都得在对话里贴一大堆约束条件设计稿在哪个路径、组件用什么方案、样式怎么组织、兼容性要到什么程度。后来我把这套流程写进了一个 skill放在项目的.claude/skills/design-to-code/目录下接下来只需要跟 AI 说“用 design-to-code 处理一下这个 Figma 链接里的页面”它就会自动去加载 skill 里定义好的步骤、工具调用规则和技术规范输出质量明显比“临场交代”稳定得多。这种体验上的差别背后其实是 skill 文件里藏了一个东西入口路由规则。AI 不是傻乎乎地每次都读所有 skill而是根据任务内容自动判断应该激活哪个。这个机制直接决定了 skills 可以做到“量大不乱”——哪怕你的技能库里有几十个 skillAI 也只会精准加载跟当前任务相关的那一个。1.2 Skills 与 MCP、Agent、目录结构之间的关系聊 skills 就绕不开 MCPModel Context Protocol因为这是它在工具调用层面的基础设施。Skill 解决的是“怎么做”的方法论问题MCP 解决的是“用什么工具去做”的能力接口问题。最直观的理解方式是这样MCP 服务就像你给 AI 接上了各种外部设备查数据库的、操作浏览器的、访问文件系统的而 skill 则是一份“操作手册”——它告诉 AI 遇到什么场景该用哪个设备、按什么顺序操作、操作完怎么检查结果。我自己实际开发的流程里经常是两者一起用。比如我有个拉取网页资料做调研的 skill里面就配好了让 AI 调用一个专门做网页抓取的 MCP 工具。skill 文件里会写清楚“遇到需要获取实时网页内容的任务使用 MCP 的 web_fetch 工具”AI 读到以后就会自己发工具请求整个过程不需要我手动指定 MCP。再说 Agent 的关系。Skills 并不等于 Agent更像 Agent 的“能力插件包”。现在很多工具提供了 Agent 模式让 AI 自主规划、自主执行但很多 Agent 跑到一半会“飘”因为缺少约束。Skill 就是在 Agent 运行过程中提供约束和行为框架的东西——它定义了任务在什么时候算完成、中途遇到分支该怎么决策、最终输出要符合什么规范。所以好的做法永远是“Agent Skills”组合而不是单纯依赖 Agent 自己发挥。还有一个非常容易被忽略的东西skills 在项目里的目录结构。通常不同的 AI 工具会约定不同的加载位置比如 Claude Code 默认是.claude/skills/有的工具则放在.cursor/skills/或者独立配置目录里。写 skill 的时候不光要把文件写对还得放对地方否则工具根本不会识别。2. 核心使用场景与 Skills 调用原理拆解2.1 主流的 Skill 文件格式与 Writing 规范现在业界对 skill 文件格式基本形成了一个默认标准就是 markdown。文件命名统一叫SKILL.md放在以 skill 名称命名的目录下。这个文件里面包含两大部分YAML 格式的 frontmatter元信息以及 markdown 格式的主体执行指南。frontmatter 部分最关键的是name和description。name是 skill 的唯一标识description是入口路由的关键——模型会根据 description 描述的内容来判断当前任务是否跟这个 skill 相关。这一点特别重要description 写得好不好直接决定了 skill 能不能被 AI“自动想起来”。我在调试 skill 的时候发现如果 description 写得太泛比如“处理前端开发任务”AI 就很容易绕开它但如果写得太细比如“仅适用于 Ant Design Pro 项目的 Table 组件页面还原”AI 的匹配又会太窄。写 description 是个需要反复调优的活儿需要在通用性和专一性之间找平衡。主体部分就是给 AI 看的行为指南。我在参考 baoyu 那套 skills 框架以及官方文档之后总结了一个非常实用的写法先给“任务定义”再列“执行步骤”然后补“约束规则”最后放“输入输出示例”。顺序不要乱。AI 是顺序敏感型的越靠前的内容优先级越高所以关键任务目标和禁止事项要放在最前面示例放在最后作为输出格式参考。2.2 不同工具Claude Code、Codex、Cursor调用 Skills 的差异现在市面上支持 skills 工具逐渐多了起来但各家实现思路还有不小差别。我把自己的实测体验列一下方便大家选型参考。Claude Code支持度最完整可以直接把 SKILL.md 放进.claude/skills/目录使用。它有两种触发方式自动触发根据任务语义和显式触发在对话里直接写“使用某 skill”。Claude Code 还允许在 skill 里通过allowed-tools字段限制 AI 能调用的工具安全边界做得很清晰。CodexOpenAI 的方案目前更偏向在对话里把 skill 作为附加上下文传入无论你是通过 CLI 还是 IDE 插件使用主要是以“注入 prompt 压缩包”的形式工作自动路由的感知能力相对弱一些。如果想把 skill 作为独立能力模块用需要在命令行里带上指定参数或者通过配置文件定义好。Cursor主要走“规则 指令”路线它把类似能力挂在了项目规则文件和自定义指令下面而不是完整的 skill 模式。好处是触发直接坏处是缺少自动定位和条件逻辑复杂一点的场景就得靠多条规则组合。我自己主力使用的组合是 Claude Code 做复杂任务因为它的 skill 路由能力最成熟Codex 做代码生成和补全类工作。如果你只想在 Cursor 里体验 skills 的能力可以把 SKILL.md 内容改写成它的 rule 文件也能达到七八成效果只是少了一些自动化逻辑。2.3 Skills 的上下文压缩机制与 token 成本优势很多人担心一个问题如果项目里装了二十个 skill每次对话是不是都要把所有 skill 内容读一遍那 token 消耗不得爆炸实测下来这个担心是多余的。现代 AI 工具在处理 skills 时做了优化一般不会把全部 skill 内容直接灌进上下文窗口而是先读所有 skill 的“元信息层”也就是 frontmatter根据任务语义做相关性排序只把命中的 skill 完整加载。这个机制跟“搜索引擎先看索引再拉取正文”的思路很像。所以即使你装了一大堆 skill只要 description 写得准确最后进入上下文的通常只有一两个相关文件。不过这里也有个隐蔽的坑如果你在同一个项目里放了多个描述特别相似的 skillAI 在做相关性排序时可能会把不该加载的那个拉进来。我踩过一次项目里有“vue page builder”和“vue component generator”两个 skill描述里都提到了“创建 vue 页面组件”结果 AI 总是搞混每次都得靠我显式指定。后来我把两个 skill 的边界描述彻底改清楚一个专注整页搭建一个专注单组件生成情况才好转。所以设计 skills 库时克制很重要——每个 skill 需要有独特定位别做一堆功能重叠的东西。3. 从零开发一套能被 AI 真正“用起来”的 Skill3.1 确定边界与设计入口描述最容易被忽视的环节我看过不少开发者的 skill代码逻辑写得头头是道还配了脚本但实际用的时候 AI 就是不触发。排查到最后发现问题几乎都出在入口描述上。所以我想先说说怎么把 description 写好。写 description 有一个非常实用的句式结构触发场景 任务对象 预期输出。举个例子我写过一个“图片还原设计稿”的 skill一开始的 description 写的是“将图片转换为前端代码”结果 AI 触发率不到三成。后来改成了“当用户提供 UI 设计图或高保真原型图片需要还原成可运行的响应式 HTML/CSS 页面时使用此技能输出包含完整样式的单页实现”。改完之后触发率明显提升原因就是 AI 能明确识别到“什么时候该用”。边界也很重要。skill 不需要把所有相关任务都包进去反而要在 description 和正文中写清楚“什么情况下不要用”。我会刻意加上一句“如果输入不包含图片或设计稿请勿使用此技能。”这样可以避免 AI 误触发。很多开发者不敢写这种限制语句担心影响匹配但实测下来好处大于坏处——因为误触发带来的纠错成本远高于偶尔漏触发。3.2 SKILL.md 的正文结构步骤、约束、示例三段式写法在正文部分我强烈建议按下面三层来组织。第一层是执行步骤。这里不要写“高质量地完成前端开发”这种废话要写可执行、可检查的具体步骤。以“图片还原设计稿”为例我会写成分析图片中的布局结构和组件层级输出 HTML 骨架按设计规范补齐 CSS 样式检查响应式断点和移动端适配输出最终代码和实现说明。每一步都是一个可验证的动作AI 在执行过程中能自己检查“这一步是否完成了”。第二层是约束规则。要明确告诉 AI 哪些能做、哪些不能做。比如“不得使用外部图片链接所有图标使用内联 SVG”“样式类名遵循 BEM 命名规范”“不得依赖任何 UI 框架使用纯 CSS 实现”。约束规则写得越具体AI 的输出就越稳定。如果让 AI 自由发挥很可能每次生成出来的风格都不一样。第三层是输入输出示例。这里不是说给 AI 看一段代码就够了而是要给“完整链路”的示例——输入长什么样处理流程怎样输出长什么样。尤其是 output 示例AI 会非常严格地模仿结构。我通常会放两到三个示例覆盖从简单到复杂的场景确保 AI 有足够多的“模板记忆”可用。3.3 如何给 Skill 挂载脚本、工具和 MCP 服务如果你的 skill 不只是“教 AI 生成文本”这么简单而是需要实际操作那你得学会给 skill 挂载脚本和工具。在 Claude Code 中skill 可以声明一个allowed-tools列表只有列表内的工具才允许被调用。这个设计很实用既安全又清晰。比如我做过一个“批量图片压缩”的 skill里面就只允许调 bash 工具来运行 ImageMagick 命令不允许调用网络类的 MCP 工具避免 AI 瞎折腾。如果想要让 skill 能调用 MCP 工具做法是在 SKILL.md 正文中用非常明确的指令告诉 AI“这个工具叫什么、在什么情况下调用、调用时会传入什么参数”。因为 AI 本身不知道 MCP 工具的参数接口skill 要充当中间说明书。我写过最简单的例子是这样的正文里写明“当流程进入第三步时若需要获取实时网页内容调用 mcp__web-fetch 工具参数 url 为目标网页地址”。AI 读到这段就知道该发什么。实际项目里更平滑的做法是把脚本固化下来。比如一个 skill 每次都依赖一个 python 脚本做数据分析我就把脚本直接放在 skill 目录的scripts/子目录里然后在 SKILL.md 中明确写明“使用python scripts/analyze.py 输入文件命令执行分析”。这样 skill 就真的成了一个自包含能力包丢到任何项目里都能用。3.4 开发流程完整复盘从测试到迭代开发 skill 不是一次写文件就完事的真实过程至少需要三轮迭代。第一轮先用最简单的场景测试 skill 是否被触发。我会手动构造一个输入然后观察 AI 的思考过程有没有读到 skill 文件读到了哪个部分的指令如果没触发回去改 description。第二轮测试执行效果。让 skill 完成一个中等复杂的任务检查流程是否完备、输出格式是否符合预期。这一轮通常会发现很多问题比如步骤顺序不合理、某个环节缺少工具调用说明、约束没有生效等。第三轮边界和异常处理测试。故意给一些超出设计范围的输入看 AI 能否正确拒绝或提示而不是硬着头皮执行。skill 里没有写“任务不明确时先向用户确认”的话AI 就可能自己瞎猜最后输出完全跑偏的东西。所以我每条 skill 里都会加一条兜底规则“如果输入缺少关键信息须先向用户提问不得擅自假设。”我在一次迭代里还发现skill 正文里如果出现太多“可选”“可以尝试”这种模棱两可的表述AI 就会选择偷懒走捷径。后来我要求自己用“必须”“不得”这类词来写关键节点AI 的输出稳定性提高了不少。所以写 skill 的时候语气该强硬的就要强硬这不是给人看的文档而是给模型下指令。4. 实战案例拆解两个高频场景的 Skill 完整实现4.1 前端开发图片还原设计稿 Skill 的实现细节这个 skill 是我用得最顺手的一个完整拆解一遍大家可以直接复制这套思路去做自己的版本。skill 文件放在.claude/skills/design-to-code/SKILL.mdfrontmatter 大概长这样--- name: design-to-code description: 当用户提供 UI 设计图或高保真原型图片需要还原为可运行的 HTML/CSS 页面时使用。输入需包含图片路径或图片内容。 allowed-tools: - bash - read - write - glob ---正文部分我按照步骤、约束、示例三层来写。步骤大概是先识别图片的整体布局和组件构成然后输出 HTML 文件接着写 CSS最后做响应式和细节检查。约束里我写明了不得使用外部图片链接、必须使用语义化标签、样式要符合设计稿的间距和颜色还有一条比较个性化——字体大小要用 rem 而不是 px这样移动端适配会方便很多。这里有个细节值得提一下我觉得“输出 HTML 文件”和“把 HTML 内容直接贴在对话里”是两种不同的执行路径。我在 skill 里明确写了“生成完整 HTML 文件并按用户指定的项目路径保存”因为很多时候我们需要的不是一段聊天里的代码而是一个能直接运行的文件。把这个写清楚AI 就会主动创建文件而不是在对话里吐一大段代码。用完这个 skill 之后我的日常工作流变成了设计师给我一张设计稿图片 → 我把图片扔进项目 → 跟 AI 说“用 design-to-code 处理” → 不到一分钟就得到一个可运行的静态页面。虽然复杂交互逻辑还得自己写但纯静态还原这块效率提升了大概三四倍。4.2 调研分析让 AI 按结构化流程抓取网页并输出报告第二个案例是做调研分析的 skill。写这类 skill 有一个核心难点AI 的即时知识是有限的它需要自己去找实时资料但找资料和整理资料是两个逻辑混在一起容易乱。我的调研 skill 把流程拆成了四步确认调研问题和范围 → 调用网页抓取工具收集至少三个独立来源 → 对比验证信息一致性 → 按固定结构输出报告。在正文里我会明确告诉 AI如果收集到的信息有冲突要在报告里直接标注“信息来源存在不一致”而不是自作主张选一个可信的。这个 skill 里最大的亮点是输出模板。我定义了一套固定的报告结构结论摘要、事实清单、关键数据、信息来源、补充说明。有了这套模板AI 每次输出的调研报告都是同一格式后续对比、归档都很方便。我甚至会把输出格式用代码块示例写出来AI 会精准照着格式来。做这类 skill 时对 MCP 工具的依赖很强。我在描述里直接写了“当需要获取网页实时内容时调用 web-fetch MCP 工具”。如果用户的运行环境里没配这个 MCP 工具skill 就会在执行过程中“卡住”AI 会主动告诉用户缺工具。这其实是好事——skill 把依赖关系显式化了踩坑和排错都更清晰。4.3 测试用例生成 Skill让 AI 按规范批量输出可维护用例测试用例生成是测试工程师用 AI 的高频场景。我见过太多人直接让 AI“帮我写测试用例”出来的东西要么是模板话术要么是完全没有边界值的废话。我自己写的测试用例生成 skill核心是定义一套用例设计方法论。步骤是分析需求描述提取功能点列表 → 针对每个功能点设计正向、反向、边界三类用例 → 每个用例按编号、标题、前置条件、测试步骤、预期结果、优先级六个字段输出 → 所有用例汇总成 markdown 表格。这套流程写进 skill 之后AI 不会再随口编用例而是会按照这套设计方法论来推演。约束部分特别重要比如“不得重复覆盖相同逻辑路径”“边界值必须包含上下限数据”“异常场景至少要覆盖参数为空、格式错误、超长输入这三类”。没有这些约束AI 生成的测试用例全都是同一套模子。我给这个 skill 加的兜底规则是如果需求文本过于模糊导致无法设计用例直接输出“需求不明确需补充以下信息”而不是强行生成。现在我在给项目写测试方案时已经习惯把原始需求文档哪怕只有几句话喂给 AI让它先按 skill 的流程生成初版用例我再人工补充业务场景。初版命中率大概有七成剩下的三成主要靠人工对业务规则的理解去弥补。5. 常见问题与排查技巧实录5.1 Skill 不被触发问题基本都出在描述和放置位置这是被问得最多的问题。我遇到技能不被触发的情况通常有三种原因。第一种是文件放错位置。不同工具识别 skill 的路径是不一样的Claude Code 认.claude/skills/而如果你用的是 Cursor 上类似的功能可能就是.cursor/下的规则目录。我在最开始踩过这个坑把 skill 放到了项目的根目录AI 根本读不到。第二种是 description 写得太差。这句话我说多少次都不嫌多description 是 AI 判断“该不该用这个 skill”的唯一依据。描述要包含明确的任务触发场景、输入形式和目标别写“用于帮助用户完成前端工作”这种放之四海而皆准的话。第三种是项目里的其他配置干扰了 AI 的判断。比如 CLAUDE.md 里写了一大堆项目规范AI 在处理任务时优先响应了这些规范而没有意识到有更专业的 skill 可用。遇到这种情况我一般会在对话里显式说一句“使用 XX skill 处理”同时检查描述文本是否足够具体。5.2 Skill 执行过程“跑偏”如何通过规则约束拉回 AIAI 执行 skill 时经常会出现一种情况流程是对的但结果跟预期有偏差。比如让 AI 做一个前端页面HTML 结构没问题CSS 里却用了内联样式而不是类名。这种“跑偏”往往不是因为 AI 能力不足而是 skill 里的约束写得不到位。解决思路是反向补充。每次 AI 生成结果之后我会有意识地看一眼结果跟我预期“哪里不对”然后把不对的地方作为一条新的约束补进 skill 中。这种“错误注入法”其实是最快的 skill 迭代方式。比如我补过一条“所有样式必须统一放在style标签内或外部 CSS 文件中禁止 style 属性内联样式”就是因为 AI 连续两次用了内联样式。还有一种“跑偏”是流程步骤被跳过。AI 常常为了“偷懒”而少做步骤尤其当步骤多且复杂时。这个问题的解决办法是在 skill 里明确写“执行完每一步后需要输出当前步骤的结果摘要再进入下一步”。当 AI 每一步都要产出结果时它就没法轻易跳过。这个技巧我测试过很多次效果非常明显。5.3 Skill 冲突与依赖管理项目级 vs 用户级配置当你的 skills 多了以后一定会遇到冲突问题。最常见的是项目里有多个 skill 对同一个场景给出了相反的指令。我遇到过最离谱的一次项目同时装了“代码优化”和“代码重构”两个 skill一个要求“保持现有代码结构最小化改动”另一个要求“必要时可重构模块划分”。AI 在执行任务时不知道听谁的最后输出的代码改了不该改的地方。解决思路是给 skill 分层。用户级的 skill 放通用能力项目级的 skill 放定制规范并且要在 skill 中明确“本项目专属规则优先于通用规则”。Claude Code 的机制也支持这种做法系统会同时读取不同层级的配置但优先级有差异。我在写项目级 skill 时都会放一句“本项目所有前端改动必须遵循本 skill 的描述若与其他通用 skill 冲突以本 skill 为准”这样就消除了大部分冲突。依赖管理也不容忽视。如果你删除了某个 skill 依赖的 MCP 服务AI 执行相关步骤时会卡住。我建议在每个 skill 的 frontmatter 里声明required-mcp字段这样 AI 在激活 skill 时就能提前感知到依赖是否满足而不是执行到一半才发现工具不可用。6. 关于 Skills 生态的一点个人观察6.1 为什么“人人都在做 Skills”从单点指令到能力复用的转变最近 GitHub 上出现了一堆优秀的开源 skills 项目包括 baoyu 那套 agent skills、吴恩达在教程里提到的 skills 框架以及社区流行的“skills 官网推荐”清单。这背后的趋势是——大家逐渐意识到AI 真正能稳定提升效率的方式不是靠临场写提示词而是把成熟的做事流程固化下来变成可复用、可分享、可演进的能力模块。对我来说skills 最大的价值在于“知识沉淀”。以前一个团队里某个成员掌握了“用 AI 写测试用例”的独门技巧效率很高但这份经验是存在于他个人脑子和聊天记录里的其他人享受不到。现在把这个技巧写成 skill放到共享目录里全团队都能用。这种从个人技巧到团队资产转化的能力是我最看好 skills 的原因。另外skills 天然是数据驱动的。我开发 skill 的过程本质上是把自己对某个任务的理解转化为 AI 可执行的规则。随着 AI 能力升级skill 的写法也会变但核心方法论和流程设计会一直有用。就像一套优秀的接口设计底层实现换了不要紧接口稳定才是关键。6.2 动手开发自己的第一个 Skill从模仿开始是最快路径如果你想体验 skills 开发我建议不要去读太多理论文档直接找三个你在实际工作中最高频的任务比如“写代码 review”“生成测试用例”“做技术调研”然后用我刚才讲的三段式写一个最小可行版本。不需要写得完美先把流程走通再在真实使用中反复迭代。推荐一个我自己的实践路径先去 GitHub 上下载几个社区评价较高的 skills 项目比如从 baoyu 的仓库里挑一个跟你工作最相关的 skill仔细读它的 SKILL.md 长什么样然后照葫芦画瓢改成你自己的版本。模仿不是抄而是理解写法背后的设计逻辑。等你改了三个以上基本就掌握套路了。我最后想说的是skills 这个方向还在非常早期各家工具的规范还不完全统一但核心思路已经比较清晰——让人把自己的经验和标准借由 AI 能力变成可复用的工具。这不是一个短暂的玩具我更愿意把 skills 看作提示词工程的下一个形态。趁现在生态还没固化早点动手把自己的能力沉淀成 skills后面会形成巨大的复利效应。