技能注入系统——三层组合模型

学习目标

• 理解技能注入与技能替换的本质差异
• 掌握 OMC 的三层技能组合公式
• 设计自己的技能注入系统
• 识别技能冲突和组合爆炸问题

前置知识

技能系统的渐进式披露、触发短语设计已在通用知识中介绍：

• Skill 渐进式知识管理

下文假设你已理解 SKILL.md 结构、渐进式披露和触发短语设计，直接聚焦 OMC 的 行为注入式技能组合模型。

项目实践

公式化技能组合

OMC 引入了一个不同于传统技能激活的组合模型。传统技能系统在触发时替换主 Agent 的行为——Skill 的指令覆盖默认系统提示。OMC 的技能则叠加到现有 Agent 行为之上。

组合公式为：

[Execution Skill] + [0-N Enhancement Skills] + [Optional Guarantee Skill]

层级	角色	示例	数量
Execution（执行层）	定义主工作流	autopilot、team、ultrawork、default	必选，1 个
Enhancement（增强层）	添加额外能力	git-master（自动提交）、frontend-ui-ux	可选，0 到 N 个
Guarantee（保证层）	强制完成约束	ralph（不完成不停止）	可选，0 或 1 个

实例分析

示例 1：ultrawork: refactor API with proper commits

• 执行层：ultrawork（最大并行执行）
• 增强层：default（标准构建流程）+ git-master（原子化提交）
• 保证层：无

示例 2：ralph: build a REST API

• 执行层：default（标准构建流程）
• 增强层：ultrawork（并行能力注入）
• 保证层：ralph（不完成不停止）

示例 3：/team 3:executor "fix all TypeScript errors"

• 执行层：team（编队流水线）
• 增强层：自动路由的 Stage-aware 分发
• 保证层：可选 ralph 修饰符

技能注入 vs 技能替换

关键差异：

• 传统模式：Skill 触发时，原始系统提示被替换——只有一个 Skill 活跃
• OMC 模式：Skill 指令叠加到系统提示上——多个 Skill 可同时生效

技能作用域与优先级

OMC 的技能存储分为两级：

目录	作用域	优先级
.omc/skills/	项目级	高（覆盖用户级）
~/.omc/skills/	用户级	低（回退）

项目级技能随 Git 仓库提交和共享，适合团队协作中的统一工作流。

问题与规避

问题 1：技能冲突

当两个 Enhancement Skill 给出矛盾的指令时，OMC 通过优先级排序解决（项目级 > 用户级）。但如果两个同级 Skill 冲突，行为是非确定性的。

规避策略：在 Skill 的 Do_Not_Use_When 中明确列出互斥条件。

问题 2：组合爆炸

随着 Enhancement Skill 数量增加，可能的组合数线性增长。3 个 Execution × N 个 Enhancement × 1 个 Guarantee = 3(N+1) 种可能的组合。

规避策略：OMC 在 omc-reference 中记录了常用组合模式，避免用户随意组合。

问题 3：隐式触发不可见

魔关键词驱动的隐式技能激活可能让用户不知道哪个 Skill 被激活了。

规避策略：通过 <system-reminder> 标签注入激活信息，如 [MAGIC KEYWORD: ralph]。

设计取舍

为什么选择注入而非替换？

维度	注入模式	替换模式
多技能协同	支持——多个 Skill 可叠加	不支持——一次只能一个 Skill
核心稳定性	高——系统提示始终保留	低——系统提示被替换
调试难度	高——多个 Skill 的叠加效果难以预测	低——只有一个 Skill 活跃
上下文消耗	高——多个 Skill 指令占用更多上下文	低——只有一个 Skill 的指令

OMC 的选择：选择注入模式，牺牲调试简单性和上下文效率，换取多技能协同的灵活性。

参考来源

• OMC Architecture - Skills System — 技能注入的官方文档
• Claude Code Skills 文档 — 原生 Skill 系统规范