★ FEATURED ARTICLE 你有没有过这种体验在 Claude 或 Codex 里折腾一下午反复调整提示词结果它写出来的代码还是不像你团队的风格让它处理批量文件每次都得重新交代一遍规则换一台电脑之前调教好的工作流全部清零。如果你点头了那“skills”这个东西你应该花半小时了解一下。Skills 是最近在 AI Agent 圈子里被反复讨论的概念核心就一句话把你常用的那些提示词、流程、示例、检查项打包成一个可复用的“技能包”让 Agent 以后遇到同类任务时不用你一句句教直接调用就能干活。我在实际项目里用了一个多月最直观的感受是它把 AI 从“问一句答一句的工具人”变成了“熟悉你习惯的老员工”。这篇就来拆一拆 skills 的底层逻辑、开发和落地方法以及我踩过的那些坑。1. 先搞清楚Skills 到底是什么1.1 从一次“翻车”说起我先讲个场景。上个月我用 AI 帮我整理一批前端组件的文档第一次效果不错格式、语气都符合要求。第二次换个项目再跑它把组件命名风格搞成了另一个团队的写法注释风格也变了。我改完提示词再跑一遍结果它又把我之前设定的规则忘得差不多。后来我才意识到问题不在模型在于我每次都从“零配置”开始——提示词塞得再多也是聊天上下文的一部分换个会话就归零。Skills 解决的正是这个重复造轮子的问题。1.2 本质是一套“标准化能力封装”用大白话说skills 就是把某一类任务的“操作手册”固化成文件。这个文件里有三样东西什么时候用这个技能触发条件、怎么干步骤和规则、干到什么程度算好质量标准。用老工程师的话讲这就是把“老师傅的脑内经验”沉淀成了“团队共享的 Check List”。最早给我这种“标准化封装”感觉的是另一个方向的例子安卓安全研究圈子里有人把脱壳、抓包、代码定位这类重复性逆向工作也写成了 skills——让 Agent 按固定流程去做样本分析。虽然具体操作我不方便展开但思路是共通的把过去靠人肉经验积累的“招数”变成 Agent 能批量执行的标准动作。这种封装能力放到前端开发、文档处理、论文写作这些通用场景里价值确实能被放大。1.3 和 Prompt、MCP 到底有什么区别这是新手最容易绕晕的地方。Prompt 是你跟模型说“你要做什么、怎么做”Skills 是让模型在合适的时候自己去查“我该怎么干这件事”。MCP 解决的是“让 Agent 能连上外部工具和数据”——类似给它接上手和眼睛Skills 解决的是“让 Agent 知道该用什么套路干活”——类似给它装上大脑里的经验库。很多平台比如 Claude 的 Agent 生态里这两者是可以协同工作的MCP 负责调用工具Skills 负责规范调用的方式和判断标准。一句话总结如果说 MCP 是 Agent 的“手”那 skills 就是它的“职业习惯”。2. 开发一个 Skills 之前思路先想清楚2.1 从“我反复在做什么”倒推开发 skills 最大的误区是一上来就写提示词。我的习惯是先翻聊天记录统计一下最近两周让 AI 干了哪些重复性的事。比如你是前端开发是不是每周都要让它生成组件文档是不是每次都要它按 ESLint 规则检查代码是不是经常要它把设计稿转成 JSX 结构把这些高频任务列个表每个任务就是潜在的 skill。2.2 边界要窄别贪心很多第一次写 skills 的人总想做一个“万能技能”什么都能干。结果模型加载之后反而不知道该执行哪条规则。我的原则是一个 skill 只解决一类任务范围宁可小一点也不要大而全。比如“写代码文档”就专门写代码文档别顺手把“检查代码质量”也塞进同一个文件里。2.3 明确“触发条件”是重中之重Skills 跟普通提示词最大的区别是“它是被模型主动调用的”。那模型怎么知道什么时候该调用靠的就是元信息里的描述description 字段。这个字段写得好不好直接决定模型能不能在合适的场景找到它。我见过有人写“用于代码文档生成”结果模型在用户让它写 README 时犹豫了半天——因为描述里没有提 README、API 文档这些具体词。要让模型一眼认出“该用这个了”就得把触发场景里的关键动词和名词写清楚。3. 手把手拆解一份完整 Skills 文件的结构3.1 核心文件SKILL.md目前社区里比较通用的格式是 Markdown 文件文件名通常叫 SKILL.md。整个文件分两块YAML 头信息元数据和正文指令主体。我拿我常用的“前端组件文档生成”作为例子来拆。--- name: frontend-doc-generator description: 适用于为 React/Vue 前端组件生成 README 文档的场景。当用户要求编写组件说明、API 文档、props 说明或使用示例时使用。 --- # 前端组件文档生成器 ## 目标 输出符合团队规范的中文组件文档覆盖组件概述、安装方式、props 说明、事件/方法说明、使用示例、注意事项。 ## 流程 1. 读取组件源码提取组件名称、props、事件、方法、插槽Vue或 JSX 结构React。 2. 根据代码注释补全 props 的类型、默认值、必填项说明。 3. 编写使用示例代码片段示例中需包含组件基本用法和一个完整业务场景用法。 4. 检查文档是否包含所有必需区块缺少的区块需补齐。 ## 规则 - 文档语言为中文。 - 每个 props 必须列出类型、默认值、是否为必填。 - 示例代码中禁止出现与业务无关的占位符如 xxx、TODO。 - 使用表格展示 props 信息格式固定为“属性名 | 类型 | 默认值 | 必填 | 说明”。3.2 为什么要有 YAML 头信息很多第一次接触这个格式的人会问正文里不都写清楚规则了吗为什么头上还要挂一段 YAML因为模型要在不打开整个文件的情况下快速判断“这个技能适不适合当前任务”。头部元信息就是它的“索引卡”。description 字段写得越精准模型命中率越高name 字段则用来在日志和调试时标识这个 skill。有些平台还会读这里的 version、tags 来做版本管理和分类所以我建议哪怕平台不强制也把这几个字段写上。3.3 正文里的“规则”怎么写才算好正文不要写成长篇论文更不要写成“请务必...”这种没有信息量的废话。我在实践中的体感是模型对“步骤型指令”和“规则型指令”的执行效果远好于“原则型指令”。比如“文档要写得专业一点”就是原则型模型不知道什么叫专业“每个 props 必须列出类型、默认值、必填项”才是规则型模型能准确执行。另外“示例”的力量远超描述——在规则后附上一小段输入和输出的样例模型就能快速对齐你的预期格式。这也是为什么社区里一些成熟的 skills 文件普遍都不短因为示例往往占了很大篇幅。4. 从零到一开发 Skills 的完整实操流程4.1 第一步先用普通对话跑通流程别急着写文件。先把你想固化的任务用普通对话让 AI 做几遍观察它的输出哪里好、哪里不稳定。拿前端代码检查来举例先丢给它一段代码要求“按团队规范检查”看它漏了哪些规则、误报哪些规则。把这些问题记录下来再在 skill 里针对性地写死规则比如“检查点组件命名必须 PascalCase事件处理函数必须用 handle 前缀禁止在 render 中定义匿名函数”。4.2 第二步写好 SKILL.md 后马上测写完文件先别急着投到生产环境。我的做法是开一个新会话模拟一个真实任务看模型能不能自动加载这个 skill。这里有个判断技巧在模型回复里确认它是否读取了 SKILL.md 里的指令通常看它输出的格式符不符合你定义的规则。如果它完全没加载大概率是 meta 信息里的 description 没写好。如果加载了但执行不到位的多半是正文里“规则”和“示例”不够具体。4.3 第三步小步迭代别追求一次完美我第一次写的“后端接口文档生成技能”规则写了将近 200 行自以为很周全实际跑下来却发现问题百出有的字段命名它理解不了有的边界情况它不知道归哪一类。后来我把规则精简到核心 80 行补充了三个错误示例和纠正方式反而稳定多了。我的心得是skills 是一版一版“长”出来的不是一次性“写”出来的。每用一次发现问题就在文件里加一条规则或一个示例。4.4 第四步版本管理和分发skills 本质是文本文件非常适合用 Git 管理。我的目录结构是 skills 根目录下每个技能一个子文件夹里面放 SKILL.md 和相关的脚本或引用文件。团队协作时我会把整个 skills 目录同步到指定位置每个人拉下来口味完全一致——这对团队统一 AI 使用规范特别有用。5. 哪些 Skills 最常用我的清单与思路5.1 前端开发方向的三个技能包结合搜索热词里“前端开发skills”和“superpowers”这两个方向我推荐从这三个入手组件文档生成器前面讲过的那个把“写文档”这个高频劳动彻底自动化团队新人对组件库的理解成本也降下来了。代码审查辅助器让 AI 按团队规范检查变更代码输出未通过项。我写这个 skill 的初衷是自己 review 前后端合并代码时总漏细节现在 AI 能帮我把低级问题筛掉一轮。设计稿转 JSX有些 AI 工具能读取设计稿截图但我更常用的是文本描述 图片的组合。这个 skill 主要封装的是“如何把设计稿描述拆成组件树、如何分配 className、如何响应式适配”这些规则。5.2 写论文、写文档方向的思考看热词里有“codex写论文的skills”“workbuddy skills 写论文”“分镜skills”这些都是一个逻辑把写作类任务的结构拆成固定流程。比如写论文的 skill可以封装“文献综述怎么写、方法论用什么时态、结论部分怎么避免空话”。我建议做写作类 skills 时除了规则一定要放“反例”因为大模型最擅长写正确的废话给它看两个“什么是不合格的段落”效果比给它看三个合格范例还明显。5.3 关于“超能力”类 Skills 的一点实话社区里“superpowers”这波风潮本质是把一些效率极高的工作流做成了开箱即用的技能合集比如自动拆解复杂任务、自动生成测试用例、跨文件重构代码。我自己用下来的体感是这类合集确实能快速打开思路但里面很多 skill 是通用型未必贴合你的实际业务。更好的用法是参考它们的结构和写法再针对自己的场景做微调。别把别人的“超能力”直接当自己的“日课”。6. 安装、引入与分享Skill 的生态现状6.1 现在主流的引入方式虽然各平台的实现细节不一样但主流的有三种本地目录方式把写好的 skill 文件夹放到 Agent 配置的指定目录下比如 Claude 桌面版或 Codex 的配置目录模型启动时自动扫描。适合个人使用。官方市场 / 仓库方式像 Claude 官方市场这种地方可以直接搜到别人分享的 skill 安装包一键下载导入。适合拿来主义。远程 Git / 社区平台直接把 skills 托管在 GitHub 上或者通过一些垂直社区平台下载。这种适合团队内部共享也方便版本管理。我第一次尝试时就是从社区平台下载了一个现成的代码审查 skill导入后用了两天虽然有些规则跟公司规范不一致但它让我直观感受到了“加载一个技能包”是什么体验——模型的输出风格确实一下子改变了。6.2 怎么判断一个 Skill 值不值得装现在各种渠道的 skills 质量参差不齐。我的筛选标准有三条一是看说明文档写得细不细好的技能不会藏着掖着描述和规则都写得很明确二是看更新频率活跃维护的 skill 通常适配新模型更快三是看有没有示例输出没贴示例的 skill 大概率质量不靠谱。踩过几次坑之后我现在下任何一个新 skill都会先在一个小任务上试跑效果好再纳入日常使用。6.3 分享自己的 Skills一种“授人以渔”的玩法写好自己的 skill 之后分享出去也比分享提示词有价值得多。因为提示词只是“台词”skills 是“人工智能的岗位说明书”——别人拿到手不仅知道 AI 干什么还知道 AI 为什么这么干。我在社区分享过自己做的一个“前端组件文档生成器”之后陆续收到一些反馈有人补充了 Vue 场景的规则有人优化了描述字段这比一个人闭门造车成长快得多。如果你也打算开源记得在 SKILL.md 里标清适用平台和模型版本能省去后来人很多试错。7. 常见问题与排查技巧实录7.1 Skill 不生效模型根本不加载这是碰到最多的问题。排查顺序我先看 description 有没有写清楚“何时该用”再确认文件路径是不是平台指定的目录最后尝试新开会话再测——很多 Agent 对配置的加载是在会话启动时完成的中途改文件不一定热更新。实在不生效也别硬抗直接在对话里显式说“请使用 xxx skill 完成”先让它跑起来再回头看定位问题。7.2 规则太笼统模型听懂了但执行偏差模型读了规则但输出跟你想的不一样十有八九是规则里缺少“边界”和“反例”。比如你写“示例代码要完整”模型确实给了完整代码但用了假数据、假函数名——这就是缺“禁止使用占位符”这类规则。加个反例比加一百字正向描述都有效。我调试技能时最常用的方法就是给模型“看一个坏输出”再配一句“不要这样做因为...”它能很快抓住重点。7.3 上下文爆掉技能文件太大有些 skill 写着写着内容越来越长像把整个团队规范都塞进去了。模型虽然能读取但会挤占宝贵的上下文窗口跟当前任务的关联信息反而被稀释。我的建议是SKILL.md 本身控制在几百行内如果确实有大量参考资料可以拆成独立的参考文件在 SKILL.md 里只写“如需详细的 ESLint 规则见 eslint-rules.md”。这样既保证可用性又不拖累上下文。7.4 涉及安全操作的技能需要特别谨慎热词里提到的“安卓脱壳skills”“自动挖洞skills”我得专门提醒一句这类技能涉及逆向分析和漏洞挖掘属于高度专业化领域。如果你是安全从业者做这类技能时一定要控制在授权测试和防御研究的合法范围内不碰未授权目标不发布任何带敏感操作细节的内容如果你只是好奇我更建议先从通用开发技能入手。安全领域的工具链和方法论永远应该在“知道边界在哪里”的前提下使用。8. 绕不开的实战心得我用 Skills 一个月的体会如果让我用一句话概括 Skills 的价值我会说它把“对 AI 的调教成本”从一次性消耗变成了可沉淀的资产。过去我面对一个新项目要重新向 AI 解释团队规范、代码风格、文档格式现在不管什么项目加载对应的 skills它就能保持一贯水准。最直观的数据是我写技术文档的时间从原来的两小时左右压缩到了四十分钟而且不用再反复检查格式。但这东西也不是装上就万事大吉。我的体会是skills 需要像代码一样持续维护。模型升级后原来写得好好的规则可能出现偏差任务的复杂度变了技能的边界也需要调整。我现在的习惯是每月花半天“盘点”一遍自己常用的技能包删掉不适用的、合并重复的、补上新踩坑得出的规则。这种维护成本换来的是每次使用时省下的时间算下来非常值得。最后分享一个小技巧如果你刚开始接触 skills别一上来就写复杂的。选一个你平时让 AI 干得最多、但每次都要重复交代的任务把它写成最简单的 skill——只要写清楚“什么时候用、按什么顺序做、做到什么标准”就行。跑通一次之后你会立刻理解为什么经验能变成资产。
阅读完成 · 觉得有帮助？
