Skill扫盲：从提示词补丁到AI工作流，我如何用dev-skill把经验沉淀成能力系统

这半年我越来越强烈地感觉到一件事：

AI Coding 真正的分水岭，已经不只是“模型够不够强”，而是“你有没有办法把合适的方法，在合适的时机交给它”。

很多人第一次接触 Skill，会觉得它只是另一种 Prompt 封装。
但如果你真的在 Claude Code、Codex、Cursor 这类工具里持续做开发，就会发现 Skill 解决的问题，比“保存几段提示词”要大得多。

它在解决的是：

  • 如何减少每次都重复灌上下文
  • 如何让 AI 在对的阶段进入对的工作流
  • 如何把个人经验变成团队可以复用的能力
  • 如何把分析、开发、审查、排障、文档这些动作串成闭环

这篇文章，我想把 Skill 这件事完整讲透，尽量做到既能扫盲，也能落地。

文章会分成四层：

  1. Skill 为什么会出现
  2. Skill 的核心原理和机制是什么
  3. Skill 和 Rules / Commands / MCP 到底怎么分工
  4. 结合我自己的 dev-skill 仓库，看看它在真实研发流程里能做什么

本文内容结合了我在 2026 年 6 月 9 日 的内部分享文档《门店后端AI学习分享-Agent Skill 工作流》，以及当前 dev-skill 仓库中的实际 Skill 设计与目录结构整理而成。

一、为什么会有 Skill

如果你经历过 AI Coding 从早期到现在的演进，会发现大家一直在解决同一个问题：

怎么把合适的信息，在合适的时机，放进模型的上下文里。

一开始最常见的做法，是写 Rules。

比如：

  • 这个仓库的业务背景是什么
  • 编码规范是什么
  • 哪些坑不能踩
  • 哪些目录不能乱改

这些东西一开始很有用，因为它能明显减少模型幻觉。

但问题也很快出现了：

  • Rules 越写越长
  • 很多规则只在特定任务下才相关
  • 它们却会在每次对话里都被加载
  • token 消耗会越来越高

尤其是在真实项目里，你很容易遇到这种情况：

  • 查日志时不需要开发规范
  • 画架构图时不需要数据库排障说明
  • 写文档时不需要完整编码规则
  • 只做链路分析时，不应该每次都把 2000 token 的开发 rules 带上

这就是 Skill 出现的背景。

Skill 的第一性价值

如果把它压成一句话，我会这样定义：

Skill 的本质，是把原来“总是加载”的静态上下文，改造成“按需加载”的动态上下文。

也就是说，Skill 不是单纯多了一个文件格式，而是在改变上下文管理方式。

它追求的是：

  • 先只暴露极少量的索引信息
  • 让 Agent 判断是否相关
  • 真正需要时，再加载完整方法
  • 更深的资料和脚本，继续延后到需要的时候再读或再执行

这就是它最关键的思想：渐进式披露。

二、什么是 Skill

通俗一点讲，Skill 可以理解成：

一份带名字、带描述、带操作说明、还能挂资源和脚本的能力模块。

它通常至少包含两层内容：

  1. 元数据：name、description
  2. 正文：SKILL.md 里的工作流、约束、步骤、触发条件

更完整一点的 Skill，还会带上：

  • references/：参考文档、模板、补充说明
  • scripts/：脚本、校验器、同步器、自动化工具
  • assets/：图片、模板、静态资源

所以一个 Skill 不只是“告诉 AI 该说什么”，更像是：

给 AI 一份“这类任务应该怎么做”的可执行说明书。

三、Skill 的核心原理：渐进式披露

这是 Skill 最值得理解的地方。

很多人第一次听这个概念，会觉得有点抽象。
其实你可以把它想成翻一本手册：

  • 平时只看目录
  • 需要时再翻章节
  • 实在要落地，再去查附录和工具

在 Skill 体系里，大致可以分成三层。

第一层：目录层

这一层通常就是 name + description。

它的特点是：

  • 始终可见
  • 很短
  • token 消耗很低
  • 作用是告诉 Agent：“现在有哪些能力可以选”

这一步本质上是在做能力发现。

第二层：章节层

这一层是 SKILL.md 的正文。

它的特点是：

  • 只有在 Skill 被判断相关后才加载
  • 主要描述 SOP、约束、流程、边界
  • 让 Agent 知道“这类事应该怎么推进”

比如：

  • 先检查项目上下文
  • 再问澄清问题
  • 再产出方案
  • 再拆任务
  • 最后才进入实现

第三层：附录层

这一层通常是：

  • references/
  • scripts/
  • 模板文件
  • 外部数据

它的特点是：

  • 不是一开始就读
  • 需要的时候才展开
  • 有些内容甚至不用进上下文，直接执行脚本就行

