2026年6月24日/ AI Engineering Notes

什么是 Skill?以及开发中常用的主流 Skill 整理

Skill 不是提示词合集,也不是单个工具调用,而是一套可复用的工作流说明。本文整理 Skill 的定义、和 Prompt / MCP / Agent 的区别,并结合 Superpowers 这类开发流程 Skill Pack、Claude Code、Codex 等开发者工作流整理开发中常用的主流 Skill 类型。

AISkillsAgentMCPWorkflow

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 个:

  1. Requirements / Brainstorming Skill
  2. Planning / Task Breakdown Skill
  3. Systematic Debugging Skill
  4. Code Review Skill
  5. 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.