跳到主要内容

Step 3 · Codex 工程实施视角独立 review brief

0. 用法说明​

这份 brief 是给 codex exec 用的 prompt 原料，由 Claude Code 主控生成、用户手工启动 Codex 后投递。投递方式见 §5。Codex load 后跑独立 review，输出报告到指定路径。本 brief 本身不修改任何文档，也不预先注入 Claude 已有的 review 结论，目的就是让 Codex 独立判断。

1. Codex 你的角色与任务​

你是 FinBayes 工程实施 agent（Codex / GPT 系），与 Claude 主控训练数据不同。Claude Code 主控刚完成 FinBayes M0 Walking Skeleton 的 P0+P1 工程化前置准入，现在请你以工程实施 agent 的视角独立 review 已落地的文档包，判断它是否足以支撑你在后续 C-1（cognition/types.py 落地）/ D-1（SQLite DDL 初始化）等 task 中高质量、低反查地把代码写出来。

你的判断维度刻意不与 Claude 治理 / 架构 reviewer 重叠：

  • 字段完整性：StructuredCognitionResult 1.1 schema 能直接 Pydantic v2 BaseModel 转译吗？字段类型 / 必选可选 / 默认值 / 枚举值是否全部明确？
  • 接口签名完整性：Provider shim / Consistency middleware / MCA classifier 等的 method signature、返回类型、异常 contract 是否清楚到能直接写实现？
  • 测试要求可执行性：M0 端到端测试、provider 抽象测试、eval-harness M0 子集是否给了足够明确的输入 / 期望输出 / 断言条件，能直接写 pytest case？
  • 数据 fixtures：M0 评测子集、annotation 样本、provider stub 响应是否已有可 mock 的 fixture 路径或 schema？
  • 错误处理 contract：候选→已确认两步契约失败、Provider 4 层降级、凭证泄漏、字段缺失等边界 case 怎么处理？
  • 跨子系统调用 contract：eval-harness / consistency-middleware / knowledge-graph-service / mca-classifier 这 4 个子系统互相调用时签名、状态对象传递、AuditEvent 写入点是否明确？
  • 单次 load 实际负载：完整 load topic agent-pack.yaml 列出的全部 sources（按 include_mode 与 anchors 解析）后，effective token 是否真的能压在 8K budget 内、32K 有效窗口内？哪些 source 体量超标？
  • 反查路径：实施时遇到字段定义模糊、跨文档语义冲突，是否能从单点（agent-pack.yaml / m0-walking-skeleton.md / cognition-1.1-contract.md）反查回事实源，不需要回头 grep 仓库？

你需要做的事：

  1. Load topic for-agents/topics/finbayes-m0-implementation/agent-pack.yaml，按其 sources / anchors / include_mode 逐项读取。
  2. 跑上述 8 维度 review，用你的训练分布独立判断。
  3. 模拟一次 C-1 与 D-1 task 的实施过程（不真写代码），列出你预计会卡住的地方。
  4. 输出 review 报告，落盘路径见 §4。

2. 必读文档清单​

按 agent-pack.yaml 顺序（include_mode 见括号）：

  • projects/finbayes/engineering/engineering-packs/m0-walking-skeleton.md（full · 入口）
  • projects/finbayes/engineering/engineering-packs/cognition-1.1-contract.md（full）
  • projects/finbayes/engineering/engineering-packs/eval-harness-formulas.md（spec）
  • projects/finbayes/engineering/engineering-packs/data-splits.md（full）
  • projects/finbayes/engineering/engineering-packs/data-providers.md（spec）
  • governance/workstreams/finbayes-cognition-system-research/drafts/2026-05-28-phase7-semi-manual-annotation-sla.md（spec）
  • projects/finbayes/engineering/architecture.md anchors §17 / §25 / §27（spec）
  • governance/workstreams/finbayes-whitepaper-rewrite/decisions/ADR-008-supplement-机制层输出契约扩展.md（full）
  • governance/workstreams/finbayes-cognition-system-research/decisions/ADR-007-supplement-金融认知体系第一版正式构成.md（spec）
  • governance/workstreams/finbayes-arch-rewrite/decisions/ADR-003-工程实施栈与协作.md（full）
  • projects/finbayes/engineering/subsystems/eval-harness.md（spec）
  • projects/finbayes/engineering/subsystems/consistency-middleware.md（spec）
  • projects/finbayes/engineering/subsystems/knowledge-graph-service.md（spec）
  • projects/finbayes/engineering/subsystems/mca-classifier.md（spec）
  • projects/finbayes/engineering/product-definition.md anchor §7.3（spec）
  • projects/finbayes/engineering/architecture-anti-bloat-guard.md（spec）
  • governance/workstreams/finbayes-cognition-system-research/drafts/2026-05-28-phase4-evaluation-system.md（spec）
  • governance/workstreams/finbayes-cognition-system-research/drafts/2026-05-28-phase5-iteration-governance.md（spec）

