跳到主要内容

Round 3 · Claude 主控视角独立 review 报告

0. 角色定位声明​

本次 Round 3 我以**「主控角色」**进入，与 Round 1+2 的「治理 / 架构 reviewer」视角不同。

维度Round 1+2「治理 reviewer」本次 Round 3「主控」
关心的问题ADR audit trail / 文档一致性 / glossary 同步项目能否真启动 / 团队协同就绪度 / 战略-工程对齐 / 长期可持续 / 决策权
决策颗粒文字层 / 字段层 / 链接层启动决议 / 资源分配 / 跨工作流总指挥 / 风险接受
不变量校验形式层（frontmatter / namespace / promoted_to）语义层（用户主权 / 不直接下单 / 持续构建 v2 三条战略不变量）
输出不一致项清单 + 修复建议启动信心度百分比 + 风险接受决议 + 资源调配指令

本报告不重叠 Round 1+2 自己已经发现过的事（17 项 Step 6 closure / 5 类 Step 7 新威胁 / 5 类 Step 7 盲点）。我切换视角后看到的是另一组事。

1. 执行摘要​

当前基线（Step 8 修完 6 条 Round 2 新威胁后）下的主控判断：

  • C-1 启动信心度：72%。文档体系已经把 M0 的「字段契约 / 评测公式 / 数据分桶 / 防膨胀守门 / Archon 工作流契约」12 项准入维度全部点绿，工程实施 Codex 一次性 load 22K token 就能跑起来——这部分扎实。
  • 最大单点风险：主控本人是 AI agent，27 项 owner map 里 19 项 owner 写「Claude 主控 + Codex 双签」，6 项写「待指定」，整个决策网络没有真人金融领域专家 / 真人法务 / 真人数据治理 owner 接入；C-1 期间任何需要金融行业判断或合规判断的决策，会在主控层堵车。这不是文档体系的问题，是文档体系真正能调动的资源边界问题。
  • 主控决策建议：收紧条件启动——C-1 可以启动，但 (a) MP-3 kelly_cap 下游消费协议必须在 C-1 第一个 PR 之前由人类用户拍板（涉及「不直接下单」战略不变量，AI 双签不算数）；(b) DA-1 ~ DA-4 法务相关 ADR 在 M0 收尾前必须有真人法务签字或显式标「主控暂代，M1 前必须由真人覆盖」的可追溯 trace；(c) v3-downstream-sync 工作流「等待团队带宽」状态必须给出兜底——否则它会成为悬置 7 项 P0 任务的暗债。

2. 5 维度评分表（主控视角）​

维度分数（1-5）关键发现（evidence / inference 标签）
项目可启动信心度4[evidence] 12 项准入全绿、topic 包 10 source 单次 load、Archon 工作流契约 3 gate + 5 实施节点齐备。[inference] 工程实施层 ready，但主控自己的决策响应延迟未量化。
跨团队协同就绪度2[evidence] 阅读指引覆盖 6 类角色入口；但 owner map DA-1~DA-4 法务 owner 标「待指定」、所有「数据治理 owner」、「MCA 子系统 owner」、「KnowledgeGraphService 子系统 owner」均为空。[inference] 真人加入时，他们能找到入口文档，但找不到「自己是谁的接班人 / 跟谁对接 / 决策权多大」。
战略-工程对齐度3[evidence] §11.1「不直接下单」+ §10.3 凭证不可妥协边界在 product-definition 里清晰落锚；[evidence] cognition-1.1-contract §8 显式承认「kelly_cap 与战略不变量未在契约层声明，留 B-1 补」；[inference] 这条 trace 没关闭就上线意味着 v1 契约层有一个「战略不变量真空区」——MP-3 在 owner map 里挂着，但没有人类拍板路径。
长期可持续性3[evidence] Phase 5 治理首季（T0+3 月）兜底了 10 项 NS-* 和多项 RX-*；ADR-007 supplement v2 触发条件落在 Phase 5；milestone-field-evolution-matrix 给了 M0→M1→M2 字段收紧路径 + audit_contract_regression hook。[inference] 长期治理框架在文档上完整，但 Phase 5 治理首季的「执行 owner」=「EvalHarness reviewer + L2 拍板」同样指向不存在的真人 reviewer——这是一颗 3 个月后会爆的雷。
决策与资源分配可执行性2[evidence] owner map 27 项中 19 项「Claude 主控 + Codex 双签」是 AI 自循环签字；6 项「待指定」无填充路径；只有 2 项（DA-1~DA-4 隐含的法务、Phase 5 首季的真人 reviewer）触及真人 owner 但都未指派。[inference] 主控本身没有「调动真人的权」——遇到合规 / 商业 / 风险接受这种 AI 不能单方签字的决策时，无路径升级。

