# 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。我们到底在做什么？ 一句话回答： > 我们不是在把文章“存进知识库”，而是在把文章里隐含的认知模型，治理成可追溯、可审查、可调用、可拒绝调用、可回归测试、可交给运行时系统使用的软件资产。 这和普通知识库的差异很大。 普通知识库关心的是： “这段内容在哪里？能不能搜出来？” 认知模型库关心的是： “这个模型什么时候应该被调用？什么时候绝对不该被调用？输入是什么？输出必须包含什么？判断错了会造成什么误用？下次改模型时，怎么知道没有把边界改坏？” 所以，项目文件数量增加，不是因为原文内容很多，而是因为我们在给模型补上“软件化外壳”： ```text 原始文章 -> 来源记录 -> 证据片段 -> 人读模型卡 -> 机器可读模型卡 -> 输出契约 -> 调用规则 -> 负向触发条件 -> selector -> calibration input -> regression cases -> validation scripts -> review bundle -> CCRA / Owner 审核意见 ``` 这些文件不是平行内容，而是不同治理层。 --- ## 1. 当前项目到底是什么 当前仓库 `the-mindscape-of-bro-tsong` 处在 `model_library_mvp` 阶段。 它不是完整产品、不是聊天机器人、不是前端平台、不是 RAG 系统、不是知识图谱，也不是商业交付系统。 它当前要验证的是： > 少量核心认知模型能否被整理成 file-first 的模型资产，并具备可读、可追溯、可调用、可测试、可路由的最低能力。 第一批样板模型是： 1. **QPI**：前置问题定性和路由模型。 2. **思想考古学**：中重型问题的深度建模模型。 这里的重点不是 QPI 本身，而是： **以 QPI 为样板，证明你的自有模型未来可以按同一种治理机制进入软件系统。** --- ## 2. 为什么不是直接把文章喂给 AI 如果只是“让 AI 读文章然后回答问题”，那确实不需要这么多文件。 但那种做法有几个问题： 1. **不可追溯**：系统用了哪篇文章、哪段原文、哪条人工判断，很难回查。 2. **不可稳定调用**：同一个问题，下次可能调用不同模型、输出不同结构。 3. **不可拒绝调用**：模型容易被滥用，例如所有复杂问题都强行套 QPI 或思想考古。 4. **不可回归**：改一条规则后，无法知道以前的边界案例是否被破坏。 5. **不可交接 Codex**：Codex 不能只拿一篇文章就知道如何构建 selector、schema、validator、测试和模型卡。 6. **不可产品化**：文章是内容资产，模型库需要的是可组合、可运行、可验证的认知工具资产。 所以这轮工作的本质不是“扩写内容”，而是“把隐性认知风格显性化，把显性模型工程化”。 --- ## 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 和思想考古仍然是： ```text status: draft stability_level: B regression_status: pending ``` 这不是失败，而是正确的质量门状态。 --- ## 4. 为什么会有这么多文件 现在看到的文件大致分成九类。 ### 4.1 原始与来源层 用途：回答“模型从哪里来”。 典型文件： ```text sources/source_articles.json sources/source_excerpts.json sources/evidence_coverage.matrix.json ``` 它们不是正文内容的重复，而是来源索引和证据定位。 ### 4.2 人读模型层 用途：让 Owner、CCRA、未来协作者能读懂模型。 典型文件： ```text cards/qpi.md cards/intellectual_archaeology.md cards/card_index.md ``` Markdown card 是人审界面。 ### 4.3 机器模型层 用途：让 selector、validator、未来运行时能读取模型。 典型文件： ```text models/qpi.model.json models/intellectual_archaeology.model.json models/model_index.json ``` JSON model card 是机器调用界面。 ### 4.4 契约与规则层 用途：约束模型卡、输出字段、数据结构和调用规则。 典型文件： ```text 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 层 用途：决定当前输入该调用哪些模型，以及不该调用哪些模型。 典型文件： ```text 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 层 用途：保护模型边界，避免以后修改规则时把模型改坏。 典型文件： ```text tests/qpi.regression.json tests/regression_cases.json tests/test_validate_model_library.py ``` regression 不是普通内容样例，而是“以后不能忘的边界条件”。 ### 4.7 Validation 层 用途：机械检查文件是否一致、字段是否完整、index 是否漂移、模型卡是否同步。 典型文件： ```text 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 审核，避免上传几十个散文件。 典型文件： ```text 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 临时与缓存层 用途：本地运行时产生，通常不应长期保留。 典型文件： ```text __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 | 交接和审核证据 | 判断标准： ```text 回答“以后一直怎么做”的文档，可以进入知识库。 回答“这轮做了什么、改了什么、哪些 PASS/FAIL”的文档，应该留在 review bundle 或 reports，不应混入长期知识库。 ``` --- ## 6. Selector 到底在做什么 Selector 可以理解成： > 模型库的入口调度器和误召回防火墙。 它不负责回答问题。 它负责判断： 1. 这个输入是否需要模型加工； 2. 如果需要，优先调用哪些模型； 3. 哪些模型应该被拒绝； 4. 拒绝理由是什么； 5. 是否命中 no-call； 6. 每个模型的分数、触发信号、惩罚项是什么。 当前 selector 仍然是 rule-based，不是 LLM selector。 这意味着它不是“AI 自由判断”，而是根据显式规则工作： ```text 输入 -> 检查 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 应覆盖什么 至少覆盖： ```text 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 的运行方式大致是： ```text 用户输入 -> 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； - 继续下潜会改变判断、路径、验证方式或行动边界。 思想考古学不适合： - 明确事实查询； - 低风险轻量改写； - 用户只需要直接执行； - 材料不足，无法区分真实假设和空泛哲学化表达。 它的关键原则是： ```text 最小充分下潜。 如果继续下潜不再改变判断、路径、验证方式或行动边界，就应停止。 ``` 所以未来系统不是“QPI 一调用就自动思想考古”，而是： ```text 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 来源证据 让模型能回到原文或代表文本。 对应文件： ```text sources/source_articles.json sources/source_excerpts.json sources/evidence_coverage.matrix.json ``` ### 11.4 调用规则 让 selector 知道什么时候调用、什么时候拒绝。 对应文件： ```text selector/selector_rules.json selector/selector_examples.json selector/selector_calibration_inputs.json ``` ### 11.5 输出契约 让模型每次输出结构稳定。 例如： ```text QPI 必须输出 classification、confidence、evidence_gap、misclassification_risk、next_model_candidates。 思想考古必须输出 should_call、recommended_max_depth、layers_to_analyze、stop_reason、validation_needed。 ``` ### 11.6 回归案例 让模型改动后仍能守住边界。 对应文件： ```text tests/*.regression.json tests/regression_cases.json ``` ### 11.7 审核与版本状态 让人知道当前模型能不能进入更正式调用。 状态包括： ```text draft / B / pending draft-callable stable deprecated needs_rework ``` 当前 QPI 和思想考古只允许称为 `draft-callable`，不能称为 stable。 --- ## 12. 未来运行时的完整调用流程 未来真正用起来时，系统可能按下面方式运行。 ```text 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. 一个示例：输入如何被处理 假设用户输入： ```text 现代人为什么一边渴望连接，一边渴望逃离连接？ ``` 系统不应该直接调用所有模型。 更合理的路径是： ```text Selector: - 不是事实查询； - 不是轻量改写； - 是认知分析输入； - 需要前置定性； - 选择 QPI； - 暂不直接选择思想考古，除非需要深层假设分析。 QPI: - problem_owner: 现代个体 / 平台社会中的连接主体 - expectation_reality_gap: 渴望亲密连接，但真实连接带来消耗、暴露和控制感下降 - classification: mixed 或 issue - evidence_gap: 需要区分心理机制、平台机制、社会结构机制 - next_model_candidates: 思想考古学 / 其他未来关系模型 / 信息论棱镜 思想考古学: - 如果继续分析，需要下潜到“连接为何既是资源又是风险” - 不必默认七层全开 - 到能改变判断和表达边界的层级就停止 综合输出: - 连接不是单纯需求，而是暴露、责任、反馈、身份协商和控制权再分配的复合场 - 现代人的矛盾不是“既想要又不想要”，而是“想要低成本确认，又害怕高成本互相塑形” ``` 这只是示例。重点是：模型不是一起上，而是被有条件调用。 --- ## 14. 为什么当前投入看起来很重 你看到的“重”，来自四个原因。 ### 14.1 从文章到模型，本来就有一次编译成本 你的文章里已经有模型，但它们是以叙事、论证、隐喻、案例、传播表达的形式存在。 系统不能直接调用“文章中的感觉”。 必须把它们编译为： ```text 定义 边界 输入 输出 调用条件 拒绝条件 误用风险 测试样例 来源证据 ``` 这一步 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 和过程文件放大了文件数量 当前文件数包含大量审核、交接、报告、命令日志、缓存和中间产物。 这些不是未来产品运行时全部需要加载的文件。 未来需要区分： ```text runtime required development required review archive temporary deletable ``` --- ## 15. 当前真正的问题不是“文件太多”，而是“文件身份需要更清楚” 1.67M 并不大。真正的风险是： **你作为 Owner 看到上千文件时，不知道哪些是核心资产、哪些是过程证据、哪些可以删、哪些将来会被运行时使用。** 因此下一步需要补的不是新模型，而是文件身份治理： ```text 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 是质检 ```text 文章 / 素材 = 原矿 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 应遵守： 1. 不把 GPT 规划直接当本地规则，必须先本地化为 schema、workflow、validator、index。 2. 不把文章摘要当模型抽取。 3. 不把模型卡完整当成模型稳定。 4. 不把 selector demo pass 当成内容稳定。 5. 不把 validation pass 当成 Owner 审核通过。 6. 不因为素材增多就无限扩展 regression。 7. 不把 calibration 全部升级成 regression。 8. 不新增模型来解决当前模型边界没稳定的问题。 9. 每个新增文件必须说明身份：canonical / generated / report / temporary。 10. 每轮交接必须用 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 增加文件身份说明 新增一个文档： ```text docs/FILE_TAXONOMY.md ``` 内容包括： - canonical files； - generated files； - review archive； - temporary files； - 可以删除 / 不应删除的文件； - release 前清理规则。 ### 19.4 清理临时文件 至少排除或删除： ```text __pycache__/ 重复 README 旧版临时报表 扁平化 zip 中的路径碰撞 ``` ### 19.5 把本文档入库 建议将本文档放入： ```text knowledge_assets/09_数据治理与模型调用机制说明.md ``` 原因是它回答的是“以后一直怎么做”，不是某一轮的临时 PASS/FAIL。 --- ## 20. 结论 我们现在做的不是“用几千万 tokens 处理十万字材料”。 更准确地说，我们在做： > 把一套以文章形式存在的个人认知模型，转化为可被 AI 软件稳定调用的模型资产库；同时建立调用门、拒绝门、输出契约、边界测试和人机交接机制。 QPI 是第一个压力测试样板。 思想考古学是第二个深度模型样板。 selector 是模型调用的守门员。 regression 是模型边界的质检夹具。 model card 是人和机器之间的共同契约。 source / evidence 是模型不漂移的锚点。 review bundle 是 Codex、CCRA、Owner 之间的交接机制。 如果这套机制跑通，未来你的 8-10 个核心模型就不是一组文章概念，而是一套可组合、可回归、可调度、可产品化的认知加工系统。