# Guidance Pack and Compliance Matrix

## 1. Guidance Priority

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

## 2. Included Guidance Documents

### v0.1 核心模型抽取样板

- Original path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md`
- SHA256: `053dbb2a89d91b116d533481e0e68bc19b436075f034b8412475183f5f63f4b6`

````markdown
# 《核心模型抽取样板 v0.1》

版本：v0.1
用途：交给 Codex 建立“模型库 / 模型管理子系统 MVP”的工程样板
当前样板模型：QPI、思想考古
第一使用者：你本人
当前阶段：模型管理子系统 MVP 前置规范，不是完整产品计划书

这份样板承接你默认产品计划书中的几个核心模块：**模型卡结构、数据结构初稿、Agentic 工作流草案、模型调用与冲突处理规则、回归测试与评估机制、给 Codex 的开发前置说明**。

---

## 0. 核心判断

当前阶段不要让 Codex 直接开发“完整模型管理后台”。

第一阶段真正要验证的是：

> 能否把你的核心认知模型，从文章和既有表述中抽取成一套既能被人理解、又能被系统调用、还能被回归测试的模型资产结构。

所以这个样板工程的目标不是做漂亮后台，而是跑通一条最小链路：

```text
原始文章 / 代表文本
→ 来源文章索引
→ 关键证据片段
→ 人读模型卡
→ 机器可读模型 JSON
→ 回归测试用例
→ 最小模型选择器
```

如果这条链路跑通，再扩展到 8-10 个核心模型。
如果这条链路不稳，贸然扩展模型数量只会制造一批“看起来完整、实际不可调用”的模型卡。

---

## 1. 文档目标

### 1.1 本文档要解决什么

本文档用于指导 Codex 完成一个 **核心模型抽取样板工程**。

它要让 Codex 明确：

1. 模型库应该采用什么目录结构；
2. 模型卡应该包含哪些字段；
3. QPI 和思想考古两个模型如何被抽成样板；
4. 来源文章和证据片段如何关联；
5. 模型如何被系统调用；
6. 模型如何做回归测试；
7. 后续扩展到 8-10 个核心模型时应该遵守什么规范。

### 1.2 本文档不解决什么

本阶段不做：

```text
完整模型管理后台
完整知识图谱
100 多个模型全量管理
自动从所有文章抽取模型
复杂 RAG 知识库
复杂用户系统
公开平台
权限系统
计费系统
多人协作系统
完整问题回答产品
```

本阶段只做 **核心模型库的工程样板**。

---

## 2. 样板工程的 MVP 定义

### 2.1 一句话定义

**核心模型抽取样板 v0.1 是一个 file-first 的模型库工程样板，用 QPI 和思想考古两个核心模型验证“文章 → 证据片段 → 模型卡 → 机器 JSON → 回归测试 → 最小选择器”的完整链路。**

### 2.2 MVP 验证命题

第一阶段要验证的核心命题是：

> 少量核心认知模型，能否被整理成结构化、可追溯、可调用、可测试的模型资产，并为后续问题回答系统提供稳定底座。

### 2.3 MVP 最小产物

Codex 完成后，至少应该产出：

```text
1. 模型库目录结构
2. model_card.schema.json
3. source_article.schema.json
4. source_excerpt.schema.json
5. regression_case.schema.json
6. QPI 人读模型卡
7. QPI 机器可读 JSON
8. 思想考古人读模型卡
9. 思想考古机器可读 JSON
10. 来源文章索引
11. 关键证据片段索引
12. 两个模型的回归测试用例
13. 最小模型选择器
14. 校验脚本或校验说明
15. README.md
```

---

## 3. 核心抽取原则

### 3.1 模型抽取不是文章摘要

文章摘要回答的是：

```text
这篇文章讲了什么？
```

模型抽取回答的是：

```text
这篇文章中有哪些可复用的认知机制？
这些机制能处理什么输入？
能输出什么结果？
什么时候该调用？
什么时候不该调用？
如何测试它是否被误用？
```

所以模型抽取不能停留在“总结观点”，必须形成可调用规格。

---

### 3.2 模型卡必须有来源证据

每个核心字段都要尽量能追溯到来源：

```text
模型定义 ← 来源文章 / 关键段落
核心机制 ← 来源文章 / 关键段落
适用场景 ← 来源文章 / 代表案例 / 后续推导
不适用场景 ← 红队推导 / 反例测试
调用规则 ← 产品化推导
回归测试 ← 模型边界推导
```

不能让模型卡变成脱离原文的二次包装。

---

### 3.3 区分“传播用模型”和“系统调用用模型”

传播用模型可以有表达性、隐喻性、文学性。

系统调用用模型必须满足：

```text
概念清楚
输入清楚
输出清楚
适用边界清楚
误用风险清楚
调用条件清楚
测试方式清楚
```

QPI 和思想考古进入模型库时，都要按“系统调用用模型”重构，而不是保留为文章中的原始表达。

---

### 3.4 第一版允许半自动，不追求全自动

Codex 不应该在 v0.1 阶段尝试自动完成全部模型抽取。

更合理的路径是：

```text
人工提供两个样板模型
Codex 建立 schema、目录、校验器、选择器
后续再用同一结构扩展更多模型
```

当前目标是“规范稳定”，不是“自动化程度高”。

---

## 4. 文章到模型的抽取协议

建议把抽取分成 5 层。

```text
第 1 层：来源文章层
第 2 层：证据片段层
第 3 层：人读模型卡层
第 4 层：机器调用规格层
第 5 层：回归测试层
```

---

### 4.1 第 1 层：来源文章层

记录模型来自哪些文章、代表文本或讨论材料。

每篇来源文章至少包含：

```json
{
  "source_id": "article_qpi_primary_001",
  "title": "问题之锚：从混沌现实到认知秩序的重构",
  "author": "Wantsong",
  "date": "unknown",
  "source_type": "original_article",
  "file_path": "sources/articles/qpi_primary.md",
  "related_models": ["qpi"],
  "source_status": "representative",
  "notes": "QPI 的主要来源文本，用于抽取 Question / Problem / Issue 三分结构。"
}
```

字段说明：

| 字段             | 说明                                                          |
| -------------- | ----------------------------------------------------------- |
| source_id      | 来源文章唯一 ID                                                   |
| title          | 文章标题                                                        |
| author         | 作者                                                          |
| date           | 日期，不确定可写 unknown                                            |
| source_type    | original_article / transcript / note / discussion / excerpt |
| file_path      | 本地文件路径或引用路径                                                 |
| related_models | 关联模型                                                        |
| source_status  | primary / representative / supplementary / deprecated       |
| notes          | 备注                                                          |

---

### 4.2 第 2 层：证据片段层

从来源文章中抽出关键片段。

注意：这里不只是摘录，而是要标记片段在模型中的功能。

片段类型建议：

| excerpt_type   | 作用     |
| -------------- | ------ |
| definition     | 定义片段   |
| problem_origin | 问题来源片段 |
| mechanism      | 机制片段   |
| taxonomy       | 分类片段   |
| procedure      | 操作流程片段 |
| boundary       | 边界片段   |
| misuse         | 误用片段   |
| example        | 示例片段   |
| metaphor       | 隐喻片段   |
| test           | 测试片段   |

示例：

```json
{
  "excerpt_id": "qpi_excerpt_problem_confusion_001",
  "source_id": "article_qpi_primary_001",
  "related_model_id": "qpi",
  "excerpt_type": "problem_origin",
  "raw_excerpt": "待填入原文片段",
  "summary": "同一个'问题'在不同角色眼中可能是事实缺口、路径障碍或系统性冲突，若不先定性，会导致认知错位和行动失灵。",
  "used_for": [
    "core_question",
    "call_when",
    "regression_tests"
  ],
  "confidence": "medium",
  "notes": "用于支撑 QPI 作为前置问题定性模型。"
}
```

---

### 4.3 第 3 层：人读模型卡层

人读模型卡用于你自己阅读、审查、修改和后续知识库沉淀。

它应该是 Markdown 格式。

每张人读模型卡至少包含：

```text
## 模型名称

### 模型 ID

### 一句话定义

### 模型类型

### 所在流程位置

### 来源文章

### 来源证据片段

### 核心问题

### 核心机制

### 输入类型

### 输出类型

### 适用场景

### 不适用场景

### 调用关键词

### 负向触发条件

### 相关模型

### 冲突模型

### 学科底座关联

### 常见误用

### 失败信号

### 可信度等级

### 稳固性状态

### 回归测试状态

### 示例输入

### 示例输出

### 产品化建议
```

---

### 4.4 第 4 层：机器调用规格层

机器调用规格用于问题回答系统读取。

它应该是 JSON 或 YAML。
v0.1 建议统一先用 JSON，便于 schema 校验。

机器调用规格必须回答：

```text
这个模型什么时候被调用？
什么时候不被调用？
输入是什么？
输出是什么？
调用优先级是多少？
适合放在流程哪个位置？
需要哪些前置模型？
后续可以接哪些模型？
与哪些模型冲突？
如何判断调用失败？
```

---

### 4.5 第 5 层：回归测试层

回归测试用于判断模型是否稳定。

每个核心模型至少有三类测试：

```text
正向适用测试
边界测试
误用测试
```

建议每个模型 v0.1 至少有 5 个测试用例：

```text
2 个正向适用
2 个边界案例
1 个误用案例
```

---

## 5. 建议目录结构

Codex 可以按下面结构创建样板工程。

```text
model_library_mvp/
  README.md

  schemas/
    model_card.schema.json
    source_article.schema.json
    source_excerpt.schema.json
    regression_case.schema.json

  models/
    qpi.model.json
    intellectual_archaeology.model.json

  cards/
    qpi.card.md
    intellectual_archaeology.card.md

  sources/
    source_articles.json
    source_excerpts.json

  tests/
    qpi.regression.json
    intellectual_archaeology.regression.json

  selector/
    selection_rules.json
    selector_examples.json

  scripts/
    validate_models.py
    validate_sources.py
    validate_tests.py
    run_selector_demo.py

  reports/
    validation_report.md
    extraction_notes.md
