用 omp 将《大象：Thinking in UML》蒸馏成 Skill

本文是「omp 编程工具使用探讨」专栏的第 11 篇。第 5 篇介绍了 Skill 工程化的概念，这篇用真实案例展示完整过程——把一本 500 页的书蒸馏成可复用的方法论 skill。

Skill 工程化的最终形态是什么？不是把一段 prompt 写进文件，也不是绑定一个部署脚本，而是把一套完整的知识体系固化到 agent 的思维里。

如果你还不熟悉”多 agent”的概念——简单说，就是让多个 AI 实例各司其职，一个负责写代码、一个负责审代码、一个负责跑测试，协同完成一个复杂任务。本文的 4 轮蒸馏中，每轮都在用这种模式。

这篇文章记录一个真实案例：用 omp 将《大象：Thinking in UML》（谭云杰，第 2 版）这本书蒸馏成一个可复用的 thinking-in-uml skill，附带 7 个 slash command，让 AI 在分析 PRD 或代码项目时自动按书中的方法论走。

整个过程通过 4 轮 omp session 完成，每轮解决一个不同层面的问题。

为什么需要这个 Skill

先说说痛点。我日常工作里经常遇到两个场景：

场景一：AI 帮我写了一份 PRD，我该怎么判断它好不好？

洋洋洒洒几千字，看起来什么都有。但仔细一想：利益相关者找全了吗？用例粒度对吗？业务规则是否归类了？抽象层次有没有交叉？这些问题如果不按方法论走一遍，你根本不知道答案。读一遍文档全靠直觉，“感觉还行”不等于”真的没问题”。

场景二：接手一个陌生项目，怎么快速建立心智模型？

拿到一个代码库，几千个文件。光看目录结构只能知道”这是个 Spring Boot 项目”，但不知道”这个项目到底在做什么业务”、“架构合理吗”、“有没有设计问题”。需要一个系统性的视角去快速回答这些问题。

这两个痛点的共同点是：缺一把尺子。AI 生成的文档和代码库的输出，需要一个固定的、可复用的”测量工具”来评估。

为什么是《大象》这本书

《大象：Thinking in UML》提供了这把尺子。全书 500 页，核心思想用一句话就能概括：

UML 只是载体，核心是 Thinking。

作者谭云杰反复强调：画图不是目的，推导才是。书里最核心的建模公式是 人 + 事 + 物 + 规则 = 完整业务模型，加上三层模型转化（现实世界 → 业务模型 → 概念模型 → 设计模型 → 代码），形成了一套完整的、可推导的、可追溯的面向对象分析设计方法论。

这套方法论天然适合固化到 skill 里——它有固定的拆解维度、明确的判断准则、可视化的输出产物（UML 图）。每次分析项目都需要走一遍的方法论，正好是 skill 的最佳场景。

为什么不能每次手动翻书

方法论本身在书里，写得很好。但每次分析项目时：

• 翻书找到对应章节 → 回忆步骤 → 照着做 → 输出结果
• 下次遇到不同项目，再来一遍

这个过程重复得越多，越觉得应该把”翻书 → 回忆”这步自动化。Skill 正好是干这个的——把方法论的执行流程固化下来，让 AI 在分析项目时自动按方法论走，不需要每次手动组织思路。

这个 skill 的目标就是：把《大象》的方法论装进 agent 的上下文里，让它在分析任何 PRD 或代码项目时，自动用这套方法论产出结构化的拆解报告。

这个 Skill 能做什么：三个真实场景

上面说的”好处”可能有点抽象。下面用三个具体场景说明，这个 skill 在实际工作中能帮你做什么。

场景一：审核 AI 写的 PRD

假设你让 AI 帮你写了一份”共享单车系统”的 PRD。AI 写了一堆功能描述，但你看完后不确定：这份文档到底有没有漏洞？该不该放行？

传统做法：你自己读一遍，凭感觉判断”还行”或”不够细”。但”还行”到底是什么意思？

用这个 skill 的做法：运行 /uml-read-spec，AI 自动按《大象》方法论拆解这份 PRD，输出一份结构化报告：

四维度归类表（人 + 事 + 物 + 规则）：

用例清单（带粒度标注）：