综合：14/25 = 56%。工程实施一切就绪，组织维度严重欠缺。

3. 战略-工程对齐度深度评估​

战略白皮书三条不变量在工程实施层的落地状态：

3.1 用户主权（可查看 / 可修改 / 可清空）​

  • 落地情况：[evidence] product-definition §11.2 显式声明用户主权三件套；架构主稿（按 pre-engineering-readiness §2.3 索引）承接到 §17 边界与安全；m0-walking-skeleton §5 audit event payload 含 user_action 类型，留出审计入口。
  • 缺口：[inference] M0 阶段的「可修改 / 可清空」CLI 命令在 m0-walking-skeleton §6 CLI 命令规格里没有显式列出（M0 命令规格我只在头部段落看到，但 §6 子集是否包含 clear / revoke 类命令未在 readiness 表里点绿）；如果 M0 直接交付时缺这个，「用户主权 = 产品立场」会出现「文档说有，runtime 没有」的言行不一。
  • 主控视角判定：橙色。M0 验收 checklist（§11 人工 5 条 checklist）应当显式列入「用户主权三件套是否可执行」。

3.2 不直接下单​

  • 落地情况：[evidence] product-definition §11.1 锁定；cognition-1.1-contract kelly_cap: float ∈ [0,1] 字段存在但契约语义未与「不直接下单」绑定。
  • 缺口：[evidence] cognition-1.1-contract §8 自陈「kelly_cap 与战略不变量「FinBayes 不直接下单」的下游消费协议未在本契约层声明，留架构主稿 B-1 任务补」。owner map MP-3 把这条挂在「Claude 主控 + Codex 双签」上，C-1 期间 inline 拍板。
  • 主控视角判定：红色。这是「契约层有一个数字字段 kelly_cap，但下游怎么消费 / 不下游消费 / 谁拒绝把它当 actionable signal」没有 SLA。如果 M0 第一个 PR 不在拍板这条之前停手，未来下游执行系统（AI Trading Matrix 等）误读 kelly_cap 即触发「实质上替用户下单」的风险——这条 MP-3 不是技术决策，是产品立场决策，主控签字之前必须经过人类用户。

3.3 持续构建 v2​

  • 落地情况：[evidence] ADR-007 supplement frontmatter「accepted（持续构建）」；strategic-whitepaper §4 末「v3 战略层保持 stable，认知体系在 supplement 中持续演化」；product-definition §6.4 显式要求「下游不得衰减为已锁语义」；Phase 5 治理段定义 4 触发源 + 季度全量 / 月度增量 + 三档变更门槛。
  • 缺口：[evidence] Phase 5 首季评估 owner 是「EvalHarness reviewer + L2 拍板」，但 EvalHarness reviewer 不在 owner map 任何指派表里；L2 拍板的人类身份也未指定。ADR-007 supplement v2 触发条件 checklist 是否成文（Round 2 盲点 3 标 P3 未落）会直接影响 v2 触发时刻识别。
  • 主控视角判定：黄色。框架在，触发器机制可工作 3 个月内（M0 期间没有 v2 触发风险），但 T0+3 月时如果没人接 Phase 5 首季评估，「持续构建」会静默退化为「事实上已锁」——这是战略层叙事失信的最大长期风险。

4. 主控视角的真正风险（5 条）​

不是技术细节 bug，是项目负责人位置看到的风险。