```

v0.1 可以没有前端界面。
只要目录、schema、样例数据、校验脚本、选择器 demo 能跑通，就算完成第一步。

---

## 6. 模型卡核心字段规范

### 6.1 必填字段

```json
[
  "model_id",
  "model_name",
  "model_type",
  "pipeline_position",
  "one_sentence_definition",
  "core_question",
  "core_mechanism",
  "source_articles",
  "source_evidence",
  "input_types",
  "output_types",
  "call_when",
  "do_not_call_when",
  "common_misuses",
  "failure_modes",
  "selection_priority",
  "confidence_level",
  "stability_profile",
  "regression_status",
  "productization_notes"
]
```

### 6.2 推荐字段

```json
[
  "trigger_keywords",
  "negative_triggers",
  "related_models",
  "conflicting_models",
  "disciplinary_anchors",
  "example_inputs",
  "example_outputs",
  "output_contract",
  "depth_control",
  "stabilization_path",
  "version",
  "last_updated"
]
```

---

## 7. 枚举值建议

### 7.1 model_type

```json
[
  "routing_model",
  "deep_modeling_model",
  "lens_model",
  "diagnostic_model",
  "evaluation_model",
  "generation_model",
  "conflict_resolution_model",
  "stabilization_model"
]
```

### 7.2 pipeline_position

```json
[
  "pre_analysis",
  "analysis",
  "deep_analysis",
  "synthesis",
  "red_team",
  "evaluation",
  "post_processing"
]
```

### 7.3 confidence_level

```json
[
  "high",
  "medium",
  "low"
]
```

### 7.4 regression_status

```json
[
  "not_started",
  "pending",
  "in_progress",
  "passed",
  "failed",
  "needs_rebuild"
]
```

### 7.5 stability_level

```json
[
  "A",
  "B",
  "C",
  "D"
]
```

建议含义：

| 等级 | 含义            |
| -- | ------------- |
| A  | 高稳固，可进入核心调用   |
| B  | 基本稳固，需要边界测试   |
| C  | 有解释力，但概念或边界不稳 |
| D  | 暂不适合系统调用，需要重构 |

---

## 8. model_card.schema.json 草案

Codex 可以先按这个草案实现，后续再细化。

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Cognitive Model Card",
  "type": "object",
  "required": [
    "model_id",
    "model_name",
    "model_type",
    "pipeline_position",
    "one_sentence_definition",
    "core_question",
    "core_mechanism",
    "source_articles",
    "source_evidence",
    "input_types",
    "output_types",
    "call_when",
    "do_not_call_when",
    "common_misuses",
    "failure_modes",
    "selection_priority",
    "confidence_level",
    "stability_profile",
    "regression_status",
    "productization_notes"
  ],
  "properties": {
    "model_id": {
      "type": "string"
    },
    "model_name": {
      "type": "string"
    },
    "model_type": {
      "type": "string",
      "enum": [
        "routing_model",
        "deep_modeling_model",
        "lens_model",
        "diagnostic_model",
        "evaluation_model",
        "generation_model",
        "conflict_resolution_model",
        "stabilization_model"
      ]
    },
    "pipeline_position": {
      "type": "string",
      "enum": [
        "pre_analysis",
        "analysis",
        "deep_analysis",
        "synthesis",
        "red_team",
        "evaluation",
        "post_processing"
      ]
    },
    "one_sentence_definition": {
      "type": "string"
    },
    "core_question": {
      "type": "string"
    },
    "core_mechanism": {
      "type": "string"
    },
    "source_articles": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "source_evidence": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "input_types": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "output_types": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "call_when": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "do_not_call_when": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "trigger_keywords": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "negative_triggers": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "related_models": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "conflicting_models": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "disciplinary_anchors": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "common_misuses": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "failure_modes": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "selection_priority": {
      "type": "integer",
      "minimum": 1,
      "maximum": 10
    },
    "confidence_level": {
      "type": "string",
      "enum": [
        "high",
        "medium",
        "low"
      ]
    },
    "stability_profile": {
      "type": "object",
      "required": [
        "stability_level",
        "needs_stabilization",
        "main_risks"
      ],
      "properties": {
        "stability_level": {
          "type": "string",
          "enum": [
            "A",
            "B",
            "C",
            "D"
          ]
        },
        "needs_stabilization": {
          "type": "boolean"
        },
        "main_risks": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "stabilization_notes": {
          "type": "string"
        }
      }
    },
    "regression_status": {
      "type": "string",
      "enum": [
        "not_started",
        "pending",
        "in_progress",
        "passed",
        "failed",
        "needs_rebuild"
      ]
    },
    "example_inputs": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "example_outputs": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "output_contract": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "productization_notes": {
      "type": "string"
    },
    "version": {
      "type": "string"
    },
    "last_updated": {
      "type": "string"
    }
  }
}
```

---

## 9. source_article.schema.json 草案

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Source Article",
  "type": "object",
  "required": [
    "source_id",
    "title",
    "source_type",
    "related_models",
    "source_status"
  ],
  "properties": {
    "source_id": {
      "type": "string"
    },
    "title": {
      "type": "string"
    },
    "author": {
      "type": "string"
    },
    "date": {
      "type": "string"
    },
    "source_type": {
      "type": "string",
      "enum": [
        "original_article",
        "representative_text",
        "discussion_note",
        "transcript",
        "excerpt",
        "other"
      ]
    },
    "file_path": {
      "type": "string"
    },
    "related_models": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "source_status": {
      "type": "string",
      "enum": [
        "primary",
        "representative",
        "supplementary",
        "deprecated",
        "unknown"
      ]
    },
    "notes": {
      "type": "string"
    }
  }
}
```

---

## 10. source_excerpt.schema.json 草案

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Source Excerpt",
  "type": "object",
  "required": [
    "excerpt_id",
    "source_id",
    "related_model_id",
    "excerpt_type",
    "summary",
    "used_for"
  ],
  "properties": {
    "excerpt_id": {
      "type": "string"
    },
    "source_id": {
      "type": "string"
    },
    "related_model_id": {
      "type": "string"
    },
    "excerpt_type": {
      "type": "string",
      "enum": [
        "definition",
        "problem_origin",
        "mechanism",
        "taxonomy",
        "procedure",
        "boundary",
        "misuse",
        "example",
        "metaphor",
        "test",
        "other"
      ]
    },
    "raw_excerpt": {
      "type": "string"
    },
    "summary": {
      "type": "string"
    },
    "used_for": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "confidence": {
      "type": "string",
      "enum": [
        "high",
        "medium",
        "low"
      ]
    },
    "notes": {
      "type": "string"
    }
  }
}
```

---

## 11. regression_case.schema.json 草案

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Regression Case",
  "type": "object",
  "required": [
    "case_id",
    "model_id",
    "case_type",
    "input",
    "expected_behavior",
    "failure_signal"
  ],
  "properties": {
    "case_id": {
      "type": "string"
    },
    "model_id": {
      "type": "string"
    },
    "case_type": {
      "type": "string",
      "enum": [
        "positive",
        "boundary",
        "misuse",
        "conflict",
        "stress"
      ]
    },
    "input": {
      "type": "string"
    },
    "expected_behavior": {
      "type": "string"
    },
    "expected_output_elements": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "failure_signal": {
      "type": "string"
    },
    "notes": {
      "type": "string"
    }
  }
}
```

---

## 12. 样板模型一：QPI

### 12.1 QPI 人读模型卡 v0.1

```markdown
## QPI 问题定性模型

### 模型 ID

qpi

### 一句话定义

QPI 是一个问题定性与认知路由模型，用来判断当前输入到底是缺信息的 Question、缺路径的 Problem，还是缺稳定性 / 共识的 Issue，并据此决定后续处理路径。

### 模型类型

routing_model

### 所在流程位置

pre_analysis

QPI 应该放在问题回答系统的前置阶段。  
它不是直接回答问题，而是先判断“这是什么类型的问题”。

### 来源文章

- article_qpi_primary_001：问题之锚：从混沌现实到认知秩序的重构
- article_qpi_supplementary_001：QPI 后续讨论或补充材料，待补充

### 来源证据片段

- qpi_excerpt_problem_confusion_001
- qpi_excerpt_taxonomy_001
- qpi_excerpt_misuse_001
- qpi_excerpt_action_path_001

### 核心问题

当前输入到底是：

1. 缺事实、数据、信息的 Question；
2. 缺路径、方案、资源的 Problem；
3. 缺稳定性、共识、动态平衡的 Issue？

### 核心机制

QPI 通过识别“核心匮乏物”来区分问题类型：

- Question：核心匮乏是信息；
- Problem：核心匮乏是路径；
- Issue：核心匮乏是稳定性、共识或动态平衡。

不同类型的问题对应不同处理范式：

- Question 适合搜索、查证、信息补全；
- Problem 适合工程求解、路径设计、资源调度；
- Issue 适合生态干预、博弈分析、结构调整、长期适应。

### 输入类型

- 模糊问题
- 复杂问题
- 产品问题
- 组织问题
- 认知困惑
- 战略判断
- 多方冲突文本
- 用户不知道该如何定义的问题

### 输出类型

- Q / P / I 分类
- 分类理由
- 误判风险
- 推荐处理路径
- 是否需要调用后续模型
- 是否需要深度下潜

### 适用场景

适合在以下场景调用：

1. 用户输入的问题定义不清；
2. 同一问题被不同主体以不同方式理解；
3. 用户急于求解，但尚未判断问题性质；
4. 问题中混杂了事实、路径、利益、共识和系统结构；
5. 需要决定后续调用哪些认知模型；
6. 需要防止把复杂 Issue 简化成普通 Problem。

### 不适用场景

不适合在以下场景调用：

1. 用户只是查询明确事实；
2. 用户已经给出明确执行任务；
3. 输入是纯创意写作，不需要问题定性；
4. 问题已经被清楚分类，只需要执行后续步骤；
5. 时间窗口极短，只允许直接行动。

### 调用关键词

- 问题到底是什么
- 为什么解决不了
- 到底卡在哪里
- 这是技术问题还是组织问题
- 是不是方向错了
- 为什么反复出现
- 该怎么定义这个问题
- 这个问题应该怎么拆

### 负向触发条件

以下情况要降低 QPI 调用优先级：

- 用户要求直接查事实；
- 用户要求直接改写文本；
- 用户要求直接生成清单；
- 输入中没有明显的问题定义困难；
- 输入已经指定使用其他模型。

### 相关模型

- 思想考古
- 认知棱镜
- 认知显影
- 问题分层类模型
- 冲突汇总类模型

### 冲突模型

暂不指定具体冲突模型。  
但 QPI 与“直接给答案”的流程存在流程冲突：如果 QPI 判断尚未完成，不应急于进入回答。

### 学科底座关联

- 问题定义理论
- 决策科学
- 系统论
- 复杂系统
- 组织行为
- 设计思维
- 工程问题分解

### 常见误用

1. 把所有复杂问题都判断成 Issue；
2. 把系统性 Issue 暴力降维成个体 Problem；
3. 把具体可解决的 Problem 恶意升维成无法处理的 Issue；
4. 在 Question 阶段过度建模；
5. 把 QPI 当成最终分析模型，而不是前置路由模型。

### 失败信号

如果系统出现以下情况，说明 QPI 调用失败：

1. 面对事实查询却输出复杂系统分析；
2. 面对组织性 Issue 却只给个人行动清单；
3. 面对具体执行 Problem 却泛化到宏大结构；
4. 分类没有给出理由；
5. 分类之后没有给出后续处理路径。

### 可信度等级

medium

### 稳固性状态

B

说明：  
QPI 的基本结构清晰，适合作为入口模型。  
但它需要大量边界案例测试，尤其要防止“所有问题都升维成 Issue”。

### 回归测试状态

pending

### 示例输入

“我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？”

### 示例输出

该输入更接近 Issue，而不是普通 Problem。

理由：

1. 它不是单纯缺信息；
2. 也不是简单缺执行路径；
3. 它涉及激励结构、时间尺度冲突、组织共识和多主体行为；
4. 如果把它当成 Problem，只给执行清单，很可能治标不治本。

推荐后续调用：

- 思想考古：下潜其深层结构；
- 冲突汇总模型：识别长期主义与短期 KPI 的冲突；
- 学科底座校准：组织行为与激励机制。

### 产品化建议