冲突优先级：ADR > engineering-pack > subsystems > product-definition（prefer-canonical）。所有路径相对仓库根，仓库根你按当前 cwd。

3. 8 维度评分锚点​

每个维度按 1–5 分锚点打分：

  • 1 分：完全不够，必须先补才能开始实施。
  • 2 分：勉强够，实施过程会高频反查、节奏被打断。
  • 3 分：够用但有 friction，可能要二次澄清。
  • 4 分：流畅，少量边界 case 需要自己合理推断。
  • 5 分：开箱即用，能直接照着写代码 / test case。

8 维度逐一展开：

  1. 字段完整性：聚焦 cognition-1.1-contract.md 的 10 要素 + 6 新增字段 + structured_result_version，逐字段判断是否 Pydantic v2 可直接转译。
  2. 接口签名完整性：聚焦 providers/base.py、4 子系统对外暴露 method、AuditEvent 写入入口。
  3. 测试可执行性：聚焦 5 个 acceptance outputs（cognition-types-py / sqlite-ddl-init / provider-shim / eval-harness-m0-subset / m0-integration-test）的可写 test case 程度。
  4. 数据 fixtures：聚焦 data-splits.md / data-providers.md / phase7-…annotation-sla.md 是否给了具体可 mock 样本结构。
  5. 错误处理 contract：聚焦候选→已确认两步契约、Provider 4 层降级、凭证不落盘、字段缺失。
  6. 跨子系统调用 contract：聚焦 4 子系统互相调用时的状态对象传递、AuditEvent 落点、生命周期跨界。
  7. 单次 load 负载：估算完整解析后的 effective token；budget 是 8K，超标项列出来。
  8. 反查路径：测试 3 个具体字段模糊场景，看能否从单点反查命中事实源（不需要回头 grep 整库）。

4. 报告输出格式​

报告落盘路径：

governance/workstreams/finbayes-arch-rewrite/2026-05-28-step3-codex-review-report.md

模板：

---
title: Step 3 · Codex 工程实施视角独立 review 报告
status: draft
last-updated: 2026-05-28
scope: project
maturity: working
---

# Step 3 · Codex 工程实施视角独立 review 报告

## 0. 执行摘要
（≤ 200 字：综合判断 + 是否可以进入 C-1 / D-1 实施 + 最大单点风险）

## 1. 八维度评分
（表格 / 列表，每维度 1–5 分 + 一句锚点说明 + 1–3 条证据）

## 2. C-1 / D-1 task 模拟
（C-1: cognition/types.py 落地 1.1 schema；D-1: migrations/0001_init.sql 含四表。
逐 task 模拟你真跑时的卡点：哪个字段你会停下来？哪段 schema 你会反查？）

## 3. 缺失 / 模糊清单
（结构：项 / 出处 / 性质 [缺失|模糊|冲突] / 阻塞等级 [P0|P1|P2]）

## 4. 修复建议
（每条对应清单一项，给最小修复动作，不要扩大范围）

## 5. 与 Claude 视角的预期差异
（你预期 Claude 治理 / 架构 reviewer 会发现哪些你这次没覆盖的事？
用于 Step 4 互换角色校准，列 3–7 条即可。）

报告体量上限 12K 字符。

5. 启动方式​

参考用户既有 codex exec 习惯（.agents/finbayes/dispatch/R8-codex-meta-prompt.txt + status.md 节点 17 的 v0.133.0 调用）。在仓库根目录下运行：

codex exec --model gpt-5 \
  < governance/workstreams/finbayes-arch-rewrite/2026-05-28-step3-codex-review-brief.md \
  > governance/workstreams/finbayes-arch-rewrite/2026-05-28-step3-codex-review-report.md

如需后台运行 + 持久化 session-id，按 status.md 节点 17 的形态另起。模型如 gpt-5 不可用，回退 gpt-5.5 / o4。

6. 关键约束（给 Codex）​

  • 不修任何文档，本任务是 review，不是 edit。
  • 不写代码、不进入工程仓做事，纯文档 review。
  • 报告体量 ≤ 12K 字符。
  • 不重复 Claude 治理 / 架构 reviewer 的事：不评判 ADR 治理流程合规性、不评判跨工作流交接、不评判文档之间的 cross-reference 一致性、不评判术语对齐。
  • 只关注「真的能不能照着写代码」这一根命题。
  • 不要把 Claude 已有的 P0 / P1 列表塞进你的判断；独立用你训练分布判定。
  • 报告里允许诚实说「我读不到 / 我估算不出」，不要硬猜。