• 业务用例：骑行共享单车（完整业务流程）
• 概念用例：扫码开锁（关键步骤）
• 系统用例：填写注册信息、提交审核（人机交互）

疑问清单（自动生成）：

模糊点：计费规则边界模糊——“高峰时段溢价”是按区域还是按时间窗口？ 缺失点：缺少”车辆调度”相关用例——运营人员如何管理车辆分布？ 矛盾点：文档说”注册即送优惠券”，但”优惠券发放规则”章节未定义发放条件。

这些疑问不是 AI 凭空编的——它是根据书里的方法论（用例完整性、边界定义、规则三分）逐项检查后发现的。如果 AI 只是”读了一遍 PRD”裸跑，它不会主动去想”边界在哪里”、“规则有没有三分”。

场景二：接手陌生项目

假设你接手了一个电商后台的代码库，几万行代码，几十个模块。你想快速知道”这个项目到底在做什么”、“架构合理吗”。

传统做法：找个老员工讲一遍，或者自己从 main 函数开始追。但老员工不一定有空，追代码太耗时。

用这个 skill 的做法：运行 /uml-read-code，AI 自动从代码结构反推设计意图：

软件架构反推：

controller/ → 展现层（REST API）
service/ → 业务逻辑层（控制类）
repository/ → 数据持久层（实体类）

参与者与用例反推（从入口代码）：

UserController → 参与者：普通用户、管理员
  POST /login → 用例：用户登录（系统级）
  GET /orders → 用例：查看订单列表（系统级）
OrderController → 参与者：运营人员
  POST /orders → 用例：创建订单（系统级）
  PUT /orders/{id}/status → 用例：修改订单状态（系统级）

业务实体提取（从数据模型）：

User（id, name, email, password_hash, role）
Order（id, userId, amount, status, createdAt）
Product（id, name, price, stock）

代码与文档矛盾点：

README 说”支持多租户”，但代码中没有任何 tenant_id 或租户隔离逻辑 → 标记为”文档声称但代码未实现”。

这比手动 grep 代码高效得多——AI 自动扫了目录结构、入口、数据模型、controller/service，然后按建模公式的四个维度整理输出。你不需要自己遍历几千个文件。

场景三：合规审查（找设计问题）

假设你要 review 一份设计文档，想知道”这份设计有没有违反面向对象原则”。

运行 /uml-check，AI 自动按 8 个检查维度扫描：

每个问题附带修改建议：比如”将 password_hash 改为 private，添加 setPassword(plainText) 方法”、“引入 IDatabase 接口，通过依赖注入注入实现”。

这相当于：你不需要自己记住 10 条反模式的判定标准，skill 替你记住了，而且逐项检查。 手动做一次合规审查至少要花 30 分钟，还得翻书确认每条反模式的判定标准。有 skill 后，一次 /uml-check 几秒钟出结果。

三个场景的共同点

这三个场景背后有一个共同模式：skill 提供了一套”固定的、可执行的检查清单”，把”凭感觉判断”变成了”逐项检查”。

没有 skill 时，AI 裸跑的”分析”是靠直觉——它不知道你期待什么格式的输出，不知道该检查哪些维度。有 skill 后，AI 的输出被方法论格式化：该有的字段一个不能少，该检查的维度一个不能漏。结果质量稳定、可复现、可比较。

这也是这个 skill 和”直接问 AI”的核心区别：直接问”帮我分析这个 PRD”，AI 可能给你一段洋洋洒洒的文字，但不会自动按”人 + 事 + 物 + 规则”四个维度归类，不会自动生成疑问清单，不会自动输出用例图。而 skill 让这些成为默认行为。

以上是 skill 能为你做什么。接下来看怎么做——用 4 轮 omp session，把这个 skill 从零建出来。

第一轮是最大的 session，运行了 Superpowers-Driven Development（SDD）流程。先写设计文档（spec），再写实施计划（plan），然后派了 8 个 subagent 并行执行。

先写 Spec

设计文档定义了 5 个核心设计决策：