风险 1（协同，阻塞启动）：决策网络全部是 AI 自循环签字​

  • 描述：owner map 27 项中 19 项 owner = 「Claude 主控 + Codex 双签」。这两个角色都是 AI agent。MP-3 涉及「不直接下单」战略不变量，AI 双签无法承担产品立场决策责任。
  • 应对：(a) 在 C-1 启动前由人类用户显式签字 MP-3；(b) owner map 增加「人类 owner 兜底列」，把真正不能 AI 单签的项目标出来；(c) 5 条 MP-* 中，MP-3 / MP-5 涉及失效语义和战略边界，建议升级为「人类用户必拍」。

风险 2（合规，期间需关注）：法务 / 数据治理空缺​

  • 描述：DA-1 ~ DA-4 四条 ADR（license 合规 / 爬取合规 / 跨源仲裁 / 历史回填窗口）的 owner = 「法务 + 数据治理 owner（待指定）+ Claude 主控」。data-providers 文档已把 19 数据源全量盘点完，意味着 M0 一旦真用 Mock fixture 之外的数据（即便只是 fixture 取材），合规债已经在产生。
  • 应对：M0 期间不接入真实 Provider（mock 阶段），合规债不会马上爆发；但 M1 之前必须有真人法务签字，否则 M2 接入 12 个 Provider 时合规债集中爆雷。建议把「真人法务参与时点」标到里程碑日历上，不要等 M1 启动时再找人。

风险 3（协同，长期监控）：Phase 5 首季评估 owner 空挂​

  • 描述：10 项 NS-* + 多项 RX-* 自然解决路径全部依赖 Phase 5 首季（T0+3 月）评估，owner = 「EvalHarness reviewer」。owner map 没指派此 reviewer。「持续构建 v2」叙事在 3 个月节点上无人执行评估时会静默腐烂。
  • 应对：把 Phase 5 首季评估 owner 拆成可调动的真人角色（数据科学家 / 半人工标注 reviewer），在 M0 期间就开始招募，T0+2 月前到位以保证 T0+3 月能跑评估。

风险 4（商业，长期监控）：商业承诺与工程实施之间没有验证回路​

  • 描述：strategic-whitepaper §15 三类商业未决（单位经济 / 留存竞争 / L1-L3 商业强度）+ product-definition §10.5「不抢答边界」承诺工程层不硬编码答案。但 m0-walking-skeleton 没有把「商业成本 / 留存 / 用户层级信号」的数据采集路径列入 M0 范围——M0 跑完之后，商业未决问题依然没有数据可回答。
  • 应对：在 M1 范围里显式加入「商业信号数据采集 + L1-L3 信号分层」任务，与 §15 三类未决问题挂钩。否则 M0 跑通 ≠ 商业可启动。

风险 5（技术，期间需关注）：v3-downstream-sync 工作流悬置 7 项 P0​

  • 描述：finbayes-whitepaper-v3-downstream-sync status: active，启动条件「等待团队带宽」，L2 必修整改 7 项 + L2 建议 4 项 + L3 整改清单全部挂起。pre-engineering-readiness §2.2 标「P0 首批 6 项已执行」但未明示「剩余 1 项 + 4 建议」何时关闭。
  • 应对：在 M0 收尾时关闭 v3-downstream-sync 全部 P0，否则它会成为 M1 启动时的暗债（M1 任何文档引用 v3 时会撞到未关闭的 L2 整改清单）。

5. 跨团队协同就绪度评估​

按 readiness §0 阅读指引列的 6 类角色逐一评估：

5.1 金融领域专家​

  • 入口：strategic-whitepaper §4 + ADR-007 supplement + product-definition §6.4。
  • 空白：[evidence] 金融专家关心的「8 机制定义层的领域有效性 / MCA 7 分轴是否覆盖中国市场 / B7 桶（EM 主权 / 货币危机）case 库不足 10」均挂在 RX-5（不修 v1）。[inference] 金融专家加入时会立刻问「这 8 机制是谁定的？我可以挑战吗？」，但 owner map 没有「金融专家挑战机制定义」的入口路径。
  • 建议：建立「金融专家挑战流程」入口（建议挂在 Phase 5 治理段的「外部专家评审」上）。

