# 1

核心模型抽取样板 v0.1，是上一次会话中你的具体安排。
ChatGPT交接文档_模型库MVP_2026-06-16，是Codex做完后的交接文档。

`intellectual_archaeology.model`，思想考古的model；思想考古的card已放在你的知识库中。
`qpi.model.json`，QPI的model；QPI的Card也放在知识库中

以及其他相关文件已经都上传。

需要你加载这些文档。目前codex提出了问题，需要你确认；同时你判断当前工作还有哪些不足。

根据 2026-06-16 的交接材料，我已把这批文件按“Codex 完成后的模型库 MVP 交接审查”加载并对齐。核心判断是：**Codex 的工程方向基本正确，没有跑偏；但当前只能算“工程 contract 通过”，还不能算“模型内容稳定通过”。下一步应进入内容审查、证据审查、回归测试扩展，而不是立刻扩展第三个模型或接入完整问题回答系统。**

我理解这个产品暂时可以定义为：**一个 file-first 的认知模型库 MVP，用 QPI 和思想考古两个样板模型，验证认知模型是否能被整理成可读、可追溯、可调用、可测试的系统资产。** 这和原样板文档的目标一致：先跑通“原始文章 / 代表文本 → 来源文章索引 → 关键证据片段 → 人读模型卡 → 机器 JSON → 回归测试 → 最小模型选择器”的链路，而不是先做完整后台或数据库。

## 1. 当前状态确认

Codex 已完成的是**模型库 / 模型管理子系统 MVP 的工程化打样**：包括 QPI 和思想考古两个样板模型、模型卡、JSON model card、source article / source excerpt 索引、regression cases、selector rules/examples、model/card index，以及 validator、card contract checker、selector demo。交接文档明确说，当前内容通过本地 contract，但仍是 `draft`，等待产品 / ChatGPT / CCRA 内容审查。

验证结果本身是好的：Unit tests、Card contract、Model library validation、Selector demo 都显示 PASS。这里要注意：**PASS 只证明工程结构和字段契约能跑通，不证明 QPI 和思想考古已经足够稳定。** 产品规划过程记录也把当前关键决策定为 file-first、JSON 作为机器数据、Markdown 作为人读卡、v0.1 选择 rule-based selector。

当前阶段边界也没有偏：这个仓库不做前端、后端、数据库、向量库、完整 RAG、用户系统、支付、公平台或多人协作；目标就是验证少量核心模型能否被整理为 Markdown card、JSON card、来源记录、证据片段、回归测试、最小规则选择器和本地校验对象。

## 2. 对 Codex 提出问题的确认

### 2.1 QPI 当前字段和边界是否准确？

**基本准确，可以作为 v0.1 draft 通过，但需要补强。**

QPI 当前定位是正确的：它是 `routing_model`，处在 `pre_analysis`，不是最终分析模型；核心机制是用“核心匮乏物”区分数据匮乏、路径/资源匮乏、共识/秩序匮乏，并据此进入提问、难题、课题的不同处理路径。

但我建议补强 4 个字段或输出要求：

1. `problem_owner`：这个问题是谁的问题；
2. `time_scale`：问题发生在短期执行、中期路径，还是长期系统演化；
3. `evidence_gap`：当前判断缺哪些证据；
4. `dominant_scarcity`：混合问题中主导匮乏物是什么。

原因是 QPI 当前最大风险不是分类不会做，而是**真实问题常常是 Q/P/I 混合状态**。QPI 卡里已经承认真实输入会出现混合状态，边界案例仍需更多测试。

### 2.2 思想考古学是否应保持七层结构，还是需要更强停止条件？

**七层结构应保留，但不能作为默认全量展开流程；停止条件必须升格为一等规则。**

思想考古当前定位是 `deep_modeling_model`，应在 QPI 或问题价值评估之后调用；它用应用层、领域层、过程层、目的层、核心机理层、人类能力层、哲学基岩层做纵向下潜。这个结构适合作为深度建模框架。

但七层结构必须受“最小充分下潜”约束：如果继续下潜不再改变判断、路径、验证方式或行动边界，就应停止。这个原则已经写入卡片，但还需要从“原则描述”变成 selector 和输出契约里的硬门槛。

所以我的确认是：**保留七层，强化停止门。** 每次调用思想考古时，输出必须包含“建议下潜到哪一层”“为什么停在这一层”“继续下潜不会增加什么价值”“哪些部分需要现实反馈校准”。

### 2.3 是否应引入第三个核心模型？

**现在不建议立刻引入第三个模型。**

当前核心模型地图已经明确：QPI 和思想考古都是 `B`，regression_status 都还是 `pending`；并且明确说，在 QPI 和思想考古稳定前不要快速扩展大量模型。

如果必须准备第三模型，我建议只做**候选模型预研**，不要进入工程录入。第三模型最好不是另一个纵向深挖模型，而是补齐当前链路短板的横向模型，例如：

**认知棱镜 / 冲突汇总 / 综合洞察类模型。**

理由：QPI 负责前置路由，思想考古负责纵向下潜，但当前缺少横向多视角比较、冲突识别和综合输出。也就是说，第三模型的方向应该服务于“问题加工系统”的前台输出，而不是继续堆模型库字段。

### 2.4 后续模型抽取是否需要拆成抽取、检验、评分三个环节？

**需要。下一轮就应拆。**

原因是当前 Codex 已经证明“结构化录入”可以完成，但没有证明“内容语义可靠”。交接文档也明确列出：QPI 和思想考古内容虽然通过 contract，但仍需产品语义审查；source evidence 是否足够支撑字段仍需判断；regression cases 只是样板级，真实业务案例不足；selector scoring 仍是 v0.1 简单规则。

我建议三段式标准如下：

**抽取环节**负责把文章和已有表达变成模型卡、JSON、source evidence、regression cases。验收标准是字段完整、ID 可追溯、结构能通过 schema。

**检验环节**负责红队：概念是否混乱、边界是否清楚、是否循环论证、是否过度解释、是否有真实反例、来源证据是否真的支撑字段。

**评分环节**负责给出 A/B/C/D 稳固性等级，并决定能否进入 selector 默认调用。评分不能只看字段完整，要看概念清晰度、机制稳定性、边界清晰度、来源证据质量、回归测试表现。稳固性规则也明确说，模型不能仅因为字段完整就升级。

### 2.5 当前样板是否暴露出需要多角色审查的质量问题？

**是，已经暴露。**