1. Skill-Command 解耦：skill 只负责方法论知识，command 只负责入口意图。command 是 30-50 行的薄壳，不重复方法论内容。
2. 三级渐进加载：SKILL.md（主上下文常驻）→ reference.md（按需读取）→ templates（输出时引用），避免一次加载膨胀。
3. 4 套执行流程：流程 A（文档综合理解）、流程 B（代码综合理解）、流程 C（单点分析）、流程 D（合规审查）。
4. 7 个 command 覆盖 2×2 矩阵：两类输入（文档 / 代码）× 两种意图（完整理解 / 单点深耕）留下 4 个单点 command。
5. 输出标准化：所有 command 共用 report.md 和 questions.md 两个模板，输出格式一致。

8 个 Task 并行

然后按照 plan 拆成 8 个 Task，每个 Task 由独立的 subagent 执行，完成后由 reviewer subagent 审查：

每个 Task 由 subagent 实现后，reviewer 立即审查。审查发现的问题（如 report.md 缺 flow B 字段、SKILL.md UML 图集缺调用图、uml-check 缺反模式补充覆盖说明）在 Task 8 的 final fix 中一次性修复。

最终产物：

.omp/skills/thinking-in-uml/
  SKILL.md              # 方法论精简版 + 4 套流程索引（~190 行）
  reference.md          # 详细方法论手册（~340 行）
  README.md             # 用户使用说明
  templates/
    report.md           # 拆解报告骨架
    questions.md        # 疑问清单骨架

.omp/commands/
  uml-read-spec.md      # 综合理解-文档输入
  uml-read-code.md      # 综合理解-代码输入
  uml-stakeholders.md   # 单点-涉众分析
  uml-usecases.md       # 单点-用例提取
  uml-entities.md       # 单点-实体发现
  uml-rules.md          # 单点-规则三分
  uml-check.md          # 合规审查

架构设计的关键

Skill-Command 解耦是这次设计最重要的决策。skill 是方法论的单点来源，command 是 30-50 行的薄壳。维护方法论时只需改 SKILL.md 和 reference.md 两个文件，7 个 command 自动生效——不需要同步 7 个地方的重复内容。

每个 command 的结构：

---
description: 用《大象:Thinking in UML》方法论拆解 PRD/spec/设计文档，输出综合拆解报告
---

加载 `thinking-in-uml` skill，按其中的「流程 A：文档输入」执行。

## 输入
$ARGUMENTS

## 任务
1. 完整读文档，抽取所有名词、动词、规则表述
2. 识别业务目标 → 推导边界
3. 从边界找涉众 → 区分主角/业务工人
...

## 输出
按 `templates/report.md` 输出拆解报告，必须包含：
- 一句话概要（用建模公式）
- 四维度归类表（人/事/物/规则）
- ...

command 只有 30-50 行，逻辑全在 skill 里。薄壳的好处是：新增一个 command 时，只需要写 30 行 markdown 和一个流程字母索引，不需要重复方法论内容。

第 2 轮：精华审计（对着书逐条检查）

第 1 轮构建完成后，我让 omp 做了一件事：读所有 4 个 skill 文件，然后对照《大象》的 5 大支柱逐项评估覆盖度与保真度。

这一步叫”精华审计”（Essence Audit）。设计文档里写的东西，和实际交付的 skill 之间，差的就是这本书的”精华”——那些只可意会不可言传的方法论灵魂。

审计结果让我意识到一个问题：第 1 轮构建出来的 skill 虽然结构完整，但缺少了一层”味道”。

书里 5 大支柱 vs skill 覆盖度

审计发现的具体缺口

审计报告逐一指出了 SKILL.md 和 reference.md 中缺失的精华内容：

• 缺少「Thinking 优先」头条原则：书里反复强调”UML 只是载体，核心是 Thinking”，反对符号堆砌。第 1 版的 skill 虽然有建模公式，但没把这个原则放在最前面。修正后在 SKILL.md 开头加了独立章节：

  ## Thinking 优先（头条原则）
  
  UML 只是载体，核心是 Thinking（面向对象思想 + 可推导、可追溯的分析过程）。
  本 skill 反对把 UML 当符号堆砌——画图不是目的，推导才是。

• 活动图立场缺失：书中第 10.4 节专门强调”活动图是过程化工具，引入有争议；它只是描述业务目标达成过程并借以发现对象的工具——不是分析目标，不是编程依据”。第 1 版 skill 只列出了活动图作为可选的 UML 图，没解释这个关键立场。修正后加入了完整的活动图立场说明。

