29 KiB
CCRA 模型库数据治理与模型调用机制说明
version: 0.1
date: 2026-06-17
status: draft for Owner alignment
recommended_repo_path: knowledge_assets/09_数据治理与模型调用机制说明.md
0. 这份文档回答什么问题
你现在看到的现象是：
原始文章和人工素材并不算大，但项目已经出现上千个文件、多个 JSON、Markdown、selector、regression、validation、review bundle，投入了大量 tokens。我们到底在做什么？
一句话回答：
我们不是在把文章“存进知识库”，而是在把文章里隐含的认知模型，治理成可追溯、可审查、可调用、可拒绝调用、可回归测试、可交给运行时系统使用的软件资产。
这和普通知识库的差异很大。
普通知识库关心的是：
“这段内容在哪里？能不能搜出来？”
认知模型库关心的是：
“这个模型什么时候应该被调用？什么时候绝对不该被调用？输入是什么？输出必须包含什么？判断错了会造成什么误用？下次改模型时，怎么知道没有把边界改坏？”
所以，项目文件数量增加，不是因为原文内容很多，而是因为我们在给模型补上“软件化外壳”：
原始文章
-> 来源记录
-> 证据片段
-> 人读模型卡
-> 机器可读模型卡
-> 输出契约
-> 调用规则
-> 负向触发条件
-> selector
-> calibration input
-> regression cases
-> validation scripts
-> review bundle
-> CCRA / Owner 审核意见
这些文件不是平行内容，而是不同治理层。
1. 当前项目到底是什么
当前仓库 the-mindscape-of-bro-tsong 处在 model_library_mvp 阶段。
它不是完整产品、不是聊天机器人、不是前端平台、不是 RAG 系统、不是知识图谱，也不是商业交付系统。
它当前要验证的是：
少量核心认知模型能否被整理成 file-first 的模型资产，并具备可读、可追溯、可调用、可测试、可路由的最低能力。
第一批样板模型是：
- QPI：前置问题定性和路由模型。
- 思想考古学：中重型问题的深度建模模型。
这里的重点不是 QPI 本身，而是：
以 QPI 为样板，证明你的自有模型未来可以按同一种治理机制进入软件系统。
2. 为什么不是直接把文章喂给 AI
如果只是“让 AI 读文章然后回答问题”，那确实不需要这么多文件。
但那种做法有几个问题：
- 不可追溯：系统用了哪篇文章、哪段原文、哪条人工判断，很难回查。
- 不可稳定调用：同一个问题，下次可能调用不同模型、输出不同结构。
- 不可拒绝调用：模型容易被滥用，例如所有复杂问题都强行套 QPI 或思想考古。
- 不可回归：改一条规则后，无法知道以前的边界案例是否被破坏。
- 不可交接 Codex：Codex 不能只拿一篇文章就知道如何构建 selector、schema、validator、测试和模型卡。
- 不可产品化：文章是内容资产，模型库需要的是可组合、可运行、可验证的认知工具资产。
所以这轮工作的本质不是“扩写内容”，而是“把隐性认知风格显性化，把显性模型工程化”。
3. 数据治理的核心目标
本项目的数据治理不是传统数据库治理，而是认知模型治理。
它要解决六类问题：
3.1 来源治理：这个模型从哪里来
每个模型必须知道：
- 来源文章是什么；
- 代表性文本是什么；
- 哪些字段是原文直接支持；
- 哪些字段是从原文推导；
- 哪些字段是产品化决策；
- 哪些字段是红队推断；
- 哪些字段是 Owner / CCRA 人工判断。
这防止模型后来变成“看起来像你的思想，但已经无法回到原文”。
3.2 结构治理：这个模型是什么
模型不能只是一段漂亮定义，而要被拆成：
- model_id；
- model_type；
- pipeline_position；
- 核心问题；
- 核心机制；
- 输入类型；
- 输出类型；
- 适用场景；
- 不适用场景；
- 负向触发条件；
- 常见误用；
- 失败信号；
- 稳固性等级；
- 输出契约。
这让模型可以被人审，也可以被机器读取。
3.3 调用治理：什么时候用，什么时候不用
模型一旦进入系统，就不能默认“能用就用”。
每个模型都需要回答：
- 什么输入应该调用它？
- 什么输入不该调用它？
- 是否必须先经过其他模型？
- 是否只能在某个流程阶段使用？
- 是否需要重型分析门槛？
- 是否存在硬 no-call 条件？
这就是 selector 要解决的问题。
3.4 输出治理：模型被调用后必须产出什么
模型输出不能随意发挥。
例如 QPI 不是随便说“这是问题还是课题”，而是必须输出：
- 当前主体是谁；
- 当前场景是什么；
- 责任范围是什么；
- 期望—现实落差是什么；
- 主导稀缺物是什么；
- 分类是 Q / P / I / mixed / no-call；
- 置信度如何；
- 缺什么证据；
- 误分类风险是什么；
- 下一步应该调用什么模型或采取什么动作。
思想考古学也不是无限哲学化，而是要说明是否应该调用、为什么调用、最多下潜到哪层、哪些层需要分析、什么时候停止。
3.5 边界治理：模型如何防止误用
你的模型往往具有很强解释力。解释力越强，越容易被滥用。
典型误用包括：
- 暴力降维：把复杂 Issue 当成简单 Problem；
- 恶意升维：把简单执行任务夸大成复杂课题；
- 手段错配：本该查资料，却启动深度模型；本该组织协商，却只做文档润色；
- 认知重工业化：一个轻量问题被多模型、多智能体、深层考古压爆。
边界治理的目的不是削弱模型，而是让模型在该用时有力，不该用时安静。
3.6 生命周期治理：模型什么时候可以升级
模型不能因为 JSON 能解析、schema 通过、demo 能跑，就升级为 stable。
升级至少需要经过：
- evidence review；
- content review；
- regression review；
- selector review；
- Owner / CCRA review。
当前 QPI 和思想考古仍然是：
status: draft
stability_level: B
regression_status: pending
这不是失败，而是正确的质量门状态。
4. 为什么会有这么多文件
现在看到的文件大致分成九类。
4.1 原始与来源层
用途：回答“模型从哪里来”。
典型文件：
sources/source_articles.json
sources/source_excerpts.json
sources/evidence_coverage.matrix.json
它们不是正文内容的重复，而是来源索引和证据定位。
4.2 人读模型层
用途：让 Owner、CCRA、未来协作者能读懂模型。
典型文件：
cards/qpi.md
cards/intellectual_archaeology.md
cards/card_index.md
Markdown card 是人审界面。
4.3 机器模型层
用途：让 selector、validator、未来运行时能读取模型。
典型文件：
models/qpi.model.json
models/intellectual_archaeology.model.json
models/model_index.json
JSON model card 是机器调用界面。
4.4 契约与规则层
用途：约束模型卡、输出字段、数据结构和调用规则。
典型文件：
schemas/model_card.schema.json
docs/DATA_CONTRACT.md
docs/QPI_CONTEXTUAL_ROUTING_RULES.md
docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md
docs/DECISIONS.md
这些文件回答“以后一直怎么做”。
4.5 Selector 层
用途：决定当前输入该调用哪些模型，以及不该调用哪些模型。
典型文件：
selector/selector_rules.json
selector/selector_examples.json
selector/selector_calibration_inputs.json
selector/qpi_case_digests.json
scripts/run_selector_demo.py
scripts/run_selector_regression.py
selector 是运行时前面的守门员。
4.6 Regression 层
用途：保护模型边界，避免以后修改规则时把模型改坏。
典型文件：
tests/qpi.regression.json
tests/regression_cases.json
tests/test_validate_model_library.py
regression 不是普通内容样例，而是“以后不能忘的边界条件”。
4.7 Validation 层
用途：机械检查文件是否一致、字段是否完整、index 是否漂移、模型卡是否同步。
典型文件：
scripts/validate_model_library.py
scripts/check_card_contract.py
scripts/check_model_card_sync.py
scripts/rebuild_indexes.py
reports/validation_report.md
reports/index_rebuild_report.md
reports/model_card_sync_report_v0.2.md
validation 不能证明模型内容正确，但能防止基础结构烂掉。
4.8 Review bundle 层
用途：每轮把 Codex 工作打包给 CCRA / GPT 审核，避免上传几十个散文件。
典型文件：
ccra_review_bundle/round-XX_YYYY-MM-DD_topic/
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
BUNDLE_FILE_MANIFEST.md
optional_raw_changed_files.zip
review bundle 是交接层，不是长期核心资产。
4.9 临时与缓存层
用途：本地运行时产生，通常不应长期保留。
典型文件：
__pycache__/
临时 command log
临时 changed files manifest
旧版 review reports
这些文件会造成“项目看起来变大”，但不等于产品资产变大。后续需要清理和归档。
5. Canonical 内容和过程文件要分开
为了避免“1100 个文件都像资产”的混乱，需要把文件分成四类。
| 类型 | 是否长期保留 | 例子 | 作用 |
|---|---|---|---|
| Canonical source of truth | 是 | models/*.model.json, cards/*.md, sources/*.json, tests/*.regression.json |
模型本体、来源、测试 |
| Stable governance docs | 是 | docs/DATA_CONTRACT.md, knowledge_assets/*质量门* |
长期规则 |
| Generated / derived artifacts | 可重建 | index、validation report、sync report | 检查和导航 |
| Round / temporary artifacts | 阶段归档 | review bundle、command log、diff report | 交接和审核证据 |
判断标准：
回答“以后一直怎么做”的文档，可以进入知识库。
回答“这轮做了什么、改了什么、哪些 PASS/FAIL”的文档，应该留在 review bundle 或 reports，不应混入长期知识库。
6. Selector 到底在做什么
Selector 可以理解成：
模型库的入口调度器和误召回防火墙。
它不负责回答问题。
它负责判断：
- 这个输入是否需要模型加工；
- 如果需要，优先调用哪些模型；
- 哪些模型应该被拒绝；
- 拒绝理由是什么；
- 是否命中 no-call；
- 每个模型的分数、触发信号、惩罚项是什么。
当前 selector 仍然是 rule-based，不是 LLM selector。
这意味着它不是“AI 自由判断”，而是根据显式规则工作：
输入
-> 检查 hard no-call
-> 检查 explicit analysis override
-> 检查模型触发词
-> 检查复杂度信号
-> 检查模型特定 gate
-> 计算 score
-> 输出 selected / rejected models
6.1 为什么不用 LLM selector
因为现在最重要的不是聪明，而是可审计。
LLM selector 可能看起来更灵活，但会带来问题：
- 为什么选这个模型说不清；
- 为什么没选另一个模型说不清；
- 修改后是否破坏边界不好测；
- 容易把所有复杂问题都交给重型模型；
- 不利于 Codex 本地测试和回归。
当前阶段，规则 selector 更笨，但更可控。
6.2 Selector 的核心价值
Selector 保护三件事：
第一，防止不该调用时调用。
例如明确事实查询、轻量改写、直接执行任务，不应该启动 QPI 或思想考古。
第二，防止重型模型过早进入。
思想考古学不应仅因出现“底层”“模型”“哲学”等词就被召回。问题定义未完成时，应先经过 QPI。
第三，让模型组合可解释。
未来不是一个模型回答所有问题，而是若干模型按流程协作。selector 是模型协作前的交通规则。
7. Regression 到底在做什么
Regression 在这里不是传统意义上的“代码单元测试”那么简单。
它是模型边界保护机制。
它要回答：
- 该调用模型时是否调用；
- 不该调用模型时是否拒绝；
- Q / P / I / mixed / no-call 是否被误判；
- 混合型输入是否暴露证据缺口；
- 是否出现暴力降维；
- 是否出现恶意升维；
- 是否把轻量问题过度重型化；
- 是否把深度模型误召回；
- 修改 selector 后，过去关键边界是否被破坏。
Regression case 不是普通例子，而是“防止系统退化的钉子”。
7.1 Regression 应覆盖什么
至少覆盖：
positive 正向调用
boundary 边界情况
misuse 常见误用
no_call 不应调用
selector_gate selector 调用门
pipeline 模型间流程关系
7.2 为什么需要很多 regression
因为你的模型不是单一分类器，而是一套认知判断机制。
一个模型可能在定义上很清楚，但一进入真实语境，就会遇到：
- 主体不同；
- 责任位置不同；
- 时间尺度不同；
- 证据不足；
- 稀缺物混合；
- 局部问题和系统问题交叉；
- 执行任务伪装成分析任务；
- 复杂任务伪装成润色任务。
这些都需要通过 regression case 固化下来。
8. Digest、Calibration、Regression 三者有什么区别
以 QPI 为例，Owner 提供了人工素材，Codex 做了 .cases.md、digest、calibration、regression 的分层处理。
这四层不要混淆。
8.1 .cases.md
这是人读的案例审阅稿。
作用：
- 保留原始案例；
- 保留 Owner / GPT 审查判断；
- 保留人能看懂的推理；
- 便于后续人工复核。
8.2 Case digest
这是压缩后的结构化案例摘要。
作用：
- 让案例变得可检索、可审计；
- 保留核心分类、主导稀缺、误用风险、边界说明；
- 作为 selector / regression 的候选素材池。
Digest 不是最终测试，它是案例资产层。
8.3 Calibration input
这是给 selector 调参和校准用的输入。
作用：
- 告诉 selector 哪些输入应该选 QPI；
- 哪些输入应该 no-call；
- 哪些输入应该低优先级；
- 哪些输入需要先 QPI 再进入思想考古；
- 哪些输入容易误召回。
Calibration 是“调方向”。
8.4 Regression case
这是高价值边界测试。
作用：
- 以后每次改规则时都要检查；
- 防止关键边界被破坏；
- 不要求覆盖所有案例；
- 只保留最容易出错、最值得保护的判断。
Regression 是“守底线”。
9. QPI 未来会怎么用起来
QPI 不是最终答案模型，而是入口路由模型。
它处理的不是“怎么解决问题”，而是：
当前输入到底是什么性质的问题？
QPI 的运行方式大致是：
用户输入
-> selector 判断是否需要 QPI
-> QPI 分析主体、场景、责任范围、期望—现实落差
-> 判断主导稀缺物
-> 输出 Q / P / I / mixed / no-call
-> 给出证据缺口、误分类风险、下一步模型候选
-> 进入后续模型或直接行动
9.1 QPI 的五种结果
| QPI 输出 | 含义 | 系统下一步 |
|---|---|---|
| Question | 数据不足 | 搜索、查证、补信息 |
| Problem | 路径、方法或资源不足 | 做方案、流程、SOP、资源约束分析 |
| Issue | 共识、秩序、确定性或治理结构不足 | 做多视角分析、动态权衡、思想考古或冲突处理 |
| mixed | 多类稀缺同时存在 | 拆分问题，分别路由 |
| no-call | 不需要问题定性 | 直接执行、改写、翻译、查事实、整理格式 |
9.2 QPI 的典型价值
QPI 防止两种常见错误：
第一，把 Issue 当 Problem。
例如一个组织信任、授权、共识和责任结构的问题，如果被当成“写个方案”处理，就会产生漂亮但无效的执行垃圾。
第二，把 Question / 轻量 Problem 当 Issue。
例如用户只是想查一个事实、改写一段话、整理表格，却启动深度模型，会造成认知重工业化。
9.3 QPI 不是解决方案
QPI 不应该直接输出组织、人事、法律、财务、运营解决方案。
它最多回答：
- 这是什么类型的问题；
- 为什么这样分类；
- 证据是否足够；
- 误判风险是什么；
- 下一步应该进入哪类处理。
10. 思想考古学未来会怎么用起来
思想考古学不是默认分析流程，而是深度建模模型。
它适合在这些情况下使用：
- 问题表层现象很多，但底层假设不清；
- 需要识别一个概念、模型或判断背后的深层机制；
- QPI 已经判断这是中重型 Problem / Issue；
- 继续下潜会改变判断、路径、验证方式或行动边界。
思想考古学不适合：
- 明确事实查询；
- 低风险轻量改写；
- 用户只需要直接执行；
- 材料不足，无法区分真实假设和空泛哲学化表达。
它的关键原则是：
最小充分下潜。
如果继续下潜不再改变判断、路径、验证方式或行动边界，就应停止。
所以未来系统不是“QPI 一调用就自动思想考古”，而是：
QPI 先判断问题性质
-> selector 判断是否满足思想考古 depth gate
-> 思想考古只分析必要层级
-> 达到充分深度就停止
11. 以 QPI 为代表，未来所有模型怎么用起来
每个未来模型都不应只是“一个概念”。
它必须具备七件东西：
11.1 人读解释
让你和协作者知道：
- 这个模型是什么；
- 来源是什么；
- 解决什么核心问题；
- 适合什么场景；
- 不适合什么场景；
- 常见误用是什么。
对应文件：cards/*.md
11.2 机器可读定义
让系统知道：
- model_id；
- model_type；
- pipeline_position；
- selection_priority；
- positive triggers；
- negative triggers；
- structured_output_contract；
- stability_profile；
- regression_status。
对应文件：models/*.model.json
11.3 来源证据
让模型能回到原文或代表文本。
对应文件：
sources/source_articles.json
sources/source_excerpts.json
sources/evidence_coverage.matrix.json
11.4 调用规则
让 selector 知道什么时候调用、什么时候拒绝。
对应文件：
selector/selector_rules.json
selector/selector_examples.json
selector/selector_calibration_inputs.json
11.5 输出契约
让模型每次输出结构稳定。
例如：
QPI 必须输出 classification、confidence、evidence_gap、misclassification_risk、next_model_candidates。
思想考古必须输出 should_call、recommended_max_depth、layers_to_analyze、stop_reason、validation_needed。
11.6 回归案例
让模型改动后仍能守住边界。
对应文件：
tests/*.regression.json
tests/regression_cases.json
11.7 审核与版本状态
让人知道当前模型能不能进入更正式调用。
状态包括：
draft / B / pending
draft-callable
stable
deprecated
needs_rework
当前 QPI 和思想考古只允许称为 draft-callable，不能称为 stable。
12. 未来运行时的完整调用流程
未来真正用起来时，系统可能按下面方式运行。
1. 用户输入一个问题 / 话题 / 文本 / 任务
2. 输入预处理
- 识别语言
- 判断是否是直接执行任务
- 判断是否需要认知加工
- 抽取显性任务目标
3. Selector 路由
- 先检查 hard no-call
- 再检查 explicit analysis override
- 再根据模型触发条件打分
- 输出 selected / rejected models、分数和理由
4. 前置模型
- 常见情况下先调用 QPI
- QPI 判断 Q / P / I / mixed / no-call
- 输出下一步模型候选
5. 深度或专项模型
- 如果是中重型 Problem / Issue，可能进入思想考古
- 如果未来有其他模型，会按 pipeline_position 接入
- 不满足 gate 的模型不得调用
6. 多模型结果汇总
- 比较不同模型的输出
- 标记冲突
- 标记证据缺口
- 标记适用边界
- 形成综合判断
7. 输出给用户
- 不只是答案
- 包含判断路径、模型调用理由、边界、下一步动作
8. 记录反馈
- 用户纠正分类或边界
- 重要反馈进入 calibration 或 regression
- 模型卡和 selector 规则迭代
这就是模型库从“静态资产”走向“运行时系统”的路径。
13. 一个示例：输入如何被处理
假设用户输入：
现代人为什么一边渴望连接，一边渴望逃离连接？
系统不应该直接调用所有模型。
更合理的路径是：
Selector:
- 不是事实查询；
- 不是轻量改写；
- 是认知分析输入；
- 需要前置定性；
- 选择 QPI；
- 暂不直接选择思想考古，除非需要深层假设分析。
QPI:
- problem_owner: 现代个体 / 平台社会中的连接主体
- expectation_reality_gap: 渴望亲密连接，但真实连接带来消耗、暴露和控制感下降
- classification: mixed 或 issue
- evidence_gap: 需要区分心理机制、平台机制、社会结构机制
- next_model_candidates: 思想考古学 / 其他未来关系模型 / 信息论棱镜
思想考古学:
- 如果继续分析，需要下潜到“连接为何既是资源又是风险”
- 不必默认七层全开
- 到能改变判断和表达边界的层级就停止
综合输出:
- 连接不是单纯需求，而是暴露、责任、反馈、身份协商和控制权再分配的复合场
- 现代人的矛盾不是“既想要又不想要”，而是“想要低成本确认，又害怕高成本互相塑形”
这只是示例。重点是：模型不是一起上，而是被有条件调用。
14. 为什么当前投入看起来很重
你看到的“重”，来自四个原因。
14.1 从文章到模型，本来就有一次编译成本
你的文章里已经有模型，但它们是以叙事、论证、隐喻、案例、传播表达的形式存在。
系统不能直接调用“文章中的感觉”。
必须把它们编译为：
定义
边界
输入
输出
调用条件
拒绝条件
误用风险
测试样例
来源证据
这一步 token 成本高，但属于一次性基础设施成本。
14.2 早期在修“治理框架”，不是只修 QPI
第一阶段做的不只是 QPI 内容，而是同时建立：
- 文件结构；
- schema；
- validator；
- selector；
- regression；
- review bundle；
- 质量门；
- Codex / CCRA 交接协议。
这些都是未来模型复用的框架。
如果后面第 3、4、5 个模型进入，成本不应按同样比例增长。
14.3 QPI 被选作压力测试样板
QPI 看起来简单，但实际上很适合测试模型库机制，因为它涉及：
- 什么时候调用；
- 什么时候不调用；
- 如何区分 Q / P / I / mixed；
- 如何防止过度升维；
- 如何防止暴力降维；
- 如何处理主体、场景、责任位置；
- 如何给后续模型路由。
如果 QPI 都治理不好，后面的模型更容易变成“概念堆叠”。
14.4 Review bundle 和过程文件放大了文件数量
当前文件数包含大量审核、交接、报告、命令日志、缓存和中间产物。
这些不是未来产品运行时全部需要加载的文件。
未来需要区分：
runtime required
development required
review archive
temporary deletable
15. 当前真正的问题不是“文件太多”，而是“文件身份需要更清楚”
1.67M 并不大。真正的风险是：
你作为 Owner 看到上千文件时，不知道哪些是核心资产、哪些是过程证据、哪些可以删、哪些将来会被运行时使用。
因此下一步需要补的不是新模型，而是文件身份治理：
canonical/
models/
cards/
sources/
tests/
runtime/
selector/
schemas/
docs/
governance/
decisions/
reports/
round-archives/
tmp_or_generated/
validation reports
caches
不一定真的要立刻改目录，但文档上必须先规定清楚。
16. 我们现在应该如何解释这个项目
可以这样对外部协作者解释：
这是一个 file-first 的认知模型库 MVP。它的目标不是存储文章，而是把作者文章中的核心认知模型整理成可读、可追溯、可调用、可测试、可路由的软件资产。QPI 和思想考古学是第一批样板模型。QPI 负责前置问题定性和路由，思想考古学负责中重型问题的深度建模。selector 负责判断何时调用模型、何时拒绝调用；regression 负责保护模型边界，防止以后修改规则时破坏关键判断。当前阶段不做前端、后端、数据库、RAG、知识图谱、商业平台或完整问答系统。
17. 给 Owner 的读法
你不需要理解每个文件。
你只需要抓住五件事：
17.1 文章是原矿，模型卡是部件，selector 是调度，regression 是质检
文章 / 素材 = 原矿
source excerpts = 证据切片
Markdown card = 人读说明书
JSON model card = 机器说明书
selector = 入口调度器
regression = 质检夹具
validation = 工程一致性检查
review bundle = 交接包
17.2 QPI 不是答案模型，而是分诊台
QPI 负责判断问题性质。
它不负责把组织问题、法律问题、人事问题、财务问题直接解决掉。
17.3 思想考古不是默认深挖，而是有门槛的深度模型
它不能因为一个问题“看起来深”就被召回。
它必须通过 depth gate。
17.4 现在文件多，是因为在建模型资产的生产线
后续如果治理得当，新模型进入时应该复用这条生产线，而不是每次重新炸出一堆临时文件。
17.5 你真正要审的是边界，不是格式
你最应该关注的问题是：
- 这个模型有没有把你的本意扭曲；
- 哪些场景不该调用；
- 哪些例子会误判；
- 哪些分类你不同意；
- 哪些输出字段会让系统误导用户；
- 哪些模型关系需要调整。
18. 给 Codex 的运作原则
后续 Codex 应遵守：
- 不把 GPT 规划直接当本地规则，必须先本地化为 schema、workflow、validator、index。
- 不把文章摘要当模型抽取。
- 不把模型卡完整当成模型稳定。
- 不把 selector demo pass 当成内容稳定。
- 不把 validation pass 当成 Owner 审核通过。
- 不因为素材增多就无限扩展 regression。
- 不把 calibration 全部升级成 regression。
- 不新增模型来解决当前模型边界没稳定的问题。
- 每个新增文件必须说明身份：canonical / generated / report / temporary。
- 每轮交接必须用 review bundle，不要让 Owner / CCRA 面对散乱文件。
19. 下一步建议
下一步不应进入新模型，也不应做平台化。
建议做一个 Round 03.1 数据治理与 selector 修补小回合：
19.1 修 selector 安全门
修复 QPI 可能被默认过度选择的问题。
要求 QPI 不能只靠 base_score + selection_priority 被选中，必须有正向信号或明确分析任务。
19.2 建立 calibration smoke test
用 selector_calibration_inputs.json 检查：
- expected no-call 的输入不能选 QPI；
- expected select_qpi 的输入必须选 QPI；
- expected IA 的输入必须满足 depth gate。
19.3 增加文件身份说明
新增一个文档：
docs/FILE_TAXONOMY.md
内容包括：
- canonical files；
- generated files；
- review archive；
- temporary files；
- 可以删除 / 不应删除的文件；
- release 前清理规则。
19.4 清理临时文件
至少排除或删除：
__pycache__/
重复 README
旧版临时报表
扁平化 zip 中的路径碰撞
19.5 把本文档入库
建议将本文档放入：
knowledge_assets/09_数据治理与模型调用机制说明.md
原因是它回答的是“以后一直怎么做”，不是某一轮的临时 PASS/FAIL。
20. 结论
我们现在做的不是“用几千万 tokens 处理十万字材料”。
更准确地说，我们在做：
把一套以文章形式存在的个人认知模型，转化为可被 AI 软件稳定调用的模型资产库；同时建立调用门、拒绝门、输出契约、边界测试和人机交接机制。
QPI 是第一个压力测试样板。
思想考古学是第二个深度模型样板。
selector 是模型调用的守门员。
regression 是模型边界的质检夹具。
model card 是人和机器之间的共同契约。
source / evidence 是模型不漂移的锚点。
review bundle 是 Codex、CCRA、Owner 之间的交接机制。
如果这套机制跑通，未来你的 8-10 个核心模型就不是一组文章概念，而是一套可组合、可回归、可调度、可产品化的认知加工系统。