QPI 的主要质量问题是：容易把复杂叙事全部升维成 Issue，或者把系统性课题降维成个人执行难题。卡片里已经把这些列为常见误用和失败信号。

思想考古的主要质量问题是：容易为了显得深刻而无限下钻、把轻量问题拖入七层分析、用哲学基岩替代现实验证、下潜后不回到可行动结论。卡片也明确列出了这些误用。

所以至少需要三个审查视角：

1. **抽取者**：负责忠实结构化；
2. **红队检验者**：负责找漏洞、边界和误用；
3. **产品评分者 / CCRA**：负责判断是否可进入系统调用。

### 2.6 regression cases 是否应按模型拆分？

**v0.1 合并可以接受；v0.2 起建议按模型拆分，同时保留总索引。**

当前 Codex 把 regression cases 合并到 `tests/regression_cases.json`，这与原计划的按模型拆分不同。交接文档已经把这列为实现差异。

我的判断是：

* 现在只有 2 个模型，合并文件能跑通，不必返工；
* 扩展到 5 个模型时，应拆成 `qpi.regression.json`、`intellectual_archaeology.regression.json` 等；
* 同时保留一个聚合视图或 validator 读取入口，方便全库校验。

也就是说，**人审按模型拆，机器校验可聚合。**

### 2.7 selector 应继续规则化，还是加入 LLM 判断层？

**v0.1 继续规则化，不要现在加入 LLM 判断层。**

selector 当前的目标不是做智能调度系统，而是验证模型 JSON 的字段能不能被机器读取，并基于 trigger keywords、negative triggers、pipeline position、selection priority 给出候选模型。README 也明确说，当前 selector 不是完整 AI 系统，只是最小推荐 demo。

下一阶段可以加 LLM，但只能作为**解释层 / 仲裁层**，不能替代规则层。推荐结构是：

```text
规则 selector 先给候选模型
→ LLM 判断输入语义和上下文
→ 检查 negative triggers
→ 输出推荐理由与不推荐理由
→ 回归测试验证 selector 是否误召回
```

现在直接加 LLM 会掩盖模型卡字段质量问题，不利于检验 schema 和调用规则是否真的有效。

## 3. 当前工作还有哪些不足

### 3.1 当前最大不足：工程 contract 通过，但内容 contract 还没有通过

Codex 已完成结构、校验和 demo，但交接文档明确说模型内容仍是 `draft`，等待产品 / ChatGPT / CCRA 内容审查。

这意味着现在不能把 QPI 和思想考古标记为“核心稳定模型”。它们目前更准确的状态是：

```text
可工程调用的 draft 模型
可进入内容审查
不可直接大规模扩展
不可直接作为稳定系统默认调用
```

### 3.2 QPI 的主导匮乏物判断还不够硬

QPI 已经有三分结构，但真实输入常常混合：既缺数据，又缺路径，还缺共识。当前已有一个混合边界测试，但不够。QPI 现在需要补的是**主导匮乏物判定规则**，否则 selector 和问题加工系统会在混合问题上摇摆。

建议增加判断顺序：

```text
先问：有没有事实缺口？
再问：事实补齐后是否仍缺路径？
再问：路径存在时是否仍因多主体/价值/秩序冲突无法推进？
最后判断：当前阶段最该先处理哪个匮乏物？
```

### 3.3 思想考古的停止条件仍偏原则化

思想考古卡里已经写了“最小充分下潜”，也写了停止条件。但当前它还没有变成可测试的操作门槛。它需要更明确地区分：

```text
不用下潜
下潜到过程层即可
下潜到目的层
下潜到核心机理层
需要触及人类能力层
极少数情况才到哲学基岩层
```

否则它会变成一个“看起来很深但产品成本很高”的模型。

### 3.4 来源证据审查还不足

原样板要求模型卡必须有来源证据，并且每个核心字段尽量能追溯到来源：模型定义、核心机制、适用场景、不适用场景、调用规则、回归测试都应能找到来源或推导依据。

但我在当前可见材料里看到的是：交接文档列出了 `sources/source_excerpts.json`，但当前上传包里我没有看到独立完整的 `source_excerpts.json` 文件；我能看到 `source_articles.json` 和模型卡中的 evidence ID 引用。因此，**source evidence 是否真的支撑所有核心字段，目前还不能最终确认。**

这一步必须补，否则模型卡仍可能变成“看似结构化的二次包装”。

### 3.5 当前 regression cases 只是样板级

当前两个模型各有 5 条回归用例，覆盖 positive / boundary / misuse 的基本要求。但这只够证明测试容器存在，不够证明模型稳定。原样板虽然说 v0.1 每个模型至少 5 条用例即可，但稳固性升级条件要求 misuse case 能暴露误用、regression 覆盖 positive/boundary/misuse，并且 selector 不会在明显负向触发时误调用。 

下一轮每个模型至少应扩到 15 条：

```text
5 条正向适用
4 条边界案例
3 条误用案例
2 条负向触发 / no-call 案例
1 条模型组合案例
```

QPI 尤其需要更多“恶意升维 / 暴力降维 / 甩锅叙事 / 混合问题”的案例。思想考古尤其需要更多“不要下潜 / 下潜到哪一层停止 / 抽象输出失败”的案例。

### 3.6 selector 目前只能证明能跑，不能证明选得准

selector demo 当前是 v0.1 简单规则，这一点交接文档已经承认。

下一步 selector 不应直接智能化，而应先加：

```text
score breakdown
negative trigger penalty
no-call threshold
tie-break rules
QPI-before-IA gate
selector regression tests
```

否则它可能因为关键词命中就过度调用思想考古。

### 3.7 schema 略重，但暂时不需要砍

当前 `model_card.schema.json` 的 required 字段很多，包括 trigger_keywords、negative_triggers、related_models、conflicting_models、disciplinary_anchors、common_misuses、failure_modes、selection_priority、confidence_level、stability_profile、regression_status、examples、output_contract、productization_notes、version、last_updated 等。

我的判断是：**schema 对 v0.1 样板略重，但可以保留。** 因为当前重点是建立高质量样板，而不是快速录入 100 个模型。

但从 v0.2 开始建议分层：

```text
Core Required：系统调用必需字段
Review Required：内容审查必需字段
Optional：扩展解释字段
```

这样后续扩展到 8-10 个模型时，不会因为每张卡都要填过多叙述字段而拖慢。

### 3.8 当前上传材料里有两个需要补齐的交接缺口