这一步很关键，因为它让 Skill 的能力不再只停留在 Prompt，而是开始连接真实文件系统和自动化动作。

一张图看懂 Skill 的三层结构

这套设计的好处非常直接：

  • 平时只花很少 token 看目录
  • 触发后才读方法正文
  • 复杂资源进一步延迟加载
  • 脚本可以直接干活，减少模型硬记细节

如果你做过大项目，就会知道这件事有多重要。
因为上下文预算永远是稀缺资源。

四、Skill 和 Rules、Commands、MCP 到底有什么区别

这是最容易混淆的一组概念。

我现在更倾向于把它们看成同一条链路上的不同层。

1. Rules：静态长期背景

Rules 适合放这种内容：

  • 仓库总原则
  • 通用编码规范
  • 业务红线
  • 不变的团队约定

它的优点是稳定，缺点是会被反复加载。

2. Commands：手动触发的静态入口

Commands 更像是：

  • 一段你希望随叫随到的固定操作模板
  • 一条快捷工作流入口

比如：

  • /openspec-proposal
  • /openspec-apply

它解决的是“重复手动输入”的问题，但本质上仍偏静态。

3. MCP：真实工具与系统接入

MCP 的重点不是“告诉 AI 怎么想”，而是“让 AI 真能做事”。

它可以负责：

  • 查日志
  • 调数据库
  • 调第三方 API
  • 操作 GitHub、飞书、Jira
  • 访问浏览器、桌面、文件系统

所以 MCP 更像工具层。

4. Skill：方法层与工作流层

Skill 的重点是：

  • 什么时候该做什么
  • 做这类事应该遵循什么顺序
  • 该用哪些资源、哪些脚本、哪些 MCP

所以它更像方法层。

一句话区分

你可以这么记：

  • Rules 负责长期背景
  • Commands 负责快捷入口
  • MCP 负责工具能力
  • Skill 负责方法编排

Skill 和 MCP 不是替代关系

这一点特别重要。

很多人会问：

Skill 和 MCP 不都是“给 AI 增强能力”吗？

表面看像，但本质不同。

我更认同这个说法：

MCP 把 Claude / Codex 连接到数据和系统；Skill 教会它如何处理这些数据、何时调用这些系统。

也就是说：

  • Skill 决定“怎么做”
  • MCP 决定“能做什么”

两者组合起来，效果才最好。

五、Skill 能做什么

如果只把 Skill 理解成“写作提示词模板”，会低估它很多。

在真实研发里，Skill 至少能覆盖下面几类事情。

1. 做需求澄清和方案设计

比如我仓库里的：

  • brainstorming

它不是单纯让 AI 多问几个问题，而是把“需求澄清 -> 方案对比 -> 分段确认 -> 落文档”的流程固定下来。

2. 做开发流程编排

比如：

  • sdd-intelligent-router
  • sdd-dev-workflow
  • dev-lifecycle

它们解决的是：

  • 什么任务该快速直做
  • 什么任务该走 Spec 驱动开发
  • 技术方案、提案、实现、测试如何串起来

3. 做代码质量保障

比如：

  • author-final-review
  • code-review
  • full-review
  • integration-test

这里 Skill 不只是“帮你看看代码”，而是把影响面分析、代码质量审查、测试建议变成标准输出。

4. 做线上排障与系统查询

比如：

  • zan-dev-flow
  • zan-log-query
  • zan-rds-ops
  • zan-redis-query
  • zan-apollo-query
  • zan-dubbo-invoke

这些 Skill 已经非常接近“半自动排障助手”了。

5. 做文档与协同系统打通

比如：

  • feishu-wiki-skill
  • project-writer
  • diagram-creation

它们能把文档读写、图表生成、Markdown 同步、图片分析这些动作接起来。

6. 做团队级协作与多 Agent 编排

比如：

  • vibe-working-agent-team

它已经不是单点技能，而是在组织角色分工、tmux 分屏和交付节奏。

所以从结果上看，Skill 可以做的事情远比“一个提示词”丰富得多。

六、结合我的 dev-skill 仓库，Skill 是怎么落地成体系的

说抽象概念容易，但真正有意思的，是它怎么落地。

我自己的 dev-skill 仓库，核心定位非常明确：

一次维护，多端同步，把高频研发流程沉淀成可复用的 Skills，并统一分发到 Cursor、Claude Code、Codex，甚至 OpenClaw 兼容层。

1. 它不是“零散技能集合”，而是一个 source of truth

在这个仓库里，dev-skill 本身是技能源码仓。

也就是说：

  • 日常开发在这里改
  • 团队共享从这里同步
  • 常用 Skill 通过 profile 安装
  • 与其他分发仓通过脚本和 manifest 对齐

