前 19 章学的 ReAct、loop、Graph、MCP——这些都是"通用基础设施"。但你自己干一段时间活后，会沉淀出只对你 / 你团队有意义的经验：commit 写法、code review 风格、部署节奏、文档模板。Skill 就是把这些沉淀变成"可加载单元"。这一篇把 Skill 是什么、不同 harness 的差异、生态发展讲透。

20.1 什么是 Skill

Skill = 一个文件夹，里面有 SKILL.md 和可能的 references，可被 harness 自动加载，达到"在某场景出现时就调度某种行为"的效果。

my-skill/
├── SKILL.md           ← 主体: trigger + 描述 + 流程
└── references/        ← 可选 references
    ├── patterns.md
    └── antipatterns.md

更精确地说，Skill 包含三要素：

要素 作用 例
Trigger 在什么场景被激活 before_any_response / 用户说"review"
Content 一个 SKILL.md 系统提示,讲解该怎么干 “评审一定要看 diff 不要看好译码”
References 给主 Agent 按需打开的子文件 “patterns.md / anti-cases.md”

Skill 不是 plugin——它不一定要带可执行代码。SKILL.md 本身就是 prompt，读到主 Agent 的上下文里去启发它。

20.2 为什么 Skill 是 Vibe Coding 的真正复利

回想 06 章 Vibe Coding 理念 提到的第五条节奏律：把无聊的循环沉淀。你有过的经验：

  • 第 1 次做 PR review：从头到尾硬想 + 写一长串 checklist
  • 第 5 次：approach 稳了，prompt 固定
  • 第 50 次：prompt 短了 → 写成 .opencode/skills/pr-review/SKILL.md
  • 第 500 次：review 节奏律在团队中共享，新人也能用

这是 Skill 的"复利价值"——你脑里的经验在 prompt 里被人看到、被模型看到、被 review 看到。

Without Skill:  │ prompt 短一短 → 直接对话 → 模型凭借默认 bias 回答
With Skill    : │ Skill 触发 → 模型在 context 中看到沉淀 → 复用经验

最后 5 步 prompt 提升的并非 50% 效率，而是 可以追溯——你能知道"为什么这次 review 有这个标准"。

20.3 Skill 的三种形态

20.3.1 Process Skill

激活后改变 Agent 的工作方式。例：

  • brainstorming：需求来时先 brainstorm，不直接动手
  • tdd：写代码前先写测试
  • systematic-debugging：debug 时先列假设再下场
# brainstorming/SKILL.md

This skill activates when the user is about to enter creative work.
Before implementation, you MUST interview the user about:
  - 目标用户
  - 输入 / 输出边界
  - 已知失败模式
Do not write implementation code until interview ends with explicit "go".

20.3.2 Reference Skill

激活后复用资料库。例：

  • security-research: 拉起安全审查工作的现成流程、清单、references
  • git-master：commit rebase / squash / fixup 的"标准模板"沉淀

20.3.3 Tool Skill

激活后派发并行 subagents 去做某事。例：

  • dispatching-parallel-agents: 把 N 个独立任务 fan-out 给 5 个 subagents
  • subagent-driven-development: 在主 session 里启 subagent 做 PoC，主 thread 收 summary

第三种是 Skill 的"进阶玩法"——把第 13 章讲过的委派模式 封装成 Skill。

20.4 OpenCode / Claude Code / Codex 三家 Skill 形态对照

维度 OpenCode Claude Code Codex CLI / LazyCodex
Skill 文件位置 .opencode/skills/, ~/.config/opencode/skills/, plugin, builtin .claude/skills, ~/.claude/skills, builtin .codex/skills/, ~/.codex/skills/, plugin
触发机制 system prompt 描述 trigger；harness 自己用 BM25 / 规则匹配 类似，自动 inject 同上,二开 LazyCodex 加了 plugin loader
Slash command 关联 Skill 同名可为 slash command 同 同
含 references ✅ 多文件可读 ✅ ✅
沉淀开发源 同 plugin (git installable) plugin / glm git LazyCodex plugin / plugin git
跨 harness 兼容 大部分 compatible，文件可以互复制 compatible compatible

事实上：Skill 的 markdown 写法很容易跨平台——把 SKILL.md 从 .claude/skills/foo/SKILL.md 复制到 .opencode/skills/foo/SKILL.md 通常都能用。只有 harness-specific meta fields 会失配（permission rules 等）。

20.5 Skill 的四种作用域

