knowledge-vault/work/internal/强哥的思想宇宙/6天4.7亿Tokens项目复盘事实底稿_2026-06-20.md

# 6天4.7亿 Tokens 项目复盘事实底稿

status: factual_material_draft
date: 2026-06-20
scope: the-mindscape-of-bro-tsong -> Cognitive-OS-Wantsong
purpose: 为后续文章写作提供事实素材，不作为最终评论稿

## 0. 使用说明

这份文档记录的是一次项目建造、治理、质疑、重启、再质疑的事实链。

它不是为了证明某个参与者“有错”，而是为了把这 6 天里发生的事情还原成可写作、可引用、可反思的素材。

其中：

- “4.7 亿 Tokens”是 Owner 在本轮对话中给出的成本口径；本文件没有独立读取 API 账单或 token 计量系统。
- “6 天”按项目从 2026-06-15 / 2026-06-16 启动，到 2026-06-20 发现新项目模型质量问题计算。
- “旧项目”指 `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`。
- “新项目”指 `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong`。
- “Web CCRA”指在 ChatGPT/Web 侧提供架构、审核、计划和验收意见的 CCRA。
- “Local CCRA”指本地 Codex/Agent 侧更贴近文件系统的审核机制。

## 1. 一句话事实结论

这次项目没有失败在“没有搭出工程结构”，而是失败在把目标从“复现并运行 Wantsong 的认知模型”偏移成了“治理 QPI / 思想考古作为 file-first 模型资产是否可追溯、可校验、可路由、可拒绝调用”。

结果是：工程结构、schema、selector、regression、review bundle、Local CCRA 流程都被做重了；但真正应该先固定的模型能力本身没有被做扎实。新项目试图继承旧项目遗产时，这个问题再次暴露：当前 `qpi.md` 和 `intellectual-archaeology.md` 仍然只是模型卡/调用契约，不是可稳定复现黄金样例的操作模型。

## 2. 事实来源

### 2.1 旧项目工程与复盘材料

- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\reports\当前项目失败总结与重启依据_2026-06-19.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\reports\cognitive-OS-wantsong_新项目立项计划稿_2026-06-19.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\docs\DECISIONS.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\reports\Round04_blind_routing_evaluation_report_2026-06-18.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\reports\Round05_1_web_ccra_acceptance_2026-06-19.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\reports\round06_1_post_patch\01_ROUND06_1_POST_PATCH_CLOSEOUT.md`

### 2.2 知识库里的计划、质疑和黄金样例

- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\作废的一轮\GPT成果\2026-06-16-给 Codex 的项目初始化说明 v0.1.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\作废的一轮\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\作废的一轮\GPT成果\CCRA_数据治理与模型调用机制说明_v0.1.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\作废的一轮\质疑\对当前QPI治理流程的质疑.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\Cognitive-OS-Wantsong项目总计划 v0.1.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\人类通用认知的七层架构-思想考古报告.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\人类通用认知的七层架构-思想考古过程.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\ccpe\ccpe\强哥的虎贲卫\房玄龄\房玄龄2.0.md`

### 2.3 新项目当前材料

- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\README.md`
- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\docs\PROJECT_BRIEF.md`
- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\docs\MODEL_MANAGEMENT_V0.md`
- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\docs\PROMPT_AUTHORITY_BOUNDARY.md`
- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\models\qpi.md`
- `C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\models\intellectual-archaeology.md`

## 3. 最初想做什么

Owner 最初想做的不是一个普通知识库，也不是一个只存文章的资料夹，而是把自己的认知模型做成能被 AI 调用、组合、运行的系统。

最初的核心设想包括：

1. 把 Wantsong 已经形成的认知模型沉淀成核心模型库。
2. MVP 阶段大约放 8-10 个核心模型，而不是一上来扩展到 100 个。
3. 第一批样板模型选用 QPI 和思想考古。
4. QPI 的定位是轻量问题定性和路由，不是最终产品。
5. 思想考古的定位是深度认知加工，是应当真正跑出成果的主引擎之一。
6. 项目的关键验证不是“模型文件是否能被治理”，而是“AI 是否能像 Wantsong 一样使用这些模型处理真实复杂输入”。

已有的黄金样例说明 Owner 不是从零开始：

- 思想考古已有成功报告：`人类通用认知的七层架构-思想考古报告.md`。
- 思想考古还有完整过程记录：`人类通用认知的七层架构-思想考古过程.md`。
- QPI 已经与 Agent 化角色结合过：`房玄龄2.0.md`。

这些材料本来应该成为模型质量的复现基准，而不是只作为来源引用或样例背景。

## 4. Web CCRA 给出的指导是什么

Web CCRA 的早期指导把项目定义成 file-first 的 `model_library_mvp`。

根据 `2026-06-16-核心模型抽取样板 v0.1.md` 和 `CCRA_数据治理与模型调用机制说明_v0.1.md`，当时的建设方向大致是：

1. 建立目录结构：
   - `docs/`
   - `schemas/`
   - `models/`
   - `cards/`
   - `sources/`
   - `tests/`
   - `selector/`
   - `scripts/`
   - `reports/`

2. 建立 JSON Schema：
   - `model_card.schema.json`
   - `source_article.schema.json`
   - `source_excerpt.schema.json`
   - `regression_case.schema.json`

3. 录入两个样板模型：
   - QPI
   - Intellectual Archaeology / 思想考古

4. 建立来源索引和证据片段索引。

5. 为每个模型建立至少 5 个回归测试用例。

6. 写校验脚本，输出 `reports/validation_report.md`。

7. 建立最小模型选择器 demo：
   - 根据关键词、输入类型、负向触发条件、selection priority 返回候选模型。

8. 做 review bundle，供 Web CCRA / Owner 审核。

CCRA 这一路径的逻辑是：不要直接把文章喂给 AI，而要把隐含认知模型治理成可追溯、可审查、可调用、可拒绝调用、可回归测试、可交给运行时使用的软件资产。

这个指导本身不是荒唐的。问题在于，它把“模型治理能力”放到了第一优先级，而模型本体的可运行质量没有先被锁定。

## 5. Codex 和 CCRA 的配合方式

配合模式大致是：

1. Web CCRA / GPT 侧给出计划、审核意见、下一轮指导。
2. Owner 把这些计划或 review bundle 带回本地。
3. Codex 在本地 repo 中按计划创建文件、写 schema、补文档、跑校验、打 review bundle、写交接文档。
4. Web CCRA 再审本地生成的 bundle 或阶段成果。
5. 出现问题后，继续进入下一轮 patch / calibration / review。

这个模式有一个重要隐患：Codex 很擅长把明确的工程指令执行到底，但如果上游 CCRA 的目标函数偏了，Codex 会把偏移的目标做得越来越完整。

这就是后来发生的事：项目越来越像一个“模型治理与审核流水线”，而不是“认知加工运行时”。

## 6. 旧项目建造过程概览

### 6.1 项目初始化与 file-first 架构

旧项目 `the-mindscape-of-bro-tsong` 建立了 file-first 架构。

关键决策包括：

- 使用 Markdown 存人读模型卡。
- 使用 JSON 存机器可读模型规格。
- 使用 JSON Schema 做校验。
- 不引入数据库、后端、前端、RAG、用户系统。
- `model_library_mvp` 作为阶段名，而不是嵌套目录。
- QPI 和思想考古作为第一批样板模型。
- selector 在 v0.1 中使用规则，不调用 LLM。

这些决策记录在旧项目 `docs/DECISIONS.md` 中，前几条 Decision 明确了：

- file-first architecture；
- JSON for machine-readable model data；
- Markdown for human-readable model cards；
- QPI and Intellectual Archaeology as first sample models；
- Rule-based selector in v0.1。

### 6.2 第一阶段产物：模型卡、模型 JSON、来源、证据、回归

Codex 随后创建或维护了：

- `models/qpi.model.json`
- `models/intellectual_archaeology.model.json`
- `cards/qpi.md`
- `cards/intellectual_archaeology.md`
- `sources/source_articles.json`
- `sources/source_excerpts.json`
- `tests/qpi.regression.json`
- `tests/intellectual_archaeology.regression.json`
- `selector/selector_rules.json`
- `scripts/validate_model_library.py`
- `scripts/run_selector_demo.py`
- `scripts/rebuild_indexes.py`

同时建立了多个报告：

- `reports/validation_report.md`
- `reports/content_review_report.md`
- `reports/evidence_coverage_report_v0.2.md`
- `reports/model_card_sync_report_v0.2.md`

这一阶段的主要成功是：工程结构开始能跑，引用关系开始能被校验，模型卡和机器数据开始同步。

这一阶段的主要偏差是：模型质量开始被“字段是否存在、source_id 是否匹配、schema 是否通过”替代。

### 6.3 第二阶段：内容稳定化与 review bundle 化

项目随后进入内容稳定化：

- 补证据覆盖；
- 修模型卡字段；
- 做 CCRA review bundle；
- 压缩上传包；
- 写 manifest；
- 记录 command log。

这一步加强了可审查性，也让项目文件数量迅速增加。

这里的关键变化是：review bundle 开始成为项目的重要产物。文件系统里出现多轮 `ccra_review_bundle/round-*`，每轮包含：

- review brief；
- patch matrix；
- current asset pack；
- validation and command log；
- review questions；
- raw changed file zip；
- bundle manifest。

这些产物对 review 有用，但它们不是认知加工产品本身。

### 6.4 第三阶段：QPI 合约硬化与案例预处理

之后项目重心转向 QPI。

本地文件与记忆记录显示，这一阶段做了：

- `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
- `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md`
- `selector/selector_calibration_inputs.json`
- `selector/qpi_case_digests.json`
- `docs/model_case_preprocessing/qpi/CASE_PREPROCESSING_WORKFLOW.md`
- `reports/model_case_preprocessing/qpi/round-01/*`
- QPI owner-reviewed subset 的 promotion；
- QPI regression 扩展；
- selector calibration。