这很重要，因为 Skill 一旦多起来，如果没有“单一事实来源”，很快就会失控。

2. 它是分层组织的

仓库当前把 Skills 分成几类：

  • skills/dev/：开发流程类
  • skills/cr/：代码审查与测试类
  • skills/writing/：文档与图表类
  • skills/zan/：排障和内部工具链
  • skills/lark/：飞书协同能力
  • skills/helm/：技能治理类
  • skills/platform/：安装、统计、团队协作等平台能力

这种分类不是为了好看，而是为了降低认知成本。
你看到目录，大致就知道能力落在哪一层。

3. 它支持跨工具同步

dev-skill 不是只服务一个 IDE。

当前这套仓库可以同步到：

  • ~/.cursor/skills
  • ~/.claude/skills
  • ~/.codex/skills.union 与 ~/.codex/skills
  • ~/.openclaw/skills

这意味着同一套 Skill 设计，可以在多个 Agent Harness 里复用。

这一点对团队推广特别关键，因为否则你会陷入：

  • Cursor 一套
  • Claude 一套
  • Codex 再来一套

最后维护成本会非常高。

4. 它不是只管分发，还管治理

这是我很看重的一点。

仓库里不只是有业务 Skill，还有治理 Skill，比如：

  • skill-usage-tracker
  • skill-creator
  • skill-publish
  • knowledge-distiller
  • auto-installer

这说明一件事：

Skill 系统一旦进入团队，就不只是“写几个好玩的 Prompt”，而是要进入完整的生命周期管理。

也就是：

  • 怎么创建
  • 怎么安装
  • 怎么追踪使用
  • 怎么发布
  • 怎么沉淀经验

这是 Skill 从“玩法”走向“基础设施”的标志。

七、从几个代表性 Skill 看它的真实价值

这一段我想直接拿仓库里的 Skill 举例，因为这样比抽象定义更有说服力。

1. brainstorming：把“先想清楚”写成工作流

这个 Skill 的核心思想非常简单，但非常重要：

不要一上来就写代码。

它会要求 Agent：

  1. 先看项目上下文
  2. 一次只问一个关键问题
  3. 给出候选方案和取舍
  4. 分段展示设计并确认
  5. 最后写成设计文档

这其实是在把优秀工程师的思考顺序显式化。

2. sdd-dev-workflow：把 Spec-Driven Development 做成可执行流水线

这个 Skill 更进一步。

它不只是“按方案开发”，而是把下面这些动作串起来：

  • 找技术方案
  • 提取能力点
  • 匹配相关应用
  • 创建 OpenSpec 提案
  • 等待用户确认
  • 按任务顺序实施开发

这已经不是单个 Prompt 能承担的事情了，而是完整的流程编排。

3. full-review：把代码审查做成组合技能

从仓库设计上看，full-review 不是一个孤立技能，而是把多个审查能力组合起来。

它通常会串联：

  • 影响面分析
  • 代码质量审查
  • 测试建议生成

这说明 Skill 的价值不只是“单点能力”，还包括能力编排。

4. zan-dev-flow：把排障入口统一起来

这类 Skill 很适合内部研发场景。

用户不需要先自己决定：

  • 该查日志
  • 该查 Redis
  • 该查 HBase
  • 还是该查 Apollo

而是先从一个统一路由入口进去，再分发到原子能力。

这和前面说的 Skill 负责方法层，MCP 负责工具层 非常契合。

5. feishu-wiki-skill：Skill 不只是“会想”，还应该“会干”

这个 Skill 很有代表性，因为它不仅有说明文档，还有成体系的脚本：

  • 读取 wiki/docx/bitable
  • 下载并分析图片
  • 把 Markdown 同步到飞书文档
  • 渲染 Mermaid 后上传

这说明 Skill 最强的形态，不是纯文本，而是：

文档方法 + 资源说明 + 脚本执行 + 外部系统接入

6. vibe-working-agent-team：Skill 可以上升到多角色协作

这个 Skill 已经开始组织：

  • 多角色分工
  • tmux 多窗口
  • Team Lead 协调
  • PRD -> 方案 -> 开发 -> CR 的交付路径

它让我越来越确信一件事：

Skill 的上限，不是“某个任务怎么做”，而是“一个团队如何协作完成任务”。

八、Skill 的几种关键机制

如果你想真正写好 Skill，光知道概念还不够，还得理解它常见的机制设计。

1. 触发机制

Skill 一般有两种触发方式：

  • 主动触发：用户点名 Skill
  • 被动触发：用户只描述意图，由 Agent 判断该用哪个 Skill

这意味着 Skill 不只是“被调用”，还需要“可发现、可匹配”。