QPI 应作为问题回答系统的默认前置路由模型之一。  
它的核心价值不是生成深刻答案，而是防止系统在问题类型错误的情况下直接回答。
```

---

### 12.2 QPI 机器调用 JSON v0.1

```json
{
  "model_id": "qpi",
  "model_name": "QPI 问题定性模型",
  "model_type": "routing_model",
  "pipeline_position": "pre_analysis",
  "one_sentence_definition": "QPI 是一个问题定性与认知路由模型，用来判断当前输入到底是缺信息的 Question、缺路径的 Problem，还是缺稳定性 / 共识的 Issue，并据此决定后续处理路径。",
  "core_question": "当前输入到底是 Question、Problem 还是 Issue？",
  "core_mechanism": "QPI 通过识别问题中的核心匮乏物进行分类：Question 缺信息，Problem 缺路径，Issue 缺稳定性、共识或动态平衡。不同类型的问题对应不同处理范式。",
  "source_articles": [
    "article_qpi_primary_001",
    "article_qpi_supplementary_001"
  ],
  "source_evidence": [
    "qpi_excerpt_problem_confusion_001",
    "qpi_excerpt_taxonomy_001",
    "qpi_excerpt_misuse_001",
    "qpi_excerpt_action_path_001"
  ],
  "input_types": [
    "模糊问题",
    "复杂问题",
    "产品问题",
    "组织问题",
    "认知困惑",
    "战略判断",
    "多方冲突文本"
  ],
  "output_types": [
    "问题类型判断",
    "分类理由",
    "误判风险",
    "推荐处理路径",
    "后续模型调用建议"
  ],
  "call_when": [
    "用户输入的问题定义不清",
    "同一问题被不同主体以不同方式理解",
    "用户急于求解但尚未判断问题性质",
    "问题中混杂事实、路径、利益、共识和系统结构",
    "需要决定后续调用哪些认知模型"
  ],
  "do_not_call_when": [
    "用户只是查询明确事实",
    "用户已经给出明确执行任务",
    "输入是纯创意写作且不需要问题定性",
    "问题已经被清楚分类且只需要执行后续步骤"
  ],
  "trigger_keywords": [
    "问题到底是什么",
    "为什么解决不了",
    "卡在哪里",
    "技术问题还是组织问题",
    "方向是不是错了",
    "为什么反复出现",
    "该怎么定义这个问题",
    "这个问题怎么拆"
  ],
  "negative_triggers": [
    "请直接查询",
    "请直接改写",
    "只要清单",
    "不要分析原因",
    "不要展开"
  ],
  "related_models": [
    "intellectual_archaeology",
    "cognitive_prism",
    "cognitive_development"
  ],
  "conflicting_models": [],
  "disciplinary_anchors": [
    "问题定义理论",
    "决策科学",
    "系统论",
    "复杂系统",
    "组织行为",
    "工程问题分解"
  ],
  "common_misuses": [
    "把所有复杂问题都判断成 Issue",
    "把系统性 Issue 暴力降维成个体 Problem",
    "把具体可解决的 Problem 恶意升维成无法处理的 Issue",
    "在 Question 阶段过度建模",
    "把 QPI 当成最终分析模型而不是前置路由模型"
  ],
  "failure_modes": [
    "面对事实查询却输出复杂系统分析",
    "面对组织性 Issue 却只给个人行动清单",
    "面对具体执行 Problem 却泛化到宏大结构",
    "分类没有给出理由",
    "分类之后没有给出后续处理路径"
  ],
  "selection_priority": 9,
  "confidence_level": "medium",
  "stability_profile": {
    "stability_level": "B",
    "needs_stabilization": true,
    "main_risks": [
      "边界案例需要测试",
      "容易把复杂问题过度升维为 Issue",
      "Question / Problem / Issue 的判断标准需要进一步示例化"
    ],
    "stabilization_notes": "优先补充正向、边界、误用三类测试案例，形成分类判准。"
  },
  "regression_status": "pending",
  "example_inputs": [
    "我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
    "我知道要做模型库，但不知道先用数据库还是文件系统，这属于什么问题？"
  ],
  "example_outputs": [
    "第一个输入更接近 Issue，因为它涉及激励结构、时间尺度冲突和组织共识。",
    "第二个输入更接近 Problem，因为目标明确，主要缺的是实现路径和技术取舍。"
  ],
  "output_contract": [
    "判断输入属于 Question、Problem、Issue 或混合型",
    "说明分类理由",
    "指出可能误判",
    "给出推荐处理路径",
    "建议后续调用模型"
  ],
  "productization_notes": "QPI 应作为问题回答系统的前置路由模型，用于防止系统在问题类型错误的情况下直接给答案。",
  "version": "0.1",
  "last_updated": "2026-06-15"
}
```

---

### 12.3 QPI 来源片段样例

```json
[
  {
    "excerpt_id": "qpi_excerpt_problem_confusion_001",
    "source_id": "article_qpi_primary_001",
    "related_model_id": "qpi",
    "excerpt_type": "problem_origin",
    "raw_excerpt": "待填入原文片段",
    "summary": "同一个'问题'在不同角色眼中可能是事实缺口、路径障碍或系统性冲突，若不先定性，会导致认知错位和行动失灵。",
    "used_for": [
      "core_question",
      "call_when",
      "example_inputs"
    ],
    "confidence": "medium",
    "notes": "用于支撑 QPI 作为问题定性模型。"
  },
  {
    "excerpt_id": "qpi_excerpt_taxonomy_001",
    "source_id": "article_qpi_primary_001",
    "related_model_id": "qpi",
    "excerpt_type": "taxonomy",
    "raw_excerpt": "待填入原文片段",
    "summary": "QPI 将问题划分为 Question、Problem、Issue 三类，分别对应信息匮乏、路径匮乏、稳定性或共识匮乏。",
    "used_for": [
      "core_mechanism",
      "output_contract",
      "regression_tests"
    ],
    "confidence": "high",
    "notes": "用于支撑 QPI 的核心三分结构。"
  },
  {
    "excerpt_id": "qpi_excerpt_misuse_001",
    "source_id": "article_qpi_primary_001",
    "related_model_id": "qpi",
    "excerpt_type": "misuse",
    "raw_excerpt": "待填入原文片段",
    "summary": "QPI 的误用包括把 Issue 降维成 Problem，或把 Problem 升维成不可处理的 Issue。",
    "used_for": [
      "common_misuses",
      "failure_modes"
    ],
    "confidence": "medium",
    "notes": "用于支撑 QPI 的边界和误用检查。"
  }
]
```

---

### 12.4 QPI 回归测试样例

```json
[
  {
    "case_id": "qpi_positive_question_001",
    "model_id": "qpi",
    "case_type": "positive",
    "input": "这段代码为什么报错？",
    "expected_behavior": "应判断为 Question 或偏 Question，因为当前主要缺少具体错误信息、日志、代码上下文等事实材料。",
    "expected_output_elements": [
      "判断为 Question",
      "要求补充事实信息",
      "不应过度建模"
    ],
    "failure_signal": "系统开始讨论组织结构、人生意义或复杂系统，而没有要求补充事实信息。",
    "notes": "测试 QPI 是否能识别简单信息缺口。"
  },
  {
    "case_id": "qpi_positive_problem_001",
    "model_id": "qpi",
    "case_type": "positive",
    "input": "我知道要先做模型库，但不知道应该用数据库还是 JSON 文件。",
    "expected_behavior": "应判断为 Problem，因为目标基本明确，主要缺的是实现路径和技术取舍。",
    "expected_output_elements": [
      "判断为 Problem",
      "指出目标明确但路径未定",
      "建议进行工程取舍分析"
    ],
    "failure_signal": "系统把问题上升到知识哲学层面，忽略具体实现路径。",
    "notes": "测试 QPI 是否能识别路径缺口。"
  },
  {
    "case_id": "qpi_positive_issue_001",
    "model_id": "qpi",
    "case_type": "positive",
    "input": "团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
    "expected_behavior": "应判断为 Issue，因为它涉及激励结构、时间尺度冲突、多主体行为和组织共识。",
    "expected_output_elements": [
      "判断为 Issue",
      "指出不是简单执行问题",
      "建议分析激励结构和组织反馈"
    ],
    "failure_signal": "系统只给出个人执行清单，例如'制定计划、加强沟通、定期复盘'。",
    "notes": "测试 QPI 是否能识别系统性稳定问题。"
  },
  {
    "case_id": "qpi_boundary_mixed_001",
    "model_id": "qpi",
    "case_type": "boundary",
    "input": "我的产品方向不确定，也不知道用户到底要什么，还担心技术做不出来。",
    "expected_behavior": "应判断为混合型问题，包含 Question、Problem 和 Issue，但需要指出当前优先处理的问题类型。",
    "expected_output_elements": [
      "识别混合型",
      "拆分信息缺口、路径缺口和稳定性缺口",
      "给出处理优先级"
    ],
    "failure_signal": "系统强行只判为一种类型，且不说明混合成分。",
    "notes": "测试 QPI 对混合问题的处理能力。"
  },
  {
    "case_id": "qpi_misuse_over_issue_001",
    "model_id": "qpi",
    "case_type": "misuse",
    "input": "我不知道 Notion 的这个按钮在哪里。",
    "expected_behavior": "应判断为 Question，不应升维为 Issue。",
    "expected_output_elements": [
      "判断为 Question",
      "建议查找界面位置或文档",
      "不做宏大分析"
    ],
    "failure_signal": "系统讨论现代工具复杂性、用户控制感、信息架构困境等宏大问题。",
    "notes": "防止 QPI 过度升维。"
  }
]
```

---

## 13. 样板模型二：思想考古

### 13.1 思想考古人读模型卡 v0.1

```markdown
## 思想考古模型

### 模型 ID

intellectual_archaeology

### 一句话定义

思想考古是一个纵向下潜模型，用来从表层现象一路追问到过程层、机理层、目的层、人类能力层乃至哲学基岩，从而识别问题或模型背后的深层结构和隐含假设。

### 模型类型

deep_modeling_model

### 所在流程位置

deep_analysis

思想考古不适合作为所有问题的默认入口。  
它应在 QPI 定性之后，被用于高复用、高复杂度、需要沉淀方法论或模型的问题。

### 来源文章

- article_archaeology_primary_001：建模者的工坊：一场将直觉锻造成罗盘的认知炼金术
- article_archaeology_supplementary_001：思想考古相关后续讨论，待补充

### 来源证据片段

- archaeology_excerpt_depth_001
- archaeology_excerpt_layers_001
- archaeology_excerpt_boundary_001
- archaeology_excerpt_modeling_001

### 核心问题

当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？

具体包括：

1. 它表面上在处理什么；
2. 它依赖什么评价标准；
3. 它背后有哪些过程和机制；
4. 它服务什么目的；
5. 它依赖什么核心机理；
6. 它对应人类哪种能力；
7. 它背后有哪些哲学前提。

### 核心机制

思想考古通过纵向下潜，把一个表层问题拆到更深层的结构。

建议七层结构如下：

1. 应用层：具体工具、流程、指标、场景；
2. 评价层：如何判断好坏、成功与失败；
3. 过程层：实际运作过程、操作链条、反馈机制；
4. 目的层：最终服务的目标和价值原子；
5. 核心机理层：系统如何学习、演化、自适应；
6. 人类能力层：它对应人类怎样的问题解决能力；
7. 哲学基岩层：它关于问题、知识、现实、主体的根本假设。

### 输入类型

- 复杂问题
- 系统性议题
- 反复失败的问题
- 需要沉淀方法论的问题
- 专家隐性知识
- 认知模型草稿
- 产品底层逻辑
- 长期可复用的分析对象

### 输出类型

- 层级化问题地图
- 深层假设清单
- 最小充分下潜层级
- 模型稳固性判断
- 需要验证的薄弱环节
- 后续建模建议

### 适用场景

适合在以下场景调用：

1. QPI 判断问题偏 Issue；
2. 问题具有高复用价值；
3. 用户希望从文章中抽取模型；
4. 当前解释停留在表层工具或症状；
5. 需要把专家隐性知识显性化；
6. 需要为一个模型寻找更稳固的底层结构；
7. 一个问题反复解决但反复失败。

### 不适用场景

不适合在以下场景调用：

1. 简单事实查询；
2. 明确执行任务；
3. 低风险、低复用问题；
4. 用户只要快速输出，不需要深层建模；
5. 继续下潜不会改变决策；
6. 缺乏证据，无法支持深层推断。

### 调用关键词

- 背后的深层结构
- 底层逻辑
- 这个模型稳不稳
- 为什么反复失败
- 这个问题的根在哪里
- 这个想法能不能沉淀成模型
- 如何从文章抽取模型
- 这个方法论的基岩是什么

### 负向触发条件

以下情况要降低调用优先级：

- 用户明确要求快速答案；
- 问题只需要查事实；
- 问题不值得重型建模；
- 当前信息不足以支持深层推断；
- 使用 QPI 后判断为轻量 Question。

### 相关模型

- QPI
- 认知棱镜
- 认知显影
- 建模者委员会
- 回归测试模型
- 学科底座校准模型

### 冲突模型

思想考古与“快速执行模型”存在成本冲突。  
如果任务目标是快速完成一个低复用动作，思想考古可能过重。

### 学科底座关联

- 哲学
- 认识论
- 系统论
- 复杂系统
- 认知心理学
- 专家知识显性化
- 因果推理
- 设计理论

### 常见误用

1. 为了显得深刻而无限下钻；
2. 把所有轻量问题都拖入七层分析；
3. 只做纵向下潜，缺少横向模型竞争；
4. 用哲学基岩替代现实验证；
5. 把隐喻性表达误当作稳定机制；
6. 下潜后没有回到可行动结论。

### 失败信号

如果系统出现以下情况，说明思想考古调用失败：

1. 分析很深，但不能改变判断或行动；
2. 层级之间没有清楚递进关系；
3. 把所有问题都下钻到哲学层；
4. 输出只有抽象概念，没有模型结构；
5. 没有说明应该在哪一层停止；
6. 没有指出需要证据验证的地方。