这一步把 QPI 从一个轻量前置定性器，推向了主治理对象。

Owner 后来明确指出：QPI 在实际认知系统中只是轻量模型，只做路由和挖掘深度判断；如果误用，主要损失是 token 和延迟，不应把它当成高风险核心系统反复治理。

### 6.5 第四阶段：多轮 selector patch 和 review bundle

旧项目随后围绕 selector 进入多轮 patch：

- Round 03：contract hardening / selector calibration。
- Round 03.1：selector no-call regression patch。
- Round 03.2：selector negative gate patch。
- Round 03.2a：depth-limiting / QPI override patch。
- Round 04：blind input routing evaluation。
- Round 04.1：selector-rule patch。

其中 Round 04 明确是盲测路由评估。`Round04_blind_routing_evaluation_report_2026-06-18.md` 中反复说明：

- selector 是 rule-based；
- no LLM；
- no vector search；
- no answer generation；
- 只做模型选择与拒绝。

这非常关键：到 Round 04，项目已经大量验证“给输入时 selector 选 QPI、选 IA、拒绝调用、no-call 是否正确”，但仍没有验证“模型被调用后能否生成高质量思想考古或 QPI Agent 输出”。

### 6.6 Local CCRA 进入系统

之后 Local CCRA 被引入，用于本地更完整地审查文件。

这部分产生了：

- `local_ccra_reviews/`
- `prompt-to-send.md`
- `agent-invocation-packet.md`
- `review-context.md`
- `review-file-manifest.json`
- `helper-outputs/`
- `04_LOCAL_CCRA_REVIEW_REPORT.md`
- `returned-output.md`
- `owner-decision.md`

Local CCRA 解决了一个真实问题：Web CCRA 看不到完整本地文件，本地 reviewer 可以更准确地审查 repo。

但它也加重了系统复杂度。Local CCRA 本身又带来了运行协议、helper output、gate manifest、lifecycle scan、bundle audit、routing diff 等新产物。

### 6.7 Round 05.1 和 Round 06.1：工程上越来越“正确”

Round 05.1 被 Web CCRA 接受为 scoped selector calibration patch。

`Round05_1_web_ccra_acceptance_2026-06-19.md` 记录：

- Web CCRA accepted Round 05.1 as a scoped selector calibration patch。
- No Round 05.1a selector repair is required。
- QPI 和 Intellectual Archaeology 不因此获得 lifecycle promotion。

Round 06.1 是 scoped selector-support patch。

`01_ROUND06_1_POST_PATCH_CLOSEOUT.md` 记录：

- 目标是 structured `qpi_context_provided` selector support；
- 支持 prior QPI handoff；
- 支持 direct IA exception；
- 支持 deterministic before / after selector behavior diff；
- 明确不做 third model；
- 不做 QPI lifecycle promotion；
- 不做 IA lifecycle promotion；
- 不做 LLM selector；
- 不改 model card；
- 不改 model spec。

Round 06.1 的 validation 很完整：

- focused tests PASS；
- full unit tests PASS；
- rebuild indexes PASS；
- validate model library PASS；
- selector regression PASS；
- model/card sync PASS；
- routing behavior diff PASS；
- lifecycle guard scan PASS。

事实上的吊诡点在这里：工程验证越完整，越能说明项目已经变成了“selector / governance / review validation”的工程，而不是“模型认知能力”的工程。

## 7. 第 6.1 轮附近开始质疑

Owner 在 `对当前QPI治理流程的质疑.md` 中集中表达了质疑。

核心事实包括：