• 类图三层观点缺失：书中第 10.2 节强调类图分概念层、说明层、实现层，“直接跳到实现层通常是因为不知道有三层”。第 1 版 skill 的 UML 图集只列出了”类图”，没说明三层观点。修正后补充了类图三层观点和生命周期说明。

• 缺少可追溯性检查机制：书中第三部分的核心就是”可追溯”——每一层模型都可以向上追溯验证。第 1 版 skill 有”三层模型转化”的概念，但没有追溯矩阵和一致性检查规则。修正后在 reference.md 中增加了完整的 §12 可追溯工件与检查章节。

• 缺少测试推导方法：书中第 13 章专门讨论如何从用例推导测试例。修正后增加了 §13 测试推导，包含七步推导法和两个覆盖率指标。

• 缺少范式选择讨论：书中第 11 章讨论了用例驱动（UDD）vs 领域驱动（DDD）的范式选择。修正后增加了范式选择讨论，明确 skill 默认采用 UDD。

• 缺少设计模式章节：书中第 4 部分的多个章节讨论设计模式。修正后增加了 §14 设计模式，强调”为需求而寻找模式而非为使用而使用”。

为什么第 1 轮会漏掉这些

这是一个值得反思的问题。第 1 轮的 spec 和 plan 是 AI 根据对书的”理解”写的，但 AI 读的是书的 markdown 转换版（经 OCR 转换），有些细微的论述被漏掉了。精华审计时让 AI 同时读 skill 文件和书的部分原文，对比之下才发现缺失。

这引出一个重要经验：用 AI 构建 Skill 时，不能只靠 AI 对书的”记忆”——需要让 AI 反复对照原文，逐条核验。 第一次构建出来的是”骨架”，精华审计填充的是”血肉”。

第 3 轮：Skill 更新（修复审计发现）

精华审计后，我让 omp 根据审计结果更新 skill 文件。这一轮实际只做了 3 件事：

1. SKILL.md 更新：加了”Thinking 优先”头条原则、反模式 11（符号堆砌）和反模式 12（过度设计），UML 图集补充了调用图、包图、时序图、协作图，更新了图集选用规则和活动图立场。

2. reference.md 追加：增加了 4 个新章节——§11 用例驱动 vs 领域驱动（范式选择）、§12 可追溯工件与检查（追溯矩阵 + 一致性检查规则 + 落地步骤）、§13 测试推导（七步推导法）、§14 设计模式（本质、学习、使用、关键告诫）。

3. report.md 更新：增加了追溯矩阵和测试覆盖两个可选章节。

更新量不大，但都是精华内容——这些恰是书里最值钱的部分。

第 4 轮：回归评估（有 skill vs 无 skill 对比）

最后一步是做回归评估：用统一的测试用例，对比”有 skill 加持”和”无 skill 裸跑”的输出质量差异。

评估框架按 4 套执行流程设计了 A/B/C/D 四个场景，本文展示最具代表性的两个：场景 A（文档输入综合理解）和场景 D（合规审查）。场景 B（代码输入）和场景 C（单点分析）的评估结果类似，不再赘述。

场景 A：共享单车 PRD 拆解

让 AI 分析一份共享单车系统的 PRD，输出综合拆解报告。

无 skill 的输出：缺少一句话概要、建模公式四维度表、追溯矩阵、Mermaid 图、疑问清单——这些是书中方法论要求的输出，但裸跑的 AI 不知道要出这些。

有 skill 的输出：全部覆盖。包含建模公式四维度表、边界与主角划分、用例清单（带粒度标注）、业务实体与领域对象、业务规则三分表、Mermaid 图集（用例图 + 类图 + 活动图 + 状态图）、追溯矩阵、疑问清单。

场景 D：设计合规审查

让 AI 审查一份含反模式的设计文档，输出问题清单。

无 skill 的输出：只覆盖了 8 个检查维度中的 5 个，漏掉了”边界被跨越”、“业务规则散落”、“追溯链断裂”三个维度。没有整体健康度评分，每个问题缺少严重程度标注。

