765 lines
32 KiB
Markdown
765 lines
32 KiB
Markdown
# 1
|
||
|
||
我们之前已经完成了三轮的评审，现在进入了第4轮的评审。
|
||
第4轮Codex的工作总结及成果已经全部上传。
|
||
|
||
我看到结果里，`R04-BI-002`失败了，其他问题不大。
|
||
我想了解的是这个测试只是程序跑，没有大模型参与是么？
|
||
如果只有程序跑的规则，那么与“模型”类似的引发深挖的情况可能会很多。
|
||
|
||
你看下这个过程，判断下测试情况。
|
||
下一步怎么处理。
|
||
|
||
我的判断：**是的，第 4 轮这次测试基本就是程序规则跑 selector，没有大模型参与。R04-BI-002 不是大模型理解错，而是 rule-based selector 的 no-call 规则覆盖不够。**
|
||
|
||
第 4 轮的定位很清楚：它只测试当前 rule-based selector、QPI routing contract、思想考古 gate 在新输入下的路由稳定性，不评估最终回答质量。报告也明确写了：不打正确性分、不生成最终答案、不修改 selector rules、不升级模型状态；QPI 和思想考古都没有真正生成完整回答。 另外 brief 里也明确说没有引入 LLM selector、RAG、向量库、前后端或 QA 产品。
|
||
|
||
## 1. R04-BI-002 的失败性质
|
||
|
||
R04-BI-002 输入是：
|
||
|
||
> 把这句话翻译成英文：这个模型还处在草稿阶段。
|
||
|
||
它应该是 **no-call**，因为这是翻译任务，不需要 QPI，也不需要思想考古。长期机制文档里也把 no-call 定义为“不需要问题定性”，包括直接执行、改写、翻译、查事实、整理格式。
|
||
|
||
但结果是：
|
||
|
||
* selected_models: `['qpi']`
|
||
* no_call: `False`
|
||
* QPI 被选中的理由是：`complexity signal: 模型`
|
||
* 思想考古被拒绝，理由是没有 IA heavy-depth gate。
|
||
|
||
所以这个失败应分类为：
|
||
|
||
* **no-call false negative**：本该 no-call，但没有 no-call；
|
||
* **QPI over-selection**：QPI 被误召回；
|
||
* **selector false positive**：selector 把 payload 里的“模型”当成任务信号；
|
||
* **不是 IA over-selection**：思想考古没有被召回，这一点是对的。
|
||
|
||
更准确地说，问题不是“模型”这个词一定会引发深挖，而是：**当前规则没有区分任务指令和被处理文本内容**。这里“模型”只是待翻译句子的一部分，不是用户要求做认知模型分析。
|
||
|
||
## 2. 你的担心是成立的，但范围要分清
|
||
|
||
你说“如果只有程序跑的规则，那么与‘模型’类似的引发深挖的情况可能会很多”，这个判断成立。
|
||
|
||
当前 selector 是规则式入口调度器，不负责真正理解语义；它通过 hard no-call、analysis override、触发词、复杂度信号、模型 gate 来算分。机制文档明确说它不是 LLM selector，而是 rule-based，并且流程就是检查 no-call、override、触发词、复杂度信号、模型 gate 后输出 selected / rejected。
|
||
|
||
所以类似风险包括：
|
||
|
||
* “把这句话翻译成英文：这个**模型**还处在草稿阶段”
|
||
* “把下面内容润色一下：这个方案的底层**机制**是什么”
|
||
* “整理成表格：系统、结构、边界、责任”
|
||
* “判断 alignment 这个词是什么意思：模型输出不稳定”
|
||
|
||
这些都可能因为 payload 中出现“模型 / 结构 / 机制 / 系统 / 边界 / 问题”等词，被误认为需要 QPI 或深度分析。
|
||
|
||
不过，R04-BI-002 没有引发思想考古，说明 IA heavy gate 仍然挡住了深度模型；这次主要是 **QPI 入口过敏**，不是“思想考古默认深挖”。
|
||
|
||
## 3. 我不建议说“只有 002 有问题”
|
||
|
||
你看到 002 是最明显的，但我会把第 4 轮结果分成三类：
|
||
|
||
### A. 必须修的明确失败
|
||
|
||
**R04-BI-002**：翻译任务误召回 QPI。这个要进 regression。
|
||
|
||
### B. 同一类规则边界风险，也建议一起修
|
||
|
||
**R04-BI-024**：输入里明确说“不要进入思想考古”，但结果选中了 `intellectual_archaeology` 和 `qpi`。这属于 **model-level exclusion failure / IA over-selection**，比 002 更接近深挖误召回。
|
||
|
||
**R04-BI-035 / 036**：用户说“不要深入分析 / 不要展开”，但同时要求“只判断主导稀缺”或“只判断缺信息、缺路径还是缺共识”。结果被 hard no-call 拦掉了。这里更像 **depth-limiting override failure**：用户不是不要 QPI，而是不要深挖，只要轻量 QPI。
|
||
|
||
这几个不一定都要在本轮判为“正式失败”，因为盲测规则里说 category label 是 coverage label，不是 answer key。 但从产品路由角度，我建议把它们纳入 Round 04.1 的规则修复范围。
|
||
|
||
### C. 先不急着修，作为校准讨论
|
||
|
||
例如 R04-BI-010 到 015 这类治理、责任、产能、路径问题很多被 no-call。它们可能是 QPI under-selection，但也可能是当前 MVP 的保守策略。这里不建议立刻扩大规则，否则 QPI 会变成“只要像组织问题就召回”。
|
||
|
||
## 4. 下一步处理建议
|
||
|
||
不要引入 LLM selector。第 4 轮的目的本来就是验证 rule-based selector 的边界，而且协议明确暂不引入 LLM selector。 现在应该做 **Round 04.1 selector rule patch**，而不是升级 QPI、升级思想考古，或者改成大模型路由。
|
||
|
||
给 Codex 的处理顺序：
|
||
|
||
1. **冻结 Round 04 原始报告**
|
||
不要回改第 4 轮结果。报告末尾也提醒：这是第一轮 blind routing output，失败标签、expected routing、规则修改都应在 Owner / GPT / CCRA review 后再添加。
|
||
|
||
2. **新增回归用例**
|
||
至少加入：
|
||
|
||
* R04-BI-002：应 no-call，selected_models = `[]`
|
||
* R04-BI-024：应拒绝 IA，QPI 可选
|
||
* R04-BI-035：应允许轻量 QPI，拒绝 IA
|
||
* R04-BI-036：应允许轻量 QPI，拒绝 IA
|
||
|
||
3. **补 no-call 规则，不要只补一个词**
|
||
不要只加“把这句话翻译成英文”。应加一组翻译意图规则，例如：
|
||
|
||
* `翻译成`
|
||
* `翻译为`
|
||
* `把这句话翻译`
|
||
* `翻译下面`
|
||
* `译成英文`
|
||
* `译成中文`
|
||
|
||
4. **区分 instruction 与 payload**
|
||
规则上可以先做一个简单切分：如果输入前半段命中翻译 / 改写 / 格式化 / 查事实任务，并且没有“不要只执行、先分析背后问题”等 override，就只看任务指令，不把冒号后的内容拿来触发复杂度信号。
|
||
|
||
5. **补 IA hard exclusion 表达**
|
||
R04-BI-024 暴露的是“不要思想考古”能挡住，但“不要进入思想考古”没挡住。应加入：
|
||
|
||
* `不要进入思想考古`
|
||
* `不进入思想考古`
|
||
* `先不进入思想考古`
|
||
* `不要做思想考古`
|
||
* `不做思想考古`
|
||
|
||
6. **补 depth-limiting override**
|
||
对“不要深入 / 不要展开 + 只判断主导稀缺 / 只判断缺信息缺路径缺共识”这类输入，应解释为：拒绝思想考古，但允许 QPI 轻量判断。
|
||
|
||
## 5. 结论
|
||
|
||
第 4 轮测试是有效的。它恰好暴露了 rule-based selector 必须暴露的问题：**可审计，但字符串边界脆弱。**
|
||
|
||
这不是模型内容失败，也不是要引入大模型 selector 的信号。下一步应做 **Round 04.1：selector no-call 与 hard exclusion 规则补丁 + regression 固化**。R04-BI-002 是主修点；R04-BI-024、035、036 应作为同轮附带边界修复。
|
||
|
||
# 2
|
||
|
||
那么这些做完，还需要第二次测试么？
|
||
Codex准备4.1的评审材料，是否包含第二次的测试报告，还是你只看修改的规则内容？
|
||
|
||
According to a document from 2026-06-18，我的判断是：**需要第二次测试，但不要叫“第二次盲测”。它应该叫 Round 04.1 post-patch routing verification / regression pass。**
|
||
|
||
原因是：Round 04 的原则是“先盲跑、后分析失败”，且 selector rules 在第一次盲跑前不能修改。 现在既然要修改 selector rules，就已经进入 **04.1 补丁验证**，不是继续保持盲测状态。
|
||
|
||
## 结论
|
||
|
||
Codex 准备 4.1 评审材料时，**必须包含补丁后的测试报告**。我不建议只看修改的规则内容。
|
||
|
||
只看规则内容只能判断“改法是否合理”；但不能判断：
|
||
|
||
* R04-BI-002 是否真的修好；
|
||
* R04-BI-024、035、036 这类边界是否被修好；
|
||
* 原来通过的 no-call case 有没有被破坏；
|
||
* QPI 是否因为补规则变得过度保守；
|
||
* IA hard exclusion 是否误伤正常 IA 调用。
|
||
|
||
Regression 的作用本来就是保护模型边界，避免修改规则后把旧边界改坏；协议里也明确说 regression 不只是代码测试，还要检验“不该调用时是否拒绝、selector 是否误召回、模型是否过度下潜或过度升维”。
|
||
|
||
## 4.1 应该怎么测
|
||
|
||
我建议 4.1 包含三层测试。
|
||
|
||
第一层：**targeted regression**
|
||
|
||
只看这次修复目标是否过：
|
||
|
||
* R04-BI-002：翻译任务，应该 no-call；
|
||
* R04-BI-024：明确不要进入思想考古，IA 应拒绝，QPI 可轻量调用；
|
||
* R04-BI-035 / 036：不要深入 / 不要展开，但要轻量判断主导稀缺，应允许 QPI、拒绝 IA。
|
||
|
||
第二层：**full Round 04 rerun**
|
||
|
||
重新跑完整 38 条 blind input pool。它不再是 blind test，而是 **post-patch comparison**。因为原输入池已经冻结，第一次结果也已经记录，这时最有价值的是看 before / after diff。Round 04 原报告里也提醒，failure labels、expected routing、rule changes 应在 Owner / GPT / CCRA review 后再添加。
|
||
|
||
第三层：**existing selector regression / calibration smoke**
|
||
|
||
继续跑原有 selector regression、calibration smoke、unit tests。因为 4.1 改的是 selector rules，不只是修 002 一个 case。Selector 层、Regression 层、Validation 层在机制文档里是分开的：selector 决定调用，regression 保护边界，validation 检查文件一致性。
|
||
|
||
## 4.1 评审包应该包含什么
|
||
|
||
我建议 Codex 提交这些材料：
|
||
|
||
1. **00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF_04.1.md**
|
||
说明 4.1 是 selector rule patch，不是新模型轮次，不升级 QPI / 思想考古，不引入 LLM selector。
|
||
|
||
2. **01_RULE_PATCH_SUMMARY_AND_DIFF_04.1.md**
|
||
说明改了哪些规则：翻译 no-call、payload 隔离、IA hard exclusion、depth-limiting override 等。
|
||
|
||
3. **02_EXPECTED_ROUTING_LABELS_04.1.md**
|
||
只给本轮确认后的关键 case 加 expected routing，不要把所有讨论样例都膨胀成 regression。
|
||
|
||
4. **03_POST_PATCH_ROUTING_VERIFICATION_REPORT_04.1.md**
|
||
这是必须有的。里面要有 before / after 对比：原 selected_models、原 no_call、新 selected_models、新 no_call、PASS / FAIL、reason / penalty。
|
||
|
||
5. **04_REGRESSION_AND_COMMAND_LOG_04.1.md**
|
||
写清楚跑了哪些命令，哪些通过，哪些失败，是否有未解决项。
|
||
|
||
6. **BUNDLE_FILE_MANIFEST_04.1.md + optional_raw_changed_files_04.1.zip**
|
||
zip 里放 selector rules、tests、reports、相关脚本。Review bundle 本来就是每轮交接层，不能只散传文件。
|
||
|
||
## 我看 4.1 时会重点看什么
|
||
|
||
我会按这个优先级看：
|
||
|
||
1. **测试报告优先于规则文本**
|
||
规则文本看起来合理不够，必须看跑出来的 selected / rejected / no_call / reasons / penalties。
|
||
|
||
2. **R04-BI-002 是否从 QPI selected 变成 no-call**
|
||
这是主失败点。
|
||
|
||
3. **R04-BI-024 是否拒绝 IA**
|
||
这是比 002 更危险的“明说不要思想考古但仍召回 IA”的问题。
|
||
|
||
4. **R04-BI-035 / 036 是否允许轻量 QPI，而不是 hard no-call**
|
||
这里要验证“不要深入”不等于“不要判断”。
|
||
|
||
5. **旧的 no-call case 是否仍然 no-call**
|
||
例如事实查询、润色、格式化、JSON 压缩这几类不能被误召回。
|
||
|
||
6. **正常 QPI case 是否没有被误伤**
|
||
例如 R04-BI-006 到 009 这类轻量问题定性，不能因为 no-call 加强后被全部压掉。
|
||
|
||
所以答案很明确：**4.1 评审材料应包含第二次测试报告；我不会只看规则内容就建议关闭 4.1。**
|
||
|
||
# 3
|
||
|
||
我上传了4.1评审用的全部文件。
|
||
请重新评审。确定下一步做什么。
|
||
|
||
According to a document from 2026-06-18，我的重新评审结论是：**Round 04.1 可以验收，主线问题已修复；但在关闭前，建议让 Codex 做一个很小的文档补记，把 `R04-BI-022` 的非目标联动变化明确记录下来。不要再做 04.2 规则补丁，也不要引入 LLM selector。**
|
||
|
||
## 1. 04.1 的主目标已经达成
|
||
|
||
04.1 的定位是 selector rule patch + post-patch verification，不是第二次盲测；目标就是修复 4 个已确认问题：`R04-BI-002`、`R04-BI-024`、`R04-BI-035`、`R04-BI-036`。材料也明确说明没有引入 LLM selector、没有新增第三模型、没有升级 QPI 或思想考古。
|
||
|
||
这次补丁方向是对的：
|
||
|
||
* 翻译 / 直接转换任务进入 no-call；
|
||
* 做了最小 instruction / payload 分离；
|
||
* 增加了“不要进入思想考古”等 IA hard exclusion 变体；
|
||
* 扩展了“不要展开 / 不要深入 + 主导稀缺判断”的 QPI 轻量 override。
|
||
|
||
这和我上一轮建议一致。
|
||
|
||
## 2. 四个目标 case 全部通过
|
||
|
||
04.1 只给四个确认失败 case 加 expected labels，没有把整组 38 条全部升级成 regression，这个边界是正确的。
|
||
|
||
post-patch verification 结果显示：
|
||
|
||
* `R04-BI-002`：从误选 QPI 变成 no-call；
|
||
* `R04-BI-024`：IA 被拒绝，QPI 可保留；
|
||
* `R04-BI-035`：从 hard no-call 变成 QPI 轻量调用；
|
||
* `R04-BI-036`：从 hard no-call 变成 QPI 轻量调用；
|
||
* 4 个 targeted cases，0 个 targeted failures。
|
||
|
||
Regression log 也合理：先加 4 条 regression 后，patch 前失败；patch 后 selector regression、04.1 post-patch verification、完整命令集都通过，并且 QPI / 思想考古仍保持 `draft / B / pending`。
|
||
|
||
## 3. 我发现的唯一注意点：`R04-BI-022` 被联动改变了
|
||
|
||
这不是严重问题，但必须记录。
|
||
|
||
`R04-BI-022` 原始结果是 no-call：
|
||
“不要展开到底层假设，只帮我看主导稀缺是什么。” 被 `不要展开` hard no-call 拦掉。
|
||
|
||
04.1 之后，它变成了 selected `qpi`，no_call=false。
|
||
|
||
我认为这个变化**语义上是正确的**。它和 `R04-BI-035 / 036` 属于同一类：用户不是拒绝所有分析，而是拒绝深挖，只要轻量 QPI 判断。更重要的是，`R04-BI-022` 里有“底层假设”这个 IA heavy signal，但用户同时说“不要展开”，所以它是一个很好的 **IA 误召回防退化样本**。
|
||
|
||
问题只在于：04.1 expected labels 只列了 4 个 target cases，没有把 `R04-BI-022` 标成目标 case；而 full rerun 实际发生了 5 个行为变化。这个不需要返工规则，但需要在报告里补记，避免以后看报告时误以为只有 4 个 case 变化。
|
||
|
||
## 4. 我的验收判断
|
||
|
||
**04.1 规则补丁：通过。**
|
||
|
||
**04.1 测试：通过。**
|
||
|
||
**生命周期：不升级。**
|
||
QPI 和思想考古不能因为 selector patch、regression pass、validation pass 就升级为 stable；质量门文件也明确说，模型升级必须经过 evidence review、content review、regression review、selector review、Owner / CCRA review。
|
||
|
||
**不用做新的 04.2 规则修复。**
|
||
|
||
但在关闭 04.1 前，让 Codex 做一个很小的收尾即可。
|
||
|
||
## 5. 给 Codex 的下一步指令
|
||
|
||
让 Codex 做 **Round 04.1 closeout note**，不改规则，只补文档和归档。
|
||
|
||
具体任务：
|
||
|
||
1. 在 `03_POST_PATCH_ROUTING_VERIFICATION_REPORT_04.1.md` 增加一个小节：
|
||
**Non-target Behavior Diff / Accepted Collateral Change**
|
||
|
||
2. 记录 5 个 before/after 变化：
|
||
|
||
* `R04-BI-002`
|
||
* `R04-BI-022`
|
||
* `R04-BI-024`
|
||
* `R04-BI-035`
|
||
* `R04-BI-036`
|
||
|
||
3. 对 `R04-BI-022` 写明判断：
|
||
|
||
* 不是新增失败；
|
||
* 属于 depth-limiting QPI override 的合理联动变化；
|
||
* IA 应继续被拒绝；
|
||
* QPI 轻量判断可接受；
|
||
* 建议进入 regression 或至少 calibration。
|
||
|
||
4. 我建议把 `R04-BI-022` 加成一条 regression case。理由是它同时包含：
|
||
|
||
* `不要展开`；
|
||
* `底层假设` IA heavy signal；
|
||
* `主导稀缺` QPI signal。
|
||
这个组合比 `035` 更容易暴露“IA 被误召回”的退化风险。
|
||
|
||
5. 重新跑：
|
||
|
||
* selector regression；
|
||
* post-patch verification；
|
||
* full unit tests；
|
||
* validation / sync checks。
|
||
|
||
这个收尾可以叫 **Round 04.1 closeout**，不要叫新一轮评审。
|
||
|
||
## 6. 关闭 04.1 后进入什么阶段
|
||
|
||
下一步不要继续围绕 002 这种 no-call patch 打转。应该进入 **Round 05：selector calibration policy review**。
|
||
|
||
Round 05 不应急着改规则，而是先做策略判断：
|
||
|
||
* 治理 / 责任 / 共识类输入是否应该更容易进 QPI；
|
||
* capacity / resource / path 类输入哪些应该 no-call，哪些应该 QPI；
|
||
* `likely_intellectual_archaeology` 里自然语言触发不足的 case，是坚持 QPI-first，还是允许 IA 直接进入；
|
||
* `QPI 已经判断...继续分析...` 这种 case，是否应该只选 IA，避免 QPI 重复 selected；
|
||
* 是否需要建立 before/after diff checker，要求每次 patch 自动列出所有非目标行为变化。
|
||
|
||
最终决策：**04.1 可以通过；先做 closeout 文档补记 + 可选增加 `R04-BI-022` regression，然后进入 Round 05 校准讨论。**
|
||
|
||
# 4
|
||
|
||
我考虑关闭Round 4。
|
||
|
||
Round 5我计划在新会话中讨论，可以考虑Codex输出一个Round 5的初始化脚本，作为我们新会话中的上下文。
|
||
你输出这个相关的指令。
|
||
|
||
---
|
||
|
||
在这里，我想和你讨论的是我能否在本地搭建一个CCRA。你/GPT和我本地打造CCRA有什么核心区别。
|
||
我现在做的很多工作是搬运工，将Codex的评审资料传上来。
|
||
我在本地Codex中也再使用GPT5.5，理论上和这里没啥区别。Codex很多问题看的不到位，我觉得有两个方面：
|
||
1. 你的系统提示词是专门设置的，Codex主会话没有这个；
|
||
2. 你从其他角度看Codex的产物，相当于是对问题做正交检查。
|
||
|
||
我可以在本地做一个装了你的提示词的Agent或者Skill，在单独线程/会话中启动，进行本地评审资料的检查。这样：
|
||
1. 我可以少很多搬运的工作
|
||
2. 有些修订、评审可以做些自动化，加快进度
|
||
|
||
对于这个思路，你有什么建议？
|
||
|
||
|
||
According to a document from 2026-06-18，我同意关闭 Round 4。Round 04.1 已经明确是 selector 规则补丁与 post-patch verification，不是第二次盲测；四个目标失败点已经被补丁覆盖，且没有引入 LLM selector、第三模型、RAG 或模型生命周期升级。
|
||
但我建议关闭前把 `R04-BI-022` 的联动变化作为 closeout note 记录下来，不需要再开 04.2。
|
||
|
||
---
|
||
|
||
# 一、给 Codex 的指令：关闭 Round 4，并生成 Round 5 初始化脚本
|
||
|
||
下面这段可以直接交给 Codex。
|
||
|
||
```text
|
||
请执行 Round 04 closeout，并准备 Round 05 新会话初始化材料。
|
||
|
||
目标：
|
||
1. 正式关闭 Round 04 / 04.1。
|
||
2. 不再修改 selector rules。
|
||
3. 不升级 QPI 或 Intellectual Archaeology 生命周期状态。
|
||
4. 不引入 LLM selector、第三模型、RAG、前端、后端或新产品模块。
|
||
5. 生成一个 Round 05 初始化脚本，用于在新会话中快速建立上下文。
|
||
|
||
一、Round 04 closeout 要求
|
||
|
||
请新增或更新以下文件：
|
||
|
||
1. reports/Round04_closeout_note_2026-06-18.md
|
||
|
||
内容必须包括：
|
||
|
||
- Round 04 原始盲测报告已保留，未回写。
|
||
- Round 04.1 是 selector rule patch + post-patch verification，不是第二次盲测。
|
||
- Round 04.1 修复目标：
|
||
- R04-BI-002：translation payload 误触发 QPI；
|
||
- R04-BI-024：不要进入思想考古未 hard-exclude IA；
|
||
- R04-BI-035：不要深入分析 + 主导稀缺判断被 hard no-call；
|
||
- R04-BI-036：不要展开 + 缺信息/缺路径/缺共识判断被 hard no-call。
|
||
- 四个 targeted cases 在 post-patch verification 中全部 PASS。
|
||
- 当前 QPI 和 Intellectual Archaeology 仍保持：
|
||
- status: draft
|
||
- stability_level: B
|
||
- regression_status: pending / in_progress
|
||
- Round 04 / 04.1 不构成模型稳定性升级依据。
|
||
- R04-BI-022 作为 accepted collateral behavior change 记录：
|
||
- 原结果：hard no-call；
|
||
- patch 后：QPI selected，IA rejected；
|
||
- 判断：这是 depth-limiting QPI override 的合理联动变化；
|
||
- 不视为新增失败；
|
||
- 建议列入 Round 05 calibration discussion，或作为 regression candidate。
|
||
- Round 05 的主题转入 selector calibration policy review，不继续围绕 04.1 做规则补丁。
|
||
|
||
2. 如尚未完成，可将 R04-BI-022 加入 regression candidate 列表；是否正式加入 regression 由 Round 05 决定。不要为了 R04-BI-022 开新补丁轮次。
|
||
|
||
二、Round 05 初始化脚本要求
|
||
|
||
请新增：
|
||
|
||
scripts/init_round05_context.py
|
||
|
||
要求：
|
||
|
||
- 使用 Python 标准库。
|
||
- 不调用 LLM。
|
||
- 不修改 selector rules、model cards、regression cases。
|
||
- 只读取现有文件并生成 Round 05 新会话上下文文档。
|
||
- 输出文件建议为：
|
||
|
||
ccra_review_bundle/round-05_init_selector-calibration-policy/00_ROUND05_NEW_SESSION_CONTEXT.md
|
||
|
||
脚本应汇总以下内容：
|
||
|
||
1. Project State
|
||
- 当前项目仍处于 model_library_mvp。
|
||
- 当前目标是 file-first 认知模型库 MVP。
|
||
- 当前样板模型是 QPI 与 Intellectual Archaeology。
|
||
- 当前 selector 仍然是 rule-based。
|
||
|
||
2. Round 04 / 04.1 Closure Summary
|
||
- Round 04 是 blind routing evaluation。
|
||
- Round 04.1 是 selector no-call、hard exclusion、depth-limiting patch。
|
||
- 四个 targeted cases 已通过。
|
||
- 不升级模型生命周期。
|
||
- 不引入 LLM selector。
|
||
|
||
3. Round 05 Proposed Scope
|
||
标题建议：
|
||
Round 05: Selector Calibration Policy Review
|
||
|
||
Round 05 只做校准策略判断，不直接修改规则，除非 Owner / CCRA 明确批准后进入 Round 05.1 patch。
|
||
|
||
4. Round 05 Core Questions
|
||
至少包含：
|
||
|
||
- Governance / responsibility / consensus 类输入是否应该更容易进入 QPI？
|
||
- Capacity / resource / path 类输入哪些应保持 no-call，哪些应进入 QPI？
|
||
- likely_intellectual_archaeology 类自然语言输入是否应允许 IA 直接进入，还是必须 QPI-first？
|
||
- 当用户说“QPI 已经判断……”时，selector 是否还应同时 selected qpi，还是只 selected IA？
|
||
- ambiguous low-context 输入如何处理？
|
||
- 是否需要 before/after behavior diff checker，自动列出所有非 target 行为变化？
|
||
- R04-BI-022 应进入 regression，还是只进入 calibration？
|
||
|
||
5. Files To Read in New Conversation
|
||
至少列出：
|
||
|
||
- reports/Round04_closeout_note_2026-06-18.md
|
||
- reports/Round04_blind_routing_evaluation_report_2026-06-18.md
|
||
- reports/Round04_1_post_patch_routing_verification_report_2026-06-18.md
|
||
- selector/round04_blind_inputs.json
|
||
- selector/selector_rules.json
|
||
- selector/selector_calibration_inputs.json
|
||
- tests/qpi.regression.json
|
||
- tests/intellectual_archaeology.regression.json
|
||
- tests/regression_cases.json
|
||
- docs/DECISIONS.md
|
||
- docs/WORKFLOW.md
|
||
|
||
6. Round 05 Non-Goals
|
||
必须写明：
|
||
|
||
- 不新增第三模型；
|
||
- 不升级 QPI；
|
||
- 不升级 Intellectual Archaeology；
|
||
- 不引入 LLM selector；
|
||
- 不引入 RAG / vector database / frontend / backend；
|
||
- 不把所有组织问题都扩展为 QPI 召回；
|
||
- 不把 Round 04 全量 blind pool 直接变成 regression。
|
||
|
||
7. Suggested Round 05 Deliverables
|
||
建议生成：
|
||
|
||
- 01_ROUND05_SCOPE_AND_POLICY_QUESTIONS.md
|
||
- 02_ROUND04_BEHAVIOR_DIFF_FOR_CALIBRATION.md
|
||
- 03_CANDIDATE_CALIBRATION_CASES.md
|
||
- 04_CANDIDATE_REGRESSION_CASES.md
|
||
- 05_CCRA_REVIEW_QUESTIONS_ROUND05.md
|
||
|
||
三、运行与验证
|
||
|
||
生成脚本后，请运行：
|
||
|
||
python scripts/init_round05_context.py
|
||
|
||
并输出：
|
||
|
||
- 生成文件路径；
|
||
- 是否成功；
|
||
- 是否有缺失文件；
|
||
- Round 05 context 中包含的主要 section；
|
||
- 不要修改 selector rules。
|
||
|
||
四、交付格式
|
||
|
||
请提交：
|
||
|
||
- reports/Round04_closeout_note_2026-06-18.md
|
||
- scripts/init_round05_context.py
|
||
- ccra_review_bundle/round-05_init_selector-calibration-policy/00_ROUND05_NEW_SESSION_CONTEXT.md
|
||
- 如有必要，更新 BUNDLE_FILE_MANIFEST 或 raw_file_list。
|
||
|
||
完成后只汇报：
|
||
1. Round 04 是否可关闭；
|
||
2. Round 05 初始化文件路径；
|
||
3. 是否有未解决问题。
|
||
```
|
||
|
||
---
|
||
|
||
# 二、你能不能在本地搭建一个 CCRA？
|
||
|
||
可以，而且值得做。
|
||
但它不应该被设计成“本地版的我”，而应该设计成：
|
||
|
||
> **本地 CCRA Reviewer = 一个只读、审查型、反证型 Agent，加上一组确定性检查 Skill。**
|
||
|
||
它的职责不是替你最终判断，而是把现在大量“搬运 + 初筛 + 对照 + 找明显漏洞”的工作本地化、自动化。
|
||
|
||
你现在的判断是对的：这里和 Codex 本地 GPT5.5 的差异，不只是模型名，而是 **提示词、上下文、工具边界、角色位置和审查视角** 的差异。
|
||
|
||
---
|
||
|
||
# 三、这里的我 / GPT 与本地 CCRA 的核心区别
|
||
|
||
## 1. 系统角色不同
|
||
|
||
这里的我被设置成“认知科学产品规划架构师 / CCRA”，优先做需求挖掘、模型产品化、边界审查、Codex 前置规划，而不是默认执行代码或修文件。
|
||
|
||
Codex 主会话更像执行者。它有 repo 操作能力，但容易进入“完成任务 / 修测试 / 让命令通过”的状态。
|
||
这也是为什么它会把工程 pass 当成阶段完成，而需要 CCRA 再问：**这个 pass 是否真的说明产品判断成立？**
|
||
|
||
当前项目本来也要求把规划转成本地规则、schema、workflow、validation、owner review points，而不能把 GPT 规划直接当执行规则。
|
||
|
||
## 2. 证据位置不同
|
||
|
||
本地 Codex 有完整仓库，适合做：
|
||
|
||
* diff；
|
||
* 文件一致性；
|
||
* regression；
|
||
* bundle 完整性；
|
||
* before / after 行为变化；
|
||
* 命令执行结果。
|
||
|
||
这里的 GPT 更适合做：
|
||
|
||
* 轮次目标是否被偷换；
|
||
* 规则补丁是否过度；
|
||
* 模型生命周期是否被提前升级；
|
||
* 哪些问题应该进入下一轮，而不是在本轮硬修；
|
||
* Codex 产物是否存在“看起来都通过，但产品判断没成立”的问题。
|
||
|
||
项目文档本身也把 selector、regression、validation、review bundle 分成不同治理层：selector 判断调用，regression 保护边界，validation 做机械一致性检查，review bundle 用于交接审核。
|
||
|
||
## 3. 正交性不同
|
||
|
||
你说得很准确：这里的一个重要价值是“正交检查”。
|
||
|
||
Codex 做了东西，它的上下文里天然带着“我刚才为什么这么做”的理由；如果同一个会话继续自审，很容易合理化自己的产物。
|
||
本地 CCRA 必须避免变成“Codex 自我复述”。
|
||
|
||
所以本地 CCRA 要和 Codex 执行者分开：
|
||
|
||
* 不在同一个主会话里连续执行；
|
||
* 不让 reviewer 直接修代码；
|
||
* 不让 reviewer 只读 Codex 总结，要读报告、diff、测试结果；
|
||
* 不允许 reviewer 因为 tests pass 就建议升级模型；
|
||
* reviewer 输出 findings 和 next actions，由另一个执行线程处理。
|
||
|
||
## 4. 自动化程度不同
|
||
|
||
本地 CCRA 可以大幅减少搬运工作，但不能完全替代这里的阶段性人工评审。
|
||
|
||
最合理的结构是：
|
||
|
||
```text
|
||
Codex 执行者
|
||
-> 生成 review bundle
|
||
-> 本地 CCRA Reviewer 自动初审
|
||
-> Codex 根据初审修补
|
||
-> 本地 CCRA Verifier 跑一致性检查
|
||
-> Owner 决策
|
||
-> 关键轮次再交给这里做外部 CCRA 复审
|
||
```
|
||
|
||
也就是说：
|
||
**本地 CCRA 解决 70% 到 80% 的机械审查和第一轮红队；这里保留为关键节点的第二视角。**
|
||
|
||
---
|
||
|
||
# 四、本地 CCRA 应该做什么，不应该做什么
|
||
|
||
## 应该做
|
||
|
||
1. **Bundle 完整性检查**
|
||
是否有 brief、manifest、raw zip、validation sidecar、报告、命令日志。
|
||
|
||
2. **轮次目标检查**
|
||
比如 Round 04 是 blind routing evaluation，不是最终回答质量评估；Round 04.1 是 post-patch verification，不是第二次盲测。
|
||
|
||
3. **生命周期守门**
|
||
检查是否有人因为 schema pass、selector demo pass、unit tests pass 就把 QPI / 思想考古升级。质量门明确说工程 contract pass 不等于内容稳定，模型升级仍需 evidence review、content review、regression review、selector review、Owner / CCRA review。
|
||
|
||
4. **before / after diff 审计**
|
||
每次 selector patch 后，自动列出所有行为变化，不只列 targeted cases。
|
||
这次 `R04-BI-022` 就是典型例子。
|
||
|
||
5. **测试语义审查**
|
||
判断测试是否真的测到了产品风险，而不是只是代码能跑。
|
||
|
||
6. **规则过拟合检查**
|
||
例如只为 `R04-BI-002` 加“模型还处在草稿阶段”这种特例就不合格；04.1 的做法更好，是加入翻译任务 no-call 和 instruction / payload 分离。
|
||
|
||
7. **Round 下一步建议**
|
||
判断一个问题应该：
|
||
|
||
* 本轮修；
|
||
* 下一轮校准；
|
||
* 进入 regression；
|
||
* 进入 calibration；
|
||
* 只作为 discussion example。
|
||
|
||
## 不应该做
|
||
|
||
1. 不直接决定模型升级。
|
||
2. 不直接新增第三模型。
|
||
3. 不把所有组织问题都扩展成 QPI。
|
||
4. 不在同一轮里既实现又自我验收。
|
||
5. 不用 LLM selector 替代当前可审计规则 selector。当前文档明确说当前阶段不做 LLM selector，且 rule-based selector 的价值是可审计、可回归。
|
||
6. 不把“本地 GPT 看了一遍”当成 Owner / CCRA 最终审查。
|
||
|
||
---
|
||
|
||
# 五、我建议的本地 CCRA 结构
|
||
|
||
## 1. 一个 Agent：`ccra-reviewer`
|
||
|
||
它的核心系统提示词不要追求完全复制当前 GPT，而要沉淀成仓库内的审查契约。
|
||
|
||
建议文件：
|
||
|
||
```text
|
||
agents/ccra-reviewer/AGENTS.md
|
||
```
|
||
|
||
核心角色写成：
|
||
|
||
```text
|
||
你是 CCRA Local Reviewer。
|
||
|
||
你的职责不是实现功能，而是审查 Codex 产物是否符合：
|
||
- 当前 round scope；
|
||
- model_library_mvp 边界；
|
||
- selector / regression / validation 治理机制；
|
||
- QPI 与 Intellectual Archaeology 的生命周期守门；
|
||
- Owner / CCRA 已确认的产品判断。
|
||
|
||
你必须优先识别：
|
||
1. 轮次目标是否被偷换；
|
||
2. 工程 pass 是否被误当成内容稳定；
|
||
3. selector 是否过拟合；
|
||
4. no-call / QPI / IA 边界是否被破坏；
|
||
5. 是否存在非目标行为变化；
|
||
6. 哪些问题应该进入下一轮，而不是本轮硬修。
|
||
|
||
你只输出 review findings、risk classification、recommended next actions。
|
||
除非 Owner 明确授权，不直接修改业务文件。
|
||
```
|
||
|
||
## 2. 一组 Skills
|
||
|
||
建议拆成 5 个本地 Skill：
|
||
|
||
```text
|
||
skills/review-bundle-audit/
|
||
skills/routing-diff-audit/
|
||
skills/regression-gate-check/
|
||
skills/lifecycle-guard/
|
||
skills/round-init-context-builder/
|
||
```
|
||
|
||
各自职责：
|
||
|
||
* `review-bundle-audit`：检查上传包结构、manifest、zip、validation sidecar。
|
||
* `routing-diff-audit`：比较 before / after routing，列出 target diff 和 non-target diff。
|
||
* `regression-gate-check`：跑 selector regression、unit tests、validation、sync。
|
||
* `lifecycle-guard`：扫描是否把 `draft / B / pending` 错误升级。
|
||
* `round-init-context-builder`：生成下一轮新会话上下文，也就是你说的 Round 5 初始化脚本。
|
||
|
||
## 3. 一个固定工作流
|
||
|
||
```text
|
||
1. Codex 执行任务
|
||
2. Codex 生成 review bundle
|
||
3. 本地 CCRA Reviewer 只读审查
|
||
4. 本地 CCRA 生成 LOCAL_CCRA_REVIEW_REPORT.md
|
||
5. Codex 根据 report 修复
|
||
6. 本地 Verifier 跑测试与 diff
|
||
7. Owner 决策是否关闭 round
|
||
8. 关键节点再上传给这里做外部 CCRA 复审
|
||
```
|
||
|
||
---
|
||
|
||
# 六、最大的风险：本地 CCRA 会不会变成“Codex 自我审查”？
|
||
|
||
会，这是最大的风险。
|
||
|
||
解决办法不是不用本地 CCRA，而是建立隔离规则：
|
||
|
||
1. **Reviewer 不修改文件**
|
||
它只输出报告。
|
||
|
||
2. **Reviewer 不读取 Codex 的解释优先**
|
||
它优先读 source files、diff、reports、tests，再读 Codex summary。
|
||
|
||
3. **Reviewer 必须列出反证**
|
||
每次都要回答：
|
||
|
||
* 有哪些 evidence 不支持 Codex 的结论？
|
||
* 有哪些通过测试但仍未证明的产品判断？
|
||
* 哪些变化是非目标变化？
|
||
* 哪些问题被推迟了？
|
||
|
||
4. **Reviewer 必须保留“不建议继续修”的能力**
|
||
比如 04.1 就应该说：不要再开 04.2，进入 Round 05 calibration。
|
||
|
||
5. **Owner 仍是最终 gate**
|
||
本地 CCRA 可以减少搬运，但不能把模型生命周期、产品方向、下一轮主题自动决定掉。
|
||
|
||
---
|
||
|
||
# 七、我的总体建议
|
||
|
||
你应该做本地 CCRA，但定位要克制：
|
||
|
||
> **本地 CCRA 负责审查自动化与第一轮正交检查；这里的 GPT 保留为关键节点的产品级、模型治理级复审。**
|
||
|
||
短期最适合先做两个东西：
|
||
|
||
1. **Round 初始化上下文生成器**
|
||
先从 Round 5 init script 做起，立刻减少新会话搬运成本。
|
||
|
||
2. **Routing diff audit**
|
||
每次 selector patch 后，自动列出所有行为变化。
|
||
这比“让 GPT 再看一遍”更稳定，也能防止 `R04-BI-022` 这种非目标变化被漏掉。
|
||
|
||
最终你会得到一个更顺的协作模式：
|
||
|
||
```text
|
||
Codex 做工程与文件修改
|
||
本地 CCRA 做机械审查、diff、测试语义初筛
|
||
这里的 CCRA 做阶段判断、产品边界、模型治理、下一轮策略
|
||
Owner 做最终决策
|
||
```
|
||
|
||
这条路是对的。关键不是“本地能不能复制 GPT”，而是：**把 CCRA 的审查原则产品化、工具化、流程化，同时保留一个外部正交视角。**
|
||
|