─────┬─────────┬───────────────────────────
作用域 │位置                  │ 适用场景
─────┼─────────┼───────────────────────────
 builtin │harness 自带            │ 普世流程如 `tdd` / `debugging`
 plugin  │git 仓库的 plugin 包    │ 团队 / 社区共享
 user    │~/.config/opencode/...  │ 你个人跨项目
 project │<repo>/.opencode/...    │ 项目内专用
─────┴─────────┴───────────────────────────

按"地域"选：

  • 你考察过的 review 风格 → user skill
  • 你团队的 commit 规范 → project skill（git 跟项目走）
  • 你公司在做的 SSH 调优 → project skill
  • 世界通用流程：用 builtin / install plugin

20.6 Skill 的"召回机制"

OpenCode 把 trigger 比喻成"判断 + 调度"。粗略实现：

async def maybe_load_skills(user_msg: str, sess_ctx) -> list[Skill]:
    candidates = await discover_all_skills()       # builtin + plugin + user + project
    scored = [(s, score(s.trigger, user_msg, sess_ctx)) for s in candidates]
    return [s for s, sc in scored if sc >= THRESHOLD][:3]   # 最相关前 3

召回关键三件事：

  1. score 阈值：避免每次都把所有 skill 灌入。OpenCode 用 BM25
  2. Top-K 限制：太多了反而让模型分心（context dilution）
  3. De-dupe：同名时优先 project > user > plugin > builtin

20.7 一段具体场景：开新会话触发什么 Skill

假设你在一个新项目下第一次启动 openCode 开对话：

> 我要加一个让用户能上传 csv 的功能

被触发 / 加载的 skill 一路下来：

  1. 💡 using-superpowers: 强制让你在 every response 之前 check skill （这条永远在）
  2. 💡 brainstorming: 这是"创建功能"的 creative work → 应主动展开
  3. ✗ tdd: 还没到写代码阶段,跳过
  4. ✗ git-master: 没说要 commit
  5. ✗ systematic-debugging: 没说要 debug
  6. 💡 frontend (因提到 csv 上传): 如果是 web 项目，会被关联召回

每个 skill 增加几百到几千 token 的 context，但避免你重新跟 Agent 讲一遍“我做新功能前请先 brainstorm”——这就是沉淀的能量。

20.8 Skill 的元级问题：什么该沉淀 / 什么不该

该：

  • 你发现自己第 N 次说"先建 spec 再写 code"的同一个 warning → 沉淀
  • 你给团队同事讲的"PR 标题规范 / commit 前自检清单" → 沉淀
  • 你发现某个 MCP server 的 quirks（如"返回的 description 不是 JSON"） → 沉淀

不该：

  • 只在你一个项目里一次性的临时偏好 → 直接写 prompt
  • 只是 tooling 流程（如 “task lint && task build”） → 写 Taskfile，不写 Skill
  • 涉密细节（真实 token、内部域名） → 永远不要写进 Skill 的 SKILL.md

边界感：“是不是会重复 3 次以上的经验？” 是 → 沉淀为 Skill。

20.9 生态、社区与未来

至 2026 年中观察：

  • superpowers (Robert Obryk, github.com/obra/superpowers)：首批开源 skill 集，覆盖 brainstorming → TDD → debugging → review → verification
  • OhMyOpenCode skills：Sisyphus 内置 build/oracle/metis/momus 等 subagent 派生 skill
  • LazyCodex extensions：Codex CLI 的社区二开，加入了完整 Skill 调用机制
  • 企业内 hub：越来越多公司在内部 git 仓库托管 skill 包，团队 install

未来一年趋势：

  • 跨 harness 兼容性更强（标准化 skill spec 出现）
  • Skill 与 MCP 的边界更模糊：某些 skill 通过 MCP server 实现"代码部分"
  • 在 IDE 内可视化编辑与管理 skill 的工具出现

20.10 小结

  • Skill = SKILL.md + references + trigger，harness 自动召回
  • 三种形态：Process / Reference / Tool
  • 作用域：builtin > plugin > user > project
  • 沉淀判定：是不是 3 次以上重复？
  • 不要把临时偏好 / 一次性临时 prompt / 涉密细节当 Skill

下一篇：《21 Skill 设计原则》——把 SKILL.md 写法的本质拔一层：从"prompt 模板"上升到"行为契约"。

Summary: Skill 是可加载的"经验包"，spawn 出跨项目复利；判别该不该沉淀看"是否重复 3 次以上"。