这两年AI编程助手迭代得实在太快我日常用的工具已经从能补全代码的编辑器变成了带项目理解能力的Agent。但真正让我觉得质变发生的其实是各家开始推skills之后。一开始我也以为这就是个预置提示词的花样直到自己动手写了一个前端设计稿还原的 skill才意识到这东西根本是给 AI 装上专业肌肉记忆。这篇就把我折腾 Claude Code、Codex、Cursor 这几个工具时积累的 skills 开发经验完整梳理一遍从机制原理到动手实操再到踩坑记录一次讲透。1. skills 机制到底解决了什么问题1.1 通用大模型和专业工作流之间的最后一公里大模型本身是个通才你给它一段需求它能写代码、能查资料、能编文案但它不知道你团队里前端代码必须遵循哪些规范测试用例要覆盖哪些边界数学建模报告按什么结构输出。这些约束如果每次都在对话里重新描述既啰嗦又不稳定换个会话就全丢了。skills 干的事情就是把这套特定领域的工作方法打包成可复用、可触发、可版本管理的文件集合。打个比方大模型像新招的实习生学习能力很强但什么都不懂rules 和 system prompt 像是贴在工位上的公司制度而一个 skill 相当于该岗位的标准化操作手册配套工具范例产出物。实习生拿到手册照着做就能交出合格结果不需要你每次从头教一遍。这个机制能流行还有一个现实原因上下文窗口再大也是稀缺资源。你不可能每个任务都把几十页规范文档塞进对话里。skill 是按需加载的AI 只在任务相关时读取手册内容省下的上下文全留给真正的业务逻辑。1.2 skill 和 prompt、rules、MCP 到底有什么区别很多刚接触的朋友会把这几样东西搞混。我用自己的理解做个区分Prompt / system prompt一次性指令随对话走不形成资产。Rules / 项目规范常驻约束AI 每次回答都要遵守。适合禁止做什么的底线要求。Skills可选择的专业能力包AI 判断任务匹配时主动触发。适合该怎么做才专业的完整流程。MCPModel Context Protocol给 AI 提供外部工具和数据来源的协议属于手和眼睛不是大脑里的方法。简单说rules 管底线skills 管上限MCP 管工具。三者可以配合使用但定位完全不同。我在实际项目中会让 rules 保持精简只放安全和合规底线把完整的分析方法论、输出模板、行业标准全部收进 skills 里。这样 AI 不会被一堆常驻规则拖慢又能按需调用专业流程。1.3 一个 skill 的完整结构长什么样不同工具对 skill 的定义略有差异但主流实现Claude Code、Codex、opencode 等基本遵循一个通用模式my-skill/ ├── SKILL.md # 入口文件描述能力、触发条件、使用流程 ├── scripts/ # 辅助脚本可以是 Python、Shell、Node.js ├── templates/ # 输出模板比如报告框架、代码脚手架 ├── references/ # 参考资料规范文档、行业标准、示例片段 └── assets/ # 静态资源图片、样式等其中最核心的是SKILL.md。它通常包含 YAML 格式的元信息name、description和 Markdown 正文。description 是 AI 判断这个 skill 要不要触发的关键必须写得够具体包含触发场景和关键词。正文则告诉 AI 具体的工作流程、执行步骤、注意事项和输出格式。我用 Claude Code 的时候把 skill 放在~/.claude/skills/下也可以放到项目.claude/skills/里实现团队共享。Codex 则是通过配置文件指定 skills 目录指向。这个后面实操部分再展开。2. 热门的 agent skills 有哪几类它们的设计逻辑是什么2.1 前端还原设计稿类 skill这类 skill 在热搜词里反复出现我猜是因为它解决的痛点太痛了拿着一张设计稿截图要 AI 写出现成的前端代码。但直接用普通对话让 AI 做往往得到一堆看起来像但细节全错的产物。问题出在哪因为标准还原流程应该包含识别设计稿尺寸和布局系统、提取色彩变量、判断字体层级、推断组件边界、再计算间距和圆角。好的前端还原 skill 会把这套流程固化成步骤。我参考几份开源实现后自己整理了一份工作流先让 AI 用视觉能力读取设计稿输出结构化描述页面宽度、布局方式、色值清单、字号清单、圆角/间距规律。根据描述判断技术栈React/Vue、Tailwind/CSS Modules并生成组件树。逐区块还原代码要求每个组件独立成文件。最后做一轮自查比对色值是否一致、间距是否成倍率、交互状态是否遗漏。这类 skill 通常还会内置一个 Tailwind 配置模板、字体对照表、以及常见的响应式断点规则。这样 AI 就从凭感觉写代码变成了按设计系统还原页面质量完全不是一个量级。2.2 测试用例生成类 skill生成测试用例这件事AI 很容易犯两个毛病一是只写 happy path边界条件全跳过二是断言太弱跑起来绿但测不出 bug。测试类 skill 的核心价值就是把测试工程师的思考框架塞给 AI。我在用的一个测试 skill 会要求 AI 按以下顺序分析代码读取函数签名列出所有输入参数及类型。绘制参数之间的关系比如a b时走哪个分支。按等价类划分法列出有效/无效输入。按边界值分析法补充边界用例。检查是否有状态依赖需不需要 setUp/teardown。断言时同时验证返回值、副作用、异常抛出。配合覆盖率报告工具这类 skill 生成出来的测试套件直接能追上人工编写的覆盖率水平。我实测在一个老项目中用它补了一轮单测分支覆盖率从 43% 提到 78%而且只花了一个下午。2.3 数学建模和学术研究类 skill数学建模 skill 在热词里占了一席之地主要是因为在数学建模竞赛和科研场景里AI 直接生成代码经常看着专业其实方法用错。比如给你来个神经网络万能拟合忽略了解析解或者传统统计方法的适用性。一份靠谱的数学建模 skill 应该包含问题分析阶段先判断问题本质是优化、预测、评价还是分类不同问题类型匹配不同的候选模型。建模阶段列出模型假设、符号说明、数学表达式并要求给出选择该模型的理由。求解阶段先尝试解析解或成熟库实现再考虑自定义算法。禁止一上来就堆深度学习。验证阶段包括灵敏度分析、鲁棒性检验、残差诊断。学术研究类 skill 也一样不是让 AI 帮你写论文而是让它按文献综述→研究方法→数据分析→论证检查的标准流程辅助你。优质的实现里会内置 APA/GB/T 格式模板、论证完整性检查清单、常见逻辑谬误提示列表。这类 skill 在大学和科研机构里流行不是没道理的它把学术规范的隐性知识显性化了。2.4 渗透测试和网络安全类 skill渗透测试 skills 热度高我完全理解毕竟安全测试有一套非常标准的方法论信息收集、威胁建模、漏洞分析、利用验证、报告输出。每一步都有大量检查项和工具调用。没有 skill 时AI 给出的安全建议往往零散且流于表面。优秀的渗透测试 skill 会内置信息收集阶段的被动/主动侦察清单。漏洞分类库参考通用缺陷枚举。利用验证时需要的 PoC 编写模板。报告输出的标准结构包括风险等级、复现步骤、修复建议。必须提醒一句安全测试 skill 只能用于你自己拥有权限的系统做合规的授权测试。任何练手都要在本地靶场或获得授权的环境里进行千万别拿这套东西做不该做的事。这个边界问题在安全领域怎么强调都不过分。3. 从零开发自己的 skills我把完整流程拆给你看3.1 从哪开始选一个高频重复的场景我见过很多人第一次开发 skill 就想着做一个万能大杀器试图把团队所有规范都装进去。结果就是 SKILL.md 写了一千多行AI 触发时读完就懵了根本抓不住重点。正确做法是从一个你每周都会重复、且流程相对固定的任务开始。我自己第一个 skill 就是创建新前端页面。当时我们的流程是确认页面需求→设计组件树→写 TypeScript 类型→实现样式→补充测试。这套流程每周至少做七八次之前每次都要在对话里重复粘贴流程要求。做成 skill 之后一句话帮我新建一个用户列表页面就能自动走完整套流程。选场景的标准就三条频率高重复次数多节省时间才有意义。流程明确步骤清楚、输出稳定AI 容易学会。结果可验证产出物能通过代码检查或人工评审确认质量。3.2 写好 SKILL.md描述要具体流程要可执行SKILL.md 是整个 skill 的灵魂。我总结了一个写作模板结构大致如下--- name: frontend-page-creator description: 用于创建标准前端页面。当用户要求新建页面、实现 UI 界面、从设计稿还原页面时使用。触发词页面、组件、设计稿、UI。 --- # 前端页面创建 Skill ## 适用场景 - 用户要求新建一个页面/视图 - 用户提供设计稿截图要求还原 - 需要补充页面级交互逻辑 ## 执行流程 ### 1. 需求澄清 如果用户描述不完整先确认以下信息 - 页面用途和主要功能 - 目标用户 - 技术栈默认 React TypeScript Tailwind - 是否有设计稿 ### 2. 组件树设计 列出页面所需的组件层级标注组件职责。规则组件粒度要适中避免粒度过细导致文件爆炸。 ### 3. 代码实现 按照类型定义 → 组件骨架 → 样式 → 交互 → 联调的顺序逐层实现。每个组件包含完整的导出、Props 类型、空状态处理。 ### 4. 自查清单 - [ ] TypeScript 编译通过 - [ ] 关键路径有错误处理 - [ ] 空态、加载态、异常态齐全 - [ ] 样式使用设计系统变量没有硬编码色值 ## 输出格式 - 新建 pages/ 目录下的页面文件 - 组件放 components/ 对应目录 - 更新路由配置 - 返回一份变更摘要列出每个文件的修改原因写这部分的几个关键经验第一description 一定不要写得太宽泛。像帮助用户创建页面这种描述AI 看到后反而犹豫要不要触发。要写清楚触发场景、触发词、排除场景。比如我的 description 里会加注意如果需要修改现有页面而非新建优先使用其他 skill。第二流程要具体到可以执行的颗粒度。与其写保证代码质量不如写每个函数必须有返回类型标注每个组件必须处理 loading 状态。第三给例子比给抽象描述更有效。在 SKILL.md 最后加一个简单的输入输出示例AI 能更准确理解你想要的结果。3.3 让 AI 帮你写 SKILL.md一条高效捷径你可能想不到开发 skill 最快的方式是让 AI 自己写自己。我的做法是先用对话方式完成一次完整任务中途不断纠正 AI 的产出直到结果满意。把这次全过程的对话记录和最终产出物交给 AI让它归纳出你是按什么步骤完成这个任务的。让 AI 基于归纳结果生成 SKILL.md再手动调整补充。为什么有效因为通过演示修正得到的流程远比凭空想象写出来的流程更贴近实际。AI 在归纳时还能把你在对话中提到的细节约束纳入到流程里这些细节你自己可能都没意识到。我做完前端页面技能后用它生成了一个测试用例生成的 SKILL.md效果出乎意料地好。它把我纠正过边界值要用等于和大于等于两种这类细节都吸收了还补充了我之前没注意到的mock 外部服务时要验证调用次数。3.4 在 Claude Code、Codex、Cursor 里怎么加载不同工具加载方式有些差别我用下来是这样Claude Code# 创建目录 mkdir -p ~/.claude/skills/my-skill # 把 SKILL.md 和相关资源放进去 # 启动后输入 /skills 查看已加载技能CodexCodex 需要在配置里指定 skills 目录。我一般在项目根目录放一个codex.md里面声明 skills 的加载路径或者直接在启动参数里指定。CursorCursor 目前对 skills 的支持偏向 Agent 模式路径和命名规则在迭代中变化较快。我的建议是优先看官方文档。不过通用的做法是放在项目的.cursor/skills/下让 Agent 在配置环境时自动发现。验证加载是否成功有一个笨办法直接在对话里问 AI 你有哪些 skills 加载了或者触发一个明显属于该 skill 的场景观察它的行为是否按流程走。如果没触发优先检查 description 的关键词是否覆盖了你用来提问的措辞。4. skills 和 MCP 工具的协作方法4.1 什么时候直接调 MCP什么时候写进 skillMCP 生态现在很丰富文件操作、浏览器抓取、数据库查询、设计稿分析都有对应的 server。有时候一个问题既可以用 MCP 工具直接解决也可以写个 skill 来处理。我的判断标准很简单一次性操作直接调 MCP 工具比如临时查一条数据库记录、打开一个网页。固定流程但每次输入不同写 skill在 skill 内部按需调用 MCP 工具。举个例子读取某个 URL 并总结内容是一次性操作直接调用浏览器 MCP 就行。但每周生成一份竞品分析报告就需要 skill 了它要把抓取竞品页面、提取关键数据、对比我们产品优劣势、按模板输出报告这些步骤全固化下来。skill 里可以嵌套 MCP 调用两者不是对立关系而是编排关系。4.2 一个实际例子网页查资料 skill 如何内部调用 MCP我在用的一个信息收集 skill定义了一套搜索→阅读→提炼→存档的流程。它在执行过程中会调用 web search MCP、网页抓取 MCP 和本地文件 MCP。流程如下1. 用户给出研究主题 2. skill 尝试从主题中提取 2~3 个搜索词组 3. 调用 web search MCP 获取候选链接 4. 调用网页抓取 MCP 读取排名靠前的页面正文 5. 对每个页面输出核心观点、关键数据、来源链接 6. 生成一份结构化研究笔记保存到 projects/notes/ 目录如果没有 skill 的封装我需要手动命令 AI 一步步操作非常麻烦。有了 skill 之后AI 会自动判断在哪个环节调用哪个 MCP 工具而且不会重复调用同一个 URL还能跳过明显是广告或无关的链接。4.3 skill 调 MCP 的几个坑坑一没有声明需要的权限。有些 skill 内部要调浏览器、要写文件如果平台默认权限没放开调用就会失败。我在 Claude Code 里会给特定 skill 配置允许的工具列表。写 SKILL.md 时也要在元数据里声明allowed-tools让 AI 知道自己可以调用哪些工具。坑二MCP 调用结果不校验。MCP 返回的数据往往是 JSON 或文本AI 有时会直接当成事实引用。在 skill 里应该写一句硬性要求所有从外部工具获得的数据必须标注来源或时间戳数据之间互相矛盾时在输出中明确标注不一致。坑三过度依赖 MCP 导致流程脆弱。有些 skill 把核心功能全部押在某个 MCP server 上一旦 server 挂了整个 skill 就废了。我建议保留一条降级路径比如网页抓取失败时提示用户手动粘贴关键内容而不是直接报错。5. 常见问题与排查技巧实录5.1 我踩过的坑和解决方案速查表整理了一张表都是真实遇到并解决的问题问题现象可能原因解决办法skill 没有被触发description 太模糊没覆盖用户的提问措辞在 description 中列出至少 3 个触发词和 1 个排除场景skill 被触发但行为不对SKILL.md 流程太抽象AI 自由发挥空间过大拆成更精细的步骤每个步骤给出明确输出物skill 里引用的资源路径失效使用相对路径时基准目录理解错误在 SKILL.md 开头明确标注所有路径的根目录中文内容输出格式混乱Markdown 模板中的中英混排不规范在输出模板中加入明确的格式示例MCP 工具调用报权限错误未在元数据中声明 allowed-tools检查 platform 配置补充工具白名单多个 skill 同时匹配引起冲突description 之间的边界模糊在 description 中增加排除条件明确分工skill 执行后结果质量不稳定缺少自查清单AI 没有最终校验在流程最后加入自查步骤要求 AI 逐项确认5.2 一个让我印象深刻的排查案例有一次我写了一个代码审查 skill怎么调整都不生效AI 每次只是草草看一遍就给出看起来不错的结论根本不按流程检查。我重新读了几遍 SKILL.md最后发现问题出在描述上——我把这个 skill 描述成用于代码审查太抽象了AI 可能没意识到这是一项需要严肃执行的专业任务。后来我把 description 里的触发描述改成了更具体的场景当用户要求审查代码质量、Pull Request 中的变更、提示代码潜在问题时使用。审查必须按文件逐个进行输出问题清单并标注严重级别。如果没有找到问题必须说明检查了哪些方面不能直接说没问题。改完之后效果立竿见影AI 开始认真逐文件检查了。这个经历让我明白一个道理AI 不会主动认真工作只有当流程明确规定它要做什么、输出什么、禁止什么时它才会按你期望的标准执行。你写在 SKILL.md 里的每一个必须和禁止都是在收紧它的自由度换回可预期的结果。5.3 评估 skill 质量的最快方法开发完 skill 后怎么知道它好不好用我的做法是准备一个最小演示任务也就是一个非常典型的小需求分别用开启和关闭 skill 两种方式运行对比输出差异。比如前端的页面创建 skill我会让它创建一个简单的登录页面。关闭 skill 时 AI 可能直接丢出一个组件开启 skill 时它会先澄清需求、设计组件树、分文件实现、最后自查输出的完整度完全不一样。如果 skill 在最小演示任务上没有表现明显优势说明流程设计得还不够好。这个时候不要急着加内容先想想是不是流程颗粒度不够细或者约束条件不够明确。5.4 几个提高 skill 开发效率的独家经验第一个经验是把 skill 当作代码一样迭代用 Git 管理 SKILL.md 的版本每次改完都记录当时的触发效果。时间久了你会积累出属于自己的最佳实践模式库。第二个经验是尽量用检查清单而不是描述性文字。AI 读文字容易漏读清单则更有可能逐项执行。我写 skill 时会在流程末尾加一个 Markdown checkbox 块AI 在自查时就会逐项打勾漏掉某个步骤的概率大幅降低。第三个经验是给 skill 起名和写 description 时要站在AI 的视角思考。你在提问时最可能用的词是什么你的团队其他人会怎么描述这个任务把这些词都埋进 description触发率才能提上去。第四个经验比较反直觉好的 skill 不应该做得太全。每加一个功能模块AI 的注意力就会被分散一分。我见过一个 skill 试图同时覆盖写代码写测试写文档部署结果每个环节都做到六十分反而不如三个专注的小 skill 各自做到九十分。专注是 skill 设计的第一原则。6. 用 skills 构建你的 AI 工作流我觉得应该分享一个具体场景让大家看看 skills 组合起来能产生什么效果。以我个人在做一个数据可视化项目举例我的工作流里并行了四个 skill数据清洗 skill处理缺失值、格式统一、异常值检测图表设计 skill根据数据类型推荐图表类型并生成配置代码代码审查 skill检查数据处理逻辑和安全性文档生成 skill把分析结论整理成结构化报告。这四个 skill 各管一段AI 能在项目推进中自动按需调用比让一个万能提示词包办所有事情稳定得多。这也让我意识到skills 的真正价值不在于单点增强而在于把完整的专业工作流沉淀成团队可复用的资产。新同事入职后不需要我苦口婆心带教一周直接把这些 skill 配置进开发环境他就能按团队标准产出代码。原来经验这个看不见摸不着的东西现在居然可以被文件化、版本化、分发化这是我去年完全不敢想的事。最后说点实在的如果你现在正准备开发自己的第一个 skills我的建议是先别追求宏大找一个你每周都会做的具体任务哪怕只是生成周报也行。先把这个小任务做到九十分切身感受一下AI 按你的方式做事是什么体验再考虑扩展到更复杂的场景。我亲手做第一个 skill 之前也看了不少教程但真正让我理解这个机制的还是自己做出来并跑起来的那一刻。那种感觉就是AI 不再是什么都能做但都不够专业的通用助手而是开始变成懂你的流程、按你的标准交付的专属搭档。这个方向值得每个认真用 AI 的人投入时间。