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 买来的最核心教训。