1. 当前项目本来只放了 QPI 和思想考古两个模型。
2. QPI 在实际应用中是轻量模型，只做前置路由和挖掘深度判断。
3. 项目却不断围绕 QPI 找边界、扩 selector、扩 regression、做 review bundle。
4. 思想考古几乎没有真正用起来。
5. 项目已经消耗 4-5 亿 tokens 量级，Owner 认为投入已经夸张。
6. 质疑文件中明确区分了两个目标：
   - “如何让 QPI / IA 作为 file-first 模型资产可追溯、可校验、可路由、可拒绝调用。”
   - “AI 能否把 QPI、思想考古和后续其他模型串联起来，像你一样完成认知加工。”
7. Owner 判断：前者是治理系统，后者是产品运行时，这两个目标不是一回事。

这个质疑不是简单抱怨进度慢，而是指出了项目目标函数错位。

## 8. 旧项目的失败机制

旧项目失败机制可以拆成五层。

### 8.1 项目类型漂移

旧项目从“认知模型运行时验证”漂移为“file-first 模型治理样板”。

它证明了：

- 模型可以被写成 JSON / Markdown；
- 来源和证据可以被索引；
- selector 可以被规则驱动；
- 回归用例可以防退化；
- review bundle 可以被打包；
- Local CCRA 可以被本地执行。

但它没有证明：

- AI 能用 QPI 生成房玄龄 2.0 那种认知光学诊断；
- AI 能用思想考古复现七层深度报告；
- QPI + 思想考古能形成一个真实 cognitive workflow；
- 模型输出有足够辨识度，区别于普通 ChatGPT 长文。

### 8.2 QPI 成为主角

QPI 原本应是前置 light-weight routing / misframing diagnostic。

实际项目中，它变成了：

- regression 主体；
- selector calibration 主体；
- review bundle 主体；
- Local CCRA / Web CCRA 审核主体；
- 多轮 patch 主体。

QPI 的误用成本和治理成本不匹配：一个轻量模型误判，通常是多花一点 token 或延迟进入下一步；但项目为它建立了重型治理宇宙。

### 8.3 思想考古被降级成 selector 标签

思想考古在黄金样例中是一种完整的纵向钻探过程。

它包括：

- 初始议题识别；
- 考古地图提出；
- 用户修正方向；
- 地图重构；
- 分层输出；
- 中途吸收 Owner 观点；
- 批判性吸收与路径重构；
- 最后一层前先规划，再由 Owner 确认；
- 输出最终报告；
- 再修标题、摘要和地图。

但在旧项目里，思想考古主要被处理为：

- 一个 model_id；
- 一个 model card；
- 一个 JSON spec；
- 一个 selector 候选；
- 一个 QPI 之后是否调用的 deep model；
- 一个深度 gate 对象。

也就是说，思想考古的“操作过程”没有被充分提炼，只有“调用边界”被治理。

### 8.4 Review artifacts 成为产品

旧项目留下大量 review bundle、validation report、lifecycle scan、routing diff、Local CCRA run record。

这些东西是审核层证据，不是用户会使用的认知加工成果。

当审核证据比模型输出更丰富时，项目已经从产品验证偏向审计系统。

### 8.5 Validation PASS 带来错误安慰

Round 06.1 的工程 validation 非常完整，但它只能证明：

- 文件引用关系没坏；
- selector 行为符合预期；
- 回归没有退化；
- bundle 完整；
- lifecycle 文案没有越权。

它不能证明：

- 模型内容足够好；
- 模型会按黄金过程操作；
- 模型产出有思想密度；
- 模型能在真实输入中产生可用认知加工。

这是本次最重要的技术教训之一：工程 PASS 和产品成功之间没有自动等号。

## 9. 重启新项目

旧项目被建议关闭为：

- asset-seed archive；
- governance lab；
- historical reference；
- anti-pattern reference。

新项目命名为：

`C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong`

重启原则：

1. 不在旧项目里继续修。
2. 不迁移旧 `ccra_review_bundle/`。
3. 不迁移旧 `local_ccra_reviews/` 历史。
4. 不迁移 full selector calibration。
5. 不迁移 full QPI regression suite。
6. 不迁移 Round Conductor。
7. 只把旧项目作为少数资产种子和反面教材。

新项目的核心问题改为：

> 给一个真实复杂输入，系统能否串联 Wantsong 的认知模型，产出有用的内部认知加工结果，并转译成读者能理解的表达？

## 10. 新项目 M0-M1 做了什么

新项目 M0-M1 已经完成基础启动。

当前 `README.md` 显示：

