文档工作流 Meta-Playbook
当你要做一份项目层文档（战略白皮书 / 产品定义 / 架构 / 工程包 / 任务包 / 等）的任意工作流（新建 / 重写 / 演化 / 跨文档对齐 / 弃用），先读本 meta-playbook，再决定用什么专用 playbook + 什么方法论组合。
本 meta-playbook 不替代专用 playbook，而是提供：
- 五条核心范式的跨层级抽象表达（与文档类型 / 操作类型无关）
- 文档层级矩阵 + 操作类型矩阵 + 决策树（选 playbook 用）
- 共享 vs 特化的清晰边界（共享模板复用 + 特化模板按需）
- 实战驱动起草新专用 playbook 的指南
第一部分：本 Meta-Playbook 的角色
| 角色 | 描述 |
|---|---|
| 范式提炼 | 把跨层级、跨操作类型的共性方法论沉淀（五范式 + 共享模板） |
| 决策入口 | 任何文档工作流启动前先来这里查："我的场景 → 用什么 playbook + 什么方法论组合" |
| 专用 playbook 的索引 | 已有的专用 playbook 列在 §6；缺的按 §7 实战驱动起草指南起 |
| 演化沉淀 | 各专用 playbook 复用后的反馈集中回写本 meta-playbook |
与各专用 playbook 的关系：
document-workflows-meta-playbook.md（本文，沉淀共性 + 提供决策）
|
┌────────────────┼────────────────┐
| | |
architecture-document- <strategic- <product-definition-
rewrite.md（已有） whitepaper- workflow.md>
workflow.md> 按需起草
按需起草
| |
[按需起草的其他专用 playbook]
第二部分：文档层级矩阵（L0-L6）
FinTec AI 生态内的文档按"上位约束 → 下位实施"分 7 层。每层用什么方法论 / 关注什么 / 由谁负责，不同。
| 层级 | 文档类型 | 典型文件 | 主要方法论 | 关注点 | 负责人 |
|---|---|---|---|---|---|
| L0 | 生态级口径 | ecosystem/object-registry.md / ecosystem/current-baseline.md | DDD 共享 ubiquitous language；RFC 跨项目协同 | 多项目对齐的"事实源" / 对象口径 / 边界 | 生态委员会 |
| L1 | 战略级 | projects/<id>/strategic-whitepaper.md | DDD + RFC + 商业模型设计；少 C4；重未决问题 + 验证假设 | 项目定位 / 战略不变量 / 商业模式 / 未决问题 | 项目战略负责人 |
| L2 | 产品级 | projects/<id>/engineering/product-definition.md | DDD + Job Stories / User Stories + 产品行为契约；少 ADR | 用户问题族 / 任务体系 / 输出契约 / 边界 | 项目产品负责人 |
| L3 | 架构级 | projects/<id>/engineering/architecture.md | arc42 精简 + C4 + ADR + DDD + 任务工程包 | 子系统 / 接口契约 / 状态机 / 部署 / 横向贯穿 | 架构负责人 |
| L4 | 工程包级 | projects/<id>/engineering/engineering-packs/m{N}-*.md | task-oriented + 接口子集 + Pydantic / DDL / fixture | 单 milestone 的可执行工程材料 | 工程负责人 |
| L5 | 任务包级 | OpenSpec proposal governance/proposals/inbox/*.md | OpenSpec 提案模板 + task spec | 单次工程任务的输入/输出/验收 | 任务派发人 |
| L6 | 代码级 | 工程实施仓 src/ tests/ | OOSO / Coding Discipline / 各项目工具栈 | 实现 + 测试 + 文档同步 | 实施 Agent / 工程师 |
约束：上位定义下位的边界；下位不得违反上位；任何"反向修订"必须经上位流程（如 governance/change-protocol.md）。
第三部分：操作类型矩阵
任何文档在生命周期内可能经历以下操作。每种操作有特定 Phase。
| 操作 | 描述 | 关键 Phase 差异 | 典型时机 |
|---|---|---|---|
| 新建（greenfield） | 0 → 1，从无到有 | 多 explore + 上位 alignment；review 着重"完整性 / 是否遗漏" | 新项目启动 / 新文档层级建立 |
| 重写（rewrite） | v1 → v2，结构性改写 | 上位对齐 + 下位演化 + v1 归档；review 着重"跨层一致性 + 工程可实施性"。architecture-document-rewrite.md 是本场景的代表实现 | v1 与战略漂移过大 / 旧文档积累过多债务 |
| 增量演化（incremental evolution） | vN → vN.1，小修小补 | 不重写，少 review；着重"是否破坏既有兼容性 / 是否引入回归" | 例行维护 / 新章节补充 |
| 跨文档对齐（alignment） | 多文档差异分析 + 同步 | 跨层 diff + 协调修订；review 着重"对齐完整度" | 上位修订后下位需同步 / 多文档术语漂移 |
| 弃用 / 归档（deprecation） | 文档退役 | 替代指针 + 下游迁移 + archived frontmatter + 顶部归档说明 | 内容被吸收 / v1 整体被 v2 替代 / 概念退役 |
第四部分：跨层级 × 跨操作 的方法论决策矩阵
怎么用本矩阵：行 = 文档层级；列 = 操作类型；格 = 推荐方法论组合 + 推荐专用 playbook（如有）。
| ↓层级 \ →操作 | 新建 | 重写 | 增量演化 | 对齐 | 弃用 |
|---|---|---|---|---|---|
| L0 生态级 | DDD + RFC + Event Storming；走 change-protocol 生态级流程 | 谨慎 + RFC + 跨项目共识；罕见操作 | RFC + change-protocol | RFC + 多项目协同 | change-protocol + 归档 |
| L1 战略级 | DDD + RFC + 商业模型设计 + 验证假设；多 explore | DDD + RFC + 范式 1-3-5（不需 merge-script，单文件够）；未来可起 strategic-whitepaper-workflow.md | 增量段更新 + 五范式纪律；少 review | 上位变化后下位 stub 指针更新 | 归档 + L2/L3 反向修订 |
| L2 产品级 | DDD + Job Stories + 产品行为契约；可参考 L3 范式简化 | DDD + 范式 1-3-5 + 简化版 merge-script；未来可起 product-definition-workflow.md | 增量章节补充 + 五范式纪律 | L1 变化后 stub 指针 + L3 反向同步 | 归档 + L3 反向修订 |
| L3 架构级 | 罕见（项目启动期才有）；用 architecture-document-rewrite.md 的范式但跳过 v1 归档 Phase | architecture-document-rewrite.md（本生态首个完整实战 playbook） | 增量章节 + ADR 起草 + verify-kb | L1/L2 变化后下位同步；用 reviews + 行动方案模式 | 整体归档少；常见是单章节归档 |
| L4 工程包级 | task-oriented 起草（含 Pydantic / DDL / CLI / fixture / CI）；未来可起 engineering-pack-creation.md | 罕见；通常是更新而非重写 | M{N} 完成后写 m{N+1} 新工程包 | 与 L3 主架构对齐 | M{N} 完成后该 milestone 工程包进入 superseded |
| L5 任务包级 | OpenSpec 提案 + task spec | 罕见 | 提案版本迭代（v1 / v2 / v3） | L3 / L4 变化后 task spec 更新 | inbox → accepted/rejected |
| L6 代码级 | OOSO / Coding Discipline / 各项目工具栈 | 工程实施仓自身重构（不在文档治理范围） | PR / commit 流程 | 与 L3-L5 文档对齐 | git deprecation tags |
重要：本矩阵的格内容是推荐基线。具体项目根据自身复杂度可增减（如小项目可跳过 review 阶段）。
第五部分：跨层级共性的五条核心范式
下列五条范式对任何层级 × 任何操作类型都适用（按层级 / 操作有细化）。
详细范式描述见 commons/playbooks/architecture-document-rewrite.md §3。本节只列跨层级适用规则。
范式 1：工作流外化（Workflow Externalization）
| 层级 / 操作 | 适用规则 |
|---|---|
| L1-L3 重写 / 新建 | 必用。governance/workstreams/<workstream-id>/ 目录骨架 |
| L1-L3 增量演化 | 简化用。可以不起独立 workstream 目录，单一 OpenSpec 提案即可承载 |
| L4 起草 / L5 任务包 | 不必。文档自身就是 task-oriented，状态机制由 OpenSpec proposal 流程承载 |
| L0 生态级 | 必用。走 governance/change-protocol.md 完整流程 |
范式 2：主轨 + 任务轨双轨拆分（Dual-Track）
| 层级 | 适用规则 |
|---|---|
| L1 战略 / L2 产品 | 不必。文档体量通常 ≤ 1000 行，单文件即可；多层级（白皮书 + 产品定义）已经是天然双轨 |
| L3 架构 | 当主架构 ≥ 6000 行 / Agent context 占用 ≥ 60% 时启用。详见 architecture-document-rewrite playbook §3 范式 2 |
| L4 工程包 | 本身就是任务轨，不需要二次拆 |
范式 3：多 Agent 跨视角三角验证
| 层级 / 操作 | 适用规则 |
|---|---|
| L1-L3 重写 / 新建 | 必用。至少 4 个 reviewer × 2 轮（R1 + R2） |
| L1-L3 增量演化 | 简化用。1 轮即可，2-3 个 reviewer 切片 |
| L4 工程包起草 | 必用，但 reviewer 维度切片不同（接口完整度 / Pydantic 兼容性 / CI 模板可执行性） |
| L0 生态级 | 必用，且需要跨项目代表性 reviewer |
Reviewer 维度切片按层级：
| 层级 | 典型 Reviewer 维度切片 |
|---|---|
| L1 战略 | 战略一致性 / 商业可行性 / 用户验证假设 / 与生态对象关系 / 上位 ecosystem 对齐 |
| L2 产品 | 用户故事完整性 / 任务体系覆盖 / 输出契约 / 边界 / 上位战略对齐 / 下位架构可承接性 |
| L3 架构 | 跨章一致性 / 上位对齐 / 工程可实施性 / 实施新人 mental model / 落地 Agent 100% 严格 |
| L4 工程包 | 接口完整度 / Pydantic schema 兼容 / DDL 可迁移 / Mock fixture 真实性 / CI 模板可跑通 |
范式 4：Merge-script 模式
| 层级 | 适用规则 |
|---|---|
| L1 战略 | 不必（单文件） |
| L2 产品 | 不必（单文件，除非项目特别复杂） |
| L3 架构 | 必用。architecture-document-rewrite playbook 已含模板 |
| L4 工程包 | 不必（单文件） |
范式 5：战略保真度 + 写作纪律双轨
| 层级 / 操作 | 适用规则 |
|---|---|
| 所有层级 / 所有操作 | 必用。具体禁词清单按层级特化（L1 战略层的禁词来自上位生态约束；L3 架构层的禁词来自 L1+L2 已禁概念） |
第六部分：已有 Playbook 索引
| Playbook | 覆盖层级 × 操作 | 状态 | 推荐使用情境 |
|---|---|---|---|
| 架构文档重构 Playbook | L3 × 重写（含 L3 新建可参考、简化） | active v1.0 | 项目架构文档从 v1 → v2 重写；项目架构新建（跳过 v1 归档 Phase） |
未来按需起草的专用 playbook（实战驱动）：
| 候选 playbook | 覆盖层级 × 操作 | 起草时机 |
|---|---|---|
strategic-whitepaper-workflow.md | L1 × 新建/重写/演化 | 生态内有项目实际要重写战略白皮书时 |
product-definition-workflow.md | L2 × 新建/重写/演化 | 生态内有项目实际要重写产品定义时 |
engineering-pack-creation.md | L4 × 新建 | 生态内有 ≥ 2 个项目都进入 M0 起草工程包时 |
cross-document-alignment.md | 跨层级 × 对齐 | 上位（L1）大改后下位（L2/L3）需要批量对齐时 |
document-deprecation.md | 任意层级 × 弃用 | 生态内有大规模旧文档弃用时 |
约定：
- 缺 playbook 不是阻塞 —— 用本 meta-playbook 的范式 + 项目特化即可启动
- 一个场景被复用 ≥ 2 次后，建议把经验沉淀为专用 playbook
- 起草新专用 playbook 见 §7
第七部分：选 Playbook / 起 Playbook 的决策树
7.1 启动期决策树
你要做什么？
├── 起新文档（greenfield）
│ ├── L3 架构 / L4 工程包 → 沿用 architecture-document-rewrite playbook，跳过 v1 归档 Phase
│ ├── L1 战略 / L2 产品 → 用本 meta-playbook 范式 1/3/5 + 项目特化（未来可起专用 playbook）
│ └── L5 任务包 / L6 代码 → 用 OpenSpec / OOSO / 各工具栈
│
├── 重写已有文档（rewrite）
│ ├── L3 架构 → 用 architecture-document-rewrite playbook ✅
│ ├── L1 战略 / L2 产品 → 用本 meta-playbook 范式 1/3/5 + 项目特化
│ └── L4 工程包 → 通常不重写，用增量演化
│
├── 增量演化（vN → vN.1）
│ ├── 走 OpenSpec 提案 + 简化版范式 3/5
│ └── 不必起独立 workstream
│
├── 跨文档对齐（多文档同步）
│ ├── 用本 meta-playbook §5 范式 3 多 Agent 跨视角验证
│ └── 写跨文档 alignment proposal
│
└── 弃用 / 归档
├── 走范式 5 + 替代指针 + archived frontmatter
└── 通知下游迁移
7.2 是否需要起独立 workstream 的判断
起 workstream（governance/workstreams/<workstream-id>/）：
- ✅ 跨多次会话 / 多个 Agent 协同
- ✅ 涉及 ≥ 2 份文档的修订
- ✅ 预计执行时长 ≥ 10 小时
- ✅ 需要多轮 review 闭环
不起 workstream，直接 OpenSpec 提案：
- ❌ 单次会话 / 单 Agent 完成
- ❌ 单文档单 PR
- ❌ 执行时长 ≤ 2 小时
- ❌ 不需要 review 闭环（如纯措辞修订）
7.3 多 Agent Review 的轮次决定
- R1（必）：跨章一致性 + 上位对齐 + 工程可实施性 + 综合独立验证（混合 Agent 模型）
- R2（视情况）：实施新人 mental model + 落地 Agent 100% 严格 + Codex 综合（当 R1 修订后引入了重大结构变化时启用，如双轨拆分）
- R3+（罕见）：仅在 R2 仍有 P0 阻断且需要新视角时
第八部分：起草新专用 Playbook 的指南（实战驱动）
当某个层级 × 操作的场景被复用 ≥ 2 次，建议把经验沉淀为专用 playbook。起草流程：
Phase A：实战完成后写复盘
每次复用 meta-playbook 或某专用 playbook 后，必须用 templates/architecture-document-rewrite/retrospective.md 模板（或类似）写复盘。复盘必含：
- 本项目与本 meta-playbook 默认基线的差异
- 本项目新增 / 调整的方法论
- 给本 meta-playbook 的反馈建议
Phase B：判断是否值得起专用 playbook
- 该场景被复用 ≥ 2 次 → 值得起
- 与现有 playbook 差异 ≥ 30% → 值得起
- 都不满足 → 留在 meta-playbook 的范式中按需特化
Phase C：起草专用 playbook
起草新专用 playbook 的标准结构（参考 architecture-document-rewrite.md）：
1. 适用场景 / 不适用场景
2. 方法论框架（继承自 meta-playbook）+ 该场景特化部分
3. 该场景特有的核心范式（如有，否则引 meta-playbook 五范式）
4. 11 Phase 启动到收尾执行流程（按本场景特化）
5. 该场景的项目特化适配指南
6. 模板指针
7. 边界与诚实声明
8. Agent 快速启动
9. 来源与反馈
Phase D：发布到 commons/playbooks/
- 文件名
<scope-slug>-workflow.md或<scope-slug>-creation.md或<scope-slug>-rewrite.md - 在本 meta-playbook §6 加索引
- 在
commons/playbooks/README.md加索引
Phase E：共享模板复用 + 特化模板按需
- 共享模板（status / ADR / review-task-packet / merge-script）放
commons/playbooks/templates/shared/（待生态有第二个 playbook 起草时建立） - 各 playbook 特化模板放
commons/playbooks/templates/<playbook-slug>/ - meta-playbook 自身不带模板，所有模板归属各专用 playbook
第九部分：共享 vs 特化的边界
| 资产类型 | 共享（跨所有专用 playbook） | 特化（按层级 / 操作专用） |
|---|---|---|
| 工作流目录骨架 | ✅ governance/workstreams/<workstream-id>/ 通用结构 | 各 playbook 可加自己的子目录（如 architecture 有 drafts/，product 可能有 personas/） |
| status.md 模板 | ✅ 续接协议 + 节点表头 + 收尾协议 | 各 playbook 加自己的"章节追踪表"或类似 |
| ADR 模板 | ✅ Context / Decision / Rationale / Consequences | 各层级特有的 ADR 类型可加专属字段 |
| Review 任务包模板 | ✅ 视角任务 + 待 review 文件 + 输出格式 | 各层级特有的"维度切片" |
| merge-script 模板 | ✅ 通用合并脚本骨架 | 各项目调 TARGET / TITLES / 章节数 |
| 章节草稿模板 | ❌ 特化 | L1 战略章节 vs L2 产品章节 vs L3 架构章节结构差异大 |
| 复盘模板 | ✅ 量化产出 + 五范式实战检验 + 反馈 | 各专用 playbook 加自己的关键指标 |
当前现状：所有模板在 commons/playbooks/templates/architecture-document-rewrite/，标记为该 playbook 专属。待生态有第 2 个专用 playbook 起草时，把共享部分提取到 commons/playbooks/templates/shared/。
第十部分：方法论的边界（诚实声明）
10.1 本 meta-playbook 当前的限制
| 限制 | 说明 |
|---|---|
| 基于单一 playbook 提炼 | 当前 architecture-document-rewrite 是唯一完成实战的专用 playbook。本 meta-playbook 的"共性范式"是基于这一个项目 + 这一个操作类型提炼 |
| L1 / L2 / L4 / L5 的特化部分尚未实战检验 | 表格内的"L1 战略需要什么 / L2 产品需要什么"是基于业界经验 + 类比推导，未经过 FinTec AI 生态内 L1/L2/L4/L5 实战 |
| 决策矩阵需要演化 | 各格内容会在 DH / TM / RLE / FEFM 实战后修订 |
10.2 不适用本 meta-playbook 的场景
- 单次会话完成的小文档（直接做即可，不必走流程）
- 工程实施仓代码层（L6，本 meta-playbook 不覆盖代码工程实践）
- 个人笔记 / 内部草稿（不在治理范围）
10.3 演化期望
每次本 meta-playbook 被复用一次，希望沉淀以下信号：
- 五范式中哪条不适用本场景（需调整范式表达）
- 是否需要新增范式（如某种新场景普遍适用的纪律）
- 决策矩阵中哪一格内容偏离实战（修正）
- 是否值得起新专用 playbook
第十一部分：Agent / 新会话快速启动
新 Agent / 新会话第一次接触本 meta-playbook 时的标准动作：
1. Read commons/playbooks/document-workflows-meta-playbook.md（本文）
2. 查 §4 决策矩阵 + §7 决策树 → 决定本场景用什么 playbook + 什么方法论组合
3. 如有现成专用 playbook（§6 索引）→ 跳到该 playbook §1 适用场景 → 走其完整流程
4. 如无现成专用 playbook → 用本 meta-playbook §5 五范式 + 项目特化启动
5. 工作流收尾时按 §8 判断是否值得起新专用 playbook
6. 写复盘并反馈到本 meta-playbook
第十二部分：来源与版本
当前版本：v1.1（2026-05-28）—— 基于 FinBayes 战略白皮书 v3 重写实战增量
来源：
governance/workstreams/finbayes-arch-rewrite/—— 第一次实战工作流（L3 架构重写，v1.0 基础）governance/workstreams/finbayes-arch-rewrite/2026-05-27-retrospective-and-reusable-methodology.md—— v1.0 项目级复盘governance/workstreams/finbayes-whitepaper-rewrite/—— 第二次实战工作流（L1 战略重写，v1.0 → v1.1）governance/workstreams/finbayes-whitepaper-rewrite/2026-05-28-retrospective.md—— v1.1 复盘commons/playbooks/architecture-document-rewrite.md—— L3 专用 playbook
第十三部分（v1.1 新增）：从 L1 战略重写实战提炼的范式补充
基于 FinBayes 战略白皮书 v3 重写工作流（2026-05-28 完成），v1.0 的五条核心范式补充以下 4 个新范式 + 2 个范式增强。
新范式 6：Stage Gate Dashboard
触发场景：长链路工作流（≥10 小时连续投入）
核心机制：每完成一个 milestone（如每两节草稿、每次大改），停下做以下事情：
- 把本阶段产出列清楚（文件路径 + 关键变化）
- 自检（禁词扫描、不变量校验、边界扫描、verify-kb）
- 浏览器预览路径供用户实时审阅
- 显式列出"你需要决策的下一步"（continue / 调整 / 暂停）
避免的反模式：黑盒一路跑完——用户失去中途审阅机会，发现问题时已是末段大量返工。
新范式 7：v → v+1 Cross-Check
触发场景：任何重写工作流（v→v+1），在合并之前。
核心机制：
- 调度专门的 sub-agent 做严肃 v2 vs 新版交叉对比
- 按章节结构 + 关键概念清单逐项检查覆盖度
- 识别三类内容：完整承接 / 部分承接 / 未承接（Gap）
- 对每个 Gap 标注下游影响等级（高/中/低）+ 影响范围（L2/L3/商业/合规）
- 用户按 gap 优先级拍板补回 / 接受丢失 / 折中
避免的反模式：依赖 review 来发现 gap——review 偏向评价新版质量，cross-check 偏向覆盖度对齐。两者不可替代。
新范式 8：立场降级 Audit Trail ADR
触发场景：v+1 把 v 中的"不可妥协边界 / 战略不变量"降为"当前版本立场，可演化"。
核心机制：起独立 ADR 记录：
- 降级范围（具体哪几条立场）
- 降级理由（产品柔性 / 演化空间 / 商业现实等）
- 演化治理路径（重大调整走 ADR 流程 / 必要时启动战略白皮书 patch 工作流）
- 对下游 L2/L3/商业/合规团队的具体影响 + 维护建议
- 与其他 ADR 的关系
避免的反模式：默默降级而不留 audit trail——下游团队不知道为何"原本是不可妥协的东西现在变成可演化的"，产生 governance 信任损耗。
新范式 9：多 Sub-Agent 并行调度（含调研 / Cross-Check / Review）
触发场景：需要多个独立分析维度并行推进时（不限于评审）。
核心机制：
- 同时调度多个 sub-agent 处理不同维度（如：业内调研 + 本地仓库调研 + 架构调研 + R1 评审 + 下游影响 + cross-check 等）
- 每个 sub-agent 返回简报（≤500-800 字）作为评审材料
- 主会话不读取 sub-agent 中间过程，只综合最终简报
- 避免主会话上下文被中间产物污染
避免的反模式：所有调研都在主会话做——上下文窗口被原始材料占满，没有空间做综合判断。
范式增强 1：范式 3 多 Agent Review 扩展
v1.0 范式 3 强调多 Agent review 中的角色互补（一致性 / 商业 / 写作纪律 等）。v1.1 增强：
- R1 可与下游影响分析并行（不必等 R1 完后再单独跑 R2）—— 让 review 周期更短
- 简报字数严格控制（每个 reviewer ≤800 字）—— 避免长报告稀释关键发现
范式增强 2：范式 5 写作纪律新增"折中方案"应对
v1.0 范式 5 给出写作纪律基本约束。v1.1 增强：
当 cross-check 补回需求（下游有锚）与写作纪律下沉判断（L1 不下沉工程细节）冲突时，按以下折中处理：
- 保留契约层面（数量、机制名、对象名）—— 让下游有指针锚点
- 删除工程实现细节（具体清单、Schema、实施过程描述）—— 让 L1 战略层保持简洁
例：本工作流第五节 7 类任务名保留 + 删除"复盘类必含 X 要素组合"映射示例；Provider 多层降级名称保留 + 删除"4 层具体清单"。
v1.1 后续演化路径
目标演化路径（v1.0 路径基础上更新）：
v1.0 → v1.1：DH 实战后调整→ 实际由 FinBayes 战略白皮书 v3 重写触发（L1 重写场景）- v1.1 → v1.2：DH 实战后调整（数据型项目章节 + L0/L2 实战适配）
- v1.2 → v1.3：TM 实战后调整（合规追溯特化）
- v1.3 → v2.0：4+ 个项目 / 多场景复用后形成稳定通用基线
反馈机制：
- 各项目复盘文档识别出对 meta-playbook 的反馈点 → 通过
governance/change-protocol.md流程评审 → 合并入本 meta-playbook - meta-playbook 自身的版本迭代记录在本节"目标演化路径"中