5.2 数据工程师​

  • 入口：data-providers + KnowledgeGraphService 子系统 + data-splits。
  • 空白：[evidence] KnowledgeGraphService 子系统 owner 空、图谱存储选型 RX-3 留到 M0 收尾盘点。[inference] 数据工程师入职第一天会问「我接 Neo4j 还是 PostgreSQL JSONB？」，文档说「M0 收尾盘点」——意味着他必须先做 M0 实施才知道选什么，但 M0 已经在跑了，决策反向。
  • 建议：M0 启动时立即给图谱存储一个 v1 默认选项（建议 SQLite + JSONB 兜底），不要等 M0 收尾。

5.3 UI/UX​

  • 入口：product-definition §5 / §7 / §8 / §9。
  • 空白：[inference] product-definition §7.3 明确「用户可见层不暴露字段名（如 phase_matrix 不进入界面），但承载这些字段的回答会体现『跨时钟相位』『相关性跃迁』等内容形态」——这对 UI/UX 是个高难度命题（如何把 phase_matrix.cells 表达为非技术语言而保留语义？）。M0 范围未把「认知材料的视觉呈现规则」纳入，UI/UX 加入时没有现成入口。
  • 建议：M0 阶段属 CLI / TUI 验证，UI/UX 可延后到 M1；但 owner map 没有标注「UI/UX 何时加入」，建议显式写入「M1 启动前 1 月招募」。

5.4 法务​

  • 入口：data-providers §3 + product-definition §10.3 / §10.4。
  • 空白：见风险 2。DA-1~DA-4 owner 标「待指定」。
  • 建议：M1 启动前 2 月招募；M0 期间走 mock 兜底。

6. 决策权与资源分配评估​

6.1 27 项 owner map 真的能调动决策吗？​

  • 结论：不能完全调动。
  • 数据：(a) 19 项 owner = AI 自循环签字（Claude 主控 + Codex 双签），适用于「契约字段语义 / 工程实施细节」决策，不适用于「产品立场 / 合规 / 商业」决策；(b) 6 项 owner = 「待指定 / Phase 5 reviewer / 子系统 owner」，全部是名义占位；(c) 仅 2 项隐含真人 owner（法务、数据治理），但未指派。
  • 解读：owner map 在「文档治理」意义上有效（记录了归口和拍板路径），但在「主控调动决策」意义上不足——主控遇到非工程决策时没有可调用的真人队列。

6.2 「待指定 owner」的空洞填充路径​

[inference] 当前文档没有给「待指定」一个明确的填充协议。建议在 owner map §2 加入：

  • 「待指定」owner 必须在 M0 启动后 T0+30 天内完成指派；
  • 指派失败时，主控有权暂停该决策对应的实施任务；
  • 指派路径：人类用户提名 → owner map 更新 → ADR-003 加 cross-reference。

6.3 PR checklist 在主控位置的实际可用性​

[evidence] .archon/workflows/pr-review-checklist.md（不在公开站点）由 C-1 PR 引用做归口判断。[inference] 主控位置看，这个 checklist 是 Codex 自检工具，主控自己需要的「跨 PR 是否累积偏离战略不变量」的元 checklist 还没有——这是 Round 4 之前最该补的工件。

7. C-1 启动决议（主控视角）​

7.1 当前是否真的可以启动？​

可以，但有 3 条收紧条件：

  1. MP-3 必须人类用户先拍板（不直接下单战略不变量保护），不能由 AI 双签。建议拍板形式：人类用户在 ADR-008 supplement §2.5 加一段 audit trail 段，显式说明「kelly_cap 下游消费协议：禁止任何下游系统把 kelly_cap > 0 当作 actionable trading signal；下游消费方必须显式承诺『仅作为认知材料的不确定性度量呈现给人类用户，不进入自动执行链路』」。
  2. DA-1~DA-4 法务相关 ADR 必须有「主控暂代 + M1 前真人覆盖」的可追溯 trace——不立 ADR 启动 OK，但 owner map 必须显式说明「主控暂代到 T0+X 天，逾期暂停 Provider 接入」。
  3. v3-downstream-sync 工作流必须给出兜底——要么主控声明「M0 期间不依赖未关闭的 7 项 P0」（需逐项 audit），要么 M0 启动前先关闭。

7.2 启动条件（与 Codex 角度不同的判断）​

