AI编程新范式：Skills机制拆解、实战开发与MCP协同

如果你最近频繁刷到“skills”这个词又正好在用 Claude Code、Codex、Cursor 这类 AI 编程工具那你大概率已经在各种 GitHub 仓库和推文里看到过它了。简单说skills 就是给 AI 装上的“专业技能包”让原本只会“聊代码”的通用模型变成懂前端还原、会写渗透测试报告、能帮你做数学建模的“专项工种”。这篇文章我不打算重复官方文档而是结合我自己实际下载、使用、开发 skills 的经验把它的原理、选型、踩坑讲透。全文会覆盖几个部分skills 到底是个什么机制、和 MCP 有什么区别、怎么快速套用别人写好的技能、怎么从零开发一个属于自己的 skills以及我会分享几个真实遇到的问题和排查思路。不管你是被“图片还原设计稿”这种热门技能吸引来的前端还是想给 Agent 加 Buff 的 AI 应用开发者这篇文章都值得花十分钟看完。1. Skills 不是新插件而是 AI 的“岗位说明书”1.1 一句话讲清 skills 是什么如果你打开一个典型的 skills 仓库会发现核心就是一个文件夹里面通常有一个SKILL.md文件和一堆辅助脚本、参考资料。这个SKILL.md用的是 Markdown 格式头部带一段 YAML 元信息正文就是给 AI 看的“操作手册”。我的理解是skills 本质上是一条“岗位说明书 培训资料包”。岗位说明书告诉 AI“你什么时候该上岗、这个岗位负责什么、按什么流程干活”培训资料包则是一些平时用不到、但在执行任务时才需要翻阅的参考文档和脚本。举一个很直观的例子你不会希望一个写代码的 AI 每次都把“如何把 PNG 设计稿还原成 React 组件”的完整方法论加载到上下文里因为这会浪费大量 token而且大部分时候用不上。skills 的解法是平时它不占用任何上下文只有当任务匹配到这个技能时模型才主动去读取SKILL.md再按需加载内部的参考资料。这就是它最核心的价值——按需激活精准加载。1.2 为什么最近突然火起来了skills 的火爆和 Claude Code 在 2025 年的一次更新有很大关系。Anthropic 正式把 Agent Skills 作为一项独立能力放进了 Claude Code紧接着吴恩达的 Agent Skills 教程也公开出来把这套机制讲得特别清楚。后面 OpenAI 的 Codex、Google 的 Gemini CLI 也陆续跟进现在 Cursor 这类编辑器也在构建自己的 skills 体系。这一波爆火还有一个直接原因——大家发现它真的能降低“调教 AI”的门槛。以前我想让 AI 稳定地按某个流程干活要么把一大段系统提示词塞进项目配置里要么天天在对话里重复要求。有了 skills 之后把一套方法封装成文件夹谁拿到都能用跨项目、跨工具复用都很轻松。社区里甚至出现了“superpower skills”这类集合包把几十个常用技能打包在一起装完就像给 AI 做了个“全家桶升级”。1.3 什么样的人最应该关注从搜索热词来看关注 skills 的人大致分几类一是前端开发最关心的就是“图片还原设计稿”这类能直接提效的技能二是测试、运维、安全方向的人他们想用 skills 固化自己的一套检查流程三是做学术研究和数学建模的希望 AI 能按学术规范整理文献、跑建模流程四是 AI 应用开发者他们想理解这套机制然后把自己沉淀的经验封装成产品化能力。我给的建议是如果你平时只用 AI 聊聊天、写写零散代码skills 暂时不是刚需但如果你希望 AI 稳定地完成某一类重复性任务——比如每次都要按团队规范做代码审查、每次都要把设计稿还原成组件——那 skills 绝对是值得投入时间研究的东西。2. 一个 SKILL.md 里到底装了什么2.1 先看一份真实的 SKILL.md 结构我拿一个自己写的“前端代码审查”技能来举例。它的文件夹结构是这样的frontend-code-review/ ├── SKILL.md ├── reference/ │ ├── code-review-checklist.md │ └── performance-rules.md └── scripts/ └── run_lint_check.sh核心入口是SKILL.md它的开头长这样--- name: frontend-code-review description: 对前端项目代码进行系统性审查覆盖可维护性、性能、安全三大维度。当用户要求“审查代码”“检查PR”“code review”时使用本技能。 ---然后是正文部分我会写清楚审查的步骤、输出格式、常见问题清单等。这里有一个非常关键的细节description 决定 AI 会不会“想到”用这个技能。你写得太泛比如“用于代码审查”AI 可能会在错误场景下触发你写得太窄模型又容易忽略它。2.2 description 的质量决定技能激活率我见过很多社区里评价一般的 skills问题都出在 description 写得不行。这其实很像搜索引擎的 SEO——你希望 AI 在合适的意图下把技能“检索”出来description 就是匹配索引。好的描述应该包含任务触发词如“审查代码”“检查PR”、适用的语言和场景、以及任务的核心目标。我当时写frontend-code-review技能时前几个版本描述写得太过正统模型经常在用户随口说“帮我看看这段代码有什么问题”时不调用而是直接凭通用知识回答。后来我把描述改成“重点检查 React 项目的 Hooks 依赖、状态管理合理性、性能隐患”激活率立刻就上来了——因为模型知道这个技能覆盖了什么领域它才会更有底气启用。2.3 渐进式加载不要让 AI 一次读太多SKILL.md本身要尽量精简正文最好控制在几百行以内。真正的“知识库”应该放到reference子目录里按需加载。你在正文里可以写“如果需要检查性能问题先读取reference/performance-rules.md再按其中的细则逐项审查。” 模型会自行决定什么时候去读这些文件。这种“渐进式加载”的设计既省 token又能保证技能在复杂任务下依然有足够的深度。我踩过的坑是刚开始把一份完整的前端工程规范全都塞进了SKILL.md结果只要一触发技能光读正文就消耗了大量上下文反而让 AI 容易遗忘用户当前的代码。后来调整成“主文件只放流程和规则摘要细节进 reference”之后实测稳定性和响应速度都好了很多。3. 五分钟跑通第一个 skills从下载到实战3.1 去哪找现成的高质量 skills如果你不想从零开始第一选择是去 GitHub 搜awesome-claude-skills这类汇总仓库里面按前端、后端、测试、办公等分类收录了大量社区技能。其次是各工具的官方文档和官方示例仓库质量有保障更新也及时。还有一些热门的个人开发者仓库比如搜索热词里出现的baoyu skills、mattpococks skills这些在社区里口碑都不错。我的建议是先别急着装一大堆选一个和你当前工作强相关的技能跑通流程再横向扩展。尤其是像“superpower skills”这种全家桶虽然看 demo 很爽但实际项目里未必每个技能都用得上装多了反而会干扰模型的选择。3.2 安装并启用一个“图片还原设计稿”技能很多前端朋友关心的“图片还原设计稿”技能安装步骤其实非常简单。以 Claude Code 为例skills目录默认在~/.claude/skills/你把下载下来的技能文件夹放进去就行mkdir -p ~/.claude/skills/ cd ~/.claude/skills/ git clone https://github.com/your-favorite/screenshot-to-code-skill.git重启 Claude Code 后在对话里输入“帮我把这张设计稿还原成 React 组件”再附上设计稿图片如果技能生效模型会自动读取对应的SKILL.md按里面的流程干活。我用过几个类似的技能表现好的通常具备这些特点说明里明确“先描述设计稿的整体布局再写代码”会要求“优先用小屏幕尺寸逐屏还原再适配桌面”还会约定“组件必须用 props 控制间距和颜色”。如果没有这些细节AI 很容易看着一张图就开始乱写布局导出结果跟设计稿偏差很大。3.3 现场实测AI 能不能真正还原设计稿拿一张常见的 SaaS 后台登录页设计稿举例装好技能、传入图片后模型通常会经历这几个阶段先看图片读取技能里的还原规则再分析设计稿的布局结构说出“顶部是 Logo、中间是表单、底部有备案信息”接着生成组件代码包括表单控件、按钮、错误提示等最后给出适配说明比如在 375px 宽和 1440px 宽下分别怎么表现。实测结果里好的技能能比较准确地还原间距、字体大小、颜色变量这类可量化的信息但图标、动效、切图这类“感觉型”信息仍然需要人工介入。所以我的心态是技能的意义不是让你做甩手掌柜而是把它当成一个不是那么“笨”的初级前端你只需做最后把关。4. 手把手开发自己的 skills把经验固化给 AI4.1 动手之前想清楚三件事开发 skills 不一定需要写代码但需要你把“一件事是怎么做好的”想清楚。我在正式动手前会先问自己三个问题第一这个技能解决什么类型的任务是固定流程还是开放探索第二任务执行过程中需要哪些外部信息和决策依据第三最终交付物长什么样怎么验收比如我想做一个“测试用例生成”技能那我需要先总结清楚输入是需求文档还是接口定义输出格式是思维导图式还是表格优先级怎么定边界条件要覆盖哪些等这些问题有了答案再写SKILL.md就顺理成章了。技能设计最花时间的不是写文件而是把隐性经验显性化。4.2 动手写 SKILL.mdfrontmatter 和任务描述下面是一个比较完整的模板你可以照着改--- name: api-test-case-generator description: 根据 OpenAPI/YAML 接口定义生成测试用例。当用户提供接口文档、Swagger 文件或要求“写接口测试用例”时使用。覆盖正向、反向、边界、异常四类用例。 --- # API 测试用例生成技能 ## 工作流程 1. 读取用户提供的接口定义文件OpenAPI 3.0 或 Swagger。 2. 提取接口路径、请求方法、参数、请求体 schema。 3. 按下面规则生成测试用例。 ## 用例规则 - 正向每个必填参数提供合法值验证响应码 200/201。 - 反向必填参数缺失、类型错误、枚举越界验证 4xx。 - 边界针对数值型参数取最小值、最大值、min-1、max1。 - 异常模拟鉴权失效、资源不存在、服务端 5xx。 ## 输出格式 使用 Markdown 表格输出 | 用例编号 | 场景 | 方法 | 路径 | 请求参数 | 预期结果 | ## 验收标准 - 每个接口至少覆盖 4 类用例。 - 所有用例的预期结果必须具体禁止写“任意/正常”。这个文件的核心是“让 AI 看到就知道该怎么干”。你甚至可以把它理解为新员工入职时拿到的工作手册——优先级最高的就是工作流程、规则和验收标准。4.3 渐进式加载参考资料和脚本怎么放当技能涉及大量领域知识时我建议你分两个目录reference/放参考文档scripts/放可执行脚本。参考文档的作用是给 AI 提供“领域知识”。比如上面这个测试用例生成技能可以放一个reference/error-code-dictionary.md里面记录公司各个服务常见的错误码含义模型生成用例时就会去查。脚本则用于那些“用自然语言很难描述、但用一段代码就能完成”的事情。我通常会把一些数据转换、代码检查的小脚本放在scripts/里然后在SKILL.md中写清楚“需要统计接口数量时运行scripts/count_api.py”。有一个点很值得注意模型并不是在技能触发时就把reference/下的所有文件都读一遍它只有在正文里被明确提示或发现自己需要某方面信息时才会去主动查看。这既是好处也是风险——如果你的正文没有引导模型可能永远不去读参考文档。所以我在写正文时会很刻意地写“根据 reference 中的规则”“先查看 reference 下的 xxx 文件”。4.4 一个可以直接抄的示例代码审查技能为了让你更直观理解我放一个简化的代码审查技能结构code-review/ ├── SKILL.md ├── reference/ │ └── review-checklist.md └── scripts/ └── eslint_check.shSKILL.md正文大约长这样节选# 代码审查技能 ## 适用场景 - 用户要求对合并请求 / PR 进行代码审查时。 - 用户给出某个文件或目录要求“看看有没有问题”时。 ## 执行步骤 1. 先运行 scripts/eslint_check.sh 检查静态代码问题记录所有报错。 2. 浏览待审查代码对照 reference/review-checklist.md 逐项检查。 3. 输出审查结果格式为“问题类型 / 严重程度 / 文件与行号 / 修改建议”。 ## 核心关注点 - 潜在 bug、安全漏洞、重复代码、可维护性问题。 - 性能隐患大数组遍历、重复渲染、未使用 memo。 - 测试覆盖新增逻辑是否有对应测试。 ## 审查语气 - 只指出事实不评价作者。 - 每条建议必须给出可执行的修改方向。这个技能在真实项目中很实用。配合里面那个eslint_check.shAI 会在开始人工审查前先把静态检查跑一遍拿到的结果再结合代码内容做综合判断。相比直接在对话里让 AI“帮我做个 code review”它的输出稳定、格式统一而且有一定深度。5. 让 skills 调用 MCP复合技能才是未来5.1 Skills 和 MCP 到底什么关系这是今年社区里被问得最多的问题之一。我个人的结论是MCP 是 AI 的手和脚负责执行外部动作skills 是 AI 的大脑和操作手册负责决定怎么想、怎么分工。举一个偏数据分析的例子如果我能通过 MCP 查数据库skills 能告诉我“怎么设计一套完整的数据分析流程”。两者结合时我可以在技能正文里这样写当需要查询用户行为数据时调用名为database-mcp的工具执行 SQL如果查询结果缺失返回NO_DATA标记并给出原因如果数据量超过 1000 行先用 Python 脚本聚合再分析。我在实际项目中给一个“周报自动生成”技能做过类似设计。技能负责定义周报要包含哪些模块——项目进展、风险、下周计划——以及在遇到某个数据字段为空时调用查询工具去补齐。如果没有 skillsMCP 只会执行“查什么返回什么”如果没有 MCPskills 再聪明也拿不到实时数据。两者是互补关系。5.2 在 SMITH.md 里写“调用工具”的正确姿势很多人不知道skills 正文里是可以描述“何时调用哪个 MCP 工具”的。关键是写清楚调用条件和结果判断。我以前写过一段时间接草稿发现如果把调用顺序写成“先查数据库再生成”模型会老老实实照做但如果只写“需要时查询数据”模型可能因为判断不准而漏掉关键步骤。推荐写法是这样的## 数据获取 - 分析需求中涉及的指标。 - 如果指标在本地数据文件中不存在调用 MySQL MCP 中 query 工具查询。 - 查询结果必须以表格形式先呈现给用户再继续判断是否需要补充查询。这就相当于在主流程里给 AI 规定了“什么情况下该伸手去拿工具”。严谨一点说这是在给 Agent 做“任务规划”而不是简单地在提示词里塞一句“你可以用工具”。5.3 组合多个 skills模块化地搭建 AI 工作流skills 的另一个玩法是组合使用。比如一个“前端设计稿还原”技能负责把图片转成组件代码另一个“无障碍检查”技能负责跑 WCAG 规则。你可以不把它们写进同一个技能而是在对话中依次激活。这意味着你完全可以把团队内部的经验拆分成多个“小技能”分别维护。对应不同项目时按需组合。我现在的做法是代码审查一个技能、性能优化一个技能、安全基线检查一个技能哪个场景需要就在该场景下触发对应技能。这样会让每个技能更短、更聚焦也更容易维护。6. 实战中的坑常见问题与排查技巧6.1 为什么 AI 就是不调用我装的 skills这是新手最容易遇到的问题。装好技能后明明按说明操作AI 却毫无反应。排查思路按概率排序第一检查技能文件夹是不是放对了位置~/.claude/skills/下每个技能必须是一个独立文件夹且根目录下有SKILL.md第二检查描述是否覆盖了你的提问方式如果描述里写的是“审查 PR”你问“帮我看下这个文件有没有问题”模型很可能不会触发第三确认工具版本是否支持 skills 功能版本太老或配置里禁用了都可能没用。还有一个容易忽略的细节如果你同时装了多个描述相似的技能模型可能随机选一个触发或者干脆都不触发。这时你需要让每个技能的 description 更有区分度比如明确标注“仅用于权限相关代码的检查”。6.2 技能触发后“发挥不稳定”怎么办有时同一个技能同样的输入两次输出差别很大。这是因为模型本身就带有随机性。我的做法是尽量在SKILL.md里把流程写“死”——比如明确“输出必须用三级标题组织结构”或者“生成测试用例时每类用例必须包含 3 条以上”。规则越具体模型发挥稳定的概率越高。另外一个办法是给技能增加结果校验步骤。比如要求“生成完代码后先自己通读一遍输出自查清单”。虽然这会增加少量 token 消耗但换来的是质量稳定性尤其在生成代码、测试用例这些场景下非常值。6.3 更新了工具版本技能失效了Claude Code 历史上发布过几次重要版本skills 的目录结构、命名规范在不同版本里有细微差异。如果你发现以前能用的技能突然失效第一件事是查看版本更新日志看看字段是否改名、文件格式是否有新要求。遇到这种情况不用急着改全部技能可以先跑一个官方示例技能确认工具本身正常再逐个排查自己的技能。如果官方示例能跑通那问题基本出在技能格式或描述写法上。6.4 如何判断一个技能好不好我从社区下载技能时有一个筛选标准首先看SKILL.md的 description 是否具体泛泛而谈的不要其次看有没有 reference 或 scripts 等辅助文件只有孤零零一个SKILL.md的技能通常深度有限再次看作者是否提供了示例输出有 example 的技能会更可信。当然最重要的还是拿到自己的项目里实测。再漂亮的文档不能解决你的实际问题就是白搭。7. 关于 skills 开发的一点个人体会开发 skills 这件事我最大的收获是它逼着你把“自己会但说不清”的经验变成 AI 能执行的规则。这个过程本身就有价值哪怕不为了给 AI 用单是把一套流程梳理成可见文档也足够让团队新人受益。如果让我给新手一条建议那就是第一次开发技能不要想着做“全能包”从一个 20 行左右的SKILL.md开始只有流程没有参考资料跑通了再逐步加厚。技能的好坏不取决于文件多少而在于模型在关键时刻能不能快速理解“该怎么做”。还有一个小技巧我习惯用 Git 管理~/.claude/skills/这个目录每次改完技能都提交一次。这样技能行为发生变化时我能知道是哪个改动造成的出问题也方便回滚。这个习惯帮我避免过很多次“技能突然不好使”导致的排查困境。最后如果你的日常工作里有一类任务每周都要重复做那就值得为它写一个 skills。写的过程可能是枯燥的但写完之后你会发现自己从一个“天天教 AI 干活”的人慢慢变成了“给 AI 设计岗位”的人。这两种心态是完全不一样的体验。