### 可信度等级

medium

### 稳固性状态

B

说明：  
思想考古的方向清晰，适合做深度建模。  
但七层结构需要进一步稳定，避免不同文章或不同任务中层级名称漂移。

### 回归测试状态

pending

### 示例输入

“我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？”

### 示例输出

该问题适合调用思想考古。

初步层级判断：

1. 应用层：把文章整理成模型库；
2. 评价层：判断模型是否稳固；
3. 过程层：从文章到证据片段，再到模型卡和测试用例；
4. 目的层：让模型能被问题回答系统调用；
5. 核心机理层：把隐性认知加工方式外化为可测试模块；
6. 人类能力层：外化专家直觉、提高问题加工稳定性；
7. 哲学基岩层：知识不是静态内容，而是可调用、可校准、可迭代的认知工具。

建议最小充分下潜到第 5 层。  
暂时不必强行进入第 7 层，因为当前任务主要是产品化和工程样板。

### 产品化建议

思想考古应作为中重度问题的深层建模模块。  
它不应该默认每次调用，而应由 QPI、问题复杂度和复用价值共同决定是否启动。
```

---

### 13.2 思想考古机器调用 JSON v0.1

```json
{
  "model_id": "intellectual_archaeology",
  "model_name": "思想考古模型",
  "model_type": "deep_modeling_model",
  "pipeline_position": "deep_analysis",
  "one_sentence_definition": "思想考古是一个纵向下潜模型，用来从表层现象一路追问到过程层、机理层、目的层、人类能力层乃至哲学基岩，从而识别问题或模型背后的深层结构和隐含假设。",
  "core_question": "当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？",
  "core_mechanism": "思想考古通过纵向下潜，把一个表层问题拆到更深层的结构。建议从应用层、评价层、过程层、目的层、核心机理层、人类能力层、哲学基岩层逐层分析，并遵守最小充分下潜原则。",
  "source_articles": [
    "article_archaeology_primary_001",
    "article_archaeology_supplementary_001"
  ],
  "source_evidence": [
    "archaeology_excerpt_depth_001",
    "archaeology_excerpt_layers_001",
    "archaeology_excerpt_boundary_001",
    "archaeology_excerpt_modeling_001"
  ],
  "input_types": [
    "复杂问题",
    "系统性议题",
    "反复失败的问题",
    "需要沉淀方法论的问题",
    "专家隐性知识",
    "认知模型草稿",
    "产品底层逻辑"
  ],
  "output_types": [
    "层级化问题地图",
    "深层假设清单",
    "最小充分下潜层级",
    "模型稳固性判断",
    "需要验证的薄弱环节",
    "后续建模建议"
  ],
  "call_when": [
    "QPI 判断问题偏 Issue",
    "问题具有高复用价值",
    "用户希望从文章中抽取模型",
    "当前解释停留在表层工具或症状",
    "需要把专家隐性知识显性化",
    "需要为一个模型寻找更稳固的底层结构",
    "一个问题反复解决但反复失败"
  ],
  "do_not_call_when": [
    "简单事实查询",
    "明确执行任务",
    "低风险低复用问题",
    "用户只要快速输出",
    "继续下潜不会改变决策",
    "缺乏证据支撑深层推断"
  ],
  "trigger_keywords": [
    "深层结构",
    "底层逻辑",
    "模型稳不稳",
    "为什么反复失败",
    "问题的根在哪里",
    "沉淀成模型",
    "从文章抽取模型",
    "方法论的基岩"
  ],
  "negative_triggers": [
    "快速回答",
    "不要展开",
    "只查事实",
    "只要执行步骤",
    "不要深入分析"
  ],
  "related_models": [
    "qpi",
    "cognitive_prism",
    "cognitive_development",
    "modeling_committee",
    "regression_testing"
  ],
  "conflicting_models": [
    "fast_execution_flow"
  ],
  "disciplinary_anchors": [
    "哲学",
    "认识论",
    "系统论",
    "复杂系统",
    "认知心理学",
    "专家知识显性化",
    "因果推理",
    "设计理论"
  ],
  "common_misuses": [
    "为了显得深刻而无限下钻",
    "把所有轻量问题都拖入七层分析",
    "只做纵向下潜而缺少横向模型竞争",
    "用哲学基岩替代现实验证",
    "把隐喻性表达误当作稳定机制",
    "下潜后没有回到可行动结论"
  ],
  "failure_modes": [
    "分析很深但不能改变判断或行动",
    "层级之间没有清楚递进关系",
    "把所有问题都下钻到哲学层",
    "输出只有抽象概念而没有模型结构",
    "没有说明应该在哪一层停止",
    "没有指出需要证据验证的地方"
  ],
  "selection_priority": 7,
  "confidence_level": "medium",
  "stability_profile": {
    "stability_level": "B",
    "needs_stabilization": true,
    "main_risks": [
      "七层结构需要进一步稳定",
      "容易过度下潜",
      "容易输出抽象概念而缺少行动回路",
      "需要更多真实案例验证"
    ],
    "stabilization_notes": "优先补充不同复杂度问题的测试案例，明确最小充分下潜原则和停止条件。"
  },
  "regression_status": "pending",
  "example_inputs": [
    "我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？",
    "现代人为什么一边渴望连接，一边又渴望逃离连接？"
  ],
  "example_outputs": [
    "第一个输入适合下潜到核心机理层，判断文章、模型卡、系统调用、回归测试之间的关系。",
    "第二个输入可从应用层、评价层、过程层、目的层和人类能力层分析连接与逃离连接的双重机制。"
  ],
  "output_contract": [
    "判断当前问题所在表层",
    "给出建议下潜层级",
    "按层级输出结构化分析",
    "指出每一层的关键假设",
    "给出最小充分下潜停止点",
    "标记需要证据或现实反馈校准的部分"
  ],
  "depth_control": {
    "principle": "最小充分下潜",
    "stop_conditions": [
      "已经足以改变决策",
      "继续下潜不会增加解释力",
      "缺少证据支撑更深推断",
      "问题不值得重型建模",
      "用户当前只需要执行层结果"
    ],
    "overuse_warning": "思想考古不是所有问题的默认流程，必须先经过问题价值评估和 QPI 定性。"
  },
  "productization_notes": "思想考古适合作为中重度问题的深层建模模块，不应默认全量调用。它应该由 QPI、问题复杂度和复用价值共同触发。",
  "version": "0.1",
  "last_updated": "2026-06-15"
}
```

---

### 13.3 思想考古来源片段样例

```json
[
  {
    "excerpt_id": "archaeology_excerpt_depth_001",
    "source_id": "article_archaeology_primary_001",
    "related_model_id": "intellectual_archaeology",
    "excerpt_type": "mechanism",
    "raw_excerpt": "待填入原文片段",
    "summary": "思想考古要求从表层现象向深层结构下潜，通过层层追问识别问题背后的机制、目的和基岩假设。",
    "used_for": [
      "core_mechanism",
      "call_when",
      "output_contract"
    ],
    "confidence": "medium",
    "notes": "用于支撑思想考古作为纵向下潜模型。"
  },
  {
    "excerpt_id": "archaeology_excerpt_layers_001",
    "source_id": "article_archaeology_primary_001",
    "related_model_id": "intellectual_archaeology",
    "excerpt_type": "taxonomy",
    "raw_excerpt": "待填入原文片段",
    "summary": "思想考古可被整理为应用层、评价层、过程层、目的层、核心机理层、人类能力层和哲学基岩层。",
    "used_for": [
      "core_mechanism",
      "example_outputs",
      "regression_tests"
    ],
    "confidence": "medium",
    "notes": "七层结构需要在后续版本中继续校准。"
  },
  {
    "excerpt_id": "archaeology_excerpt_boundary_001",
    "source_id": "article_archaeology_primary_001",
    "related_model_id": "intellectual_archaeology",
    "excerpt_type": "boundary",
    "raw_excerpt": "待填入原文片段",
    "summary": "思想考古应遵守最小充分下潜原则，不应把所有问题都拖入重型建模流程。",
    "used_for": [
      "do_not_call_when",
      "depth_control",
      "common_misuses"
    ],
    "confidence": "medium",
    "notes": "用于防止思想考古过度使用。"
  }
]
```

---

### 13.4 思想考古回归测试样例

```json
[
  {
    "case_id": "archaeology_positive_modeling_001",
    "model_id": "intellectual_archaeology",
    "case_type": "positive",
    "input": "我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？",
    "expected_behavior": "应调用思想考古，将问题从文章整理下潜到模型稳固性、系统调用和认知能力外化层面。",
    "expected_output_elements": [
      "给出层级化分析",
      "指出模型稳固性问题",
      "说明最小充分下潜层级",
      "回到可执行的模型抽取流程"
    ],
    "failure_signal": "系统只给出普通资料整理建议，没有触及模型稳固性、调用规则和回归测试。",
    "notes": "测试思想考古是否能用于模型抽取场景。"
  },
  {
    "case_id": "archaeology_positive_issue_001",
    "model_id": "intellectual_archaeology",
    "case_type": "positive",
    "input": "现代人为什么一边渴望连接，一边又渴望逃离连接？",
    "expected_behavior": "应将问题下潜到连接的功能、连接带来的负荷、主体边界、社会反馈和人类关系需求等层级。",
    "expected_output_elements": [
      "识别表层矛盾",
      "分析连接的收益与成本",
      "指出深层心理或社会机制",
      "避免只做情绪化解释"
    ],
    "failure_signal": "系统只输出鸡汤式解释，例如'人既需要爱也需要自由'。",
    "notes": "测试思想考古能否处理复杂认知现象。"
  },
  {
    "case_id": "archaeology_boundary_light_task_001",
    "model_id": "intellectual_archaeology",
    "case_type": "boundary",
    "input": "帮我把这句话改得更简洁。",
    "expected_behavior": "不应调用思想考古，或只轻量说明无需深层建模。",
    "expected_output_elements": [
      "识别为轻量任务",
      "不进入七层分析",
      "直接执行改写"
    ],
    "failure_signal": "系统开始分析语言背后的哲学基岩。",
    "notes": "防止思想考古过度调用。"
  },
  {
    "case_id": "archaeology_boundary_stop_depth_001",
    "model_id": "intellectual_archaeology",
    "case_type": "boundary",
    "input": "我在设计模型库时，不确定模型卡字段要不要加'哲学基岩'。",
    "expected_behavior": "应分析到产品调用和字段成本层面即可，不必强行进入完整七层。",
    "expected_output_elements": [
      "判断字段是否服务调用",
      "说明哲学基岩可作为可选字段",
      "提出最小充分方案"
    ],
    "failure_signal": "系统展开大段哲学分析，却没有回答字段设计取舍。",
    "notes": "测试最小充分下潜原则。"
  },
  {
    "case_id": "archaeology_misuse_abstract_001",
    "model_id": "intellectual_archaeology",
    "case_type": "misuse",
    "input": "我的模型管理 MVP 下一步要做什么？",
    "expected_behavior": "如果调用思想考古，也必须回到可执行任务，不应只输出抽象层级。",
    "expected_output_elements": [
      "识别当前阶段",
      "说明下潜对决策的帮助",
      "输出下一步任务清单"
    ],
    "failure_signal": "系统只讨论知识、现实、主体性等抽象概念，没有任务切片。",
    "notes": "防止思想考古脱离产品规划。"
  }
]
```

---

## 14. QPI 与思想考古的组合关系

这两个模型在系统中不是并列替代关系，而是前后衔接关系。

```text
输入问题
→ QPI 判断问题类型
→ 判断是否需要深度下潜
→ 如果问题复杂、高复用、偏 Issue，则调用思想考古
→ 输出层级结构和深层假设
→ 后续再接其他横向棱镜模型
```

### 14.1 系统位置

| 模型   | 系统位置          | 作用            |
| ---- | ------------- | ------------- |
| QPI  | pre_analysis  | 判断问题类型，决定处理路径 |
| 思想考古 | deep_analysis | 对复杂问题进行纵向下潜   |

### 14.2 调用优先级

| 场景              | 推荐调用        |
| --------------- | ----------- |
| 问题定义不清          | 优先 QPI      |
| 只是查事实           | 不调用思想考古     |
| 目标明确但路径未定       | QPI 后进入工程求解 |
| 多主体冲突 / 系统性反复失败 | QPI + 思想考古  |
| 需要从文章抽模型        | 思想考古        |
| 需要判断模型是否稳固      | 思想考古 + 回归测试 |

---

## 15. 最小模型选择器规则

v0.1 的模型选择器不需要复杂算法。

可以先使用规则 + 简单评分。

### 15.1 输入

```json
{
  "user_input": "团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
  "task_type": "question_analysis",
  "depth_preference": "medium"
}
```

### 15.2 输出

```json
{
  "recommended_models": [
    {
      "model_id": "qpi",
      "score": 0.92,
      "reason": "输入包含'到底是什么问题'，且存在问题定性需求。"
    },
    {
      "model_id": "intellectual_archaeology",
      "score": 0.78,
      "reason": "该问题涉及长期主义、KPI、组织激励和反复失败，适合进行深层结构分析。"
    }
  ],
  "not_recommended_models": [],
  "routing_notes": "先用 QPI 判断问题类型。如果判定为 Issue，再调用思想考古进行最小充分下潜。"
}
```

### 15.3 简单评分规则

建议先按 4 类信号评分：

```text
1. trigger_keywords 命中
2. input_types 匹配
3. do_not_call_when 是否触发
4. pipeline_position 是否适合当前阶段
```

伪规则：

```text
初始分 = 0