第一，我在当前可见上传文件里没有看到独立的 `qpi.model.json`，只看到了 `qpi.md`、核心模型地图里对 `models/qpi.model.json` 的引用，以及原样板中的 QPI JSON 示例。核心模型地图明确把 QPI 的 source of truth 指向 `models/qpi.model.json` 和 `cards/qpi.md`。

第二，我没有看到独立完整的 `source_excerpts.json`。交接文档说它存在，但当前可见材料不足以让我做 evidence-level 审查。

所以我现在可以确认 QPI card 的产品语义方向，但不能最终确认 QPI 机器 JSON 与 evidence excerpt 的一致性。

## 4. 我给 Codex 的下一轮确认意见

可以给 Codex 这样的结论：

```text
当前 model_library_mvp 工程方向确认通过。QPI 和思想考古两个样板模型可以保留为 v0.1 draft，但不得升级为 stable，也不要立刻扩展第三个模型。

下一轮优先做内容稳定化，而不是功能扩展：

1. 补齐并提交 qpi.model.json、source_excerpts.json、selector_rules.json、selector_examples.json、validation_report.md。
2. 对 QPI 增加 problem_owner、time_scale、evidence_gap、dominant_scarcity 的输出要求。
3. 对思想考古强化最小充分下潜门槛，保留七层结构，但禁止默认全量七层展开。
4. 将模型抽取流程拆成 extraction / inspection / scoring 三段式。
5. regression cases 暂可合并，但 v0.2 起按模型维护，聚合校验。
6. selector v0.1 继续规则化，不加 LLM；先增加 no-call threshold、negative trigger penalty、score breakdown 和 selector regression tests。
7. 每个模型回归测试扩展到至少 15 条，再讨论是否引入第三个核心模型。
```

## 5. 下一步我建议你先做的决策

现在最关键的不是“第三个模型是谁”，而是先确认两件事：

**第一，QPI 和思想考古是否允许进入 `draft-callable` 状态。** 我的建议是允许，但必须带 guardrail：只能在测试链路和内部问题加工链路里调用，不能标记为 stable。

**第二，是否接受三段式审查流程。** 我的建议是接受。从第三个模型开始，不要再让 Codex 一次性完成“抽取 + 判断 + 评分”，否则后面 8-10 个核心模型会积累隐性质量债。

---

我补充了两份缺失的文档，同时补充了相应的Index文档。

我的问题是，model index 和card index，是每次增量更新，还是需要的时候全量更新一次。

然后需要你给一份新的指导性意见，我保存成文件，让Codex来读取执行。

根据 2026-06-16 的当前模型地图和 README，答案是：**model index 和 card index 应采用“每次增量同步 + 关键节点全量重建 / 全量校验”的混合策略。**

不要只在需要时全量更新一次。因为当前模型地图已经把 `models/model_index.json` 定义为机器索引源，把 `cards/card_index.md` 定义为人读索引源；新增模型前也明确要求必须具备 `model/card index entries` 和 validation report。
也不要每次都靠人工全量重写。项目原则已经是 file-first、JSON 机器可读、Markdown 人读，并且 validation 要检查 model/card indexes、source references、regression references、Markdown card required sections 等一致性。

我的判断是：

```text
单次资产变化：必须增量更新 index
交接 / release / schema 改动 / 批量扩展 / 状态升级前：必须全量重建或全量校验
```

更具体地说：

```text
新增模型、删除模型、修改状态、修改稳固性、修改回归状态、
新增 source evidence、增加 regression cases、重命名 card/model 文件
=> 同一轮必须更新 model_index.json 和 card_index.md
```

但在这些节点必须全量检查：

```text
交给 ChatGPT / CCRA 前
生成 validation_report.md 前
新增一批模型后
schema 改动后
selector 依赖 index 前
模型准备从 draft 升级前
发现 index drift 后
```

关键原则是：**索引是导航和注册表，不是完整内容本体。** 完整内容仍在 `models/*.model.json`、`cards/*.md`、`sources/*.json`、`tests/*.json`；但机器和人都要通过索引快速发现当前模型库状态。当前交接文档也显示 Codex 已创建 model/card/source/excerpt/regression/index schemas、model index、card index、validator 和 selector demo，所以现在应该把 index 维护升级为可校验流程，而不是继续靠人工记忆。

我已生成一份给 Codex 执行的指导文件：

[下载：CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md](sandbox:/mnt/data/CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md)

这份文件的核心执行口径是：

```text
1. 新增 docs/INDEX_MAINTENANCE_PROTOCOL.md
2. 新增 scripts/rebuild_indexes.py
3. 支持 --check 和 --write
4. 让 model_index.json 从模型 JSON、source、test 统计中生成或校验
5. 让 card_index.md 从 model_index.json 渲染
6. 扩展 validate_model_library.py 检查 index drift
7. 保持 QPI / 思想考古当前仍为 draft + B + pending
```

一句话给 Codex：**不要把 index 当成手工维护文档；把它变成“每次变更同步、关键节点重建、validator 强制检查”的模型库注册机制。**

# 2

第一轮的检查时，我遗漏了两个文件。
现在能否继续判断当前工作还有哪些不足，也生成一个指导文件，我也让Codex去完成。

可以。补齐 `qpi.model.json` 和 `source_excerpts.json` 之后，我的判断更新为：

**缺文件问题已经解决；但当前仍只是“工程 contract + 基础证据链通过”，还没有进入“内容稳定通过”。下一轮 Codex 应该做内容稳定化，而不是扩展第三模型。**

依据是：交接文档已经说明 QPI 和思想考古学虽然通过本地 contract，但仍是 `draft`，等待产品 / ChatGPT / CCRA 内容审查；它还明确列出 source evidence 充分性、regression cases 样板级、selector 评分简单规则等未解决问题。 README 也把当前 selector 定义为基于 trigger keywords、input type、negative triggers、pipeline position、selection priority 的简单 demo，并强调不要在样板模型稳定前扩展大量模型。

我现在看到的主要不足有 7 个：

1. **证据片段已经存在，但还不是字段级证据矩阵。**
   `source_excerpts.json` 已经补齐，QPI 和思想考古各有来源片段；但当前还没有标明每个模型字段到底是“原文直接支撑”“原文推导”“产品化决策”还是“红队推导”。

2. **`raw_excerpt` 的精确性需要规范。**
   有些片段是压缩摘录，比如思想考古七层结构片段用了省略表达。这种内容不能长期都叫 `raw_excerpt`，否则会制造“看似可追溯、实际不可精确追溯”的风险。