所以 name 和 description 往往特别重要。

2. 渐进式加载机制

这就是前面说的三层披露：

  • 目录层
  • 正文层
  • 资源层

Skill 设计得越好，越不会一开始就把所有东西灌进上下文。

3. 组合与依赖机制

很多大 Skill 本身不会单干，而是组合别的 Skill。

比如仓库里的依赖关系就很典型：

  • sdd-intelligent-router 会路由到 ai-pair-programmer 和 sdd-dev-workflow
  • sdd-dev-workflow 本身依赖其他开发类能力
  • full-review 会串起 review 与测试相关 Skill
  • zan-dev-flow 会分发到日志、缓存、数据库等原子能力

这说明 Skill 系统并不是平铺的，而是一个图。

4. 资源外置机制

很多重要信息不适合都写进 SKILL.md。

更好的做法是：

  • 流程放正文
  • 长说明放 references/
  • 自动化动作放 scripts/

这样既减少上下文噪音，也方便复用和维护。

5. 治理与观测机制

这个机制经常被忽略，但团队化后非常重要。

比如我的仓库里就有：

  • skill-usage-tracker

它会记录：

  • 哪个 Skill 被用了多少次
  • 最近一次是什么场景
  • 哪些 Skill 真正高频

这会反过来影响后续治理，比如：

  • 哪些 Skill 值得继续打磨
  • 哪些 Skill 应该合并
  • 哪些 Skill 实际没人用

九、Skill 设计里，我觉得最有价值的几个经验

写到这里，我其实更想分享一些实践感受。

1. Skill 不是“把 Prompt 存起来”

真正好的 Skill，核心不是文案，而是：

  • 决策顺序
  • 任务边界
  • 信息加载节奏
  • 资源组织方式

Prompt 只是表层。

2. Skill 越贴近真实工作流，价值越大

最有价值的 Skill，往往不是那种“万能专家 Prompt”，而是：

  • 需求澄清 Skill
  • Spec 驱动开发 Skill
  • 审查闭环 Skill
  • 排障路由 Skill
  • 文档同步 Skill

因为这些东西本来就在团队里高频出现。

3. Skill 的核心复利在于经验沉淀

这件事我现在越来越确定。

一个团队真正有复利的，不是每个人都临场发挥得多聪明，而是：

能不能把做过十次、踩过十次坑的事情，沉淀成第十一次可以直接复用的方法。

Skill 恰好就是这种经验的载体。

4. Skill 最终会走向“Prompt + Tool + Workflow + Governance”

如果只看现在，很多人会觉得 Skill 还处在早期。

但从趋势上看，我认为它一定会继续往这几个方向发展：

  • 更强的自动触发
  • 更清晰的依赖图
  • 更成熟的 Skill 市场
  • 更标准的治理与分发机制
  • 更深的 MCP 和脚本联动

换句话说，Skill 不会停留在“方便写 Prompt”这个层面。

它更像是 Agent 时代的方法资产格式。

十、如果你要开始搭自己的 Skill 系统，我建议怎么做

最后给一个更务实的建议。

如果你准备在自己的团队里推广 Skill，我不建议一上来就做几十个。

更稳的路径通常是：

第一步：先找高频且稳定的任务

比如：

  • 需求澄清
  • 技术方案写作
  • 代码审查
  • 日志排障

这些任务的共同点是：

  • 高频
  • 有固定结构
  • 容易标准化

第二步：先把方法写成 Skill，不要急着全自动

一开始最重要的，不是“写多厉害的脚本”，而是先把：

  • 顺序
  • 边界
  • 输入输出

定义清楚。

第三步：再把资源和脚本往外挪

等 Skill 稳定后，再逐步补：

  • references/
  • scripts/
  • 模板
  • MCP 接入

第四步：最后再做治理

也就是：

  • 安装
  • 统计
  • 发布
  • 沉淀

这样做，系统会稳很多。

十一、最后一句话：我为什么觉得 Skill 值得认真做

因为它解决的不是一个“小技巧”问题，而是一个“AI 如何真正进入工作流”的问题。

过去很多人用 AI，像在和一个聪明聊天机器人对话。
但当你开始把：

  • 规则
  • 方法
  • 工具
  • 资源
  • 治理

这些东西组合起来以后，AI 才会开始更像一个真正能协作的执行系统。

而 Skill，正是这条路上非常关键的一层。

它让我们第一次可以比较系统地回答这个问题：

怎么把个人经验，变成团队可复用、可维护、可组合、可演进的 Agent 能力。

这也是为什么我越来越愿意把 dev-skill 这种仓库，看成一种新的研发基础设施，而不只是“AI 时代的提示词收藏夹”。

延伸阅读