2026年6月24日/ AI Engineering Notes
什么是 Skill?以及开发中常用的主流 Skill 整理
Skill 不是提示词合集,也不是单个工具调用,而是一套可复用的工作流说明。本文整理 Skill 的定义、和 Prompt / MCP / Agent 的区别,并结合 Superpowers 这类开发流程 Skill Pack、Claude Code、Codex 等开发者工作流整理开发中常用的主流 Skill 类型。
Skill 可以理解成一份给 AI Agent 用的“工作流说明书”。
它不是一句 prompt,也不是某个工具本身,而是把一个高频任务拆成固定流程:什么时候触发、需要读哪些上下文、能调用哪些工具、输出什么格式、哪些动作必须停下来确认、最后怎么验证。
用一句话概括:
Prompt 负责说明这次要做什么。
Tool 负责执行一个具体动作。
MCP 负责把外部能力接进来。
Skill 负责把一类任务变成稳定流程。
比如“帮我 review 代码”是一句 prompt;git diff、浏览器、测试命令是工具;MCP 可以把 GitHub、数据库、浏览器暴露给 Agent;而 Code Review Skill 会规定完整流程:先读 diff,再看项目规则,再按严重程度输出问题,最后给验证建议。
Skill 解决什么问题
AI Agent 最大的问题不是不会写,而是容易不稳定。
同一个任务,不同轮对话里它可能:
- 漏读项目规则。
- 顺手改无关文件。
- 输出一堆泛泛建议。
- 忘记跑测试。
- 把高风险动作当普通动作执行。
- 没有记录做了什么。
Skill 的作用就是把这些要求固化下来,让 Agent 每次遇到同类任务时按固定流程执行。
适合写成 Skill 的任务通常有三个特征:
- 高频:经常重复做。
- 有流程:不是随便聊几句就结束。
- 有风险:做错会影响代码、数据、发布或判断。
一个 Skill 应该包含什么
一个可用的 Skill 至少要写清楚 7 件事。
| 模块 | 说明 |
|---|---|
| 触发条件 | 什么任务应该用这个 Skill,什么任务不应该用 |
| 输入要求 | 需要 diff、日志、截图、链接、需求文档还是测试结果 |
| 读取顺序 | 先读 README、AGENTS、SPEC、接口文档还是错误日志 |
| 执行步骤 | 按什么顺序分析、修改、验证、记录 |
| 工具边界 | 能用哪些命令、MCP、浏览器操作,哪些不能自动执行 |
| 输出格式 | 输出 findings、表格、JSON、补丁、报告还是检查清单 |
| 验收标准 | 用什么命令、页面、指标判断任务完成 |
简单例子:
Code Review Skill
触发:用户要求 review / 检查 diff / 看 PR 风险。
输入:git diff、相关文件、项目规则、测试结果。
流程:
1. 先读项目规则。
2. 只关注 bug、回归、安全、性能、测试缺口。
3. 按严重程度排序。
4. 每个问题必须带文件位置、原因、影响、建议。
5. 没有问题就明确说没有高风险项。
禁止:
- 不为了重构而重构。
- 不输出泛泛的“建议优化可读性”。
这比一句“帮我 review 代码”稳定得多。
Skill 和 Prompt 的区别
Prompt 是一次性的任务描述。Skill 是可复用的流程。
Prompt 更适合:
- 临时提问
- 改一段文案
- 总结一段材料
- 解释一个报错
Skill 更适合:
- code review
- 系统调试
- 前端验收
- 技术调研
- 发布检查
- 简历改写
- RAG 评测
如果某个 prompt 你已经复制粘贴了很多次,并且每次都要补一堆边界和格式,那它就应该升级成 Skill。
Skill 和 MCP 的区别
MCP 是工具接入方式,Skill 是工作方法。
MCP 解决的是:
Agent 能不能访问某个外部系统?
比如:
- 读 GitHub issue
- 查数据库
- 控制浏览器
- 调用设计稿
- 读取文档系统
Skill 解决的是:
Agent 拿到这些能力后,应该按什么流程做事?
一个 Skill 可以使用多个 MCP。比如“前端验收 Skill”可能同时用浏览器 MCP、截图工具、终端命令和日志读取。
这些开发 Skill 类型从哪里来
这里的“主流”限定在软件开发过程里,不包含办公文档、PPT、Excel、通用写作这类 Skill。先把一个概念说清楚:Superpowers 本身不是单个 Skill,而是一套开发流程 Skill Pack。它把需求澄清、计划拆分、TDD、系统化调试、代码审查、验证、工作树隔离等流程拆成多个可组合的 Skill。
这篇里的开发 Skill 类型主要参考三类来源:
- 开源开发流程 Skill Pack:Superpowers 这类集合,把 brainstorming、planning、TDD、systematic debugging、code review、verification、git worktree 等开发流程拆成一组 Skill。
- 编码 Agent 社区:Claude Code、Codex、Cursor、Gemini CLI 用户社区里反复出现的开发 Skill,集中在需求澄清、测试、调试、代码审查、前端验收、安全检查、发布检查和交接。
- 官方/半官方示例:官方 Skills 里和开发直接相关的 frontend design、skill creator、代码审查、浏览器验证、项目交接等类型。
所以这份清单更准确地说是:网上公开开发者生态里反复出现、开发时实际会安装或仿写的 Skill 类型。
开发中常用的主流 Skill
1. Requirements / Brainstorming Skill
这类 Skill 在 Superpowers 的 brainstorming / problem shaping 流程,以及 Claude Code 社区的需求澄清流程里很常见。
用途:在写代码前把模糊需求变成可实现、可验收的任务。
常见规则:
- 先问目标用户、核心场景和验收标准。
- 明确不做什么。
- 识别风险点和未知项。
- 输出方案前先确认边界。
- 不直接跳到代码。
适合场景:新功能、重构、复杂 bug、技术选型。
2. Planning / Task Breakdown Skill
这类 Skill 在 Superpowers 的 writing-plans / executing-plans,以及 Codex / Claude Code 长任务 plan workflow 里很常见。
用途:把需求拆成小任务,控制 Agent 不跑偏。
常见规则:
- 每个任务有输入、输出、验收标准。
- 任务粒度控制在可短时间完成。
- 明确要改哪些文件。
- 高风险改动先停下来确认。
- 每步完成后跑验证。
适合场景:多文件改动、长期任务、代码迁移、功能迭代。
3. TDD / Test Writer Skill
这类 Skill 在 Superpowers test-driven-development、TDD Guard 和社区测试优先工作流里很常见。
用途:补单元测试、集成测试、回归测试。
重点规则:
- 先找风险路径。
- 修 bug 时先写失败用例。
- 只补能证明问题的测试。
- 不生成一堆没有断言价值的测试。
- 测试通过后再改生产代码。
适合场景:后端 service、工具函数、API 处理、状态机逻辑、bug 修复。
4. Systematic Debugging Skill
这类 Skill 在 Superpowers systematic-debugging 和大量 Agent 调试工作流里很常见。
用途:处理报错、线上问题、本地启动失败。
执行流程:
现象 -> 复现 -> 收集日志 -> 缩小范围 -> 假设 -> 最小验证 -> 修复 -> 回归测试
关键点是先收集证据,不要直接猜原因。
5. Code Review Skill
这类 Skill 在 Superpowers 的 review 工作流,以及 Claude / Codex 社区的 PR review、simplify、reviewer 类技能里很常见。
用途:检查 PR、diff、提交前改动。
重点规则:
- 只找具体风险。
- 按严重程度排序。
- 每个问题带文件位置。
- 关注 bug、回归、安全、性能、测试缺口。
- 不做风格化长篇点评。
适合输出:
[P1] 问题标题
文件位置:
问题原因:
影响:
建议:
6. Frontend Design Skill
来源:Anthropic 官方 frontend design skill、社区里的 design / UI polish / landing page skill。
用途:让 Agent 做前端页面时先建立设计方向,而不是生成千篇一律的卡片、紫色渐变和普通排版。
常见规则:
- 先判断页面类型:营销页、产品页、后台工具、作品集、游戏。
- 先定字体、色彩、间距、信息层级。
- 避免通用 AI 味布局。
- 真实业务界面优先可扫读和可操作。
- 移动端检查溢出和遮挡。
7. Browser Validation / Playwright Smoke Skill
来源:Claude/Codex 浏览器控制、Playwright smoke test、前端验收类 Skill。
用途:前端页面改完后的浏览器验收。
检查点:
- 页面能打开。
- 关键按钮能点击。
- 表单状态正确。
- 移动端不溢出。
- 控制台没有错误。
- 网络请求没有明显失败。
- 截图和设计预期一致。
这个 Skill 一般要配合浏览器、截图和控制台日志。
8. Codebase Context Skill
来源:Claude Code / Codex 社区里常见的 repo onboarding、context builder、read-before-edit 流程。
用途:让 Agent 在改代码前先读懂项目。
常见规则:
- 先读 README、AGENTS、SPEC、package.json。
- 看目录结构和入口文件。
- 确认包管理器和脚本。
- 搜索相关模块。
- 输出“当前目标、影响文件、验证方式”。
适合场景:接手老项目、二开、跨模块修改。
9. Research Note / Tech Choice Skill
来源:社区里的 web research、source-grounded research、technical research note 类 Skill。
用途:技术调研、工具选型、资料整理。
输出结构:
- 结论
- 关键事实
- 来源链接
- 适用场景
- 不适用场景
- 未确认问题
重点是区分官方资料、社区经验和营销材料。
10. Architecture Review Skill
用途:看系统设计、技术方案、模块拆分。
检查点:
- 边界是否清楚。
- 数据流是否闭环。
- 失败状态怎么处理。
- 权限和安全是否前置。
- 是否有观测和回滚。
- 是否过度设计。
这个 Skill 适合在写代码前使用。
这类 Skill 不一定都有官方名字,但在代码 Agent 社区里很常见:让 Agent 先审方案,再写代码。
11. API Contract Skill
用途:设计或检查接口。
检查点:
- URL 和方法是否符合语义。
- 请求参数是否明确。
- 响应结构是否稳定。
- 错误码是否可处理。
- 幂等性是否需要保证。
- 权限校验在哪一层做。
适合后端接口、前后端联调、开放 API 文档。
12. Security Gate Skill
来源:社区 security review、secrets scan、prompt injection check、Sentry / Trail of Bits / 安全审查类工作流。
用途:高风险改动前检查。
重点检查:
- API key、token、cookie 是否泄露。
- 权限校验是否绕过。
- 用户输入是否进入命令、SQL、Prompt。
- 文件上传是否限制类型和大小。
- 删除、支付、权限、生产配置是否被误改。
这个 Skill 应该偏保守,宁可多停下来确认。
13. Migration / Refactor Skill
来源:社区里的 safe refactor、migration plan、large change workflow。
用途:做框架升级、目录迁移、API 替换、批量重构。
常见规则:
- 先列出影响范围。
- 先做小范围样本。
- 保持行为不变。
- 每一步都可回滚。
- 跑测试和构建。
- 不顺手做无关重构。
适合场景:依赖升级、组件库替换、路由迁移、数据库字段迁移前的代码层改造。
14. RAG Evaluation Skill
用途:知识库、文档问答、RAG 系统评测。
检查点:
- 是否有固定问题集。
- Recall@K 是否记录。
- 引用是否命中原文。
- 无答案问题是否拒答。
- 改切片或 embedding 后是否回归。
- 失败样本是否沉淀。
适合企业知识库、客服问答、内部文档助手。
这类 Skill 在 RAG 项目、知识库项目、企业文档问答里越来越常见。
15. Release Checklist Skill
用途:上线前检查。
检查点:
- build / test / lint 是否通过。
- 环境变量是否齐全。
- 数据库迁移是否确认。
- 回滚方式是否明确。
- 监控和日志是否可用。
- 发布说明是否写清楚。
这个 Skill 不负责替你发布,它负责减少漏项。
16. Handoff Skill
来源:Claude Code / Codex / Cursor 长任务里常见的 handoff、continuation、session summary 工作流。
用途:长任务暂停、换窗口、交接给另一个 Agent。
必须记录:
- 当前目标
- 已完成
- 未完成
- 已修改文件
- 已验证内容
- 未验证风险
- 下一步只做什么
长期项目里,这个 Skill 比很多“智能规划”更实用。
怎么判断一个 Skill 值不值得写
可以用一个简单标准:
如果这个任务你已经反复提醒 AI 三次以上,就值得写成 Skill。
更具体一点:
- 每次都要强调边界。
- 每次都要规定输出格式。
- 每次都要提醒它先读某些文件。
- 每次都要让它跑同样的验证命令。
- 每次都容易因为遗漏步骤出问题。
这些都说明任务已经不是一次性 prompt,而是稳定工作流。
Skill 写得不好会怎样
Skill 不是越长越好。写得差的 Skill 会变成另一种噪音。
常见问题:
- 触发条件太宽,什么任务都想用。
- 步骤太抽象,没有可执行动作。
- 输出格式不固定,最后还是一大段自然语言。
- 没有验证标准。
- 没有禁止事项。
- 把多个不相关任务塞进一个 Skill。
好的 Skill 应该小而清楚。一个 Skill 只解决一类任务。
我的整理顺序
如果从零开始整理,我建议先写这 5 个:
- Requirements / Brainstorming Skill
- Planning / Task Breakdown Skill
- Systematic Debugging Skill
- Code Review Skill
- Handoff Skill
这几个覆盖开发里最容易重复、最容易跑偏、最需要验证的场景。
后面再补 TDD、Frontend Design、Browser Validation、Security Gate、Migration、Release Checklist。
结论
Skill 的价值不是让 Agent 看起来更强,而是让它在高频任务里更稳定。
Prompt 解决一次沟通,Skill 解决长期复用。
真正值得整理的 Skill,不是花哨的“万能助手”,而是那些边界清楚、步骤固定、输出可检查的工作流。把这些流程沉淀下来,AI 才会从“每次重新解释一遍”变成“按规矩持续干活”。
Brief
A Skill is not a prompt collection or a single tool call. It is a reusable workflow spec. This note explains what a Skill is, how it differs from prompts, MCP and agents, and collects useful Skill patterns.