3. **QPI 的输出契约还不够硬。**
   现在 QPI 的输出类型包括“问题类型判断、分类理由、核心匮乏物判断、误判风险、推荐处理路径、后续模型调用建议”，但还没有把 `problem_owner`、`time_scale`、`dominant_scarcity`、`evidence_gap` 强制纳入输出。

4. **思想考古的停止条件还不够可测试。**
   当前已经有“最小充分下潜”的边界意识，但下一步必须把它转成结构化字段：建议下潜到哪一层、为什么停在这一层、继续下潜不会改变什么。否则七层结构很容易被误用成默认全量下钻。

5. **regression cases 仍只是样板级。**
   当前用例已经覆盖 positive、boundary、misuse，但数量还是每个模型 5 条左右，只够证明测试容器存在，不足以证明模型稳定。

6. **selector 还只能证明“能跑”，不能证明“选得准”。**
   交接文档也承认 selector demo 可运行，但评分逻辑仍是 v0.1 简单规则。下一轮需要 no-call threshold、negative trigger penalty、QPI-before-IA gate、score breakdown 和 rejected model reasons。

7. **Markdown card 与 JSON model card 还缺语义同步检查。**
   当前 card index 已经列出 QPI 和思想考古的 card / model JSON / 稳固性 / 回归状态，但这只能证明索引存在，不证明 Markdown 与 JSON 的关键字段语义一致。

我已生成新的 Codex 指导文件：

[下载：CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md](sandbox:/mnt/data/CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md)

这份文件的核心执行口径是：

```text
不要扩展第三模型
不要接完整问题回答系统
不要引入 LLM selector
不要升级 stable

先做：
1. 字段级 evidence coverage matrix
2. source excerpt 精确性修复
3. QPI 输出契约强化
4. 思想考古停止门强化
5. regression cases 扩展到每模型至少 15 条
6. selector v0.2 防误召回
7. JSON / Markdown 同步检查
8. content review report
```

给 Codex 的一句话是：**把 QPI 和思想考古从“工程可运行”推进到“内容可审查、证据可追溯、误用可测试、selector 可防误召回”，然后再讨论第三模型。**

# 3

Codex完成后，下一轮（也许是新会话），我需要提供哪些内容，供你再次审核？
三次指导文件都需要吧？
若知识库的文件有变化，我会进行更新。
其他的呢？

是的，**三次指导文件都需要**，但它们在下一轮审核里的作用不一样，不能等权读取。

我建议你下一轮给我一个“审核包”，不要只给 Codex 的交接文档。因为我需要判断的是：**Codex 是否按指导执行、是否产生新的质量债、QPI 和思想考古是否可以从 draft-callable 进一步推进，而不是只看它说自己完成了什么。**

## 一、三份指导文件都要提供

建议三份都放进下一轮审核包：

```text
1. 2026-06-16-核心模型抽取样板 v0.1.md
2. CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md
3. CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md
```

但优先级要这样理解：

```text
v0.1 核心模型抽取样板
= 初始总规范 / baseline

v0.2 Index 更新策略
= 索引维护、index drift、rebuild/check 规则

v0.3 内容稳定化
= 本轮 Codex 最主要执行依据
```

也就是说，如果三份文件之间有冲突，**v0.3 优先于 v0.2，v0.2 优先于 v0.1**。v0.1 主要用于判断 Codex 有没有偏离最初 MVP 边界：文章 / 代表文本 → source article → source excerpt → Markdown card → JSON model → regression cases → selector → index → validation report。这个链路本身仍然是当前项目的基础。

## 二、下一轮必须提供的内容

### 1. Codex 新一轮交接文档

这是最重要的。文件名建议类似：

```text
ChatGPT交接文档_模型库MVP_第二轮内容稳定化_YYYY-MM-DD.md
```

里面至少要包含：

```text
1. 本轮 Codex 接收了哪些指导文件
2. 本轮实际完成了哪些任务
3. 哪些任务没有完成，以及原因
4. 新增 / 修改 / 删除了哪些文件
5. 跑了哪些命令
6. 每条命令的结果：PASS / FAIL / SKIP
7. 哪些地方 Codex 做了实现取舍
8. 哪些问题需要 CCRA / 用户确认
9. 当前 QPI 和思想考古的状态判断
10. 是否仍保持 draft / B / pending
```

目前上一轮交接文档已经按这种方式列出了阶段、目标、已完成内容、关键文件路径、差异和待审查点，所以下一轮也应该延续这个交接格式。

### 2. 当前完整的 index 文件

必须提供：

```text
models/model_index.json
cards/card_index.md
```

原因是下一轮我要检查 Codex 是否正确执行了“增量同步 + 全量校验 / 重建”的策略。当前 `model_index.json` 记录了 QPI 和思想考古的模型类型、流程位置、source evidence count、regression case count、stability level、regression status 和 status。 `card_index.md` 是对应的人读索引，记录 card、model JSON、稳固性、回归状态和状态。

如果 Codex 新增了 rebuild 或 check 脚本，下一轮还要提供：

```text
reports/index_check_report.md
reports/index_rebuild_report.md
```

或者把相关内容并入 validation report。

### 3. 两个模型的最新 JSON 和 Markdown card

必须提供：

```text
models/qpi.model.json
models/intellectual_archaeology.model.json

cards/qpi.md
cards/intellectual_archaeology.md
```

因为下一轮重点不是看字段是否存在，而是看字段是否被强化到可调用状态。比如 QPI 当前是前置路由模型，核心机制已经包含“问题拥有者、来源、时间尺度、核心匮乏物、暴力降维、恶意升维、手段错配”等判断。 思想考古当前是 deep_analysis 模型，核心机制是七层下潜，并带有“最小充分下潜”原则。

下一轮我要重点检查：

```text
QPI 是否新增 / 强化：
- problem_owner
- time_scale
- dominant_scarcity
- evidence_gap
- mixed_state 判断
- 暴力降维 / 恶意升维识别

思想考古是否新增 / 强化：
- recommended_depth
- stop_reason
- value_of_deeper_analysis
- what_would_not_change_if_deeper
- validation_need
- 不默认七层全量展开
```

### 4. source articles 和 source excerpts

必须提供：

```text
sources/source_articles.json
sources/source_excerpts.json
```

