先交代个背景我以前用 Claude Code 写测试用例最怕那种“你替我全面测一下这个接口”的需求。给一堆需求描述然后我复制粘贴一段又臭又长的提示词进去第一版能出个轮廓第二版开始编造字段第三版已经忘了最开始的功能约束。后来我试着把测试策略写成独立文件让 Agent 加载发现效果完全不一样——它每次都能按固定流程来先拆需求、再列边界、补异常分支最后才生成用例文件。这个“独立文件”就是现在被反复讨论的 Skills。也就是从那个节点开始我彻底理解了 Claude Skills、Agent Skills 这些东西到底在解决什么问题。它不是加几个提示词模板那么简单而是把“教 Agent 做某件事的完整方法论”打包成可复用的能力单元让模型按需加载、稳定执行。这篇文章我就围绕 Skills 是什么、和 MCP 怎么配合、哪些场景下真正好用、以及怎么自己开发一套把我几个月的实操记录和踩坑过程完整写出来。1. 别把 Skills 当“提示词收藏夹”它是 Agent 的能力插件先厘清一个基础认知。很多人第一次接触 Skills 这个概念会把它理解为“更好的提示词”——毕竟打开一个 SKILL.md 文件里面好像就是一大段 Markdown 指令写着“你是一个测试专家”“请按以下步骤操作”。如果只是这种理解那你很难体会到 Skills 的真正威力。1.1 为什么不直接复制粘贴一段提示词核心区别在触达机制。普通提示词随着对话上下文一起进入模型模型每次都要从海量内容里去理解“你到底想让我按什么规矩干活”。当你的业务逻辑复杂到一定程度比如测试用例生成要覆盖需求分析、边界枚举、依赖 Mock、断言规范、回归标记一次性塞进对话里模型会迷失优先级经常在前后两次回答中表现得像两个不同的师傅。而 Skills 是运行时的能力插件。它平时躺在固定的目录里Agent 在任务开始时根据用户的意图去检索匹配的 Skill找到后才把对应的 SKILL.md 内容注入上下文。这种“按需加载”的机制让技能文件保持精简、聚焦模型拿到的是已经整理好的操作手册而不是一大坨混着闲聊的聊天记录。1.2 引用官方定义时我在想什么2025 年 Anthropic 提出 Claude Skills 之后官方文档说得很直白Skills 是一系列指令、参考文件和脚本的集合让模型能更快更好地执行常见或复杂任务。吴恩达后来在 Agent Skills 教程 PDF 里也做过一个判断他说 Agentic Workflow 取得成绩的关键不在模型本身变强而在于我们能把领域知识和工作流程注入到 Agent 的工作循环里Skills 就是这种注入的标准化载体。这个判断我特别认同。拿数学建模这件事举例你要让 Agent 帮你做一套完整建模流程如果直接丢一个“帮我做个数学模型”的 Prompt它顶多给你列几条思路不会真去写微分方程。但如果你加载一个数学建模 Skill它会自动拆成问题重述、假设条件、符号说明、模型建立、求解、敏感性分析、优缺点评价等步骤每一步都有对应的操作指导。能力边界完全不一样。1.3 从“每次重新教学”到“装上就会”我个人的比喻是普通提示词像你每天给新员工口述工作流程今天讲一遍、明天讲一遍语速快了他记不住你哪天少说一个步骤他就漏做。Skills 像你给员工一份标准作业指导书平时锁在柜子里接到对应工单才拿出来照着执行。指导书还能配套工具、脚本、检查清单写着写着累了它还能自己跑代码。这种结构性改变带来的直接收益是稳定性。我实测过同一个任务用简单 Prompt 跑五次五次结构都不同挂上 Skill 跑五次产出结构基本一致只有细节随业务输入变化。对于任何需要交付到下游环节的工作这个稳定性比什么都重要。2. Skill 与 MCP 的关系这一节得掰开揉碎讲Skills 和 MCP 是 Agent 生态里最容易混淆的两个概念。很多刚接触的人会问Skills 里要不要配置 MCPMCP 能替代 Skills 吗答案是它们完全不在一个维度上必须配合使用。2.1 管脑子的和管手脚的我习惯用一张表来理解这个事维度SkillsMCP本质能力方法论/操作流程外部工具与数据协议主要作用告诉 Agent 怎么做、按什么步骤做给 Agent 提供能调用的工具或数据源表现形式SKILL.md、参考文档、脚本标准化的工具函数、资源、上下文典型例子测试用例生成流程、代码评审流程GitHub API、数据库连接、浏览器操作触发方式按需匹配加载运行时按工具名直接调用一句话总结Skills 决定 Agent 用脑子去想什么MCP 决定 Agent 能伸手摸到什么。一个人光会思考但没有手什么都做不了光有手但不知道流程做出来的事也是乱的。2.2 Skills 如何调用 MCP 工具关键在于SKILL.md 文件本身不直接配置 MCP 的连接参数而是在指令文本里告诉模型完成本任务时遇到哪些场景必须调用哪些工具以及这些工具该怎么组合使用。MCP 工具在运行时会以mcp__服务器名__工具名这样的格式暴露给模型Skill 只需要在正文中声明这一调用预期即可。举个例子我在做网页截图回归对比的时候写过这样的 Skill 指令## 操作步骤 1. 使用 mcp__browser__navigate 打开目标页面。 2. 使用 mcp__browser__screenshot 捕获当前页面快照。 3. 将快照与基准图片对比标记差异区域。 4. 如果存在差异使用 mcp__github__create_issue 创建回归问题单。看到了吗Skill 在这里扮演的是“操作脚本设计者”而 MCP 是“具体动作执行者”。Skill 负责把复杂的诊断流程编排出来MCP 负责真正抓到数据、触发动作。如果只有 Skills 没有 MCP模型只能凭空推测浏览器里发生了什么如果只有 MCP 没有 Skills模型拿到了工具也不知道人类希望它按什么顺序用。2.3 很多人卡住的配置环节实际配置时最容易出问题的节点是工具命名。不同运行时的 MCP 命名规则不完全一样Claude Code 里通常是mcp__server-name__tool-nameCodex 和 OpenCode 又各有自己的调用方式。我建议在 SKILL.md 里不要写死在某个框架下的完整工具名而是用一个通用描述加建议工具列表比如需要数据库操作时优先调用可用 MCP 工具执行 SQL避免自行虚构数据。这样你的 Skill 文件可以在多个运行时里复用不会被特定配置绑死。等真正跑起来再在对应的运行时配置层做映射。3. 实测过几类高热度 Skills哪些真正值得安装因为工作关系我陆续调研和试用了社区里流传较广的几类 Skills包括测试用例生成、图片还原设计稿、数学建模、学术研究、渗透测试这几种。这里说说我的实际感受不是照着 README 念。3.1 测试用例生成 Skills最成熟、收益最直接这类 Skill 是整个生态里最成熟的一类因为软件测试的流程高度标准化特别适合沉淀成技能。baoyu skills 里就有相关的整理。我用的这套 Skill 会把测试设计拆成六步需求澄清、场景罗列、等价类划分、边界值提取、依赖分析、输出用例表。其中第三步和第四步最关键模型被要求把每个输入字段的可选值都列出来再逐一标记正常域和异常域。实际跑一个订单接口测试的效果非常明显。裸跑 Prompt 时模型会写二十几条用例看着热闹但大量重复挂了 Skill 之后它先画出字段矩阵五个必填字段各配一个边界区间再组合出跨字段依赖用例最后连数据库回滚验证都列进去了。产出的用例数量反而少了但覆盖率明显提升。3.2 图片还原设计稿给前端开发爽但也有边界“图片还原设计稿”是前端开发场景里讨论度很高的一个方向核心逻辑是让 Agent 识别 UI 截图再生成对应的 HTML/CSS 代码。好用的 Skill 会要求先描述布局结构、再列出色值字号间距、然后按区域分块生成代码。我拿一个中等复杂度的后台表格页面测试生成结果初看很像样栅格系统、圆角、阴影都能对上。但它有很明显的能力边界。当设计稿里有精致插画、手写字体、复杂交互动效时Agent 基本无法还原只能给出占位实现。此外图片像素大小、清晰度也会严重影响识别准确度所以在 SKILL.md 里我会额外加一条截图分辨率低于 800px 时先提出放大建议。这个提示词在社区版本里基本都没有属于我后来补上去的实操经验。3.3 数学建模和学术研究流程大于生成数学建模 Skills 在我周边竞赛党的口碑不错。它的核心价值不是帮你想出一个新的数学模型而是强制按竞赛标准流程走先把目标函数定义清楚再列假设条件再做量纲分析然后才是建模和求解。这种流程规范对新手特别友好至少不会交上去一份缺胳膊少腿的论文。学术研究类 Skills 我更关注它怎么处理引用和文献综述。好的实现会让 Agent 分步骤做三件事先检索已有文献再按主题聚类最后才起草综述草稿。最忌讳的是让 Agent 直接生成一个没有出处的综述那对论文没有任何帮助。目前社区里成熟可用的这类 Skill 还不太多质量参差需要自己挑。3.4 渗透测试等安全方向必须强调授权边界渗透测试 Skills 存在性很强但我要先把丑话说在前面任何安全测试类技能只允许在授权环境中使用针对自己负责的系统或已签署授权协议的目标进行测试才是合法且职业的做法。好的渗透测试 Skill 会把流程规范成信息收集、漏洞探测、利用验证、日志清理评估、报告编写五个阶段并且每个阶段都有对应的指令约束避免模型乱说技巧、脱离实际。实际上这类 Skill 最大的价值是报告规范化。以往人工做渗透测试写报告容易漏掉复现步骤Skill 会强制要求每一步都记录命令、输出和影响评估报告质量好很多。下面是各场景的简要结论Skills 类型适合人群实测收益注意点测试用例生成前后端开发者、测试工程师高覆盖率和稳定性提升明显需要定制字段说明图片还原设计稿前端开发中高快速出静态页面可用复杂视觉元素难还原数学建模竞赛学生、科研人员中高流程规范模型推导还需要人来把关学术研究学生、论文作者中文献聚类有用引用真实性必须核验渗透测试安全工程师中报告规范价值高必须走授权流程4. 自己开发一个 Skill从零到可交付的完整流程看完别人的 Skill总会冒出“我也想搞一个”的念头。开发 Skill 的技术门槛其实不高核心是设计意图和流程拆解能力。以一个我自己从零开发的“代码评审 Skill”为例完整走一遍流程。4.1 第一步定义边界一个 Skill 只做一件事这是最重要也最容易被忽略的一步。新手经常想做一个“超级 Skill”既能写代码又能查资料还能发邮件结果每个功能都做不深。好的实践是每个 Skill 只聚焦一个核心能力最多带两个辅助能力。我当时的定义本 Skill 用于本地代码仓库的变更评审输入是一批代码 diff输出是结构化的评审报告。边界很清晰不涉及 CI/CD 集成不涉及自动修复代码不涉及跨仓库对比。这个边界决定了后来 SKILL.md 的撰写深度。4.2 第二步设计目录结构Skills 的标准目录结构一般长这样code-review-skill/ ├── SKILL.md ├── references/ │ ├── coding-standards.md │ └── review-checklist.md └── scripts/ └── extract_diff.pySKILL.md 是入口必须存在且命名准确references 放辅助参考文档适合放那些不需要完整注入、但是需要的时候可以按需检索的说明scripts 放可执行脚本适合把那种模型不擅长做的确定性逻辑交给代码处理。我这个代码评审 Skill 里为什么需要 Python 脚本因为纯靠模型去解析大量 diff 文件容易漏文件和统计错行数。脚本先把 diff 解析成结构化 JSON模型拿到 JSON 再做语义分析准确率立刻提升。这也印证了一个原则能用代码确定完成的事不要丢给模型自由发挥。4.3 第三步写好 SKILL.md 的内容模板SKILL.md 我习惯分成五个区块--- name: code-review-skill description: 对本地代码变更执行结构化评审适合提交 MR/PR 前使用。 --- # 代码评审技能 ## 能力范围 本技能仅处理本地代码 diff 的结构化评审不执行自动修复。 ## 工作流程 1. 调用 scripts/extract_diff.py 解析 diff 文件生成变更清单。 2. 按 references/review-checklist.md 中列出的维度逐项检查。 3. 输出 Markdown 格式评审报告按严重程度分级。 4. 在报告中标注文件路径和行号。 ## 关键规则 - 只评审已变更的代码不评审全量仓库。 - 所有结论必须引用具体代码位置。 - 不确定的样式问题归为建议级不归为阻断级。 ## 注意事项 - 当用户没有指定 diff 来源时默认扫描当前 git diff。 - 不要修改任何源代码。description 字段特别重要Agent 是靠这个字段来判断什么时候加载该 Skill 的。写得过于宽泛无关任务也会触发导致上下文浪费写得过于具体可能真需要时又匹配不到需要反复调试。4.4 第四步调试与迭代三板斧写完 Skill 之后要用真实任务反复验证。我的调试方法有三个步骤静态检查先检查 frontmatter 的 YAML 格式是否合法只要缩进出问题整个文件就可能不被识别。定向测试用一份小的、确定性的 diff 测试 Skill观察模型是否准确执行了流程中的每一步尤其注意它有没有跳过 script 调用直接给出泛泛结论。边界试探故意给一个不符合 Skill 范围的输入比如让代码评审 Skill 去写接口文档判断模型能否正确拒绝。我是刻意要求“我的 Skill 不处理这类项目建议你使用其他专门技能”避免模型硬答。迭代两三轮之后Skill 的可用性就会高很多。这里再补充一个经验版本管理。我会把 Skill 目录放到 Git 仓库里每当模型表现出超出预期或者明显错误的场景就把案例补充到 references 里的 sample.md让后续版本的 Skill 能吸取历史教训。5. 安装、分发与生态现状好技能也得有好环境Skill 文件的开发和调试已经能跑通了但如果装不到正确的路径、找不到好用的现成资源前面这些功夫也白费。最后聊聊安装、分发和整个生态的现状。5.1 不同运行时各自的安装目录目前主流运行时的 Skills 目录约定如下运行时存放目录说明Claude Code~/.claude/skills/官方支持可通过插件管理批量安装Cursor.cursor/skills/项目级技能和项目设置一起提交Codex~/.codex/skills/支持全局和项目目录两级OpenCode~/.config/opencode/skills/遵循 XDG 规范安装时最容易出错的是目录层级。很多新手直接把整个含有 SKILL.md 的文件夹放到 skills 目录里结果运行时发现不了因为没有让 SKILL.md 处于顶层索引位置。正确做法是让每个 Skill 独占一个子目录SKILL.md 直接放在该子目录下而不是嵌套更深。5.2 社区生态从 baoyu 到 Claude Code 官方文档Skills 生态成长速度很快。中文社区里 baoyu skills 是绕不开的名字它把许多热门技能做了整理和索引对刚入门的人帮助很大英文社区里有 Matt Pocock 做的技能合集前端向内容居多质量也很高Anthropic 官方文档则是最权威的语法与规范来源遇到解析问题我第一反应都是翻官方文档而不是看二手解读。吴恩达的 Agent Skills 教程 PDF 内容偏理论和实践结合它没有停留在概念层面而是给了一套怎么识别业务场景该用 Skill、该用 Workflow 还是该用 MCP 的判断框架。WorkBuddy 这类产品开始把 Skill 制作流程图形化底层维护的其实还是 SKILL.md 结构只是在编辑器和自动化方面做了增强。5.3 不可忽视的生态问题虽然 Skills 很热但有几个问题我想提醒一下第一技能来源安全性。Skill 本质上是可执行的指令集某些复杂 Skill 还包含脚本。下载来路不明的 Skill等于让别人在你的环境里执行代码。社区里出现过夹带恶意指令的软件包所以在引入任何第三方便利之前我会先打开 SKILL.md 通读一遍运行脚本前再看一遍 scripts 目录的代码逻辑。第二技能膨胀。刚开始接触 Skills 的人很容易陷入“收藏癖”装了几十个 Skill 在目录里真正用的没几个。技能目录越大Agent 在按需匹配时的噪声也越大反而更容易选错技能。我自己的目录现在只保留六个处于活动状态的 Skill其他全部移到一个archive/目录里。第三AI 生成技能的循环依赖问题。现在不少人用 Agent 帮自己写 Skill这没问题但如果不经过人工验证就直接投放到生产很容易把模型自己的偏见固化进流程。我的处理方式是让第二个模型做独立评审对 SKILL.md 的流程完整性提出反对意见然后再调整。6. 写在最后的个人体会做了几个月 Skills 开发之后我最大的体会是Skill 的真正价值不在于让模型“记住更多东西”而在于让我们团队的最佳实践变得可以复制、可以版本化、可以审查。以前带新人我得花半天时间讲测试的设计规范现在我把规范写成 Skill新人装好之后按流程走产出质量立刻达到老员工八成水平。如果你打算入坑我的建议是别一上来就做复杂的 Skill挑一个你最熟悉、重复次数最多的日常工作流比如周报生成、会议纪要整理、Pull Request 描述生成把流程拆清楚写进 SKILL.md跑通一轮再慢慢丰富。你很快会发现这个看起来不过是“一个 Markdown 文件”的东西实际是你的团队知识沉淀的最小单位。从 Skills 被装进一个个 Agent 运行时那天起模型的能力就不再只取决于参数规模也取决于用户手里有没有一份把工作流讲清楚的“作业指导书”。这大概就是 Agent 时代里个体差异的新来源。 从Claude Skills到MCP：构建可复用的Agent能力单元实战指南
先交代个背景我以前用 Claude Code 写测试用例最怕那种“你替我全面测一下这个接口”的需求。给一堆需求描述然后我复制粘贴一段又臭又长的提示词进去第一版能出个轮廓第二版开始编造字段第三版已经忘了最开始的功能约束。后来我试着把测试策略写成独立文件让 Agent 加载发现效果完全不一样——它每次都能按固定流程来先拆需求、再列边界、补异常分支最后才生成用例文件。这个“独立文件”就是现在被反复讨论的 Skills。也就是从那个节点开始我彻底理解了 Claude Skills、Agent Skills 这些东西到底在解决什么问题。它不是加几个提示词模板那么简单而是把“教 Agent 做某件事的完整方法论”打包成可复用的能力单元让模型按需加载、稳定执行。这篇文章我就围绕 Skills 是什么、和 MCP 怎么配合、哪些场景下真正好用、以及怎么自己开发一套把我几个月的实操记录和踩坑过程完整写出来。1. 别把 Skills 当“提示词收藏夹”它是 Agent 的能力插件先厘清一个基础认知。很多人第一次接触 Skills 这个概念会把它理解为“更好的提示词”——毕竟打开一个 SKILL.md 文件里面好像就是一大段 Markdown 指令写着“你是一个测试专家”“请按以下步骤操作”。如果只是这种理解那你很难体会到 Skills 的真正威力。1.1 为什么不直接复制粘贴一段提示词核心区别在触达机制。普通提示词随着对话上下文一起进入模型模型每次都要从海量内容里去理解“你到底想让我按什么规矩干活”。当你的业务逻辑复杂到一定程度比如测试用例生成要覆盖需求分析、边界枚举、依赖 Mock、断言规范、回归标记一次性塞进对话里模型会迷失优先级经常在前后两次回答中表现得像两个不同的师傅。而 Skills 是运行时的能力插件。它平时躺在固定的目录里Agent 在任务开始时根据用户的意图去检索匹配的 Skill找到后才把对应的 SKILL.md 内容注入上下文。这种“按需加载”的机制让技能文件保持精简、聚焦模型拿到的是已经整理好的操作手册而不是一大坨混着闲聊的聊天记录。1.2 引用官方定义时我在想什么2025 年 Anthropic 提出 Claude Skills 之后官方文档说得很直白Skills 是一系列指令、参考文件和脚本的集合让模型能更快更好地执行常见或复杂任务。吴恩达后来在 Agent Skills 教程 PDF 里也做过一个判断他说 Agentic Workflow 取得成绩的关键不在模型本身变强而在于我们能把领域知识和工作流程注入到 Agent 的工作循环里Skills 就是这种注入的标准化载体。这个判断我特别认同。拿数学建模这件事举例你要让 Agent 帮你做一套完整建模流程如果直接丢一个“帮我做个数学模型”的 Prompt它顶多给你列几条思路不会真去写微分方程。但如果你加载一个数学建模 Skill它会自动拆成问题重述、假设条件、符号说明、模型建立、求解、敏感性分析、优缺点评价等步骤每一步都有对应的操作指导。能力边界完全不一样。1.3 从“每次重新教学”到“装上就会”我个人的比喻是普通提示词像你每天给新员工口述工作流程今天讲一遍、明天讲一遍语速快了他记不住你哪天少说一个步骤他就漏做。Skills 像你给员工一份标准作业指导书平时锁在柜子里接到对应工单才拿出来照着执行。指导书还能配套工具、脚本、检查清单写着写着累了它还能自己跑代码。这种结构性改变带来的直接收益是稳定性。我实测过同一个任务用简单 Prompt 跑五次五次结构都不同挂上 Skill 跑五次产出结构基本一致只有细节随业务输入变化。对于任何需要交付到下游环节的工作这个稳定性比什么都重要。2. Skill 与 MCP 的关系这一节得掰开揉碎讲Skills 和 MCP 是 Agent 生态里最容易混淆的两个概念。很多刚接触的人会问Skills 里要不要配置 MCPMCP 能替代 Skills 吗答案是它们完全不在一个维度上必须配合使用。2.1 管脑子的和管手脚的我习惯用一张表来理解这个事维度SkillsMCP本质能力方法论/操作流程外部工具与数据协议主要作用告诉 Agent 怎么做、按什么步骤做给 Agent 提供能调用的工具或数据源表现形式SKILL.md、参考文档、脚本标准化的工具函数、资源、上下文典型例子测试用例生成流程、代码评审流程GitHub API、数据库连接、浏览器操作触发方式按需匹配加载运行时按工具名直接调用一句话总结Skills 决定 Agent 用脑子去想什么MCP 决定 Agent 能伸手摸到什么。一个人光会思考但没有手什么都做不了光有手但不知道流程做出来的事也是乱的。2.2 Skills 如何调用 MCP 工具关键在于SKILL.md 文件本身不直接配置 MCP 的连接参数而是在指令文本里告诉模型完成本任务时遇到哪些场景必须调用哪些工具以及这些工具该怎么组合使用。MCP 工具在运行时会以mcp__服务器名__工具名这样的格式暴露给模型Skill 只需要在正文中声明这一调用预期即可。举个例子我在做网页截图回归对比的时候写过这样的 Skill 指令## 操作步骤 1. 使用 mcp__browser__navigate 打开目标页面。 2. 使用 mcp__browser__screenshot 捕获当前页面快照。 3. 将快照与基准图片对比标记差异区域。 4. 如果存在差异使用 mcp__github__create_issue 创建回归问题单。看到了吗Skill 在这里扮演的是“操作脚本设计者”而 MCP 是“具体动作执行者”。Skill 负责把复杂的诊断流程编排出来MCP 负责真正抓到数据、触发动作。如果只有 Skills 没有 MCP模型只能凭空推测浏览器里发生了什么如果只有 MCP 没有 Skills模型拿到了工具也不知道人类希望它按什么顺序用。2.3 很多人卡住的配置环节实际配置时最容易出问题的节点是工具命名。不同运行时的 MCP 命名规则不完全一样Claude Code 里通常是mcp__server-name__tool-nameCodex 和 OpenCode 又各有自己的调用方式。我建议在 SKILL.md 里不要写死在某个框架下的完整工具名而是用一个通用描述加建议工具列表比如需要数据库操作时优先调用可用 MCP 工具执行 SQL避免自行虚构数据。这样你的 Skill 文件可以在多个运行时里复用不会被特定配置绑死。等真正跑起来再在对应的运行时配置层做映射。3. 实测过几类高热度 Skills哪些真正值得安装因为工作关系我陆续调研和试用了社区里流传较广的几类 Skills包括测试用例生成、图片还原设计稿、数学建模、学术研究、渗透测试这几种。这里说说我的实际感受不是照着 README 念。3.1 测试用例生成 Skills最成熟、收益最直接这类 Skill 是整个生态里最成熟的一类因为软件测试的流程高度标准化特别适合沉淀成技能。baoyu skills 里就有相关的整理。我用的这套 Skill 会把测试设计拆成六步需求澄清、场景罗列、等价类划分、边界值提取、依赖分析、输出用例表。其中第三步和第四步最关键模型被要求把每个输入字段的可选值都列出来再逐一标记正常域和异常域。实际跑一个订单接口测试的效果非常明显。裸跑 Prompt 时模型会写二十几条用例看着热闹但大量重复挂了 Skill 之后它先画出字段矩阵五个必填字段各配一个边界区间再组合出跨字段依赖用例最后连数据库回滚验证都列进去了。产出的用例数量反而少了但覆盖率明显提升。3.2 图片还原设计稿给前端开发爽但也有边界“图片还原设计稿”是前端开发场景里讨论度很高的一个方向核心逻辑是让 Agent 识别 UI 截图再生成对应的 HTML/CSS 代码。好用的 Skill 会要求先描述布局结构、再列出色值字号间距、然后按区域分块生成代码。我拿一个中等复杂度的后台表格页面测试生成结果初看很像样栅格系统、圆角、阴影都能对上。但它有很明显的能力边界。当设计稿里有精致插画、手写字体、复杂交互动效时Agent 基本无法还原只能给出占位实现。此外图片像素大小、清晰度也会严重影响识别准确度所以在 SKILL.md 里我会额外加一条截图分辨率低于 800px 时先提出放大建议。这个提示词在社区版本里基本都没有属于我后来补上去的实操经验。3.3 数学建模和学术研究流程大于生成数学建模 Skills 在我周边竞赛党的口碑不错。它的核心价值不是帮你想出一个新的数学模型而是强制按竞赛标准流程走先把目标函数定义清楚再列假设条件再做量纲分析然后才是建模和求解。这种流程规范对新手特别友好至少不会交上去一份缺胳膊少腿的论文。学术研究类 Skills 我更关注它怎么处理引用和文献综述。好的实现会让 Agent 分步骤做三件事先检索已有文献再按主题聚类最后才起草综述草稿。最忌讳的是让 Agent 直接生成一个没有出处的综述那对论文没有任何帮助。目前社区里成熟可用的这类 Skill 还不太多质量参差需要自己挑。3.4 渗透测试等安全方向必须强调授权边界渗透测试 Skills 存在性很强但我要先把丑话说在前面任何安全测试类技能只允许在授权环境中使用针对自己负责的系统或已签署授权协议的目标进行测试才是合法且职业的做法。好的渗透测试 Skill 会把流程规范成信息收集、漏洞探测、利用验证、日志清理评估、报告编写五个阶段并且每个阶段都有对应的指令约束避免模型乱说技巧、脱离实际。实际上这类 Skill 最大的价值是报告规范化。以往人工做渗透测试写报告容易漏掉复现步骤Skill 会强制要求每一步都记录命令、输出和影响评估报告质量好很多。下面是各场景的简要结论Skills 类型适合人群实测收益注意点测试用例生成前后端开发者、测试工程师高覆盖率和稳定性提升明显需要定制字段说明图片还原设计稿前端开发中高快速出静态页面可用复杂视觉元素难还原数学建模竞赛学生、科研人员中高流程规范模型推导还需要人来把关学术研究学生、论文作者中文献聚类有用引用真实性必须核验渗透测试安全工程师中报告规范价值高必须走授权流程4. 自己开发一个 Skill从零到可交付的完整流程看完别人的 Skill总会冒出“我也想搞一个”的念头。开发 Skill 的技术门槛其实不高核心是设计意图和流程拆解能力。以一个我自己从零开发的“代码评审 Skill”为例完整走一遍流程。4.1 第一步定义边界一个 Skill 只做一件事这是最重要也最容易被忽略的一步。新手经常想做一个“超级 Skill”既能写代码又能查资料还能发邮件结果每个功能都做不深。好的实践是每个 Skill 只聚焦一个核心能力最多带两个辅助能力。我当时的定义本 Skill 用于本地代码仓库的变更评审输入是一批代码 diff输出是结构化的评审报告。边界很清晰不涉及 CI/CD 集成不涉及自动修复代码不涉及跨仓库对比。这个边界决定了后来 SKILL.md 的撰写深度。4.2 第二步设计目录结构Skills 的标准目录结构一般长这样code-review-skill/ ├── SKILL.md ├── references/ │ ├── coding-standards.md │ └── review-checklist.md └── scripts/ └── extract_diff.pySKILL.md 是入口必须存在且命名准确references 放辅助参考文档适合放那些不需要完整注入、但是需要的时候可以按需检索的说明scripts 放可执行脚本适合把那种模型不擅长做的确定性逻辑交给代码处理。我这个代码评审 Skill 里为什么需要 Python 脚本因为纯靠模型去解析大量 diff 文件容易漏文件和统计错行数。脚本先把 diff 解析成结构化 JSON模型拿到 JSON 再做语义分析准确率立刻提升。这也印证了一个原则能用代码确定完成的事不要丢给模型自由发挥。4.3 第三步写好 SKILL.md 的内容模板SKILL.md 我习惯分成五个区块--- name: code-review-skill description: 对本地代码变更执行结构化评审适合提交 MR/PR 前使用。 --- # 代码评审技能 ## 能力范围 本技能仅处理本地代码 diff 的结构化评审不执行自动修复。 ## 工作流程 1. 调用 scripts/extract_diff.py 解析 diff 文件生成变更清单。 2. 按 references/review-checklist.md 中列出的维度逐项检查。 3. 输出 Markdown 格式评审报告按严重程度分级。 4. 在报告中标注文件路径和行号。 ## 关键规则 - 只评审已变更的代码不评审全量仓库。 - 所有结论必须引用具体代码位置。 - 不确定的样式问题归为建议级不归为阻断级。 ## 注意事项 - 当用户没有指定 diff 来源时默认扫描当前 git diff。 - 不要修改任何源代码。description 字段特别重要Agent 是靠这个字段来判断什么时候加载该 Skill 的。写得过于宽泛无关任务也会触发导致上下文浪费写得过于具体可能真需要时又匹配不到需要反复调试。4.4 第四步调试与迭代三板斧写完 Skill 之后要用真实任务反复验证。我的调试方法有三个步骤静态检查先检查 frontmatter 的 YAML 格式是否合法只要缩进出问题整个文件就可能不被识别。定向测试用一份小的、确定性的 diff 测试 Skill观察模型是否准确执行了流程中的每一步尤其注意它有没有跳过 script 调用直接给出泛泛结论。边界试探故意给一个不符合 Skill 范围的输入比如让代码评审 Skill 去写接口文档判断模型能否正确拒绝。我是刻意要求“我的 Skill 不处理这类项目建议你使用其他专门技能”避免模型硬答。迭代两三轮之后Skill 的可用性就会高很多。这里再补充一个经验版本管理。我会把 Skill 目录放到 Git 仓库里每当模型表现出超出预期或者明显错误的场景就把案例补充到 references 里的 sample.md让后续版本的 Skill 能吸取历史教训。5. 安装、分发与生态现状好技能也得有好环境Skill 文件的开发和调试已经能跑通了但如果装不到正确的路径、找不到好用的现成资源前面这些功夫也白费。最后聊聊安装、分发和整个生态的现状。5.1 不同运行时各自的安装目录目前主流运行时的 Skills 目录约定如下运行时存放目录说明Claude Code~/.claude/skills/官方支持可通过插件管理批量安装Cursor.cursor/skills/项目级技能和项目设置一起提交Codex~/.codex/skills/支持全局和项目目录两级OpenCode~/.config/opencode/skills/遵循 XDG 规范安装时最容易出错的是目录层级。很多新手直接把整个含有 SKILL.md 的文件夹放到 skills 目录里结果运行时发现不了因为没有让 SKILL.md 处于顶层索引位置。正确做法是让每个 Skill 独占一个子目录SKILL.md 直接放在该子目录下而不是嵌套更深。5.2 社区生态从 baoyu 到 Claude Code 官方文档Skills 生态成长速度很快。中文社区里 baoyu skills 是绕不开的名字它把许多热门技能做了整理和索引对刚入门的人帮助很大英文社区里有 Matt Pocock 做的技能合集前端向内容居多质量也很高Anthropic 官方文档则是最权威的语法与规范来源遇到解析问题我第一反应都是翻官方文档而不是看二手解读。吴恩达的 Agent Skills 教程 PDF 内容偏理论和实践结合它没有停留在概念层面而是给了一套怎么识别业务场景该用 Skill、该用 Workflow 还是该用 MCP 的判断框架。WorkBuddy 这类产品开始把 Skill 制作流程图形化底层维护的其实还是 SKILL.md 结构只是在编辑器和自动化方面做了增强。5.3 不可忽视的生态问题虽然 Skills 很热但有几个问题我想提醒一下第一技能来源安全性。Skill 本质上是可执行的指令集某些复杂 Skill 还包含脚本。下载来路不明的 Skill等于让别人在你的环境里执行代码。社区里出现过夹带恶意指令的软件包所以在引入任何第三方便利之前我会先打开 SKILL.md 通读一遍运行脚本前再看一遍 scripts 目录的代码逻辑。第二技能膨胀。刚开始接触 Skills 的人很容易陷入“收藏癖”装了几十个 Skill 在目录里真正用的没几个。技能目录越大Agent 在按需匹配时的噪声也越大反而更容易选错技能。我自己的目录现在只保留六个处于活动状态的 Skill其他全部移到一个archive/目录里。第三AI 生成技能的循环依赖问题。现在不少人用 Agent 帮自己写 Skill这没问题但如果不经过人工验证就直接投放到生产很容易把模型自己的偏见固化进流程。我的处理方式是让第二个模型做独立评审对 SKILL.md 的流程完整性提出反对意见然后再调整。6. 写在最后的个人体会做了几个月 Skills 开发之后我最大的体会是Skill 的真正价值不在于让模型“记住更多东西”而在于让我们团队的最佳实践变得可以复制、可以版本化、可以审查。以前带新人我得花半天时间讲测试的设计规范现在我把规范写成 Skill新人装好之后按流程走产出质量立刻达到老员工八成水平。如果你打算入坑我的建议是别一上来就做复杂的 Skill挑一个你最熟悉、重复次数最多的日常工作流比如周报生成、会议纪要整理、Pull Request 描述生成把流程拆清楚写进 SKILL.md跑通一轮再慢慢丰富。你很快会发现这个看起来不过是“一个 Markdown 文件”的东西实际是你的团队知识沉淀的最小单位。从 Skills 被装进一个个 Agent 运行时那天起模型的能力就不再只取决于参数规模也取决于用户手里有没有一份把工作流讲清楚的“作业指导书”。这大概就是 Agent 时代里个体差异的新来源。