无可就是九头鸟这两年做 Coding Agent 相关的东西，被问得最多的就是：“我到底该怎么让 AI 稳定按我团队的规范干活？” 这个问题过去靠堆 system prompt 强行解决，但 prompt 越长，Agent 越容易选择困难，到了后期基本失控。直到 Skills 这套机制开始普及，我才觉得方向对了：它不是再给 Agent 塞更多规则，而是把“某一类任务该怎么做”打包成独立工作流，让它按需加载、照章办事。这套玩法在 Claude Code、Codex、Cursor 这类工具里都已经支持，而且收益极其明显。
这篇文章准备一步到位做个总结：先讲明白 Skills 到底是什么、为什么能解决 Coding Agent 的痛点，然后把我实际用下来觉得最值得装的 10 个 Skills 逐个拆开讲，接着说优质来源去哪儿找，最后是我自己写 Skill 的一些习惯，以及排查“装了不生效”的实战经验。无论你是刚开始接触 Agent 的新手，还是已经被提示词折腾到烦的老手，这篇应该都能给到参考。
1. 先把概念对齐：Skills 到底解决什么问题
1.1 一句话定义：它是“带标准作业流程的手册”
你可以把 Skill 理解成一个文件夹，里面装着一个主导文件 SKILL.md，再加上若干辅助脚本、模板和参考资料。这个文件夹放在 Agent 能扫描到的固定位置，比如项目的 .claude/skills/ 目录或用户级全局目录。当任务进来时，Agent 会先根据每个 Skill 的 name 和 description 做匹配，一旦判断当前任务跟某个 Skill 相关，就会读取这个 Skill 的内容，然后严格按文档里写的流程来干活。
SKILL.md 的内容结构通常是这样的：
markdown复制---
name: code-review
description: 当需要对代码变更进行审查时使用，适合 PR 评审、提交前检查、代码质量评估等场景。
---
# 目标
对代码变更做分层评审，输出可执行的问题清单。
# 执行步骤
1. 先读变更范围和 diff 概要
2. 按安全性、逻辑正确性、边界条件、可维护性四个维度检查
3. 输出按严重程度分级的评审结果
# 完成标准
- 每个问题都有具体行号或代码片段
- 给出修复建议而不是只说“有问题”
从这个模板就能看出来，Skill 不是一堆规则的堆砌，而是一份“作业指导书”。它把 Agent 本该靠“临场发挥”的部分，变成了有标准、有步骤、有输出的工程流程。这个东西特别像新员工入职时拿到的手册：不靠悟性，靠流程也能做好。
1.2 为什么 Coding Agent 特别吃这一套
核心原因就一个：上下文是有限的资源，且塞越多越乱。你可以在顶层 system prompt 里写 50 条规范，可模型真正处理任务时，每一条都会被分摊注意力，反而不知道该优先服从哪个；而 Skill 采用的是“按需加载”模式，平时只存着不占地方，碰到相关任务才读进来。也就是说，Agent 在写前端时读前端规范，在提交代码时读提交规范，在写测试时读测试规范，每一项规则都拿在“最需要它发挥作用的那一刻”。
另外，Skill 也解决了团队协作的问题。以前每个人自己调 prompt、自己攒规则，换台电脑、换个工具，所有经验全丢。现在把 Skill 放进仓库里，全团队共享，新增成员也能立刻继承整套工作流。我和团队现在把常用的十几个 Skill 直接放在代码仓库的 .claude/skills/ 目录下，谁拉代码谁就有了，不需要额外培训。
1.3 它和 MCP、普通提示词不是一回事
很多人会把 Skills 和 MCP（Model Context Protocol）搞混，这里必须说清楚。MCP 解决的是“连接”问题，比如让 Agent 能查数据库、能调 GitHub API、能操作浏览器，它提供的是“手”和“眼睛”；Skills 解决的是“方法”问题，当这些工具都在的时候，Agent 该按什么顺序用、用什么标准判断结果、怎么输出才符合团队预期，这是 Skill 要定义的。
普通提示词和 Skill 的区别就更明显了。提示词是一次性的，每次都要重新粘；Skill 是结构化的、可复用、可版本管理、可多人维护的工程产物。好的 Skill 甚至自带脚本和模板，不只是一段文字。简单说，提示词像手写便签，Skill 像固化下来的公司 SOP。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 值得装的 10 个 Skills 推荐
下面这 10 个是我自己收集、改造、长期在用之后筛选出来的功能模块，我把它们按功能命名，方便你在不同 Agent 工具里找对应的替代品。每个我都会说明解决什么问题、我实际怎么配置、以及用的时候有什么需要注意的点。
2.1 任务拆解类：task-breakdown
这个 Skill 是刚需中的刚需。它的作用很简单：当用户抛来一个“帮我做一个 用户 管理系统”这样的大任务时，Agent 不会一上来就写代码，而是先把需求拆成阶段性的任务清单，每一步都带明确的验证标准。拆解完以后，它会把计划写到一个 plans/task.md 文件里，而不是只输出在对话里。
我会在 Skill 里明确要求 Agent：每个任务必须包含“完成定义（DoD）”，比如“登录接口完成 = 能通过异常输入测试 + 返回统一格式的 JSON”。这样一个模块一个模块推进，后期就算上下文被洗掉，Agent 重新读计划文件也能接上进度。
经验提示：计划文件放进项目仓库后，我一般会在开发完成后让它“逐个勾选 DoD 并删除已完成项”，避免计划文档越积越厚，后期失去参考价值。这个习惯帮我在长项目里节省了大量重复沟通。
2.2 前端实现类：frontend-react
前端代码是最容易失控的领域。同一个功能，今天用函数组件，明天用类组件，样式的命名也五花八门。我用的这个前端 Skill，核心作用就是让 Agent 在写 React 组件前先遵守团队约定：先看是否要用索引文件导出，组件命名用 PascalCase，样式优先使用设计系统里的 token，不允许在组件里硬编码颜色和间距。
更关键的是，它要求 Agent 在动手写组件之前，先看一遍项目里已有的类似组件，尽可能复用而不是新造轮子。这个规则看起来简单，实际效果特别大——代码风格的一致性直接决定一个前端项目后期的可维护性。我在 Skill 里放了一个最小示例组件模板作为参考，Agent 照着模板写，第一次的产出基本就能通过评审。
2.3 代码评审类：code-review
这个 Skill 相当于给 Agent 装了一个严格的代码评审官。它的检查维度我固定为四条：安全性、逻辑正确性、边界条件、可维护性。每次评审都要求按严重程度分类，输出问题清单，每条必须带具体位置或行号，以及修复建议。输出格式长这样：
| 严重级别 | 位置 | 问题说明 | 建议 |
|---|---|---|---|
| 高 | src/auth/login.ts:42 |
密码明文写入日志 | 改为脱敏后再输出 |
| 中 | src/api/user.ts:88 |
未处理超时异常 | 加超时重试逻辑 |
| 低 | src/utils/format.ts:15 |
函数命名语义不清 | 改为 formatCurrency |
我用下来最大的体感是：配上这个 Skill 之后，Agent 不会再说“代码整体看起来不错”这种废话了，它会真的逐行找问题。在 CI 里跑一轮 MR 自检，能把很多低级问题先堵住，人审的时候轻松很多。
2.4 测试生成类：test-case
这个 Skill 是我认为投入产出比最高的一个。它规定 Agent 在写代码时必须同步产出测试，而且不是那种只覆盖 happy path 的假测试。Skill 里要求：先分析输入输出边界，默认考虑 null、空数组、并发调用、时间依赖、网络异常这些场景；测试命名要体现行为而不是实现细节；Mock 策略要明确，不能无脑 mock everything。
我还会在 Skill 里加一条规则：“如果测试需要 5 分钟以上才能跑完，优先考虑是否可以通过拆分测试减少时间。” 这样 Agent 不会写出一堆超重的集成测试导致 CI 越来越慢。实践下来，这个 Skill 最大的变化是减少了“代码看着对，一上线就崩”的尴尬瞬间。
2.5 Git 工作流类：git-workflow
这个 Skill 主要管理两件事：生成合规的 commit 信息和执行 Git 操作时的安全边界。首先，它要求所有 commit message 符合约定式提交规范，比如 feat: 增加用户信息导出功能、fix: 修复移动端布局错位问题，并且描述要聚焦在“为什么”而不是“改了什么”。
更重要的安全设置是：Skill 里明确禁止 Agent 在没有人工确认时执行高风险命令，比如 force push、reset --hard、删除远程分支这类操作，只允许它给出命令建议，由人确认后执行。然后在需要查看变更时，要求先用 git diff --stat 和 git diff --cached 确认范围，再决定下一步。这套约束让 Agent 在多人合作仓库里变成真正“靠谱的协作者”，而不是危险分子。
2.6 重构迁移类：code-migration
跨语言、跨框架的迁移，是最容易翻车的任务。这个 Skill 的核心原则有三条：尽量保持行为一致、分批小步迁移、每一步都要有验证手段。它要求 Agent 在拿到迁移任务后，先不急着改写，而是先确认现有测试基线是否存在；如果没有测试，先生成基础测试，再开始迁移。
比如把一个老项目从 JavaScript 迁移到 TypeScript，Skill 会要求 Agent 按模块逐批处理，每个模块完成后补齐类型定义并跑通单测，然后才进入下一个模块。这个技能在升级依赖大版本时也很好用，因为它的核心不是“重写”，而是“可控地改造”。我实际经验是，它最大的价值是阻止了 Agent 那种“一上来就大刀阔斧删删改改”的冲动。
2.7 接口设计类：api-contract
这个 Skill 适合做前后端并行开发或者对外提供 API 的场景。它要求 Agent 先根据需求设计完整的 OpenAPI 定义，包含路径、参数、请求体和响应格式，然后基于这个定义生成 TypeScript 类型声明和 Mock 数据。前后端可以同时开始，不用等后端代码写完才能联调。
我在 Skill 里加了一条硬性规定：接口文档必须和代码放同一个仓库目录，任何接口改动必须同步更新定义文件，不允许只改代码不更新文档。这个约束看起来简单，但能解决团队中百分之八十的“接口文档过期”问题。配合类型生成和 mock 请求，整个开发链路会顺滑很多。
2.8 问题定位类：debug-route
这个 Skill 解决的是 Agent 调试时最容易犯的毛病——瞎试。它定义了从报错到修复的完整排查路线：先根据堆栈把错误分类（参数错误、类型错误、资源不存在、依赖升级问题等），然后建立复现路径，再定位最小改动范围，最后才提修复方案。Skill 里有一条我特别强调的规则：“在修改代码之前，必须首先检查相关文档、变更日志和最近几次相关改动。”
有一次我花了大半天定位一个性能问题，后来让 Agent 用这个 Skill 排查，它很快就发现是某个依赖版本升级后内部实现变化导致的，而不是业务代码的问题。如果没有这条规则，它大概率又会去改业务代码，“治标不治本”。这就是方法论的价值。
2.9 数据库优化类：sql-optimization
这个 Skill 让 Agent 在面对数据库相关任务时不只会“给一个 SELECT 语句”，而是能给出真正可落地的优化方案。它要求 Agent 在处理慢查询时分析执行计划，关注是否走了全表扫描、是否存在 N+1 查询、索引顺序是否符合查询条件的选择性。输出建议时必须要附带理由，不允许只写“建议加索引”。
我给它加了两个规则：一是先看 WHERE 条件和 join 字段上的索引分布，再决定索引方案；二是对返回大量行的统计类查询，优先考虑分页或异步方案而不是一条大 SQL 硬怼。这个 Skill 不会把 Agent 变成 DBA，但至少能在日常开发中帮你挡住一大批明显的数据库坏味道。
2.10 技术文档类：docs-writer
我用这个 Skill 来规范 Agent 产出文档的格式和时机。它不是简单地说“写文档”，而是规定了什么场景该生成什么类型文档：功能变更要更新 README，接口变更要更新 API 文档，复杂的决策要写 ADR（架构决策记录），release 时要生成 CHANGELOG。
文档模板里我对语言风格做了约束：用简洁明确的祈使句和目标导向表达，不使用模糊的“大概”“可能”，每个关键操作必须给出可执行的步骤。这个 Skill 用久了之后，项目里的文档就像有人专门维护的一样，而不是开发完就废弃的摆设。尤其在团队协作和项目交接的时候，价值直接拉满。
3. 优质 Skills 从哪找：来源与检索技巧
3.1 官方仓库和文档是优先级
找 Skills 一定要先从官方渠道下手。Claude Code 的官方文档里有专门的 Skills 章节，而且官方仓库里也放了几个示例技能用来展示格式和最佳实践，直接照着写比自己摸索省力很多。Codex 那边也能找到 skills 相关的官方说明和示例目录，OpenCode、Qwen Code 这些开源工具也各自提供了技能文档和社区示例。官方的优势是格式兼容性有保证，不会出现拿回家发现解析不了的问题。
我的建议是：每接触一个新工具，先去它们的官方文档或 GitHub 仓库里搜 skills 这个关键词，把基础示例读一遍，然后再去社区找进阶内容。这样你对格式、加载机制、命名规范会有正确的“基准感”，不会被乱七八糟的二手经验带偏。
3.2 GitHub 上两种高频搜索姿势
第一种是按文件名搜。GitHub 的代码搜索支持按文件名过滤，你可以直接搜 filename:SKILL.md，会搜出大量公开仓库里的技能文件。这个姿势能看到各类团队真实在用的技能内容，特别适合找灵感，比如别人的 code-review 技能是怎么写的、测试技能里定了哪些规则，直接拿来对照学习。
第二种是按路径搜。搜 path:.claude/skills 或者 path:skills，可以快速定位那些把技能放到约定目录里的项目。这种方式能找到很多打包好的完整技能集合，适合直接 clone 下来试用。搜索的时候我习惯加上一个筛选条件：按最近更新时间排序，或者限定最近一年内更新过的仓库。技能这个领域变化太快，一年前的写法可能已经过时，新写的通常兼容性更好。
3.3 值得关注的社区开发者和聚合项目
社区里已经有几个做技能聚合做得不错的项目。比如有人维护了 Awesome 风格的技能收藏列表，把不同方向的技能分好类，从文档生成、代码审查到数据处理都有覆盖。还有一个比较出圈的技能合集叫 Superpowers，它把任务拆解、需求分析、子 agent 协作这些能力打包成一套完整的“技能组”，装完之后 Agent 的做事方式会发生质的变化。前端圈的 Matt Pocock 也经常在社区分享他给 Claude Code 配置的类型推导与前端相关技能，他的写法非常干净，适合做前端方向的人直接抄作业。
多关注这些活跃的作者有个额外好处：他们的技能文件更新频率高，跟着学能第一时间知道这个领域的新玩法。而且他们的技能里很多设计细节值得模仿，比如怎么描述触发条件、怎么组织步骤、怎么定义“完成标准”，这些都是社区经过真实项目踩坑磨出来的，比官方示例更贴近生产场景。
3.4 下载安装前判断“能不能用”的几个信号
下载一个 Skill 之前，别急着装。先看它的目录结构是否完整，是否包含 SKILL.md 这个核心文件；再看 description 是否写清楚了触发场景，描述写得太宽泛的技能容易误触发；然后看它有没有依赖外部脚本或服务，如果有，确认依赖是否和你的环境兼容；最后看更新时间和维护频率，一个长期不更新的技能很可能已经在用旧格式，装了之后大概率会有兼容性问题。
我自己的习惯是装完一个新技能后，立刻找一个最小场景测试触发。比如装完 code-review，就随便改一行代码然后让它审查一下；装完 test-case，就让它给一个函数写测试。测试不过就直接卸载，不留垃圾。这一步坚持下来，技能目录里留下的都是能打的。
4. 自己开发：从零写一个稳定可复用的 Skill
4.1 标准目录结构
一个完整且规范的 Skill 目录，通常长这样：
text复制my-skill/
├── SKILL.md
├── scripts/
│ └── parse_todo.py
├── templates/
│ └── task_plan.md
└── references/
└── api_design_guide.md
SKILL.md 是入口，Agent 优先读它；scripts/ 放一些能被调用的小工具脚本，比如解析任务文件、生成测试报告这些重复性劳动；templates/ 放统一格式的模板文件，比如任务计划模板、API 文档模板；references/ 放详细但非每次都要读的资料，比如完整的设计规范，避免 SKILL.md 本身过长。分工明确之后，技能既好维护，也能控制上下文消耗。
4.2 SKILL.md 的字段模板与解析
一个我常用的基础模板是这样的：
markdown复制---
name: api-contract
description: 设计或修改 REST API 时使用，用于生成和维护 OpenAPI 定义、类型声明与 Mock 数据。适合接口设计、前后端联调、接口文档更新等任务。
version: 1.0.0
author: yourname
---
# 目标
在接口开发前后维护一份可执行的 API 契约，让前后端实现和文档始终一致。
# 核心原则
- 所有接口必须先在 OpenAPI 定义中声明
- 类型声明由定义文件统一生成，禁止手写
- 接口变更必须同步更新文档和 Mock 数据
# 执行步骤
1. 明确接口用途、调用方和数据结构
2. 生成或更新 OpenAPI 定义
3. 同步生成 TypeScript 类型声明
4. 更新 Mock 数据和文档示例
# 完成标准
- OpenAPI 定义能通过格式校验
- 类型声明和定义完全一致
- Mock 数据可以通过请求验证
# 相关参考
- 阅读 references/api_design_guide.md 获取详细规范
- 阅读 templates/openapi_template.yaml 获取定义模板
description 字段是整个技能的“触发器”，它的质量直接决定 Agent 能不能在正确的时机加载这个技能。写的时候不要只写一句“用于 API 设计”，要写明适用任务类型和使用场景，同时点到几个高频触发词，让 Agent 在模糊匹配时更容易命中。
4.3 内容设计上我比较坚持的几条原则
第一，规则写清楚，示例再补充。不要一上来堆一大段案例，先让 Agent 记住核心约束，再看例子；第二，能省则省。SKILL.md 只放核心操作指令，大块头内容一律拆到 references/，需要时再让 Agent 读取；第三，必须有“完成标准”。没有这个字段的技能等于没有终点的跑道，Agent 干到哪儿算哪儿，质量完全看运气。
还有一条很重要的：要允许 Agent 在遇到规则冲突时“停下提问”，而不是自行猜测。比如技能里可以写“若本技能与项目其他指令冲突，暂停执行并请用户决策”。这个兜底设计能避免很多莫名其妙的行为。技能文档本质上是在训练一个不稳定的“员工”，你把异常流程定义得越清楚，它就越稳定。
4.4 写完怎么验证：小步快跑式测试
写完一个 Skill 之后不要直接扔进正式环境。我是这样验证的：先用一个极简的测试任务，明确包含触发词，比如“用 task-breakdown 把登录功能拆成任务”，看它能不能加载并执行；再测试模糊场景，模拟一次真实对话，看技能在描述不直接匹配时能不能被正确触发；最后测试异常场景，故意给出一个超出规范的任务，观察它是否会引用 Skill 里的兜底规则进行提问。
这三个步骤跑完之后，基本能确定这个 Skill 在真实环境里可不可用。整套流程下来大概 30 到 60 分钟，但换来的是未来每次对话的稳定输出。技能这种资产，前期调试越仔细，后期越省心。
5. 装着装着就踩坑：常见问题与实操排查
5.1 装好了但 Agent 就是不触发
这是遇到最多的问题，十次里有八次是位置放错了。很多工具分“项目级技能目录”和“用户级全局目录”，放错位置就加载不到。另外，如果同时存在多个同名技能，工具可能会选择其中一个并忽略另一个，这时要查一下技能名称是否冲突。
还有 description 写得太泛也会导致不触发。比如描述只写“代码质量工具”，Agent 很难判断什么时候该加载它。解决方式也很简单：先把 description 改成带触发词的描述，然后在测试中直接点名让 Agent 使用这个技能，看它能不能成功加载。如果点名能用但自动触发不行，那大概率是描述不够精确，调一下描述就好。
5.2 上下文被技能文件吃掉太多，输出开始变笨
加载了一个很大的技能之后，Agent 明显变得迟钝，这是典型的上下文占用过多。我的处理思路是“能拆就拆”，把 SKILL.md 压缩到只保留最核心的执行步骤和判断标准，把模板、示例、详细规范全部搬到 references/ 或 templates/ 目录，然后在 SKILL.md 里写清楚“执行到第 X 步时，读取 references/xxx.md”。这样既保证了专业性，又不会开场就把上千行内容全塞进上下文。
另一个容易被忽略的点是：同时加载多个技能也会互相挤占上下文。如果你发现 Agent 装了十几个技能后整体变笨了，可以试试把不常用的技能暂时移出默认目录，留几个核心的，随时要用再放回来。
5.3 多个技能互相打架，行为混乱
技能数量多了以后，冲突是难免的。比如 code-review 要求“所有变更必须先提评审意见再提交”，而 git-workflow 要求在提交时自动生成 commit 信息，两个流程叠加就可能让 Agent 卡在原地不知道先干哪个。我习惯在每个技能里都写一句“如果与当前任务无关，忽略本技能的约束”，同时要求 Agent 在所有输出前面加一个简短标记，比如“根据 code-review 技能”或“根据 git-workflow 技能”，这样一旦行为不对，能立刻看出是加载了哪个技能导致的。
定期清理也很重要。我会每隔一段时间检查一次技能目录，把三个月没触发过的技能移走。技能不是为了装而装，装太多反而会变成一场灾难。
5.4 这些场景我建议别用技能
不是所有任务都适合上技能。一次性任务、临时查个资料、简单问答，这些直接对话就能完成，套技能反而增加开销。再一个是“过度工程化”的陷阱：我见过有人为了一个特别简单的格式化输出也写一个技能，维护成本远大于收益，完全没必要。
还有一个安全相关的建议：不要让技能自动调用高危操作。技能文件是文本，本质上也是“不可信的输入”，从网络上下载回来的技能如果在脚本里藏了危险命令，后果会很严重。所有外部下载的技能，我都会先通读一遍 SKILL.md 和 scripts/ 目录，确认没有敏感操作再使用。尤其是团队项目里统一使用的技能，一定要走代码评审流程，不能谁想装就装。
最后再分享一点个人感受：Skills 这个东西，本质上是在帮你把“经验”沉淀成“资产”。一个团队想把 Coding Agent 真正用起来，最好的路径不是追着模型版本跑，而是慢慢积累一套属于自己的技能库。每解决一个问题，就把它固化成一个技能；每踩一个坑，就把它写进技能的“注意事项”里。半年后回头看，你会发现自己手里的 Agent 比半年前稳定太多了，而这才是这个方向真正值得花时间的地方。