`source_articles.json` 用于确认来源文章记录是否仍然指向正确的上游材料。当前它记录了 QPI 主来源、思想考古主来源和认知操作系统综合材料。

`source_excerpts.json` 用于检查证据链。当前它已经有 QPI 的 definition、taxonomy、application_rule 等证据片段，并且每条有 `used_for`、`raw_excerpt`、`confidence`、`notes`。 下一轮我要看 Codex 是否把它推进到**字段级 evidence coverage matrix**，而不是只停留在“模型引用了几条 excerpt”。

### 5. regression cases

必须提供：

```text
tests/regression_cases.json
```

或者如果 Codex 已按建议拆分，则提供：

```text
tests/qpi.regression.json
tests/intellectual_archaeology.regression.json
tests/regression_index.json
```

当前 regression cases 已经有 positive、boundary、misuse 类型，例如 QPI 有“服务器日志缺失”作为 Question 正例、“留存提升缺方法资源”作为 Problem 正例、“部门无共识”作为 Issue 正例、“用户流失既缺数据又缺判断”作为 mixed boundary case。 下一轮我要检查的是：是否从每模型约 5 条扩展到至少 15 条，是否覆盖 no-call、negative trigger、误召回、混合型、组合调用。

### 6. selector 相关文件

必须提供：

```text
selector/selector_rules.json
selector/selector_examples.json
```

如果 Codex 新增了 selector v0.2，还要提供：

```text
reports/selector_regression_report.md
reports/selector_score_breakdown.md
```

README 已明确当前 selector 不是完整 AI 系统，只是最小选择器基础；验证应检查 required fields、source references、regression references、model/card indexes、Markdown card required sections 和 regression coverage。 下一轮我要判断 selector 是否仍只是“能跑”，还是已经能防止明显误召回。

### 7. validation / review reports

必须提供 Codex 新生成的报告。建议至少包括：

```text
reports/validation_report.md
reports/content_review_report.md
reports/evidence_coverage_matrix.md
reports/selector_regression_report.md
reports/index_check_report.md
reports/内容修复检查摘要_v0.2.md
```

如果 Codex 没有拆成这么多文件，也可以合并成一个：

```text
reports/第二轮内容稳定化报告.md
```

但里面必须包含：

```text
1. schema validation 结果
2. card contract check 结果
3. model library validation 结果
4. index drift check 结果
5. source evidence coverage 结果
6. regression coverage 结果
7. selector no-call / negative trigger 测试结果
8. JSON / Markdown 语义同步检查结果
```

### 8. changed files manifest

这个很重要，建议让 Codex 必须生成：

```text
reports/changed_files_manifest.md
```

内容格式可以是：

```text
| File | Change Type | Why Changed | Related Guidance | Need Human Review |
| --- | --- | --- | --- | --- |
| models/qpi.model.json | modified | strengthen output_contract | v0.3 | yes |
| tests/regression_cases.json | modified | expand to 15 cases/model | v0.3 | yes |
| models/model_index.json | regenerated | sync regression count | v0.2 | yes |
```

这能显著降低下一轮审核成本。否则我需要从一堆文件里反推 Codex 改了什么。

## 三、建议提供的内容

这些不是绝对必须，但强烈建议。

### 1. 仓库目录树

给一份：

```text
repo_tree.txt
```

只需要 2-3 层目录，不要包含 `.git`、缓存、依赖目录。

原因是当前项目结构已经固定为：

```text
docs/
schemas/
models/
cards/
sources/
tests/
selector/
scripts/
reports/
knowledge_assets/
```

README 也明确了这些目录的职责。 下一轮如果 Codex 新增目录，我需要判断它是否合理，还是过早复杂化。

### 2. 本轮执行命令记录

建议提供：

```text
reports/command_log.md
```

格式：

```text
python -m unittest discover -s tests -p "test*.py" -v
PASS

python scripts/check_card_contract.py
PASS

python scripts/validate_model_library.py
PASS

python scripts/run_selector_demo.py
PASS

python scripts/rebuild_indexes.py --check
PASS
```

当前长期记录里已经有 Unit tests、Card contract、Model library validation、Selector demo 都 PASS 的基线。 下一轮我要对比的是：第二轮新增检查是否也通过，而不是只重复旧 PASS。

### 3. Codex 遇到的问题清单

建议提供：

```text
reports/open_questions_for_CCRA.md
```

里面不要写泛泛问题，要写具体决策点，例如：

```text
1. QPI output_contract 是否应把 problem_owner 设为 required？
2. 思想考古 recommended_depth 是否进入 schema required？
3. regression_status 是否可以从 pending 改成 in_progress？
4. stability_level 是否仍保持 B？
5. selector 是否允许对 mixed QPI cases 同时推荐 QPI + IA？
```

### 4. 如果 schema 改了，必须提供 schema diff 说明

如果 Codex 修改了：

```text
schemas/model_card.schema.json
schemas/source_excerpt.schema.json
schemas/regression_case.schema.json
schemas/model_index.schema.json
```

就要提供：

```text
reports/schema_change_notes.md
```

当前 `model_card.schema.json` 已经把 trigger keywords、negative triggers、related models、disciplinary anchors、common misuses、failure modes、selection priority、stability profile、output contract、version、last_updated 等字段列为 required。 如果 Codex 再加字段，我要判断是否会把 v0.2 变得过重。

## 四、知识库文件需要怎么更新

你说“若知识库的文件有变化，我会进行更新”，这个方向对。

但我建议区分两类文件：

### 1. 应更新进知识库的长期文件

这些是长期上下文，应该更新：

```text
00_用户背景与产品上下文.md
01_核心模型地图.md
02_模型卡结构规范.md
03_核心模型抽取样板.md
06_模型稳固性评级规则.md
07_产品规划过程记录.md
```

当前知识资产已经记录：项目处于 `model_library_mvp`，目标是建立 file-first 认知模型库 MVP，不做前端、后端、数据库、完整 RAG、用户系统、支付、公平台和多人协作。 核心模型地图也明确当前以 `models/model_index.json` 为机器索引源，以 `cards/card_index.md` 为人读索引源。

如果 Codex 第二轮改变了这些判断，就应该更新知识库。

### 2. 不一定要进知识库、但下一轮要上传的临时文件

这些更像本轮工程产物，不一定长期进入知识库，但下一轮审核必须提供：

```text
validation_report.md
content_review_report.md
selector_regression_report.md
changed_files_manifest.md
index_check_report.md
command_log.md
```

