FinBayes 架构重构复盘 + 可复用方法论
⚠️ 文档定位调整（2026-05-27）：本文档的通用方法论部分已提炼为生态级 playbook 并发布到：
- 主 Playbook：架构文档重构 Playbook —— 含方法论矩阵（arc42 / C4 / ADR / DDD / Google Design Doc 等）+ 五条核心范式 + 11 Phase 流程 + 项目特化适配指南
- 模板目录：架构文档重构 — 模板目录 —— 含 6 份可直接复制的模板（status / ADR / 章节草稿 / Review 任务包 / merge-script / 复盘）
其他生态内项目（DH / TM / RLE / FEFM）应直接读 commons playbook 启动，不再依赖本 FinBayes-specific 复盘。
本文档保留作 FinBayes 项目级历史资产，含 FinBayes 工作流的具体节点 / 时间线 / 实战细节，作为 commons playbook 的"第一次实战参考案例"。
2026-05-26 至 2026-05-27 用约 36 小时（跨 ~20 个工作流节点）完成的工作：把 988 行 v1 工程架构重写为 5976 行 v2 主架构 + 1639 行 M0 task-oriented 工程包 + 6 份 ADR + 9 份 review report + 上下游文档对齐。本文档保留作 FinBayes 项目级复盘资产；可复用方法论已提炼到 commons playbook（见上方 banner）。
第一部分：成果概览
量化产出
| 类别 | 产出 |
|---|---|
| 主架构文档 | architecture.md v2，9 部分 28 节，5976 行，44 张 Mermaid 图 |
| task-oriented 工程包 | m0-walking-skeleton.md，1639 行（10 项 deliverable + Phase 1 五节 P0 扩展） |
| 架构决策（ADR） | 6 份 accepted（ADR-001/002/003 + ADR-004/008/010 M0 最小版）；4 份待 M1+ 起草 |
| 多 Agent Review | R1 四份（跨章一致性 / 上位文档对齐 / 工程可实施性 / Codex 综合）+ R2 三份（实施新人可读性 / 落地 Agent 100% / Codex 综合）+ 2 份综合行动方案，共 9 份 review report |
| 上位文档对齐 | 战略白皮书（5 处旧术语 + 七类任务清单 + 候选两步契约 + 4 层降级 stub）；产品定义（L24 + 7 处 stub 指针 + L127 Session 删除级联 + §1/§3.5/§4.3/§12 措辞） |
| 同位文档归档 | local-runtime-and-entrypoints / session-and-context-architecture / baseline-evaluation 三份 v1 工程化补充文档归档到 _archive |
| 派生路由扩展 | derive-agent-pack.mjs 加 engineering-packs/ 路由 |
| 状态外化 | status.md 共 20 个节点 + 4 份 ADR / 28 份草稿 / 5 份 review + 综合 / 1 份本复盘 |
质量指标
| 指标 | 数值 |
|---|---|
| 战略保真度 grep 命中（合法元引用除外） | 0 |
| 实施新人 mental model 信心打分（R2-A） | 4.75 / 5 |
| 工程化落地 Agent 严格视角 M0 完成度（R2-B） | 80%（拉到 95%+ 需 §28 之外的工程实施仓 bootstrap） |
| Codex 独立 review M0 完成度（R2-C） | 65-75% |
| 三检 review gate 拦截能力（综合 R2） | 6-7.5 / 10 |
| verify-kb 全程跑通 | 100% |
| 跨 Agent 三角验证 | 4 份 R1 + 3 份 R2 = 7 个独立 reviewer 视角 |
第二部分：方法论核心 — 五条可复用范式
范式 1：工作流外化（Workflow Externalization）
问题：长链路、多步骤的文档重构任务，单一 Agent / 单一会话的 context 会爆炸，多次断点续接时心智模型容易漂移。
解法：把工作流状态、决策、草稿都外化到独立目录，会话只是"加工现场"。
目录结构（已验证）：
governance/workstreams/<workstream-id>/
├── status.md # 节点时间线 + 当前状态 + 续接协议
├── decisions/ # ADR-NNN-*.md 独立成档
├── drafts/ # CHAP-NN-*.md 章节草稿
├── reviews/ # 多 Agent Review 报告（按轮次组织）
└── 2026-XX-XX-retrospective.md # 工作流收尾时的复盘（本文）
关键约定：
status.md节点编号严格递增（节点 1 / 节点 2 / ...）+ 每节点描述时间戳 + 完成的事情 + 当前阻塞decisions/与drafts/独立 —— 决策不污染主文档；草稿不污染决策- 续接协议在
status.md头部固定段落："读这份 → 查 ADR → 看草稿 → 不要回看对话历史" - 重要约定固化到
status.md末尾（如稳定 ID 规则 / 写作纪律 / 战略不变量）
收益（实测）：
- 16+ 次会话续接全部能在 ≤3 分钟内重建心智模型
- 多 Agent 接手时不依赖前一 Agent 的会话记忆，靠工作流目录即可
- 工作流结束后整套资产作为历史复盘 + 后续工作流模板
与 ADR-001 的关系：本范式是 ADR-001（Harness Workflow + 里程碑切片 + 走通骨架试点）在文档治理层的实施，与 ADR-001 在工程实施层的实施互为镜像。
范式 2：A+C 双轨文档（治理事实源 + Agent 消费包）
问题：单一架构文档随着完整性提升必然膨胀，工程实施 Agent 一次性 load 时 context 占用 75-85%，多文件操作或调试时易爆。
解法：A 治理事实源（主架构）+ C task-oriented Agent 消费包（engineering-packs/m{N}-*.md）双轨。
A 治理事实源（主架构）：
- 角色：战略 → 业务 → 系统 → 横向贯穿 → 质量 → 缺口 → 落地 的完整契约定义
- 目标受众：评审 / 战略保真度审计 / ADR 起草 / Round-N review
- 大小：5000-7000 行
- 不变量：完整 / 自洽 / 治理可追溯
C Agent 消费包（engineering-packs/）：
- 角色：按里程碑切片，单 milestone 的 task-oriented 工程材料
- 目标受众：M0 / M1 / ... 实施 Agent（Codex / Claude Code）
- 大小：1500-3000 行 / 包
- 不变量：自包含 / 可直接消费 / 与主架构互为指针不重复定义
双轨的契约：
| 维度 | 主架构 | engineering-packs |
|---|---|---|
| 战略不变量 | 定义 | 引用主架构 §N |
| 业务对象 | 定义（含跨层映射表） | 引用主架构 + 给 M0 Pydantic schema |
| 接口子集 | 抽象定义（高层接口） | 具体 M0 implement/stub/skip 表 |
| Pydantic 模型 | 引用 engineering-packs | 完整代码 |
| DDL | 抽象（总览） | 完整 SQL |
| CLI 规格 | 抽象 | 命令字符串 + 退出码 |
| Mock fixture | 概念 | 目录结构 + hash 算法 |
| CI 模板 | 概念 | 完整 yaml |
| 凭证正则 | 策略表 | Python pattern + 词表 source |
| 工程包 bootstrap | 不写 | pyproject.toml + 工具链选定 |
收益（实测）：
- 主架构净降 7.8%（6483 → 5976 行）
- M0 实施 Agent 单次 load context 占用从 75-85% 降到 ~30%
- 与 ADR-001 Walking Skeleton + ADR-003 OpenSpec task packet 范式自然契合
- 主架构演化（M1+ 起草）不污染 M0 工程包；M0 工程包微调（如 fixture 阈值）不污染主架构
约定：
- 每个 milestone 一个 engineering-packs 文件
- engineering-packs 文件命名
m{N}-<slug>.md（如m0-walking-skeleton.md/m1-state-confirmation.md） - 主架构对应章节（如 §28）改为简短指针段（30-80 行），不重复展开
- 横向贯穿关注点（边界 / 可观测 / 演化）继续留在主架构（被各 engineering-packs 引用）
范式 3：多 Agent 跨视角三角验证（Cross-Agent Triangulation）
问题：单一 Agent / 单一视角的 review 会有盲点（如只看可读性不看落地完整性 / 只看战略保真度不看工程可执行性）。
解法：按 user_agent_ecosystem.md 路由表分工 + 多维度并行 + 跨 Agent 互不引用。
实战分工（R1 + R2 两轮共 7 个 reviewer）：
| 轮次 | Reviewer | 视角 | 关键指标 |
|---|---|---|---|
| R1-A | Claude Code sub-agent (researcher) | 跨章内部一致性 | 找出 §8 vs §27 代码骨架冲突 / §11 vs §27 状态机不一致 |
| R1-B | Claude Code sub-agent (researcher) | 上位文档对齐 | 找出战略白皮书 5 处旧术语 / 产品定义 7 处 stub 缺失 |
| R1-C | Claude Code sub-agent (researcher) | 工程可实施性 | 找出 6 项 P0（M0 接口子集 / Pydantic schema / 凭证正则等） |
| R1-D | Codex via codex exec CLI | 综合 + 独立验证 | 反向验证主会话修订生效 + 发现 5 项独立议题 |
| R2-A | Claude Code sub-agent (researcher) | 实施新人 mental model | 信心打分 4.75/5 |
| R2-B | Claude Code sub-agent (researcher) | 落地 Agent 100% 严格 | M0 完成度 80% / gate 拦截 6/10 |
| R2-C | Codex via codex exec CLI | 综合 + 独立验证 | M0 完成度 65-75% / gate 拦截 7.5/10 |
关键纪律：
- 互不引用 —— Reviewer 之间不引用对方报告，避免群体思维偏移
- 覆盖不同维度 —— 每个 reviewer 有清晰的"视角任务"，不重复
- 混合 Agent 模型 —— Claude Code（Sonnet/Opus）+ Codex（GPT-5.5）形成模型多样性
- 统一输出 schema —— P0 / P1 / P2 + 抽查问题 + 强项 + 独立发现 五段式
收益（实测）：
- 单个 reviewer 的发现率约 60-70%；7 个 reviewer 合并后接近 95%
- 跨 Agent 三角验证发现"单 reviewer 看不到"的问题（如 Codex 反向验证主会话修订是否真的生效）
- 不同视角的发现自然分层（P0 阻断 vs P1 重要 vs P2 优化）
调度模式：
| 模式 | 用法 | 适用场景 |
|---|---|---|
Agent 工具（sub-agent，run_in_background=true） | Claude Code 主会话内调度，并行运行 | 维度切片明确的 review，每个 reviewer 任务 ≤200K tokens |
codex exec CLI（worker-dispatch） | 主会话 Bash 调用，独立 session | 用 Codex 配额 + 跨模型三角验证 |
codex exec --skip-git-repo-check < prompt.md > output.md | stdin pipe 任务包 + stdout 重定向 | 任务包结构化、结果可程序化解析 |
范式 4：从草稿到合并的 merge-script 模式
问题：27+ 章独立草稿如何合并为单一主文档？修订时如何避免主文档与草稿分叉？
解法：草稿是事实源 → merge 脚本是机械产物。
脚本（/tmp/merge_architecture.py 一次性使用）：
def main():
chapter_files = sorted(DRAFTS.glob("CHAP-*.md"))
assert len(chapter_files) == N, f"Expected {N} chapters"
# 读主文档，截取到合并标记前
existing = TARGET.read_text(encoding="utf-8")
marker = "<!-- 以下为"
if marker in existing:
idx = existing.index(marker)
end_idx = existing.index("\n", idx)
prologue = existing[:end_idx+1]
else:
prologue = existing
parts = [prologue.rstrip() + "\n\n"]
for f in chapter_files:
body = strip_frontmatter(f.read_text())
body = shift_headings(body, num, title) # # 第N节 → ## N. 标题，其他 heading 下移一级
parts.append(body.rstrip() + "\n")
TARGET.write_text("".join(parts), encoding="utf-8")
约定：
- 修订永远回 drafts/，不直接编辑合并后的主文档（"merged out 不是修订入口"）
- prologue 区（主文档顶部 frontmatter + 目录 + 配套资产指针）在主文档中直接编辑（不在 drafts/）
- 合并标记
<!-- 以下为 N 章正文，由 ... 合并而成 -->划分 prologue 与章节正文 - 跨章引用替换 CHAP-NN → §N 作为合并后的后处理（一次性 sed）
收益：
- 修订单章只需改一个 draft 文件
- 主文档永远是机械产物（不需要担心人工编辑漂移）
- 多次重新合并（本工作流中 4 次）零差错
范式 5：战略保真度 + 写作纪律 双轨
问题：长文档容易掺入战略层被否决的概念 / 防御型清单 / 方法论冗余。
解法：
| 纪律 | 实施 |
|---|---|
| 禁词清单（被否决概念） | verify-kb.mjs 自动 grep + PR Review 人工语义复核（防同义改写） |
| 建设型而非防御型 | 每节首段一句话回答"这节回答什么"；不变成"不许什么"清单 |
| 不解释方法论 | 方法论选择放 ADR；主文档只引结论 |
| 抽象 vs 具体 | 优先 FinBayes 实际场景，少用"系统应该" |
| 图配三段说明 | 图表达什么 / 图特意不表达什么 / 怎么读 |
| 专有名词第一次出现给一句话解释 | 强制 |
实测：禁词命中0（除合法元引用如 §17 Review Gate 段 / §23 拒绝清单 / §26 同义改写示例）；防御型清单完全收敛到 §17 边界与安全（且建设型化重写）。
第三部分：可复用模板 — 文档治理工作流启动模板
启动检查清单（适用于 DH / TM / RLE / FEFM 等项目的架构重构）
## Phase 0：启动条件（治理）
- [ ] 上位事实源齐备？（战略白皮书 + 产品定义文档）
- [ ] 上位文档已对齐？（任务清单 / 业务对象 / 边界 / 未决问题）
- [ ] 工程范式确定？（Harness Workflow / Walking Skeleton 类比）
- [ ] 工程协作模式确定？（OpenSpec / Codex 工具栈 / Review 链路）
## Phase 1：工作流初始化
- [ ] 建 `governance/workstreams/<workstream-id>/` 目录
- [ ] 起 status.md（节点 1：工作流初始化）
- [ ] 起 ADR-001 工程范式 / ADR-002 文档结构 / ADR-003 工程协作（如已存在的项目可继承 FinBayes 范式）
## Phase 2：章节追踪表 + 草稿起草
- [ ] 决定章节数量与结构（参考 FinBayes 9 部分 28 节，按项目特点调整）
- [ ] 起 章节追踪表（在 status.md）—— 每章 ID / 标题 / 状态 / 草稿文件 / 阻塞
- [ ] 按章节分批起草（每批 3-5 章为节点）
- [ ] 每批完成时跑战略保真度 grep + verify-kb + 记节点
## Phase 3：合并为主文档
- [ ] 准备 merge script（继承 finbayes 范式）
- [ ] 起主文档 prologue（frontmatter + 目录 + 配套资产指针）
- [ ] 合并 + §N 替换 + verify-kb
## Phase 4：多 Agent Review（R1）
- [ ] 启动 3 个 Claude Code sub-agent 并行（跨章一致性 / 上位对齐 / 工程可实施性）
- [ ] 启动 Codex worker-dispatch（综合 + 独立验证）
- [ ] 持久化 4 份 review report 到 reviews/
- [ ] 起 R1 综合行动方案
## Phase 5：修订（按 R1 行动方案）
- [ ] P0 修订（必须）
- [ ] P1 修订（建议）
- [ ] 重新合并 + verify
## Phase 6：双轨拆分（如主文档 ≥6000 行）
- [ ] 建 engineering-packs/ 目录
- [ ] 拆出 m0-walking-skeleton.md（含 Pydantic + DDL + CLI + Mock fixture + CI 模板等）
- [ ] 主文档对应章节缩为指针段
- [ ] 扩展 derive-agent-pack.mjs 路由
## Phase 7：多 Agent Review（R2）
- [ ] 启动 R2 reviewer（实施新人 mental model + 落地 Agent 100% + Codex 综合）
- [ ] 持久化 R2 reports + 综合行动方案
## Phase 8：修订（按 R2 行动方案）
- [ ] P0 修订（Phase 1）
- [ ] P1 修订（Phase 2）
- [ ] 重新合并 + verify
## Phase 9：上下游对齐
- [ ] 战略白皮书反向修订（如发现）
- [ ] 产品定义文档反向修订（如发现）
- [ ] 同位 v1 文档归档（被新架构吸收的）
- [ ] proposal accepted（如有挂起的相关提案）
## Phase 10：ADR 关键决策起草
- [ ] M0 接口锁定的 ADR 起草（M0 启动前置）
- [ ] 中优先级 ADR 留 M1+
## Phase 11：工作流收尾
- [ ] CLAUDE.md 提示更新
- [ ] goal-execution / 同类 v1 实施文档 deprecation note
- [ ] status.md 节点收尾 + 工作流状态 active → stable
- [ ] 起复盘文档（本类型）
第四部分：FinBayes 工作流的真实时间线（节点级复盘）
完整时间线见
governance/workstreams/finbayes-arch-rewrite/status.md更新历史段（节点 1 至 20）。本节抽取关键决策时刻。
| 节点 | 时间（相对） | 关键事件 | 经验教训 |
|---|---|---|---|
| 1 | T+0 | 工作流初始化，3 份 ADR 入档，27 章追踪表建立 | 一开始就建工作流目录而非直接写主文档，省后续重构成本 |
| 2-4 | T+1-3h | 第一部分 3 章草稿 + 用户反馈"建设型而非防御型 + 不解释方法论" + 重写 | 用户级写作纪律反馈越早越好 |
| 3-4 | 同上 | "0 命中"/"Case Library 作门禁"的 Goodhart's law 警觉 + 改为"机械 grep + 人工实质语义核查"双层 | 战略保真度的实施机制本身要防钻空子 |
| 5 | T+5h | 第二部分 3 章草稿 | 业务建模章节是后续所有章节的基础，要早做 |
| 6 | T+8h | 用户反馈任务类型不能写死 + 关系图换 flowchart + 动态画像方向调整 + 启动意图识别深度调研 | 战略层未决问题在工程层抢答前，必须先跑研究 |
| 7-9 | T+10-22h | 第三 / 第四 / 第五部分 10 章草稿 | 6 子系统 / 4 状态机 / 8 sequence 是工程层最丰盛的产出 |
| 10 | T+23h | 第六部分 3 章 + 进入横向贯穿关注点 | 横向贯穿章节看起来散，实际上是各 milestone 共享的基础 |
| 11-13 | T+25-28h | 第七 / 第八 / 第九部分 8 章草稿 —— 28 章草稿全部收官 | 量产期保持节奏一致 |
| 14 | T+29h | 主文档合并（5796 行）+ v1 architecture.md 归档 | 合并脚本一次性使用即可 |
| 15-16 | T+30-32h | R1 4 reviewer 并行（含 Codex 直接调度）+ 综合行动方案 | codex exec CLI 是 worker-dispatch 的真正实现 |
| 17 | T+33h | 上位文档（战略白皮书 / 产品定义）直接修订 + 同位 v1 工程文档归档 | 当 reviewer 一致指出上位漏洞时，主控可直接改 —— 不必拘泥于"上位不动"原则 |
| 18 | T+34h | A1 + A2 + C1 + 多处 P1 整改 + 重新合并 | 双轨拆分前先解决主架构内部冲突 |
| 19 | T+35h | R2 三 reviewer（含 Codex）+ 综合 + Phase 1/2 行动方案 | 第二轮 review 维度从"理解层"切换到"落地层"，发现深得多 |
| 20 | T+36h | A+C 双轨拆分（engineering-packs/m0-walking-skeleton.md 1639 行）+ Phase 1 五节 P0 扩展 + Phase 2 五项 P1 修订 + 派生路由扩展 | 双轨拆分一定要在足够多 review 后做 —— 不要早拆（早拆 = 草稿期就分裂） |
第五部分：给 DH / TM / RLE / FEFM 的具体建议
Data Horizon（DH）— 数据感知层
与 FinBayes 的差异：
- DH 是数据管道项目，不是 LLM 应用 —— 业务建模章节会简单很多（无任务类型 / 综合层 / 综合输出契约）
- DH 的 first-class 业务对象偏数据型（事件 / 实体 / 时间线 / 数据点 / 数据源）
- DH 的边界与安全约束不同（不收凭证仍适用；但有数据源 licensing 约束）
复用建议：
| 范式 | 复用方式 |
|---|---|
| 工作流外化 | 直接复用，建 governance/workstreams/data-horizon-arch-rewrite/ |
| A+C 双轨 | 直接复用，engineering-packs/ 按数据 source / pipeline 切（不按 LLM-milestone） |
| 多 Agent 跨视角 review | 维度调整：跨章一致性 / 数据源契约对齐 / 数据质量保证 / 与 FinBayes 接口契合 |
| merge-script | 直接复用脚本模板 |
| 战略保真度纪律 | 直接复用，DH 已有禁词清单（如"不替 FinBayes 判断"等） |
DH 特有的章节建议：
- 数据源注册与生命周期
- 数据质量指标体系（freshness / completeness / accuracy / lineage）
- 数据 schema 版本化（schema_version + migration 比 FinBayes 更复杂）
- 与 FinBayes / Trading Matrix 的接口契约（事件 / 实体 / 时间线的下游消费）
Trading Matrix（TM）— 交易执行支持
与 FinBayes 的差异：
- TM 是执行层项目，与 FinBayes "不下单不持账户凭证"边界镜像（TM 持凭证 + 受治理执行）
- TM 的边界与安全约束远比 FinBayes 严格（金融执行凭证管理 / 多步骤交易签名 / 审计合规）
- TM 的状态对象偏交易型（订单 / 仓位 / 资金流 / 执行回报）
复用建议：
| 范式 | 复用方式 |
|---|---|
| 工作流外化 | 直接复用 |
| A+C 双轨 | 直接复用，engineering-packs/ 按执行场景切（市价单 / 限价单 / 网格 / 等） |
| 多 Agent 跨视角 review | 维度增加合规视角：跨章一致性 / 合规边界 / 执行可靠性（含恢复路径）/ 与 FinBayes 接口契合 / 监管审计可见性 |
| 战略保真度纪律 | 直接复用 + 加强凭证保护审计（TM 的凭证不变量 ≠ FinBayes 的"不收不存"，而是"严格受治理存储 + 多签 + 行为审计"） |
TM 特有的章节建议：
- 凭证管理（与 FinBayes 凭证不变量正交但不冲突的设计）
- 多步骤交易签名流程
- 执行回报与对账
- 监管合规审计
- 与 FinBayes / DH 的接口契约
RLE（强化学习引擎）— 反馈学习引擎
与 FinBayes 的差异：
- RLE 是学习层项目，整合 FinBayes / TM / 用户反馈，产出模型改进
- RLE 的业务对象偏数据型（轨迹 / 奖励 / 模型版本 / 实验）
- RLE 的边界与安全约束（用户隐私 / 数据脱敏 / 模型版本回滚）
复用建议：
- A+C 双轨可能不够 —— RLE 可能需要 三轨：(A) 治理事实源 (B) 实验包（每个实验一份 task-oriented） (C) 模型部署包
- 工作流外化适用
- 多 Agent review 维度：数据采集合规 / 实验设计严谨度 / 与生态各产品接口契合
FEFM（金融领域基础模型）— 金融专家大模型
与 FinBayes 的差异：
- FEFM 是模型层项目，产出基础模型供 FinBayes / DH / TM 调用
- FEFM 的工程范式更接近 ML training pipeline + 模型服务
- FEFM 的 ADR 会涉及预训练数据 / 微调策略 / 量化推理 / 部署形态
复用建议：
- A+C 双轨适用 —— A 治理事实源 + C 训练实验包 / 评估包 / 部署包
- 工作流外化适用
- 多 Agent review 维度：模型质量评估 / 训练数据合规 / 与生态接口契合
第六部分：方法论的反思与边界
这套方法不适用的场景
| 场景 | 不适用原因 |
|---|---|
| 单一 Agent / 单次会话即可完成的小重构 | 工作流外化 + 多 Agent review 的开销不值 |
| 战略 / 产品定义尚未稳定的项目 | 架构重写需要稳定上位作为锚点；上位漂移会让所有努力作废 |
| 纯文档润色（不涉及结构 / 决策变化） | 不需要 ADR / Review 闭环；用普通 PR 流程即可 |
| 工程实施仓的代码层 | 这套方法是文档治理层，不适用直接写代码（代码层用 OpenSpec task packet 范式） |
这套方法的真实限制
- 依赖人工裁决 —— 多 Agent review 找出 P0/P1，但最终修订决策仍需主控人裁决（Agent 不能自主推进战略层修订）
- 依赖工具链 ——
codexCLI / Claude Code Agent / verify-kb / merge script —— 任一缺失需要替代方案 - 依赖工作流维护者的纪律 —— 节点编号、frontmatter 规范、战略保真度自检 —— 这些是人为纪律不是机械约束
- 质量保证有上限 —— 综合 R2 显示 M0 阶段 CI 拦截率上限 ~50-55%（语义层 10-15%），要拉到 95%+ 需评估闭环（M6 才上）—— 这是结构性约束
真实的工作量预估
| 项目类型 | 章节数估算 | 工作流时长估算 |
|---|---|---|
| DH（数据感知） | 20-25 章 | 25-35 小时 |
| TM（交易执行） | 25-30 章（合规重） | 35-45 小时 |
| RLE（学习引擎） | 22-28 章 | 30-40 小时 |
| FEFM（基础模型） | 18-24 章 | 25-35 小时 |
前提：上位事实源（战略白皮书 + 产品定义）已稳定，主控人能投入连续时间（不是碎片化）。
第七部分：可复用资产清单
下列资产可直接复制到 DH / TM / RLE / FEFM 的工作流：
| 资产 | 路径 | 复用方式 |
|---|---|---|
| 工作流目录骨架 | governance/workstreams/finbayes-arch-rewrite/ | 复制结构（不复制内容） |
| status.md 模板 | governance/workstreams/finbayes-arch-rewrite/status.md | 模板化前 50 行（续接协议 + 节点表头） |
| ADR-001 工程范式 | decisions/ADR-001-工程范式.md | 直接复用（Walking Skeleton + 里程碑切片是 FinTec AI 生态通用范式） |
| ADR-002 架构文档结构 | decisions/ADR-002-架构文档结构.md | 直接复用（arc42 + C4 + ADR + DDD） |
| ADR-003 工程协作 | decisions/ADR-003-工程实施栈与协作.md | 按项目调整（工具栈可能不同） |
| Merge script | /tmp/merge_architecture.py（一次性，未入仓） | 复制 Python 文件，修改 TARGET 路径与章节标题映射 |
| Multi-Agent Review prompt 模板 | reviews/codex-review-task-spec.md + 各 sub-agent 任务包 | 调整任务包字段（按项目维度） |
| 派生脚本扩展模式 | scripts/derive-agent-pack.mjs source_refs | 加新项目的 engineering-packs 路径 |
| 复盘文档模板 | 本文 | 各项目结束时类比写一份 |
第八部分：下一步建议
FinBayes 自身
- M0 OpenSpec task packet 起草（含工程实施仓 cwd / 验收命令 / Provider mock/real 边界）—— 本工作流外的工作
- 工程实施仓 bootstrap 跑通 M0（按 m0-walking-skeleton 第 1 小时步骤）—— Codex 实施
- M1-M7 engineering-packs 在各里程碑启动时按需起草
- 中优先级 ADR-005/006/007/009 在 M1+ 实施初期补齐
生态内其他项目（建议优先级）
- DH 重构优先（数据是 FinBayes / TM / RLE 的共同上游）—— 建议立刻启动
- TM 次之（FinBayes 已 ready 等 TM 接口稳定）—— DH 完成 70% 后启动
- RLE 再次（依赖 FinBayes + TM 出数据）—— FinBayes / TM 上线后启动
- FEFM 最后（基础模型层，FinBayes / DH / TM 上线后才有真实的 fine-tuning 信号）—— 12-18 个月后启动
元方法论的演化
下次工作流（如 DH）启动后，请把以下问题作为复盘核心：
- 这套方法在 DH 上是否仍然适用？哪些步骤需要调整？
- 多 Agent review 的"维度切片"在 DH 上需要怎样的新维度？
- A+C 双轨在 DH 上是否需要变成三轨（A 治理 + B 数据 source pack + C pipeline pack）？
- 战略保真度纪律的禁词清单在 DH 上是什么？
每一次复用都是对方法论的实战检验。本工作流的复盘已经显示：方法论本身要与项目特点共同演化，不要照搬。
致谢与署名
- 工作流维护者：项目主控
- 主控 Agent：Claude Code（Anthropic Sonnet 4.5 / 200K context）
- 协作 Agent：Codex（OpenAI gpt-5.5 via
codex execCLI v0.133.0）+ 多个 Claude Code sub-agent（researcher） - 上位文档：FinBayes 战略白皮书 v2 + 产品定义文档
- 工程范式上位：ADR-001 / ADR-002 / ADR-003
本工作流的所有产出（草稿 / 决策 / Review / 主文档 / 工程包 / 复盘）保留为 governance/workstreams/finbayes-arch-rewrite/ 的完整资产，作为生态内后续项目的可复用模板。
END of 复盘