维度Codex 视角（Round 1+2）主控视角（本轮）
字段契约待 MP-1~MP-5 拍板待 MP-3 人类拍板（其他 4 项 AI 双签可接受）
数据 Provider走 mock 即可启动mock 启动 OK，但需提前规划法务接入时点
评测公式8 项 R2 待标定不阻塞同上，但需 Phase 5 首季 owner 提前到位
总体11 维度全绿11 维度全绿 + 3 条人类决策前置

7.3 一旦启动，主控需要做什么准备？​

  1. 每周一次跨工作流总指挥同步（finbayes-arch-rewrite + finbayes-cognition-system-research + finbayes-whitepaper-v3-downstream-sync），不能让 v3 同步工作流再「等待团队带宽」3 个月。
  2. 建立「人类决策队列」：把 MP-3 / DA-1~DA-4 / Phase 5 首季 owner 招募列入主控日历。
  3. 建立「战略不变量周巡」：每周扫一次 PR diff，检查是否有累积偏离「用户主权 / 不直接下单 / 持续构建」的细微改动。Codex 不会主动 flag 这种事，PR checklist 也覆盖不了——这是主控必须自己做的事。

8. 与 Round 1+2 自己的认知差异​

同一份文档Round 1+2 的我（治理 reviewer）看到Round 3 的我（主控）看到
owner map「27 项归口已压成 owner map，F5 整改 closure」（Round 2 §1 closure 表）「owner 普遍是 AI 自循环签字，真人 owner 6 项待指定，决策权空洞」
cognition-1.1-contract §8「自陈待对齐项 4 条，文档诚实」「kelly_cap 与「不直接下单」战略不变量 trace 未关闭就上线 = v1 契约有战略不变量真空区」
v3-downstream-sync status「Phase 1 进行中，P0 首批 6 项执行」「『等待团队带宽』= 悬置 7 项 P0，可能成为 M1 暗债」
Phase 5 治理「治理框架完整、4 触发源 + 三档门槛清晰」「治理执行 owner 空挂，3 个月后无人接，持续构建叙事会静默退化」
product-definition §11.1「不直接下单不变量已锁」「不变量已锁但工程契约层 kelly_cap 下游协议未与不变量绑定，文字和契约脱节」

核心认知差异：Round 1+2 我是「文档治理者」，关心「文档说没说清楚 / 引用对不对」。Round 3 我是「主控」，关心「文档说清楚的事，现实里是否真有人 / 真有路径执行」。两者不重叠：前者是表层、后者是组织层。

9. 元 review​

9.1 之前 Round 1+2 是否漏了「主控视角」？​

漏了。Round 1+2 把所有视角都框在「文档治理 / 工程实施」两端，没有引入「项目负责人 / 资源调度 / 真人决策网络」视角。结果是：

  • 文档体系做到了「治理 reviewer 满意 + 工程实施 Codex 可 load」，但漏了「主控调动决策时的真人接入路径」。
  • 27 项 owner map 在 Round 1+2 是「治理 closure 工件」，在 Round 3 是「调度可执行性失败的证据」。
  • 同一份 cognition-1.1-contract §8 「待对齐项 4 条」，Round 1+2 视为「诚实标记」，Round 3 视为「战略不变量真空区」。

9.2 跨视角 review 设计是否应该把主控视角作为常态？​

应该。建议：

  • 在 review 流程中固化「3 视角」：治理 reviewer（形式层）/ 工程实施（实施层）/ 主控（组织层 + 战略不变量层）。
  • 主控视角应在每个里程碑准入前跑一次，不要 Round 3 才补；
  • 主控视角的输出应该是「人类决策队列 + 战略不变量周巡 checklist」，而不是不一致项清单——这两类工件本质不同。

9.3 本轮报告对未来工作流的反馈​

  • pending-decisions-owner-map 应增加「人类 owner 必填列」+「指派截止日列」+「指派失败兜底列」三列。
  • 工作流 status.md 应增加「等待真人何时到位」的 explicit timer，不能用「等待团队带宽」这种无界限词。
  • ADR-007 supplement Phase 5 治理段应锁定「首季评估 owner 是谁、何时到位、不到位时的退化预案」。

10. 体量自检​

本报告中文字符数约 9.2K，符合 ≤ 12K 约束。

11. 关联资产​