它们是“本轮审计材料”，不是长期产品背景。

## 五、下一轮最小审核包

如果你想控制上传量，最小包是这个：

```text
01_guidance/
  2026-06-16-核心模型抽取样板 v0.1.md
  CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md
  CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md

02_handoff/
  ChatGPT交接文档_模型库MVP_第二轮内容稳定化_YYYY-MM-DD.md
  changed_files_manifest.md
  open_questions_for_CCRA.md

03_current_assets/
  README.md
  models/model_index.json
  cards/card_index.md
  models/qpi.model.json
  models/intellectual_archaeology.model.json
  cards/qpi.md
  cards/intellectual_archaeology.md
  sources/source_articles.json
  sources/source_excerpts.json
  tests/regression_cases.json
  selector/selector_rules.json
  selector/selector_examples.json

04_reports/
  validation_report.md
  content_review_report.md
  evidence_coverage_matrix.md
  selector_regression_report.md
  index_check_report.md
  command_log.md

05_schemas_if_changed/
  model_card.schema.json
  source_article.schema.json
  source_excerpt.schema.json
  regression_case.schema.json
```

如果 Codex 把 regression cases 拆分了，就把拆分后的所有 regression 文件一起给我。

## 六、最好让 Codex 在交接文档开头写一段“审核摘要”

你可以要求 Codex 在下一轮交接文档第一屏写这个：

```text
## 审核摘要

本轮依据：
- 2026-06-16-核心模型抽取样板 v0.1.md
- CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md
- CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md

本轮目标：
- 不扩展第三模型
- 不接入完整问题回答系统
- 不引入 LLM selector
- 不升级 stable
- 优先完成 QPI / 思想考古内容稳定化、证据矩阵、回归扩展、selector 防误召回和 index drift 检查

当前状态：
- QPI: draft / B / pending 或 in_progress
- 思想考古: draft / B / pending 或 in_progress

请求 CCRA 审核：
1. 内容稳定化是否达标
2. evidence coverage 是否足够
3. regression cases 是否足够
4. selector v0.2 是否避免误召回
5. 是否允许进入下一阶段
```

## 七、下一轮你可以直接这样开场

你可以在新会话直接发：

```text
这是 Codex 按三份指导文件完成后的第二轮交接材料。
请你作为 CCRA 审核当前模型库 MVP 的完成质量，重点判断：
1. QPI 和思想考古是否仍应保持 draft / B；
2. 内容稳定化是否达标；
3. evidence coverage matrix 是否足够；
4. regression cases 是否足够；
5. selector v0.2 是否仍有误召回风险；
6. model index 和 card index 是否与实际资产一致；
7. 当前是否可以进入下一阶段，还是需要继续修复。
```

然后上传上面的最小审核包即可。

我的建议是：**三份指导文件 + Codex 新交接文档 + changed files manifest + reports + 当前核心资产文件**，这五类一定要有。知识库更新负责长期上下文，审核包负责本轮审计证据，两者不要互相替代。


# 4

即使按照最小包，也接近30个文件。
我在新会话中上传了最小包之后，点击发送就会报错，应该是有限制。

那么这个新会话中，我们怎么做？
分拆成两批文件？文件不在对话中上传，在GPT的知识库中上传？还是我在本地，做个打包，打包成几个大文件？

或者有没有可能我们在本地放一个Codex的GPT，让它来根据需要检查？因为本地Codex我也用的5.5，WEB的GPT也是5.5。

这个你有什么办法？

核心判断：**不要在新会话里继续上传 30 个分散文件。最佳方案是让本地 Codex 先生成“少量审核包文件”，再上传给我审核。**

也就是说，不是“分批上传 30 个文件”，也不是“全部塞进 GPT 知识库”，而是改成：

```text
Codex 本地读取完整仓库
→ Codex 生成 CCRA Review Bundle
→ 新会话只上传 3-5 个审核包文件
→ 我先审查方向、差异、风险和报告
→ 必要时再点名要某几个原始文件
```

我已给你整理成一份可交给 Codex 的文件：

[下载：CCRA_下一轮审核包压缩上传协议_v0.1_2026-06-16.md](sandbox:/mnt/data/CCRA_下一轮审核包压缩上传协议_v0.1_2026-06-16.md)

## 1. 最推荐方案：让 Codex 生成 4 个审核包文件

下一轮不要上传 30 个文件，而是让 Codex 生成这个目录：

```text
ccra_review_bundle/
  00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
  01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
  02_CURRENT_ASSET_PACK.md
  03_REPORTS_DIFF_AND_COMMAND_LOG.md
  optional_raw_changed_files.zip
```

然后新会话优先上传前 3 个：

```text
00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
03_REPORTS_DIFF_AND_COMMAND_LOG.md
```

如果我需要看原始资产，再上传：

```text
02_CURRENT_ASSET_PACK.md
```

或者只上传我点名要看的原始文件。

这样不会损失审核质量，因为当前项目本来就是 file-first，JSON 用于机器可读数据，Markdown 用于人读模型卡和文档；README 也明确当前验证应检查 required fields、source references、regression references、model/card indexes、Markdown card sections 和 regression coverage。

## 2. 三次指导文件仍然需要，但合并成一个文件

三份指导文件都要保留：

```text
1. 核心模型抽取样板 v0.1
2. Index 更新策略与下一轮执行 v0.2
3. 第二轮内容稳定化 v0.3
```

但不要分三份上传。让 Codex 合并为：

```text
01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
```

这个文件里要有一个执行对照表：

```text
| Guidance | Requirement | Done / Partial / Not Done | Evidence File | Notes |
```

优先级建议固定为：

```text
v0.3 内容稳定化 > v0.2 Index 更新策略 > v0.1 核心模型抽取样板
```

原因是 v0.1 是原始样板，v0.2 解决 index 维护，v0.3 才是本轮内容稳定化的主执行依据。当前核心模型地图也已经把 `models/model_index.json` 作为机器索引源，把 `cards/card_index.md` 作为人读索引源，所以 index 相关要求不能丢。

## 3. GPT 知识库怎么用

知识库可以用，但不要把它当成本轮审核包。

适合放进 GPT 知识库的是长期稳定上下文：

```text
00_用户背景与产品上下文.md
01_核心模型地图.md
02_模型卡结构规范.md
03_核心模型抽取样板.md
06_模型稳固性评级规则.md
07_产品规划过程记录.md
已定稿的 CCRA 指导协议
```

不适合放进知识库的是本轮临时产物：