- status: `m0_m1_startup`
- 项目定义为 lightweight, file-first cognitive-processing runtime。
- 目标不是证明模型文件可以被治理，而是验证真实复杂输入能否经过 Wantsong 模型链生成内部分析和读者转译。

M0 做的是边界冻结：

- 旧项目只是 seed/archive/reference；
- 不迁移旧 reports、review bundles、Local CCRA histories、selector calibration、full regression、Round Conductor。

M1 做的是最小模型管理内核：

- `models/qpi.md`
- `models/intellectual-archaeology.md`
- `models/model-registry.json`
- `docs/MODEL_MANAGEMENT_V0.md`
- `docs/MODEL_ORCHESTRATION_V0.md`
- `docs/COGNITIVE_WORKFLOW_V0.md`
- `docs/READER_TRANSLATION_LAYER_V0.md`

新项目比旧项目清醒的一点是：它明确把 QPI 放回 front-routing，把思想考古定位为 first deep-processing engine，把 Local CCRA 限制为 milestone review lane。

## 11. M2a/M2b 时发现的第一个冲突：Prompts 权威边界

Web GPT 的新计划在 M2 中建议直接创建一组 prompts：

- `prompts/intake-value-assessor.md`
- `prompts/qpi-router.md`
- `prompts/lens-orchestrator.md`
- `prompts/intellectual-archaeology-runner.md`
- `prompts/synthesis-engine.md`
- `prompts/calibration-checker.md`

但这和本地工程边界冲突：

- canonical Prompt Cards / Agent Specs / Runtime Specs 应属于 `ccpe-system`。
- deterministic automation 应属于 `skills-vault`。
- 新产品 repo 只应该放 product-local runtime adapters。

因此 M2a 做了边界修正，形成 `docs/PROMPT_AUTHORITY_BOUNDARY.md`。

该文档明确：

- M2 不得直接把 GPT-authored prompt plan 实现为本 repo 的 canonical prompts。
- 如果创建 `prompts/`，只能是 product-local draft adapters。
- 缺 canonical prompt/spec/rubric/protocol 时，写 `requirements/ccpe/` 请求。
- 缺 reusable deterministic automation 时，写 `requirements/skills-vault/` 请求。

这个修正是必要的，但它仍然假设当前 QPI 和思想考古已经是可运行模型。

## 12. M2 继续推进时发现的第二个、更深的冲突：模型质量没有到位

Owner 随后提出更深问题：

1. 当前模型质量很差。
2. 虽然旧项目消耗巨大，但没有产出能复现黄金样例的模型。
3. 当前 `intellectual-archaeology.md` 是否能跑出七层思想考古报告？答案是否定的。
4. 当前 `qpi.md` 是否能打造出房玄龄 2.0 那种 Agent？答案也是否定的。
5. 因此不应该先打造 Agent / Skill，而应该先重新提炼模型本身。

本地对照支持这一判断。

### 12.1 当前思想考古模型缺什么

新项目 `models/intellectual-archaeology.md` 当前包含：

- one-sentence definition；
- runtime role；
- core question；
- seven layer framework；
- minimum sufficient depth；
- call / do-not-call；
- input types；
- output contract；
- common misuses；
- source seed notes；
- current limits。

这些是模型卡要素。

但黄金思想考古报告和过程体现的是操作模型：

- 先把议题作为地表遗迹；
- 先提出考古地图；
- 等 Owner 确认或修正地图；
- 根据 Owner 修正把“软件问题”升格为“人类通用认知问题”；
- 每一层要输出错位、机制、跨领域证据；
- 第 4 层嵌入 QPI 理论；
- 第 6 层嵌入生物机器与系统 1 / 系统 2；
- 第 7 层前暂停，要求对 Owner 补充观点做批判性吸收和路径重构；
- 经 Owner 确认后，再输出最终哲学基岩层；
- 最后对报告标题、摘要、地图进行修缮。

当前模型卡没有把这些交互过程、分层写作规程、证据选择方式、用户修正规则和停止/继续机制表达成可执行操作手册。

### 12.2 当前 QPI 模型缺什么

新项目 `models/qpi.md` 当前包含：

- Q/P/I/mixed/no_call 分类；
- owner / subject / scenario context；
- scarcity profile；
- dynamic stage；
- misclassification risk；
- output contract；
- common misuses；
- depth control。

这些是 QPI 分类器/路由器的契约。

但 `房玄龄2.0.md` 展示的是一个 Agent 化模型：

- 角色身份：认知光学与战略引擎；
- 核心层、执行层、约束层、操作层；
- QPI 光学折射逻辑；
- 光谱扫描；
- 透镜检视；
- 病理筛查；
- 重构策略；
- 报告输出模板；
- 用户反驳时的反事实推演；
- QPI 理论附录；
- 认知主体的情绪、信念、知识分辨率分析。