命中 trigger_keywords：+0.2
匹配 input_types：+0.2
任务阶段匹配 pipeline_position：+0.2
用户表达中出现复杂性 / 反复失败 / 多主体冲突：+0.2
模型 selection_priority 高：+0.1

命中 negative_triggers：-0.3
命中 do_not_call_when：-0.5
```

v0.1 只需要返回候选模型和推荐理由，不需要自动生成最终分析。

---

## 16. 最小 selector_examples.json

```json
[
  {
    "example_id": "selector_example_001",
    "user_input": "我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
    "expected_models": [
      "qpi",
      "intellectual_archaeology"
    ],
    "expected_reasoning": "先用 QPI 判断该问题更偏 Issue，再用思想考古分析其激励结构、时间尺度和组织共识。"
  },
  {
    "example_id": "selector_example_002",
    "user_input": "这段代码为什么报错？",
    "expected_models": [
      "qpi"
    ],
    "expected_reasoning": "QPI 应将其判断为偏 Question，但不应继续调用思想考古。"
  },
  {
    "example_id": "selector_example_003",
    "user_input": "我想从一篇文章里抽出一个可复用的认知模型，应该怎么做？",
    "expected_models": [
      "intellectual_archaeology",
      "qpi"
    ],
    "expected_reasoning": "该问题涉及模型抽取和隐性知识显性化，思想考古适合主导；QPI 可用于前置判断任务性质。"
  },
  {
    "example_id": "selector_example_004",
    "user_input": "帮我把这句话改得更简洁。",
    "expected_models": [],
    "expected_reasoning": "这是轻量执行任务，不需要调用 QPI 或思想考古。"
  }
]
```

---

## 17. 稳固性评级规则 v0.1

每个模型都要有稳定性评估，不要只写“可信度高 / 中 / 低”。

建议从 5 个维度评估：

```text
概念清晰度
机制稳定性
边界清晰度
来源证据质量
回归测试表现
```

### 17.1 评分维度

| 维度     | 问题              |
| ------ | --------------- |
| 概念清晰度  | 模型的核心概念是否清楚？    |
| 机制稳定性  | 模型是否有明确运作机制？    |
| 边界清晰度  | 是否知道什么时候不能用？    |
| 来源证据质量 | 是否能追溯到文章和关键片段？  |
| 回归测试表现 | 是否通过正向、边界、误用测试？ |

### 17.2 等级规则

| 等级 | 标准               |
| -- | ---------------- |
| A  | 五个维度都较稳定，可进入核心调用 |
| B  | 基本可用，但需要边界案例测试   |
| C  | 有启发，但系统调用风险较高    |
| D  | 不适合进入模型库，需要重构    |

### 17.3 QPI 当前建议评级

```json
{
  "model_id": "qpi",
  "stability_level": "B",
  "reason": "三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。",
  "next_stabilization_action": "补充混合问题、误用问题和轻量问题测试。"
}
```

### 17.4 思想考古当前建议评级

```json
{
  "model_id": "intellectual_archaeology",
  "stability_level": "B",
  "reason": "纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。",
  "next_stabilization_action": "补充不同复杂度问题的下潜深度测试，明确最小充分下潜原则。"
}
```

---

## 18. Codex 开工任务

### Task 1：创建工程目录

目标：

```text
创建 model_library_mvp 目录
按本文档建立 schemas / models / cards / sources / tests / selector / scripts / reports
```

验收标准：

```text
目录结构完整
README.md 存在
所有关键目录都有占位说明
```

---

### Task 2：创建 JSON Schema

目标：

```text
创建：
- model_card.schema.json
- source_article.schema.json
- source_excerpt.schema.json
- regression_case.schema.json
```

验收标准：

```text
schema 可以被 jsonschema 校验工具读取
必填字段生效
枚举值生效
错误数据能被识别
```

---

### Task 3：录入两个样板模型

目标：

```text
创建：
- models/qpi.model.json
- models/intellectual_archaeology.model.json
- cards/qpi.card.md
- cards/intellectual_archaeology.card.md
```

验收标准：

```text
两个 JSON 文件通过 model_card.schema.json 校验
两个 Markdown 卡片可读
字段与本文档基本一致
```

---

### Task 4：创建来源索引和证据片段索引

目标：

```text
创建：
- sources/source_articles.json
- sources/source_excerpts.json
```

验收标准：

```text
source_articles.json 至少包含 QPI 和思想考古的来源记录
source_excerpts.json 至少包含两个模型各 3 条证据片段
模型卡中的 source_articles 和 source_evidence 能对应到实际 ID
```

---

### Task 5：创建回归测试用例

目标：

```text
创建：
- tests/qpi.regression.json
- tests/intellectual_archaeology.regression.json
```

验收标准：

```text
每个模型至少 5 个测试用例
包含 positive、boundary、misuse 三类
测试用例通过 regression_case.schema.json 校验
```

---

### Task 6：创建校验脚本

目标：

```text
创建：
- scripts/validate_models.py
- scripts/validate_sources.py
- scripts/validate_tests.py
```

验收标准：

```text
能检查 JSON 是否符合 schema
能检查 model_id 是否唯一
能检查 source_evidence 是否存在
能检查 regression_tests 是否引用了存在的 model_id
输出 validation_report.md
```

---

### Task 7：创建最小模型选择器 demo

目标：

```text
创建：
- selector/selection_rules.json
- selector/selector_examples.json
- scripts/run_selector_demo.py
```

验收标准：

```text
输入一个问题
读取两个模型 JSON
根据关键词、输入类型、负向触发条件、selection_priority 返回候选模型
输出推荐理由
至少能跑通 selector_examples.json 中的样例
```

---

## 19. 验收标准总表

Codex 完成后，必须满足：

```text
1. 项目目录结构完整
2. schema 文件存在并可校验
3. QPI 模型 JSON 存在并通过校验
4. 思想考古模型 JSON 存在并通过校验
5. 两张人读模型卡存在
6. 来源文章索引存在
7. 来源证据片段索引存在
8. 模型卡引用的 source_id 和 excerpt_id 能找到
9. 每个模型至少 5 个回归测试用例
10. 回归测试用例通过 schema 校验
11. 最小模型选择器能返回推荐模型和理由
12. README.md 说明如何运行校验和 selector demo
13. reports/validation_report.md 记录校验结果
```

不要求：

```text
不要求前端界面
不要求数据库
不要求向量检索
不要求真实 LLM 调用
不要求完整问题回答系统
不要求自动抽取所有模型
```

---

## 20. Codex 返回 ChatGPT 时的交接材料

Codex 完成后，请整理一份：

```text
Codex_工程产物摘要_v0.1.md
```

建议包含：

```markdown
## Codex 工程产物摘要 v0.1

### 1. 当前完成阶段

### 2. 已创建目录结构

### 3. 已创建文件清单

### 4. Schema 实现情况

### 5. QPI 模型卡实现情况

### 6. 思想考古模型卡实现情况

### 7. 来源索引实现情况

### 8. 回归测试实现情况

### 9. 模型选择器实现情况

### 10. 校验结果

### 11. 与原计划不一致的地方

### 12. 当前发现的问题

### 13. 需要 ChatGPT / CCRA 判断的问题

### 14. 下一步建议
```

你回到 ChatGPT 新会话时，建议上传：

```text
1. Codex_工程产物摘要_v0.1.md
2. README.md
3. model_card.schema.json
4. qpi.model.json
5. intellectual_archaeology.model.json
6. source_articles.json
7. source_excerpts.json
8. qpi.regression.json
9. intellectual_archaeology.regression.json
10. selector_examples.json
```

不要直接上传整个工程目录。
先让我判断结构是否合理，再决定是否需要看代码细节。

---

## 21. 下一阶段判断点

当 Codex 完成这个样板工程后，下一步不要立刻扩展到 100 多个模型。

应该先判断 5 个问题：

```text
1. 当前模型卡 schema 是否过重？
2. QPI 和思想考古的字段是否足够支撑系统调用？
3. 来源证据片段是否真的能帮助追溯？
4. 回归测试是否能暴露模型误用？
5. 最小模型选择器是否足以推荐 3-5 个候选模型？
```

如果这 5 个问题基本通过，下一阶段再做：

```text
扩展到 5 个核心模型
→ 扩展到 8-10 个核心模型
→ 接入最小问题回答链路
→ 让输入问题经过 QPI、模型选择器、多棱镜分析、冲突汇总、综合洞察输出
```

如果这 5 个问题没有通过，先修 schema 和抽取协议，不要扩展模型数量。

---

## 22. 给 Codex 的一句话指令

可以把下面这段直接放给 Codex：

```text
请根据《核心模型抽取样板 v0.1》，创建一个 file-first 的 model_library_mvp 工程。不要开发完整后台，不要接数据库，不要做复杂 RAG。第一阶段只需要建立目录结构、JSON Schema、QPI 和思想考古两个样板模型、人读模型卡、来源文章索引、证据片段索引、回归测试用例、校验脚本和最小模型选择器 demo。完成后输出 README.md 和 Codex_工程产物摘要_v0.1.md，说明已完成内容、校验结果、与计划差异和需要下一轮产品判断的问题。
```

---

## 23. 最后提醒

这个样板工程的成败，不取决于代码复杂度，而取决于一件事：

> QPI 和思想考古是否真的从“文章里的概念”变成了“系统能稳定调用的认知模型”。

所以第一版宁可简陋，也要保证：

```text
结构清楚
来源可追溯
边界可检查
误用可测试
后续可扩展
```

这就是模型管理子系统 MVP 的第一块地基。
````

### v0.2 Index 更新策略

- Original path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md`
- SHA256: `a4fff44fa30883986bbbab61e430494cca88869d40b93bf2e4f193dcf133646d`

````markdown
# CCRA 指导意见：Model/Card Index 更新策略与下一轮执行说明

version: 0.2  
date: 2026-06-16  
scope: `model_library_mvp`  
target_reader: Codex  
status: approved_for_next_execution  

---

## 0. 核心结论

`model_index.json` 和 `card_index.md` 不应只在“需要时”才全量更新，也不应每次都靠人工全量重写。

采用策略：

```text
每次资产变更必须增量同步索引
+
关键节点必须全量重建或全量一致性校验
```

也就是：

```text
incremental update on every model/card/source/test change
+
full rebuild / full reconciliation at release, handoff, schema migration, batch expansion, or validation drift
```

原因：

1. `model_index.json` 是机器发现模型的入口。
2. `card_index.md` 是人读审查模型卡的入口。
3. 它们不是模型内容本身的唯一真相，但它们是模型库导航、校验、交接和后续 selector 使用的注册表。
4. 如果索引滞后，ChatGPT / CCRA / Codex 会读到不完整或过期状态。
5. 如果每次都手工全量更新，随着模型扩展到 8-10 个会增加漂移风险。