```text
validation_report.md
command_log.md
changed_files_manifest.md
selector_regression_report.md
content_review_report.md
index_check_report.md
临时 diff
未审定的中间状态文件
```

原因是知识库更适合长期上下文；临时报告会造成后续检索污染。比如某一轮的 `pending`、`failed`、`partial` 状态，过几轮后可能已经过时，但知识库检索时仍可能被召回。

所以更稳的做法是：

```text
长期背景 → 更新 GPT 知识库
本轮审核证据 → 新会话上传 review bundle
```

## 4. zip 包可以有，但不要作为主审核材料

可以让 Codex 生成：

```text
optional_raw_changed_files.zip
```

但它只能作为备份，不要作为主材料。

原因很简单：压缩包在新会话里不一定能被稳定索引；就算能读，也会把大量原始文件混在一起，增加审核噪音。更稳的是让 Codex 生成 Markdown 审核包，用清晰文件头分隔：

````markdown
===== FILE: models/qpi.model.json =====

```json
{ ... full file content ... }
```
````

这种格式更适合我做语义审核、字段比对和引用定位。

## 5. 本地 Codex / 本地 GPT 可以用，但角色要限定

可以在本地放一个 Codex / GPT-5.5 来检查，但它不应该替代我做最终判断。

推荐分工是：

```text
本地 Codex：
- 读取完整仓库
- 跑 validation
- 跑 selector regression
- 生成 diff
- 生成 changed files manifest
- 生成 evidence coverage matrix
- 生成 CCRA review bundle
- 做预审并列出疑点

Web 端 CCRA：
- 判断是否符合产品阶段
- 判断 QPI / 思想考古是否仍为 draft / B
- 判断内容稳定化是否足够
- 判断是否可以进入下一阶段
- 判断是否产生新的质量债
```

这里的关键不是模型能力差异，而是**角色分离**。Codex 是执行者，让它完全自审会有确认偏差。稳固性规则里也明确说，模型不能仅因为字段完整就升级；升级还需要来源证据充分、边界清楚、misuse case 有效、regression 覆盖 positive / boundary / misuse、selector 不在负向触发时误调用，以及 owner 或 CCRA 完成内容审查。

## 6. 如果新会话仍然上传失败，按两批走

第一批只传这两个：

```text
00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
03_REPORTS_DIFF_AND_COMMAND_LOG.md
```

我先判断：

```text
Codex 做了什么
哪些文件变了
哪些验证通过 / 失败 / 跳过
是否有明显偏离指导
是否需要看原始资产
```

然后我会点名要第二批，例如：

```text
请补充上传 02_CURRENT_ASSET_PACK.md
```

或者：

```text
请只补充 models/qpi.model.json、tests/regression_cases.json、selector/selector_rules.json
```

这样可以避免你一次性试错。

## 7. 给 Codex 的简短指令

你可以直接对 Codex 说：

```text
请根据 CCRA_下一轮审核包压缩上传协议_v0.1_2026-06-16.md 生成 ccra_review_bundle/。

不要让我在新会话上传 30 个分散文件。
请把三份 CCRA 指导文件合并为 guidance pack，并生成 compliance matrix。
请把当前核心资产合并为 current asset pack。
请把 changed files、validation reports、evidence coverage、selector regression、index drift、command log、open questions 合并为 reports/diff pack。
每个被引用文件标注原始路径和 SHA256。
如果某个文件太长，不要写“略”；保留与 CCRA 指导相关的完整片段，并把原始文件放入 optional_raw_changed_files.zip。
```

## 8. 我建议你下一轮实际这样做

最稳路线：

```text
1. 让 Codex 完成工作。
2. 让 Codex 生成 ccra_review_bundle/。
3. 新会话先上传：
   - 00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
   - 01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
   - 03_REPORTS_DIFF_AND_COMMAND_LOG.md
4. 你发一句：
   “这是 Codex 完成后的压缩审核包。请先审查是否需要补充原始资产。”
5. 我根据这三份判断是否需要 02_CURRENT_ASSET_PACK.md 或个别原始文件。
```

一句话：**用本地 Codex 做“仓库读取 + 打包 + 预审”，用新会话 GPT 做“产品质量门槛审核”。不要再把 30 个文件当作上传单位。**

# 5

> 已定稿的 CCRA 指导协议

之前有4份协议。现在Codex按你的要求生成这些合并文档。

这里有定稿的CCRA指导协议，需要放进知识库的么？

需要放，但**不要把“下一轮审核包合并文档”整体放进知识库**。更稳的做法是：

```text
知识库放：长期有效的 CCRA 指导协议 / 质量门 / 交接规则
新会话上传：Codex 本轮执行结果、diff、报告、审核包
```

也就是说，**定稿协议可以进知识库；本轮审核证据不要进知识库。**

## 1. 四份协议是否要放进知识库？

我的判断是：**要放，但最好不是 4 份原样全量都塞进去，而是整理成 1 份“长期协议合集”或 2 份分层文件。**

你之前的 4 份大致可以分成两类：

```text
A. 长期产品 / 工程协议
1. 核心模型抽取样板 v0.1
2. Index 更新策略与下一轮执行 v0.2
3. 模型库 MVP 第二轮内容稳定化 v0.3

B. 长期交接 / 审核协议
4. 下一轮审核包压缩上传协议 v0.1
```

其中第 1 份已经有长期知识资产版本：`03_核心模型抽取样板.md` 已经记录了“GPT 规划必须先转为 local rules、schemas、workflow gates、indexes、validation tools、owner review points，再进入内容抽取”。

第 2 份应该沉淀进知识库，因为当前核心模型地图已经明确：`models/model_index.json` 是机器索引源，`cards/card_index.md` 是人读索引源；新增模型前必须有 source article、source evidence、model JSON、Markdown card、regression cases、selector rules、model/card index entries 和 validation report。

第 3 份也应该沉淀，因为它实际上是“内容稳定化质量门”。现有稳固性规则已经明确：模型不能仅因为字段完整就升级，必须同时满足来源证据充分、边界清楚、misuse case 有效、regression 覆盖、selector 不误调用，以及 owner / CCRA 内容审查。

第 4 份也建议沉淀，但它不是模型库规则，而是**CCRA 审核协作协议**。它解决的是你新会话上传文件数量受限的问题，应作为长期交接规则保留。

## 2. 不建议放进知识库的内容

不要把 Codex 新生成的这些本轮审核包放进知识库：