当前 `qpi.md` 能帮助分类，但不能自然生成房玄龄式的认知诊断 Agent。

因此，当前新项目 M1 的“callable”应被重新理解：它只是“有调用边界的草案”，不是“已能复现模型能力”。

## 13. 这次事件中各角色做了什么

### 13.1 Owner

Owner 提供了：

- 原始认知模型材料；
- QPI 与思想考古的黄金样例；
- Web CCRA 计划与反馈；
- 本地路径和审计材料；
- 对 Round 06.1 后治理偏移的质疑；
- 关闭旧项目、重开新项目的判断；
- 在新项目 M2 时再次发现模型质量问题。

Owner 的关键判断变化：

1. 最初相信通过 CCRA + Codex 可以较快把已有模型工程化。
2. 中途发现项目开始围绕 QPI governance 自转。
3. Round 06.1 后判断旧项目应该关闭或归档。
4. 新项目启动后，进一步发现旧项目并没有真正产出可用模型，只产出模型治理壳。

### 13.2 Web CCRA / GPT

Web CCRA 提供了：

- file-first model library MVP 方向；
- schema / source / evidence / regression / selector / validation / review bundle 规划；
- 多轮 review 和 patch 指导；
- 新项目总计划。

Web CCRA 的问题：

- 它看不到完整本地工程全貌。
- 它倾向于把风险转译成治理、字段、审查、边界、回归。
- 它不了解或没有充分嵌入本地 `ccpe-system` / `skills-vault` 边界。
- 它没有在早期强制要求“模型复现黄金样例”作为质量门。

### 13.3 Codex

Codex 执行了大量本地工程工作：

- 创建目录和文件；
- 写 schema；
- 写模型 JSON 和模型卡；
- 写校验脚本；
- 写 selector；
- 写测试；
- 跑 validation；
- 打 review bundle；
- 写 Local CCRA 运行材料；
- 按 Web CCRA 反馈做 patch；
- 写新项目启动文件。

Codex 的问题不在于没有执行，而在于执行目标被上游计划定义成工程治理目标后，Codex 会把治理目标贯彻到底。

对这次事件而言，Codex 更像高效施工队：图纸如果偏了，它会把偏掉的楼盖得很规整。

### 13.4 Local CCRA

Local CCRA 的价值是真实存在的：

- 它能看本地文件；
- 它比 Web CCRA 更适合审查 repo 实际状态；
- 它适合作为里程碑审计。

但 Local CCRA 也会放大治理倾向：

- 它引入更多审核文件；
- 需要 packet、prompt、context、manifest、helper output；
- 如果每轮都用，会把项目拖回 review universe。

新项目正确地把 Local CCRA 限制成 milestone review lane，而不是 default round factory。

### 13.5 CCPE / skills-vault

新项目 M2a 发现：

- canonical prompt / Agent spec / runtime spec 应进入 `ccpe-system`；
- deterministic automation 应进入 `skills-vault`；
- 产品 repo 不该直接复制 canonical CCPE artifacts。

这个边界判断是对的。

但它不是当前最底层问题。最底层问题是：还没有稳定可复现的模型操作手册。

## 14. 这件事真正买来的教训

### 14.1 “可治理”不等于“可运行”

旧项目证明了模型资产可以被治理：

- 可追溯；
- 可审查；
- 可校验；
- 可路由；
- 可拒绝调用；
- 可回归测试。

但它没有证明模型本身可运行。

### 14.2 “模型卡完整”不等于“模型质量好”

一个模型可以拥有：

- model_id；
- status；
- call_when；
- do_not_call_when；
- output_contract；
- source evidence；
- regression cases；
- selector rules。

但它仍然可能无法产出黄金样例级别的结果。

模型卡是容器，不是模型能力本身。

### 14.3 “工程验证通过”不等于“产品验证通过”

Round 06.1 可以有十几项 PASS，但产品问题仍然没被回答：

> 给一个真实复杂输入，系统能不能产生有辨识度的 Wantsong 式认知加工结果？

### 14.4 轻量模型不应被重型治理压爆

QPI 是路由和定性，不是主引擎。

当一个轻量模型的误用成本只是 token 和延迟时，不应消耗数亿 tokens 做高强度治理。

### 14.5 黄金样例应该先成为模型质量门

如果目标是复现 Wantsong 的认知模型，那么已有黄金样例应当成为第一质量门：