因此，下一轮应把索引维护从“人工补文档”升级为“可生成、可校验、可审查”的工程规则。

---

## 1. 当前事实基线

当前项目处于 `model_library_mvp` 阶段。

已存在两类索引：

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

当前长期知识资产中的核心模型地图已经规定：

```text
models/model_index.json 是机器索引入口
cards/card_index.md 是人读索引入口
```

当前模型库已有两个样板模型：

```text
qpi
intellectual_archaeology
```

当前两个模型状态均为：

```text
status: draft
stability_level: B
regression_status: pending
```

当前工作重点不是扩展大量模型，而是稳定模型库资产链路：

```text
source article record
-> source evidence excerpts
-> model JSON
-> Markdown card
-> regression cases
-> selector examples or routing rules
-> model/card index entries
-> validation report
```

---

## 2. 索引的产品定位

### 2.1 model_index.json 的定位

`models/model_index.json` 是机器可读的模型注册表。

它用于：

```text
发现当前有哪些模型
读取模型路径
读取 card 路径
读取模型类型
读取 pipeline position
读取状态、稳固性、回归测试状态
读取 source / evidence / regression case 数量
支持 selector、validator、handoff、未来应用层集成
```

它不应承载完整模型内容。完整内容仍在：

```text
models/*.model.json
cards/*.md
sources/source_articles.json
sources/source_excerpts.json
tests/regression_cases.json
```

### 2.2 card_index.md 的定位

`cards/card_index.md` 是人读模型卡索引。

它用于：

```text
快速查看模型卡列表
快速检查模型状态
帮助 ChatGPT / CCRA / owner 审查模型库
作为交接文档中的人类入口
```

它不应成为另一个独立维护的内容源。它应该是 `model_index.json` 与模型卡实际存在状态的人读投影。

### 2.3 两个索引的关系

推荐关系：

```text
models/*.model.json + cards/*.md + sources/*.json + tests/*.json
        ↓
scripts/rebuild_indexes.py
        ↓
models/model_index.json
        ↓
cards/card_index.md
```

解释：

1. 机器注册表优先生成或校验 `model_index.json`。
2. 人读索引 `card_index.md` 应从 `model_index.json` 渲染出来。
3. 如果暂时不做自动生成，也必须用 validator 检查二者一致。
4. 不允许长期手工维护两个索引而不做漂移检查。

---

## 3. 更新策略

### 3.1 每次必须增量更新的情况

只要发生以下任一变更，必须在同一次提交 / 同一轮 Codex 修改中更新索引：

```text
新增模型
删除模型
归档模型
重命名 model_id
修改 model_name
修改 model_type
修改 pipeline_position
修改 model_file 路径
修改 card_file 路径
新增或删除 source article 关联
新增或删除 source evidence 关联
新增或删除 regression case
修改 stability_level
修改 regression_status
修改 status
模型从 draft 进入 review / callable / stable 等状态
card 文件新增、删除、重命名
```

最低要求：

```text
资产变更不能让 model_index.json 或 card_index.md 滞后一轮。
```

也就是说：

```text
新增模型时，index entry 必须同时出现。
删除或归档模型时，index entry 必须同时更新。
状态变化时，index 中状态必须同时更新。
```

### 3.2 必须全量重建或全量一致性校验的情况

以下情况必须运行全量重建或全量校验：

```text
每次交接给 ChatGPT / CCRA / owner 前
每次准备 validation_report.md 前
每次 schema 发生变化后
每次新增一批模型后
每次模型路径、目录结构、文件命名规则发生变化后
每次合并较大范围修改后
每次 selector 规则依赖模型索引前
每次模型状态准备升级前，例如 draft -> reviewed / callable / stable
每次发现 index drift、dangling reference、orphan file 后
```

建议节奏：

```text
单模型变更：增量更新 + full check
批量变更：最后 full rebuild + full check
交接节点：必须 full rebuild/check
版本节点：必须 full rebuild/check
```

### 3.3 不建议的做法

不建议：

```text
只在最后需要交付时才补一次 index
每次手工全量重写两个 index
把 card_index.md 当作独立内容源手工维护
让 model_index.json 与模型 JSON 状态不一致
让 regression_case_count 手工估算
让 source_evidence_count 手工估算
只靠 README 说明当前模型列表
```

---

## 4. 下一轮 Codex 执行任务

### 4.1 新增索引维护协议文档

新增：

```text
docs/INDEX_MAINTENANCE_PROTOCOL.md
```

内容应包含：

```text
index 的定位
增量更新触发条件
全量重建触发条件
model_index.json 字段来源
card_index.md 生成规则
drift 检查规则
Codex 修改模型时的 checklist
```

### 4.2 新增索引重建脚本

新增：

```text
scripts/rebuild_indexes.py
```

功能要求：

1. 扫描 `models/*.model.json`，排除 `models/model_index.json`。
2. 对每个模型读取以下字段：

```text
model_id
model_name
model_type
pipeline_position
stability_profile.stability_level
regression_status
status
version
last_updated
```

3. 检查对应 card 是否存在。
4. 从模型 JSON 的 `source_articles` 计算 `source_article_count`。
5. 从模型 JSON 的 `source_evidence` 计算 `source_evidence_count`。
6. 从 `tests/regression_cases.json` 计算 `regression_case_count`。
7. 生成或更新：

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

8. 输出 report：

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

9. 支持两种模式：

```powershell
python scripts\rebuild_indexes.py --check
python scripts\rebuild_indexes.py --write
```

要求：

```text
--check 只检查，不写文件；发现漂移时返回非零退出码。
--write 重新生成 index 文件。
```

### 4.3 扩展 validate_model_library.py

修改：

```text
scripts/validate_model_library.py
```

新增校验项：

```text
model_index.json 中每个 model_file 必须存在
model_index.json 中每个 card_file 必须存在
每个 models/*.model.json 必须有 index entry
每个 cards/*.md 必须有 card_index entry
card_index.md 中每个条目必须能在 model_index.json 找到
source_article_count 必须与模型 JSON source_articles 数量一致
source_evidence_count 必须与模型 JSON source_evidence 数量一致
regression_case_count 必须与 tests/regression_cases.json 中同 model_id 数量一致
stability_level 必须与模型 JSON stability_profile.stability_level 一致
regression_status 必须与模型 JSON regression_status 一致
status 必须与模型 JSON status 一致
```

### 4.4 明确 index 字段来源

`model_index.json` 中字段来源如下：

| index 字段 | 来源 |
|---|---|
| `model_id` | `models/*.model.json.model_id` |
| `model_name` | `models/*.model.json.model_name` |
| `model_type` | `models/*.model.json.model_type` |
| `pipeline_position` | `models/*.model.json.pipeline_position` |
| `model_file` | 文件路径 |
| `card_file` | 按模型 ID 匹配或模型 JSON 中显式字段；若没有则按约定推断 |
| `source_article_count` | `source_articles` 数组长度 |
| `source_evidence_count` | `source_evidence` 数组长度 |
| `regression_case_count` | `tests/regression_cases.json` 中同 `model_id` 的 case 数 |
| `stability_level` | `stability_profile.stability_level` |
| `regression_status` | `regression_status` |
| `status` | `status` |
| `last_updated` | `last_updated` |

### 4.5 card_index.md 生成规则

`card_index.md` 应从 `model_index.json` 渲染生成。

表格字段保持当前简单结构：

```text
Model ID
模型名称
类型
流程位置
Card
Model JSON
稳固性
回归状态
状态
```

可追加但非必须字段：

```text
source evidence count
regression case count
last_updated
```

v0.2 不建议把 card_index.md 做得太复杂。

---

## 5. 状态升级规则

索引维护不能自动把模型升级为 stable。

Codex 可以根据文件内容同步：

```text
status
stability_level
regression_status
```

但不能自行判断模型升级。

升级必须由 owner / ChatGPT / CCRA 审查后明确决定。

禁止：

```text
因为 schema pass 就把 status 改成 stable
因为 regression case 数量增加就把 regression_status 改成 passed
因为 index 一致就把 stability_level 从 B 改成 A
```

当前 QPI 和思想考古仍保持：

```text
status: draft
stability_level: B
regression_status: pending
```

直到内容审查、边界测试和 selector 回归测试完成。

---

## 6. 验收标准

Codex 完成后，应满足：

```powershell
python scripts\rebuild_indexes.py --check
python scripts\check_card_contract.py
python scripts\validate_model_library.py
python scripts\run_selector_demo.py
python -m unittest discover -s tests -p "test*.py" -v
```

全部通过。

同时生成或更新：

```text
docs/INDEX_MAINTENANCE_PROTOCOL.md
scripts/rebuild_indexes.py
reports/index_rebuild_report.md
reports/validation_report.md
models/model_index.json
cards/card_index.md
```

验收时重点检查：

```text
没有 orphan model JSON
没有 orphan card
没有 dangling model_file
没有 dangling card_file
没有 source evidence 计数漂移
没有 regression case 计数漂移
model_index.json 与 card_index.md 状态一致
validation_report.md 明确写出 index check 结果
```

---

## 7. 下一步工作边界

本轮只做索引维护与校验机制，不做：

```text
数据库
后台 UI
自动抽取 100 个模型
LLM selector
完整 RAG
跨仓库同步器
公开产品功能
```

可以做：

```text
索引维护协议
索引重建脚本
索引一致性校验
validation report 扩展
README / handoff 中补充索引维护说明
```

---

## 8. 给 Codex 的执行口径

请按以下顺序执行：

```text
1. 阅读现有 README、model_index.json、card_index.md、validate_model_library.py、check_card_contract.py。
2. 新增 docs/INDEX_MAINTENANCE_PROTOCOL.md。
3. 实现 scripts/rebuild_indexes.py，支持 --check 和 --write。
4. 用 --write 生成当前 model_index.json 与 card_index.md。
5. 扩展 validate_model_library.py 的 index drift 检查。
6. 运行全部验证命令。
7. 更新 reports/validation_report.md。
8. 在交接文档中说明：索引采用“每次增量同步 + 关键节点全量重建/校验”策略。
```

提交完成后，把以下信息交回：

```text
变更文件列表
索引重建结果
校验命令结果
是否发现 drift
是否有字段需要 owner 决策
是否保持 QPI / 思想考古为 draft + B + pending
```

---

## 9. CCRA 判断

当前索引策略的核心不是“省事”，而是避免模型库变成一堆散文件。

`model_index.json` 和 `card_index.md` 是模型库进入可维护状态的最小导航层。  
它们必须跟随内容资产同步更新，但又不能靠人工长期维护。  
因此 v0.2 的正确方向是：让 Codex 把索引更新变成脚本化、可检查、可交接的工程约束。
````

### v0.3 内容稳定化