```text
00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
02_CURRENT_ASSET_PACK.md
03_REPORTS_DIFF_AND_COMMAND_LOG.md
changed_files_manifest.md
command_log.md
selector_regression_report.md
content_review_report.md
index_check_report.md
validation_report.md
```

这些是**本轮审计证据**，不是长期知识。放进知识库会有两个问题：

```text
1. 状态污染：
   某一轮的 pending / partial / failed / draft 状态，后面可能已变化。

2. 检索污染：
   以后我可能召回旧报告，把已修复的问题误当成当前问题。
```

你的知识库应该保存“规则、边界、长期决策、稳定协议”，不要保存每一轮执行痕迹。

## 3. 我建议知识库新增哪一份文件？

最推荐新增一份：

```text
08_CCRA模型库MVP长期指导协议.md
```

或者更具体：

```text
08_CCRA模型库MVP质量门与交接协议.md
```

这份文件不是简单拼接 4 份原文，而是把 4 份协议压缩成长期有效规则。

建议结构如下：

```markdown
# CCRA 模型库 MVP 长期指导协议

version: 0.1
last_updated: 2026-06-16
status: active

## 1. 协议来源

本文件综合以下 CCRA 指导文件：
- 核心模型抽取样板 v0.1
- Index 更新策略与下一轮执行 v0.2
- 模型库 MVP 第二轮内容稳定化 v0.3
- 下一轮审核包压缩上传协议 v0.1

如发生冲突，优先级为：
v0.3 内容稳定化 > v0.2 Index 策略 > v0.1 抽取样板；
审核包上传协议只约束交接方式，不覆盖模型质量规则。

## 2. 当前阶段边界

当前阶段是 model_library_mvp。
不做完整前端、后端、数据库、RAG、知识图谱、用户系统、商业平台。
优先验证 QPI 和思想考古两个模型的可读、可追溯、可调用、可测试。

## 3. 模型抽取链路

原始文章 / 代表文本
-> source article record
-> source evidence excerpts
-> Markdown card
-> JSON model card
-> regression cases
-> selector rules/examples
-> model/card indexes
-> validation report
-> CCRA review

## 4. Index 维护规则

model_index.json 和 card_index.md 采用：
- 每次资产变化后增量同步；
- 交接、release、schema 变化、批量扩展、状态升级前全量重建或全量校验。

Index 是注册表和导航层，不是内容本体。

## 5. 内容稳定化质量门

QPI 和思想考古在通过内容审查前保持：
- status: draft
- stability_level: B
- regression_status: pending 或 in_progress

不得仅因 schema pass 或 contract pass 升级 stable。

## 6. QPI 强化要求

QPI 输出契约必须包含：
- problem_owner
- time_scale
- dominant_scarcity
- evidence_gap
- mixed_state
- misclassification_risk
- next_processing_path

## 7. 思想考古强化要求

思想考古必须保留七层结构，但不得默认全量展开。
输出契约必须包含：
- recommended_depth
- stop_reason
- why_not_deeper
- validation_need
- actionable_return

## 8. Regression 扩展要求

每个核心模型从样板阶段进入稳定化阶段时，至少应覆盖：
- positive
- boundary
- misuse
- no-call / negative trigger
- conflict or combination cases

## 9. Selector v0.2 原则

selector 继续 rule-based。
暂不引入 LLM selector。
优先补强：
- no-call threshold
- negative trigger penalty
- score breakdown
- rejected model reasons
- QPI-before-IA gate
- selector regression tests

## 10. CCRA 审核包规则

新会话不要上传 30 个分散文件。
由 Codex 生成 ccra_review_bundle：
- 00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
- 01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
- 03_REPORTS_DIFF_AND_COMMAND_LOG.md
- 必要时再提供 02_CURRENT_ASSET_PACK.md

本轮报告、diff、command log 不进入知识库，只作为当轮上传审核材料。
```

这份文件进知识库，比把 4 份原文都塞进去更稳。

## 4. 是否还需要保留四份原始协议？

需要，但我建议它们放在本地仓库，不一定都进 GPT 知识库。

本地仓库可以保留：

```text
docs/ccra_guidance/
  CCRA_核心模型抽取样板_v0.1.md
  CCRA_Index更新策略_v0.2.md
  CCRA_内容稳定化_v0.3.md
  CCRA_审核包压缩上传协议_v0.1.md
```

知识库只放：

```text
knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md
```

这样有两个好处：

```text
1. 本地有完整历史，可追溯。
2. GPT 知识库只召回定稿规则，减少冲突。
```

## 5. 现有知识库还需要同步更新哪些文件？

建议更新 3 个已有长期文件：

### 1. `01_核心模型地图.md`

增加一句：

```text
Index 维护采用“每次资产变化增量同步 + 关键节点全量重建 / 全量校验”的混合策略。
```

因为这个文件已经声明 model index 和 card index 是当前机器 / 人读索引源。

### 2. `06_模型稳固性评级规则.md`

增加一句：

```text
QPI 和思想考古在第二轮内容稳定化完成前，保持 B 级，不因 schema、contract 或 selector demo 通过而升级。
```

这个文件本来就记录了 QPI 和思想考古当前都是 B，并说明升级不能只看字段完整。

### 3. `07_产品规划过程记录.md`

增加一条过程记录：

```text
为避免新会话上传文件过多，后续 Codex 交接采用 CCRA review bundle 压缩审核协议；长期协议进知识库，本轮执行证据通过新会话上传。
```

当前过程记录已经保存了 file-first、JSON 机器可读、Markdown 人读、rule-based selector 等关键决策。

## 6. Codex 合并文档是否要放进知识库？

分情况：

```text
如果 Codex 生成的是“长期协议合集”
=> 可以放进知识库。

如果 Codex 生成的是“下一轮审核包”
=> 不要放进知识库，只在新会话上传。
```

判断标准很简单：

```text
文档回答“以后一直怎么做”
=> 进知识库。

文档回答“这轮做了什么、改了什么、哪些 PASS/FAIL”
=> 不进知识库。
```

## 7. 最终建议

你可以让 Codex 做两件事：

```text
1. 生成 knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md
   用于进入 GPT 知识库。

2. 生成 ccra_review_bundle/
   用于下一轮新会话审核上传。
```

一句话：**定稿协议要进知识库，但应以“长期质量门与交接协议”的压缩定稿版进入；Codex 本轮合并审核包不要进知识库，只作为下一轮上传材料。**