- 当前思想考古模型是否能复现七层报告的结构与过程？
- 当前 QPI 模型是否能支撑房玄龄 2.0 的操作效果？

旧项目没有把这个质量门放在最前面。

### 14.6 继承遗产会继承旧问题

新项目一开始做得比旧项目轻，但它继承了旧项目抽出来的 `qpi.md` 和 `intellectual-archaeology.md`。

如果旧项目没有真正抽出高质量模型，新项目即使边界正确，也会继承低质量模型。

### 14.7 CCPE / skills-vault 边界重要，但不是模型质量的替代品

M2a 对 prompts 权威边界的修正是必要的。

但在模型未稳定前，讨论 prompt 放产品 repo 还是 CCPE，只是第二层问题。

第一层问题是：模型操作手册本身是否足够稳定。

## 15. 文章可用的事实命题

以下命题可以作为文章主线素材。

### 命题 1：我买到的不是一个认知系统，而是一套过度完整的审计系统

事实支撑：

- 旧项目有完整 schema、selector、regression、review bundle、Local CCRA。
- 但没有能复现思想考古黄金报告的模型操作手册。

### 命题 2：系统越正规，越容易掩盖目标偏移

事实支撑：

- Round 06.1 validation chain 全部通过。
- 但这只证明 selector patch 正确，不证明模型能力正确。

### 命题 3：QPI 被治理成主角，是项目偏航的标志

事实支撑：

- QPI 原本是轻量前置模型。
- 项目围绕 QPI 建立多轮 selector、regression、review。
- 思想考古没有成为主要运行产物。

### 命题 4：黄金样例没有被当成验收门，是这次最大的遗漏

事实支撑：

- `人类通用认知的七层架构-思想考古报告.md` 已存在。
- `人类通用认知的七层架构-思想考古过程.md` 已存在。
- `房玄龄2.0.md` 已存在。
- 当前模型文件无法自然复现它们。

### 命题 5：Web CCRA 和 Codex 的协作模式有放大器效应

事实支撑：

- Web CCRA 给治理型计划；
- Codex 高效落地治理型工程；
- 本地文件越多，review 越多，下一轮越需要更多 bundle 和 validation；
- 系统进入自我强化。

### 命题 6：新项目不是旧项目修复，而是对旧项目假设的否定

事实支撑：

- 新项目没有迁移旧 review bundle / local CCRA histories / full regression / selector calibration。
- 但新项目继续推进时又发现模型质量问题，说明旧项目连可继承资产都要重新审查。

## 16. 文章可用的时间线

### 2026-06-15 / 2026-06-16：启动

Web CCRA / GPT 给出 file-first model_library_mvp 计划。Codex 建立旧项目结构。

核心任务是：目录、schema、两个样板模型、来源索引、证据片段、回归测试、校验脚本、selector demo。

### 2026-06-16：模型资产链路成型

QPI 和思想考古被写成模型卡 / JSON spec。来源、证据、校验报告开始出现。

项目看上去进入正轨，但质量重心已经偏向模型结构和可审查性。

### 2026-06-16 / 2026-06-17：内容稳定化与 review bundle

项目开始围绕 evidence coverage、model card sync、review bundle、validation report 运转。

CCRA 审核包成为主要交付物之一。

### 2026-06-17：QPI 治理加深

QPI contextual routing、case preprocessing、owner-reviewed subset、selector calibration、regression promotion 成为主线。

### 2026-06-17 / 2026-06-18：多轮 selector patch

Round 03、03.1、03.2、03.2a 和 Round 04 聚焦 selector no-call、negative gate、depth limiting、blind routing evaluation。

项目越来越关注“什么时候不要调用模型”和“怎么防止误路由”。

### 2026-06-18 / 2026-06-19：Local CCRA 和 Round 05.1 / 06.1

Local CCRA 被引入。Round 05.1 和 06.1 完成 scoped selector patch、validation、Web acceptance / closeout。

工程上越来越成熟，产品上越来越远离“跑出认知成果”。

### 2026-06-19：Owner 开始系统性质疑

Owner 在 `对当前QPI治理流程的质疑.md` 中指出：

- QPI 被过度治理；
- IA 没有真正用起来；
- 花费巨大；
- 目标从产品运行时变成治理系统；
- 下一步应切回认知加工运行时。

### 2026-06-19：旧项目被建议归档，新项目被提出

形成：

- `当前项目失败总结与重启依据_2026-06-19.md`
- `cognitive-OS-wantsong_新项目立项计划稿_2026-06-19.md`

旧项目定位为 archive / asset seed / anti-pattern reference。