- Original path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md`
- SHA256: `6a4a653602cc467b0a7fbb52765336e75e4109b8af2c0d5bd5aa584dcb86464c`

````markdown
# CCRA 给 Codex 的指导意见：模型库 MVP 第二轮内容稳定化与质量补强 v0.3

日期：2026-06-16  
适用仓库：`model_library_mvp`  
适用阶段：QPI / 思想考古学两个样板模型进入内容稳定化审查  
执行者：Codex  
上游判断者：CCRA / ChatGPT / Owner  

---

## 0. 一句话结论

本轮不要扩展第三个模型，也不要接入完整问题回答系统。  
当前应从“文件和 contract 能跑通”推进到“证据链、边界、回归测试、selector 误召回防护能站住”。

两个此前遗漏的文件已经补齐：

```text
models/qpi.model.json
sources/source_excerpts.json
```

这解决了第一轮审查中的“QPI 机器卡缺失”和“证据片段索引缺失”问题。  
但补齐文件后，当前工作暴露出新的质量债：模型内容仍是 `draft`，证据支撑还没有做到字段级，回归测试仍是样板级，selector 还不能证明“选得准、不误召回、不乱下潜”。

---

## 1. 当前状态确认

### 1.1 已经可以确认通过的部分

当前工程方向继续确认通过：

```text
file-first 架构：通过
JSON 作为机器可读模型数据：通过
Markdown 作为人读模型卡：通过
QPI / 思想考古两个样板模型：通过工程 contract
source_articles / source_excerpts：已补齐
model_index / card_index：当前两模型条目与数量基本一致
回归测试容器：已存在
最小 selector demo：已存在
```

### 1.2 不能确认通过的部分

以下内容不能升级为 stable：

```text
QPI 内容稳定性：不能通过，只能保持 draft-callable
思想考古学内容稳定性：不能通过，只能保持 draft-callable
source evidence 字段级充分性：不能通过
regression cases 稳定性验证强度：不能通过
selector 选择准确性：不能通过
内容审查闭环：不能通过
```

当前正确状态应是：

```text
engineering_contract_passed = true
content_review_status = pending
evidence_review_status = pending
selector_review_status = pending
stability_level = B
regression_status = pending
model_status = draft
```

不要把 `validation_report: PASS` 理解为模型内容已稳定。它只代表字段、引用和基础 contract 能跑通。

---

## 2. 本轮发现的主要不足

### 2.1 证据链仍然停留在“片段存在”，没有进入“字段级支撑”

当前每个模型都有 5 条 source evidence，数量满足 v0.1 样板要求。  
但现在的 `used_for` 只覆盖了部分字段，很多系统调用关键字段仍属于产品推导、红队推导或人工判断，没有被显式标记。

需要区分四类支撑来源：

```text
direct_source：原文直接支撑
derived_from_source：从原文合理推导
product_decision：产品化调用规则
red_team_inference：红队边界或误用推导
owner_decision：Owner / CCRA 的人工决策
```

当前不足不是“没有证据”，而是“没有标明哪些字段是原文直接支撑，哪些是产品化推导”。

### 2.2 `raw_excerpt` 需要区分“原文摘录”和“压缩摘录”

当前 `source_excerpts.json` 中，部分 `raw_excerpt` 不是完整原文摘录，而是压缩表达。  
例如思想考古七层结构片段使用了省略号：

```text
第一层（应用层）...第七层（哲学基岩层）
```

如果字段名叫 `raw_excerpt`，就应尽量是原文准确摘录；如果为了节省篇幅而压缩，必须显式标记。

建议新增或规范字段：

```json
{
  "quote_status": "exact | condensed | paraphrased",
  "raw_excerpt": "原文准确摘录；如果不是 exact，不应伪装成完整原文",
  "summary": "摘要或解释",
  "source_location": "章节、段落、标题或行号，若未知则写 unknown"
}
```

验收要求：

```text
quote_status = exact 时，raw_excerpt 不应包含无说明的 “...” 或 “……”
quote_status = condensed 时，必须保留 summary，并在 notes 说明已压缩
```

### 2.3 source schema 枚举可能已经和实现数据漂移

当前实现数据里出现了以下值：

```text
source_type: synthesis_note
source_status: derived_synthesis
excerpt_type: application_rule / value_claim / boundary_rule / validation_rule
```

这些值有产品意义，可以保留。  
但 Codex 必须确认本地 schema 是否已经支持它们。

执行规则：

```text
如果 schema 已支持这些枚举：
  更新 docs 和 knowledge_assets 中的 schema 摘要，避免长期文档落后。

如果 schema 未支持这些枚举：
  不要静默绕过校验。
  要么将数据映射回既有枚举；
  要么正式扩展 schema，并在 DECISIONS / docs 中记录原因。
```

不能出现“数据中有一套枚举，schema 文档中是另一套枚举”的隐性漂移。

### 2.4 QPI 的输出契约还不够硬

`qpi.model.json` 的 `core_mechanism` 已经提到：

```text
问题拥有者
问题来源
时间尺度
核心匮乏物
暴力降维 / 恶意升维 / 手段错配
```

但当前 `output_types` 和 `output_contract` 还没有强制这些字段。  
这会导致 QPI 在真实问题中输出仍然偏“解释性”，不足以支撑稳定路由。

QPI 必须新增或强化结构化输出字段：

```json
{
  "problem_owner": "谁的问题",
  "problem_source": "问题从哪里被提出，是否可能带有立场或甩锅框架",
  "time_scale": "short_term | mid_term | long_term | mixed | unknown",
  "scarcity_profile": {
    "data_scarcity": "high | medium | low | unknown",
    "path_or_resource_scarcity": "high | medium | low | unknown",
    "consensus_or_order_scarcity": "high | medium | low | unknown"
  },
  "dominant_scarcity": "data | path_resource | consensus_order | mixed | unknown",
  "classification": "question | problem | issue | mixed | no_call",
  "classification_confidence": "high | medium | low",
  "evidence_gap": ["还缺哪些信息才能稳定判断"],
  "misclassification_risk": ["可能被暴力降维、恶意升维或手段错配的风险"],
  "recommended_next_step": "检索 / 工程拆解 / 共识协调 / 补充上下文 / 不调用",
  "next_model_candidates": ["后续可调用模型 ID"]
}
```

这不要求立即开发完整运行时，只要求模型卡、JSON 和回归测试先按这个契约准备好。

### 2.5 思想考古学的停止条件还没有足够可测试

思想考古学保留七层结构是正确的，但不能默认全量七层展开。  
当前 `depth_control.stop_conditions` 已经存在，但还需要变成可测试输出。

思想考古学必须新增或强化结构化输出字段：

```json
{
  "should_call": true,
  "entry_reason": "为什么值得进入思想考古",
  "recommended_max_depth": "application | domain | process | purpose | core_mechanism | human_capability | philosophical_bedrock",
  "layers_to_analyze": ["实际需要分析的层级"],
  "stop_reason": "为什么停在这一层",
  "no_deeper_reason": "继续下潜不会改变什么",
  "assumptions_by_layer": {
    "application": [],
    "domain": [],
    "process": [],
    "purpose": [],
    "core_mechanism": [],
    "human_capability": [],
    "philosophical_bedrock": []
  },
  "validation_needed": ["哪些判断需要现实反馈、数据、专家盲审或红队"],
  "action_implication": "下潜结果如何改变下一步行动"
}
```

重点不是让输出更复杂，而是防止思想考古变成“自动哲学化”。

### 2.6 regression cases 仍是样板级，不能证明模型稳定

当前每个模型 5 条用例，满足 v0.1 最低要求，但不足以支撑 B 级以上稳定调用。

下一轮最低目标：

```text
每个模型至少 15 条 regression cases
```

建议结构：

```text
QPI:
- 3 条 Question 正例
- 3 条 Problem 正例
- 3 条 Issue 正例
- 3 条 mixed / boundary 案例
- 2 条 misuse 案例：恶意升维、暴力降维
- 1 条 no-call 案例：明确事实查询 / 纯改写 / 直接执行

思想考古学:
- 3 条重型正例
- 3 条中型正例：只下潜到目的层或核心机理层
- 3 条 no-call / minimum-depth 案例
- 3 条 misuse 案例：过度哲学化、无现实验证、层级跳跃
- 2 条 selector gate 案例：QPI 不应放行或只应轻量放行
- 1 条模型抽取场景案例
```

### 2.7 regression cases 还不够机器可评估

当前 case 主要是自然语言 `expected_behavior` 和 `expected_output_elements`。这适合人审，但不够支撑 selector / model behavior 自动检查。

建议在 `regression_case.schema.json` 中新增可选 v0.2 字段：

```json
{
  "should_call_model": true,
  "expected_primary_model": "qpi",
  "negative_expected_models": ["intellectual_archaeology"],
  "expected_classification": "question | problem | issue | mixed | no_call | not_applicable",
  "expected_dominant_scarcity": "data | path_resource | consensus_order | mixed | unknown | not_applicable",
  "expected_max_depth": "application | domain | process | purpose | core_mechanism | human_capability | philosophical_bedrock | no_call | not_applicable",
  "minimum_required_elements": ["必须出现的输出元素"],
  "forbidden_elements": ["不应出现的输出元素"],
  "evaluation_mode": "manual | keyword | structured | semantic"
}
```

v0.2 不必马上做复杂 LLM 评测，但数据结构要先为自动评估留接口。

### 2.8 selector 仍停留在 demo，不足以证明选择准确

selector v0.1 可以继续规则化，不要现在加入 LLM。  
但必须增强以下能力：

```text
negative trigger 先行
no-call threshold
QPI-before-IA gate
score breakdown
rejected model reasons
selector regression tests
```

建议 selector 输出格式：

```json
{
  "input": "...",
  "selected_models": [
    {
      "model_id": "qpi",
      "score": 0.86,
      "reasons": ["trigger keyword matched", "pipeline_position pre_analysis"],
      "penalties": [],
      "decision": "selected"
    }
  ],
  "rejected_models": [
    {
      "model_id": "intellectual_archaeology",
      "score": 0.21,
      "reasons": [],
      "penalties": ["negative trigger: 只查事实", "no QPI heavy-problem gate"],
      "decision": "rejected"
    }
  ],
  "no_call": false
}
```

重点是让 Codex 能用 regression cases 验证：

```text
不该调用思想考古时，不能因为“深层、底层、模型”等词误召回。
明确事实查询时，QPI 也不应过度分析。
```

### 2.9 Markdown card 与 JSON model card 需要语义同步检查

当前 `check_card_contract.py` 主要检查 Markdown 章节是否存在。  
它不能证明 Markdown 和 JSON 的关键字段语义一致。

需要新增：

```text
scripts/check_model_card_sync.py
```

至少检查：

```text
model_id
model_name
model_type
pipeline_position
source_articles
source_evidence
stability_level
regression_status
version
last_updated
output_contract 摘要
depth_control / 停止条件摘要
```

v0.2 只做硬字段一致性即可，中文长文本不做完全相等检查。

### 2.10 状态门不够细

当前 `status: draft` 太粗。建议不一定立刻改 schema，但至少在报告中明确四个状态：

```text
engineering_contract_status
content_review_status
evidence_review_status
regression_review_status
selector_review_status
```

示例：

```json
{
  "model_id": "qpi",
  "engineering_contract_status": "passed",
  "content_review_status": "needs_minor_revision",
  "evidence_review_status": "needs_field_level_matrix",
  "regression_review_status": "needs_expansion",
  "selector_review_status": "needs_no_call_tests"
}
```

先放在 `reports/content_review_report_v0.2.md` 或 `reports/model_review_status.json`，不急着塞进 `model_index.json`。

---

## 3. 本轮 Codex 执行任务

### Task 0：先跑现有基线，不改内容

先运行现有命令并记录结果：

```powershell
python -m unittest discover -s tests -p "test*.py" -v
python scripts\check_card_contract.py
python scripts\validate_model_library.py
python scripts\run_selector_demo.py
```

输出：

```text
reports/baseline_before_content_stabilization_v0.2.md
```

报告中说明：

```text
当前模型数量
当前 source evidence 数量
当前 regression cases 数量
当前 selector 示例数量
当前 model/card index 状态
当前 PASS 代表什么、不代表什么
```

---

### Task 1：新增内容稳定化协议

创建：

```text
docs/CONTENT_STABILIZATION_PROTOCOL.md
```

必须写清楚：

```text
1. 工程 contract 通过不等于内容稳定。
2. 模型从 draft 升级必须经过：
   - evidence review
   - content review
   - regression review
   - selector review
   - owner / CCRA review
