你有没有过这种体验：在 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——只要写清楚“什么时候用、按什么顺序做、做到什么标准”就行。跑通一次之后，你会立刻理解为什么经验能变成资产。