### 2026-06-20：新项目 M0-M1 完成

新项目 `Cognitive-OS-Wantsong` 建立边界、模型管理内核、QPI / IA draft callable model cards。

### 2026-06-20：M2a 发现 prompt 权威边界问题

GPT 计划直接搭 prompts，但本地工程判断 canonical prompt / Agent spec 应属于 CCPE，产品 repo 只能放 draft adapters。

形成 `docs/PROMPT_AUTHORITY_BOUNDARY.md` 和 supplier requests。

### 2026-06-20：M2 继续推进时发现模型质量根本问题

Owner 发现：

- 当前 `intellectual-archaeology.md` 不能复现思想考古报告；
- 当前 `qpi.md` 不能复现房玄龄 2.0；
- 当前不应继续 Agent / Skill 化；
- 应先重新提炼模型，固定稳定可用版本。

这是第二次、更深层的重启点。

## 17. 文章中可以补充的遗漏事实

### 17.1 旧项目并非完全没有价值

旧项目留下了：

- file-first model governance 经验；
- schema / validation 经验；
- selector / regression 反面经验；
- review bundle / Local CCRA 经验；
- 关于“不要让 QPI 成为主角”的明确教训；
- 关于“Local CCRA 应作为里程碑审核”的边界经验。

它失败在主目标，不代表所有产物都没有价值。

### 17.2 真正不可取的是“把样板模型当压力测试对象”

QPI 被当成治理系统的压力测试样板，这让项目能快速产生工程成果。

但 QPI 本身不是高价值深加工模型。用它压力测试治理链路，会自然导致项目围绕轻量入口模型自转。

### 17.3 思想考古的黄金样例其实已经给出了答案

思想考古报告和过程已经展示了：

- 如何开始；
- 如何与 Owner 协商地图；
- 如何逐层推进；
- 如何在中途吸收新观点；
- 如何在最终层前暂停规划；
- 如何做报告修缮。

这比当前模型卡更接近“模型本体”。

### 17.4 新项目的 M0-M1 正确，但不充分

新项目已经避免了旧项目的重治理继承。

但它仍然把旧项目压缩出来的模型卡当成 M1 的可调用模型。

这说明“轻量化”不能替代“模型质量校验”。

## 18. 后续应如何继续，作为文章结尾事实依据

当前最合理的下一步不是继续 M2 prompts，也不是继续 CCPE / skills-vault 分工，而是进入：

`M2-RESET: Golden Sample Back-Extraction`

即：

1. 从思想考古报告和过程反向提炼思想考古操作手册。
2. 从房玄龄 2.0 反向提炼 QPI Agent 化操作手册。
3. 建立黄金样例复现标准。
4. 用复现标准判断模型是否可进入 CCPE Prompt Card / Agent Spec。
5. 只有模型稳定后，再做 Skill / Agent / runtime adapters。

建议新项目先产出：

- `models/intellectual-archaeology.operation-manual.md`
- `models/qpi.operation-manual.md`
- `report/golden-sample-gap-analysis_2026-06-20.md`

## 19. 可作为文章标题的素材

以下不是最终标题，只是素材：

1. 《4.7 亿 Tokens 买来的教训：我如何把认知模型项目做成了审计系统》
2. 《当模型还没学会思考，系统已经学会了审查》
3. 《从 QPI 到思想考古：一次 AI 项目目标函数偏移的全过程》
4. 《工程全绿，产品失败：一个认知模型库的六天复盘》
5. 《我花 4.7 亿 Tokens 证明了一件事：可治理不等于可运行》
6. 《为什么最危险的失败，是每一步看起来都正确》
7. 《QPI 不是主角：一次模型治理过载事故》

## 20. 最终事实摘要

这 6 天的事实不是“什么都没做出来”。

相反，做出来的东西很多：

- 旧项目有模型卡、JSON spec、source index、evidence excerpt、regression、selector、validation、review bundle、Local CCRA。
- 新项目有清晰边界、M0-M1 docs、模型管理内核、prompt authority boundary、CCPE / skills-vault request channel。

真正的问题是：这些东西没有优先服务于“模型能不能产生 Wantsong 式认知加工结果”。

旧项目把“可治理”当成了“可运行”的前提；新项目一开始又继承了这个未被验证的前提。直到 M2，Owner 才重新把问题拉回最核心的位置：

> 现在的 QPI 和思想考古，到底能不能跑出我已经跑出来过的效果？

目前的事实答案是：不能，至少不能仅凭当前模型卡稳定做到。

这就是 6 天、4.7 亿 Tokens 买来的最核心教训。