3. QPI 和思想考古保持 B / pending / draft。
4. 不引入第三模型，直到两个样板模型通过本轮内容稳定化。
```

---

### Task 2：建立字段级 evidence coverage matrix

创建：

```text
reports/evidence_coverage_report_v0.2.md
sources/evidence_coverage.matrix.json
```

`evidence_coverage.matrix.json` 建议结构：

```json
{
  "model_id": "qpi",
  "field_coverage": [
    {
      "field": "core_mechanism",
      "support_type": "direct_source",
      "excerpt_ids": ["excerpt_qpi_primary_spectrum_001"],
      "coverage_status": "supported",
      "notes": "Q/P/I 和核心匮乏物有原文直接支撑。"
    },
    {
      "field": "negative_triggers",
      "support_type": "product_decision",
      "excerpt_ids": [],
      "coverage_status": "derived",
      "notes": "来源于产品化防误用规则，不是原文直接表达。"
    }
  ]
}
```

coverage_status 枚举建议：

```text
supported
partially_supported
derived
unsupported
needs_owner_review
```

验收标准：

```text
每个模型至少覆盖 model_card.schema.json 的 required 字段。
每个 required 字段都必须被标记为 supported / derived / needs_owner_review 等状态。
不要求所有字段都有原文直接证据，但必须诚实标注。
```

---

### Task 3：修复 source evidence 精确性与枚举一致性

检查并修复：

```text
sources/source_excerpts.json
schemas/source_excerpt.schema.json
schemas/source_article.schema.json
docs/MODEL_EXTRACTION_RULES.md
knowledge_assets/03_核心模型抽取样板.md（如存在对应摘要）
```

具体要求：

```text
1. 为 source excerpt 增加 quote_status 或等价字段。
2. raw_excerpt 如非准确原文，不得伪装成完整原文。
3. 检查 excerpt_type 是否被 schema 正式允许。
4. 检查 source_type / source_status 是否被 schema 正式允许。
5. 对 synthesis_note / derived_synthesis 明确说明它们是综合材料，不等于原始主证据。
```

---

### Task 4：强化 QPI 机器输出契约与模型卡

修改：

```text
models/qpi.model.json
cards/qpi.md
```

必须补入或强化：

```text
problem_owner
problem_source
time_scale
scarcity_profile
dominant_scarcity
classification_confidence
evidence_gap
misclassification_risk
recommended_next_step
next_model_candidates
```

建议位置：

```text
output_types
output_contract
depth_control
stabilization_path
example_outputs
```

验收标准：

```text
QPI 输出不再只是“判断类型 + 理由”，而是能产出稳定路由所需字段。
QPI 对 mixed 案例必须先标 evidence_gap，再判断 dominant_scarcity。
QPI 对事实查询和纯执行任务能输出 no_call / stop。
```

---

### Task 5：强化思想考古的深度控制与停止门

修改：

```text
models/intellectual_archaeology.model.json
cards/intellectual_archaeology.md
```

必须补入或强化：

```text
should_call
entry_reason
recommended_max_depth
layers_to_analyze
stop_reason
no_deeper_reason
assumptions_by_layer
validation_needed
action_implication
```

验收标准：

```text
思想考古保留七层结构，但每次调用必须说明最多下潜到哪一层。
如果不应调用，必须能说明不调用原因。
如果停止在过程层 / 目的层 / 核心机理层，不能继续自动展开到哲学基岩。
输出必须回到行动、验证或模型稳定化判断。
```

---

### Task 6：扩展并拆分 regression cases

当前可以保留聚合文件，但 v0.2 要增加按模型拆分文件：

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

规则：

```text
按模型文件是人审 source of truth。
聚合文件可以由脚本生成，用于统一校验。
```

数量要求：

```text
qpi >= 15 cases
intellectual_archaeology >= 15 cases
```

类型至少包含：

```text
positive
boundary
misuse
no_call
selector_gate
pipeline
```

如果暂时不改 schema enum，则先把新增类型放在 notes 或扩展 schema 后再录入。不要把 no_call / selector_gate 硬塞进 boundary 里导致语义不清。

---

### Task 7：增强 regression schema 的可评估字段

修改：

```text
schemas/regression_case.schema.json
```

新增 v0.2 可选字段：

```json
[
  "should_call_model",
  "expected_primary_model",
  "negative_expected_models",
  "expected_classification",
  "expected_dominant_scarcity",
  "expected_max_depth",
  "minimum_required_elements",
  "forbidden_elements",
  "evaluation_mode"
]
```

验收标准：

```text
旧用例仍可通过。
新增用例能表达 no-call、误召回、最大下潜层级和禁止输出项。
validator 能检查字段类型和 model_id 引用。
```

---

### Task 8：强化 selector v0.2，但不引入 LLM

修改或新增：

```text
selector/selector_rules.json
selector/selector_examples.json
scripts/run_selector_demo.py
scripts/run_selector_regression.py
```

selector 规则必须包含：

```text
negative trigger 先行
no-call threshold
QPI-before-IA gate
score breakdown
rejected model reasons
```

新增 selector regression：

```text
从 tests/*.regression.json 读取 no_call / selector_gate / pipeline cases。
验证 selected_models 和 rejected_models 是否符合预期。
输出 reports/selector_regression_report_v0.2.md。
```

不得做：

```text
不接 LLM
不接向量库
不做完整问题回答系统
不做复杂 agent runtime
```

---

### Task 9：新增 JSON / Markdown 同步检查器

创建：

```text
scripts/check_model_card_sync.py
reports/model_card_sync_report_v0.2.md
```

检查：

```text
model_id
model_name
model_type
pipeline_position
source_articles
source_evidence
stability_level
regression_status
version
last_updated
关键 output_contract 条目是否在 Markdown 中有对应说明
关键 depth_control / 停止条件是否在 Markdown 中有对应说明
```

验收标准：

```text
QPI 和思想考古都通过硬字段同步检查。
如果中文长文本不能完全同步，也要在 report 中列出人工审查项。
```

---

### Task 10：生成内容审查报告和下一步状态表

创建：

```text
reports/content_review_report_v0.2.md
reports/model_review_status.json
reports/next_action_register_v0.2.md
```

`content_review_report_v0.2.md` 必须包含：

```text
1. 本轮修改摘要
2. QPI 内容审查结果
3. 思想考古内容审查结果
4. evidence coverage 结论
5. regression coverage 结论
6. selector regression 结论
7. 仍未解决的问题
8. 是否允许进入 draft-callable
9. 是否允许升级 stable
10. 是否允许扩展第三模型
```

默认结论应保持：

```text
draft-callable: allowed
stable: not allowed
third_model_expansion: not allowed
```

除非 owner / CCRA 明确改判。

---

## 4. 本轮验收标准

Codex 完成后，必须满足：

```text
1. 现有工程命令仍全部 PASS。
2. 新增 content stabilization protocol。
3. 完成字段级 evidence coverage matrix。
4. source excerpt 的 raw / condensed / paraphrased 状态明确。
5. schema 与实现枚举一致。
6. QPI 输出契约包含 problem_owner、time_scale、dominant_scarcity、evidence_gap。
7. 思想考古输出契约包含 recommended_max_depth、stop_reason、no_deeper_reason。
8. 每个模型 regression cases >= 15。
9. selector 能输出 score breakdown 和 rejected model reasons。
10. 新增 selector regression report。
11. 新增 JSON / Markdown 同步检查报告。
12. 生成 content_review_report_v0.2.md。
13. model_index / card_index 按上一份 CCRA index 指导意见同步更新或通过 --check。
14. QPI / 思想考古仍保持 B / pending / draft，除非 CCRA 明确升级。
```

---

## 5. 不要做的事情

本轮不要做：

```text
不要扩展第三个模型
不要录入 8-10 个模型
不要接入完整问题回答链路
不要接 LLM selector
不要接向量数据库
不要做前端或后台管理页面
不要做知识图谱
不要把 regression_status 改成 passed
不要把 stability_level 改成 A
不要把 draft 改成 stable
```

本轮目标只有一个：

```text
把 QPI 和思想考古两个样板模型，从“工程可运行”推进到“内容可审查、证据可追溯、误用可测试、selector 可防误召回”。
```

---

## 6. 给 Codex 的执行顺序建议

建议严格按顺序执行：

```text
1. 跑 baseline report
2. 写 CONTENT_STABILIZATION_PROTOCOL
3. 做 evidence coverage matrix
4. 修 source evidence 精确性和 schema 枚举
5. 修 QPI 输出契约
6. 修思想考古停止门
7. 扩展 regression schema
8. 扩展 regression cases
9. 强化 selector
10. 加 JSON / Markdown sync checker
11. 跑全量 validation
12. 生成 content_review_report_v0.2
13. 更新 indexes 或运行 index --check
14. 输出 Codex 交接摘要
```

如果中途发现 schema 改动会牵连过大，优先保留 backward compatibility，新增字段设为 optional，不要破坏现有 v0.1 数据。

---

## 7. Codex 交接时必须返回的文件

完成后请返回或汇总以下文件：

```text
docs/CONTENT_STABILIZATION_PROTOCOL.md
reports/baseline_before_content_stabilization_v0.2.md
reports/evidence_coverage_report_v0.2.md
sources/evidence_coverage.matrix.json
models/qpi.model.json
cards/qpi.md
models/intellectual_archaeology.model.json
cards/intellectual_archaeology.md
tests/qpi.regression.json
tests/intellectual_archaeology.regression.json
tests/regression_cases.json
schemas/regression_case.schema.json
schemas/source_excerpt.schema.json
selector/selector_rules.json
selector/selector_examples.json
scripts/check_model_card_sync.py
scripts/run_selector_regression.py
reports/selector_regression_report_v0.2.md
reports/model_card_sync_report_v0.2.md
reports/content_review_report_v0.2.md
reports/model_review_status.json
reports/next_action_register_v0.2.md
```

交接摘要必须明确回答：

```text
1. 当前 QPI 是否仍为 draft？
2. 当前思想考古是否仍为 draft？
3. 每个模型 evidence coverage 哪些字段是 supported，哪些是 derived？
4. 每个模型 regression cases 数量与类型分布是什么？
5. selector 有哪些 no-call / false-positive 防护？
6. 哪些问题仍需要 CCRA / Owner 判断？
7. 是否建议进入第三模型扩展？默认答案应为否。
```
````

## 3. Compliance Matrix

| Guidance | Requirement | Done / Not Done / Partial | Evidence File | Notes |
| --- | --- | --- | --- | --- |
| v0.3 | 不扩展第三模型 | Done | `reports/content_review_report_v0.2.md` | 保持两模型 |
| v0.3 | 不接完整问题回答系统 | Done | `reports/content_review_report_v0.2.md` | 未新增问答链路 |
| v0.3 | 不引入 LLM selector | Done | `selector/selector_rules.json`; `scripts/run_selector_demo.py` | selector v0.2 remains rule-based |
| v0.3 | 不升级 stable | Done | `models/model_index.json`; model JSON files | 两模型 draft / B / pending |
| v0.3 | 字段级 evidence coverage matrix | Done | `sources/evidence_coverage.matrix.json` | required fields classified |
| v0.3 | source excerpt 精确性修复 | Done | `sources/source_excerpts.json`; `schemas/source_excerpt.schema.json` | quote_status/source_location added |
| v0.3 | QPI 输出契约强化 | Done | `models/qpi.model.json`; `cards/qpi.md` | problem_owner/time_scale/dominant_scarcity/evidence_gap included |
| v0.3 | 思想考古停止门强化 | Done | `models/intellectual_archaeology.model.json`; `cards/intellectual_archaeology.md` | recommended_max_depth/stop_reason/no_deeper_reason included |
| v0.3 | 每模型 regression >= 15 | Done | `tests/qpi.regression.json`; `tests/intellectual_archaeology.regression.json` | 17 each |
| v0.3 | selector v0.2 防误召回 | Done | `reports/selector_regression_report_v0.2.md` | 9 selector cases PASS |
| v0.3 | JSON / Markdown 同步检查 | Done | `reports/model_card_sync_report_v0.2.md` | hard-field sync PASS |
| v0.2 | index rebuild/check script | Done | `scripts/rebuild_indexes.py` | --check / --write supported |
| v0.2 | index drift check | Done | `reports/index_check_report.md`; `reports/index_rebuild_report.md` | PASS |
| v0.2 | model/card index synchronized | Done | `models/model_index.json`; `cards/card_index.md` | counts updated |
| v0.1 | file-first JSON/Markdown MVP | Done | `README.md`; assets | no DB/frontend/backend |

## 4. Deviations From Guidance

- `draft-callable` remains a report conclusion, not a model JSON status value.
- `reports/*_v0.2.md` files are canonical; no-version aliases were added for audit convenience.
- Full source files are included in `02_CURRENT_ASSET_PACK.md`; optional zip is only backup.

## 5. Open Decisions For CCRA

- See `reports/open_questions_for_CCRA.md` and section 10 of `03_REPORTS_DIFF_AND_COMMAND_LOG.md`.