有 skill 的输出：8 个维度全部覆盖，准确检测出”数据库查询是功能当用例”、“密码校验是步骤当用例”、“管理员是名词命名不是用例”、“订单管理与修改订单状态粒度不一”、“数据库不应作为参与者”、“User 类 password_hash setter 破坏封装”、“OrderController 直接 new 实现类未面向接口”等典型问题。

评估结果总结

注：Mermaid 支持用例图、类图、活动图、状态图、时序图，覆盖本文涉及的所有 UML 图类型。协作图和包图需用 PlantUML 等工具补充，不在本文讨论范围内。

注：评估数据基于 2 个测试场景的定性对比，非严格统计。~90% 准确率指有 skill 时 8 个检查维度中覆盖了 7-8 个，~60% 指无 skill 时覆盖了 4-5 个。

有 skill 加持的输出质量明显更高——不是因为 AI 变聪明了，而是因为 skill 给了一套固定的、可执行的检查清单和输出格式。AI 在裸跑时不知道”该看什么”、“该输出什么”，skill 告诉它了。

贯穿 4 轮的 omp 使用技巧

上面的 4 轮过程背后，每一轮都用到了 omp 的魔法关键词（magic keywords）。这些关键词在输入时显示渐变高亮，提交后向 agent 注入隐藏的 System Notice，改变 agent 的行为模式。下面按轮次逐一说明，附带真实的用户输入 prompt。

第 1 轮：ultrathink + orchestrate 双关键词

第 1 轮 SESSION 的起点是这个 prompt：

阅读@《大象：Thinking in UML》（第2版）.md 理解其中的精髓 ultrathink 告诉我你理解后都能做什么工作？

ultrathink 是第一个关键词。它的作用是跳过自动难度分类，直接把 agent 的 thinking level 拉到最高。我当时还不知道这本书能干什么，所以让 agent 先读一遍，用最高推理深度去理解，再告诉我它能做什么。

agent 读完整本书后，给出了一个全面的能力评估，然后我接着写设计文档、实施计划，正式开始 SDD 构建。这时用了第二个关键词：

orchestrate 魔法关键词的作用是激活多 agent 编排模式。8 个 Task，每个 Task 要派 implementer + reviewer 两个 subagent，总共 16 个 agent 实例。如果手动一个个调度，光协调就累死了。

orchestrate 注入的编排规则强制：拆解所有任务、最大化并行、每个 task 自包含、每阶段后验证、重试不吸收。效果是：我只需要写一个 design spec + 一个 implementation plan，然后说”用 subagent-driven-development 执行这个 plan”，agent 会自动拆成 8 个 Task，逐个派 subagent 执行，每个完成后派 reviewer 审查，发现的问题自动派 fix subagent 修，修完再 rereview。12 个 commit 全程自动完成。

第 2 轮：orchestrate 驱动的精华审计

第 2 轮的精华审计也是用 orchestrate 驱动的：

总结原文。每章的主要内容，以及这本书的核心思想。确认 skill 是否领悟了精髓 orchestrate

这个 prompt 做了两件事：一是要求 agent 阅读全书原文并总结每章内容，二是要求它对照 skill 文件检查是否领悟了精髓。

orchestrate 收到后，agent 自动分解成 5 个并行子任务：4 个 subagent 各读一本书的 Part（Part I-IV），产出每章摘要；1 个 subagent 读 4 个 skill 文件；然后主 agent 汇总对比，产出精华审计报告。

这个场景特别适合 orchestrate——任务天然可以拆成 5 个独立子任务（4 个读书 + 1 个读 skill），没有依赖关系，并行度拉满。

第 3 轮：orchestrate 继续 + 并行 task

第 3 轮的 skill 更新是第 2 轮的延续。精华审计报告出来后，我输入：

继续

orchestrate 的编排规则还在生效（一次提交后持续有效直到 session 结束）。agent 自动根据审计结果，拆出 3 个并行修复任务：

• Worker A: reference.md 追加 §11-§14（UDD vs DDD / 可追溯 / 测试 / 设计模式）
• Worker B: SKILL.md 修订（Thinking 头条原则 + 流程追溯 + 检查项 + 触发条件 + 反模式）
• Worker C: report.md 加追溯矩阵和测试覆盖章节

这 3 个 worker 用 omp 的 task 工具并行派发，各改各的文件，互不干扰。串行做的话至少 6 分钟，并行 2 分钟搞定。

第 4 轮：workflowz 驱动 eval 流水线

第 4 轮的回归评估用了 workflowz 关键词：

先修复P1再修复P2, 最后修复p3-p5, 再跑eval验证效果。workflowz

workflowz 注入的是一套”确定性多子 agent 工作流”规则——跟 orchestrate 的灵活编排不同，workflowz 更强调阶段化、有序执行、每阶段完成后才进入下一阶段。

agent 收到后，自动拆成两个阶段：

Phase 1：修复（串行，因为要求有序执行）

• fix-p1 subagent：修 report.md 的孤立 pipe 字符
• fix-p2-p5 subagent：修 SKILL.md 和 uml-check.md 的 4 个问题

Phase 2：Eval（并行 + 聚合）

• 4 个 flow executor 并行跑测试（flow-a with/without skill、flow-d with/without skill）
• 4 个 grader 并行评分
• regrade + aggregate 汇总

workflowz 和 orchestrate 的核心区别在这里：orchestrate 适合”拆成独立子任务，能并行就并行”的灵活编排；workflowz 适合”先做 A，再做 B，最后做 C”的确定性流水线。第 4 轮的要求是”先修复，再验证效果”——修复阶段有顺序依赖（P1 先修，P2 再修，P3-P5 最后修），验证阶段有并行子任务，workflowz 的”阶段化”模式正好匹配。

构建成本：4 轮消耗了 63M tokens

还有一个读者可能关心的问题：这 4 轮蒸馏总共花了多少 token？

从 session 记录里统计了一下：

第 1 轮占了绝大部分（~85%），因为 8 个 Task 的 implementer + reviewer 循环产生了大量对话。后 3 轮加起来不到 10M tokens。

所有 session 都运行在 xhigh thinking level 下，这意味着每个 token 都经过了完整推理。如果换成 auto 模式，token 消耗可能更少，但输出质量也会下降。

模型方面，第 1 轮用了 4 种模型（flash 用于快速 implementer、pro 用于 reviewer、seed-2.0-pro 用于 implementer、glm-5.2 用于阅读中文书）。第 2 轮和第 4 轮主要用 flash（速度快、成本低），glm-5.2 用于需要读中文原文的子任务。

这些数据来自 session 持久化文件（JSONL 格式，omp 默认保存所有会话），每行都记录了 prompt 和 completion 的 token 数。

技巧总结

经验总结：Skill 蒸馏的 4 轮方法论

回头看这 4 轮，每轮解决不同层面的问题：

这个 4 轮模式不是预设的，是从实践中长出来的。第 1 轮做完后直觉告诉我”少了点什么”，于是有了第 2 轮的精华审计。审计发现缺口后自然需要第 3 轮的修复。修复完了想知道效果如何，于是有了第 4 轮的回归评估。

如果只做第 1 轮，得到的是一个”正确但没灵魂”的 skill——结构完整，但缺少方法论的味道。 精华审计正是把”味道”加进去的环节。

跟 book 本身的关系

最后想聊聊”蒸馏”的含义。这本书本身在很多读者心中是”字字珠玑，醍醐灌顶”的存在——作者花了 10 年经验写的 500 页。skill 当然不可能替代这本书，但 skill 能做一件书做不到的事：在需要的时候，自动出现在 AI 的思维里。

你读这本书需要花一周时间，每次分析项目要回忆方法论的步骤。skill 在分析项目时自动加载方法论的上下文，省去了”翻书 → 回忆 → 应用”的环节。

但 skill 也有代价：它丢失了书中的大量案例、讨论、作者的思考过程。skill 版本的”精华”是经过压缩的，只保留了可直接执行的方法论和判断准则。如果你想真正理解”为什么这样建模”，还是得读原书。

所以 skill 和书的关系不是替代，而是互补：skill 负责”在需要时自动执行”，书负责”在需要时深入理解”。

本文是「omp 编程工具使用探讨」专栏第 11 篇。文中所有 skill 文件和 session 记录都在 learnspace 仓库的 src/content/posts/omp/ 目录下，欢迎查看真实产物。