knowledge-vault/work/internal/强哥的思想宇宙/Cognitive-OS-Wantsong项目总计划 v0.1.md

# Cognitive-OS-Wantsong 项目总计划 v0.1

status: draft_for_owner_review
owner: Wantsong
planning_role: Web CCRA / 认知科学产品规划架构师
executor: Codex
date: 2026-06-20

## 1. 一句话产品定义

`cognitive-OS-wantsong` 是一个面向 Wantsong 个人认知模型体系的轻量认知加工运行时：它通过模型管理、模型调度、深度加工、综合校准和表达转译，把复杂输入加工成既接近 Wantsong 思考方式、又能被前端用户/读者理解的结构化输出。

这里要特别注意：**“像我一样思考”不是最终用户输出。**

产品内部可以使用你的模型、公式、隐喻、层级和复杂推理；但前端用户看到的必须是一次转译后的表达。

---

## 2. 项目背景与重启依据

旧项目 `the-mindscape-of-bro-tsong` 不删除，但从现在起隔离为备查仓库。它与新项目使用两个 git 库、两套远程库，不共享开发节奏，不在新项目中延续旧项目 round 结构。

旧项目可以作为：

```text
model-governance-lab
asset-seed archive
historical reference
anti-pattern reference
```

但不能作为新项目的产品运行时基础。

旧项目失败的核心不是所有产物无用，而是项目类型漂移。过程证据、review bundle、selector diff、validation report 等逐渐成为项目主体，而真实运行时问题没有被验证。旧总结里已经指出：当前项目缺失的问题是，给一个真实输入时，系统能否产出 QPI 判断、模型推荐、思想考古加工、多模型综合、证据等级、行动边界和反馈记录。

新项目必须遵守重启原则：

```text
First prove cognitive processing.
Only then govern the pieces that prove useful.
```

即：

```text
先跑真实认知流程
再治理被证明有用的模型部件
```

旧项目总结也明确建议：旧仓库应关闭产品运行时开发，只作为资产种子和历史证据，不再作为 cognitive operating system 的主建设地点。

---

## 3. 项目目标

### 3.1 第一目标

验证 AI 是否能把 Wantsong 的认知模型串联起来，处理真实复杂输入，并产出有辨识度的认知加工结果。

### 3.2 第二目标

建立一个极简但可持续扩展的模型管理系统，让模型能够被登记、调用、组合、校准、冻结、弃用和回收。

### 3.3 第三目标

建立表达转译层，把内部模型输出转成前端用户/读者能理解的解释、文章、报告或产品化输出。

### 3.4 非目标

v0.1 不追求：

```text
完整模型库
10 模型扩张
100 模型调度系统
完整 selector
完整 regression suite
前端 UI
后端服务
数据库
RAG
知识图谱
商业化包装
```

这些在新项目计划稿中也已被列为 v0.1 明确排除项，包括 full model library、10-model expansion、database、frontend UI、vector database、full RAG、full regression suite、before/after selector diff 和 full rule-based semantic selector。

---

## 4. 核心判断

这个项目不是“两部分”，而是“三层一轨”。

```text
第一层：模型管理层
第二层：认知加工运行层
第三层：表达转译层
横向轨道：里程碑质量门
```

你原先说的“模型管理子系统 + 问题回答子系统”仍然成立，但现在必须显式加入第三层：

```text
表达转译层 / Reader Translation Layer
```

否则内部思考方式会直接暴露给前端用户，导致两个问题：

```text
1. 用户看不懂你的公式化、模型化、隐喻化表达。
2. 系统输出像内部分析备忘录，而不是可消费产品。
```

这不是营销包装，也不是销售话术，而是认知加工结果的可理解化。

---

## 5. 关键产品假设

### H1：认知加工假设

只要给系统少量高质量核心模型，系统就能对真实复杂输入产出明显不同于普通 ChatGPT 的认知加工结果。

### H2：模型资产假设

不是所有文章和模型都要先治理。只有在真实运行中反复有用的模型，才值得进入更高等级模型管理。

### H3：表达转译假设

你的内部模型输出不能直接面向前端用户。系统必须区分：

```text
内部分析稿
前端解释稿
读者可理解版本
可发布内容版本
```

### H4：模型调度假设

10 个模型时可以用人工 + LLM 语义判断解决主辅关系；100 个模型时必须引入模型分组、模型角色、优先级、互斥关系和信息增益评分。

---

## 6. 产品架构

## 6.1 模型管理层

职责：

```text
登记模型
描述模型
标记来源
定义输入输出
定义调用条件
定义不调用条件
定义主辅角色
定义冲突关系
记录使用反馈
管理模型状态
```

第一阶段不要使用 `lite` 后缀。旧项目里的东西没法真正用起来，新项目里的模型不是“旧模型的轻量版”，而是**新运行时里的正式模型资产初版**。

推荐文件名：

```text
models/qpi.md
models/intellectual-archaeology.md
models/model-registry.json
```

不使用：

```text
qpi_lite.md
intellectual_archaeology_lite.md
```

但可以在模型卡内部写：

```text
runtime_scope: minimal_v0
governance_level: draft_callable
```

### 模型状态

```text
seed
draft
callable
core_candidate
core_active
needs_rework
deprecated
archived
```

### 模型等级

```text
L0 source_material
L1 candidate_model
L2 callable_model
L3 core_model
L4 stable_core_model
```

v0.1 只需要 L0-L2。
MVP 8-10 模型阶段才需要 L3。
L4 暂不追求。

旧质量门文档强调，模型不能因为 JSON 可解析、schema pass、selector demo 能运行或 index drift check pass 就升级为 stable；核心模型升级必须经过 evidence review、content review、regression review、selector review 和 Owner / CCRA review。这个原则可以保留，但在新项目中要压缩使用，不能让它再次吞掉运行时。

---

## 6.2 认知加工运行层

职责：

```text
接收输入
判断加工强度
判断问题类型
推荐模型/棱镜
运行主模型
运行辅助模型
识别冲突
综合判断
标记证据等级
标记行动边界
生成反馈记录
```

推荐 v0 流程：

```text
1. Intake / Value Assessment
2. QPI
3. Lens Orchestrator
4. Deep Processing
5. Synthesis & Calibration
6. Feedback & Asset Decision
```

这个流程沿用新项目计划稿里的 runtime flow，但去掉 `lite` 命名。原计划稿中已有相近结构：Intake 判断加工强度，QPI 做问题定性，Lens Orchestrator 推荐 2-4 个模型，Deep Processing 运行思想考古，Synthesis 处理冲突、证据等级和行动边界，Feedback 决定是否沉淀为样例或更新模型规则。

---

## 6.3 表达转译层

这是我建议新增为核心层的部分。

职责：

```text
把内部模型解释转成前端用户/读者能理解的表达。
```

它不是简单“降智”，而是做四种转换：

```text
1. 术语转译：把模型术语换成日常语言。
2. 结构转译：把推理链改写成用户能跟上的层级。
3. 例子转译：用贴近用户经验的案例承接抽象机制。
4. 行动转译：把洞察转成“所以我该怎么看/怎么做”。
```

内部输出可以是：

```text
QPI 判断
思想考古七层结构
模型公式
机制链条
冲突矩阵
证据等级
```

前端输出必须转成：

```text
这个问题表面上是什么
真正卡住的地方是什么
为什么普通理解会误判
背后的机制是什么
可以用什么例子理解
对你有什么启发
哪些地方不能过度解释
下一步可以怎么想
```

### 表达转译层的输出档位

```text
R0 internal_trace：内部分析记录，只给你看。
R1 owner_brief：给你快速判断质量的摘要。
R2 reader_explanation：给普通读者看的解释。
R3 publishable_draft：可进入写作工作台的文章草稿。
R4 product_response：未来前端产品里的正式回答。
```

v0.1 只做 R0 + R2。

---

## 7. 模型主辅调度设计

你的第二个挑战很关键：10 个模型时还好，100 个模型时必须解决“谁为主、谁为辅”。

所以从 v0.1 开始，模型卡里就要预埋主辅调度字段，而不是等到 100 个模型再补。

### 7.1 模型角色

每个模型在一次运行中只能扮演一种或少数几种角色：

```text
primary_model：主解释模型
support_model：辅助解释模型
contrast_model：反证/对照模型
calibration_model：校准模型
translation_model：转译模型
routing_model：路由模型
depth_model：下潜模型
synthesis_model：综合模型
```

例如：

```text
QPI = routing_model
思想考古 = depth_model / primary_model
认知棱镜 = support_model / contrast_model
学科底座 = calibration_model
表达转译器 = translation_model
```

### 7.2 单次调用限制

默认一轮认知加工最多：

```text
1 个主模型
2-3 个辅助/对照模型
1 个校准视角
1 个转译器
```

不允许 10 个模型同时展开。
不允许 100 个模型平铺打分。
不允许因为“可能有关”就调用。

### 7.3 主模型选择依据

主模型优先级由五类信号决定：

```text
1. 问题类型匹配度
2. 解释增益
3. 输出用途
4. 模型稳定性
5. 处理成本
```

不是关键词匹配。

### 7.4 辅助模型选择依据

辅助模型只在三种情况下加入：

```text
1. 主模型有盲区
2. 主模型可能过度解释
3. 问题需要横向比较或反证
```

### 7.5 100 模型阶段的策略

100 个模型时不能做 flat selector，而要做分层调度：

```text
输入
-> 领域/问题类型判断
-> 模型家族筛选
-> 候选模型 5-8 个
-> 主模型 1 个
-> 辅助模型 2-3 个
-> 校准/反证 1 个
-> 输出综合
```

未来的 model-registry 应支持：

```json
{
  "model_id": "intellectual_archaeology",
  "model_family": "deep_modeling",
  "default_role": "depth_model",
  "can_be_primary": true,
  "can_be_support": false,
  "can_be_contrast": false,
  "best_for": ["deep_structure", "hidden_assumptions", "mechanism_excavation"],
  "avoid_for": ["fact_lookup", "light_rewrite", "low_stakes_execution"],
  "cost_level": "high",
  "reader_translation_required": true,
  "conflicts_with": [],
  "pairs_well_with": ["qpi", "cognitive_prism", "evidence_calibrator"]
}
```

---

## 8. MVP 范围

## 8.1 v0.1 必须有

```text
1. 新 git 仓库和新远程库。
2. 旧项目隔离为备查，不作为代码或流程继承源。
3. 项目边界文档。
4. 模型管理最小规范。
5. QPI 模型卡。
6. 思想考古模型卡。
7. model-registry.json。
8. Intake prompt。
9. QPI prompt。
10. Lens Orchestrator prompt。
11. Intellectual Archaeology runner prompt。
12. Synthesis prompt。
13. Reader Translation prompt。
14. 一个真实输入端到端跑通。
15. 一份内部分析输出。
16. 一份读者可理解输出。
17. 一份 Owner review note。
```

## 8.2 v0.1 可以手工替代

```text
模型选择可以手工确认。
模型卡可以 Markdown 优先。
JSON 可以只做 registry，不做完整 schema。
运行记录可以手写。
回归测试可以只保留 3-5 条关键样例。
Local CCRA 只在里程碑触发。
```

## 8.3 v0.1 不做

```text
完整前端
后端服务
数据库
RAG
向量库
知识图谱
完整 selector
完整 regression suite
完整模型生命周期系统
10 模型扩展
100 模型调度
商业化页面
付费系统
用户账户
```

---

## 9. 推荐仓库结构

```text
cognitive-OS-wantsong/
  README.md
  AGENTS.md
  PROJECTS.md

  docs/
    PROJECT_BRIEF.md
    COGNITIVE_WORKFLOW_V0.md
    MODEL_MANAGEMENT_V0.md
    MODEL_ORCHESTRATION_V0.md
    READER_TRANSLATION_LAYER_V0.md
    LOCAL_CCRA_MILESTONE_PROTOCOL.md
    ASSET_MIGRATION_POLICY.md
    DECISIONS.md

  models/
    qpi.md
    intellectual-archaeology.md
    model-registry.json

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

  examples/
    sample-input-001.md
    sample-internal-output-001.md
    sample-reader-output-001.md
    sample-review-notes-001.md

  runs/
    README.md

  local-ccra-reviews/
    README.md

  reports/
    README.md
```

注意：新计划稿里原建议 v0.1 控制在 30-40 个文件，并且不创建 `ccra_review_bundle/`，除非 Web CCRA 明确要求。这个约束应保留。

---

## 10. 旧项目迁移规则

### 10.1 允许备查

```text
models/qpi.model.json
cards/qpi.md
models/intellectual_archaeology.model.json
cards/intellectual_archaeology.md
sources/source_articles.json
sources/source_excerpts.json
selected IA examples
selected QPI examples
09_数据治理与模型调用机制说明.md
```

### 10.2 禁止迁移

```text
ccra_review_bundle/
reports/
local_ccra_reviews/
full regression suite
full selector calibration
Round Conductor
lifecycle-status scan
before/after selector diff workflow
review-bundle packager workflow
```

新项目计划稿也明确要求：不要复制旧项目中的 `ccra_review_bundle/`、`local_ccra_reviews/`、`reports/`，也不要复制 full selector calibration、full QPI regression suite、Round Conductor、lifecycle-status scan workflow 和 review-bundle packager workflow；迁移资产必须改写成新项目运行时语言，不可 bulk-copy 后再修。

### 10.3 关键修正

旧稿中出现的 `QPI-lite`、`Intellectual Archaeology-lite` 统一改为：

```text
QPI
Intellectual Archaeology / 思想考古
```

原因：

```text
旧项目不是可运行正版本；
新项目不是旧项目的轻量分支；
新项目里的模型是运行时正式资产的初始版本。
```

---

## 11. 里程碑计划

## M0：项目边界冻结

目标：建立新项目，不继承旧项目治理惯性。

产物：

```text
README.md
AGENTS.md
docs/PROJECT_BRIEF.md
docs/ASSET_MIGRATION_POLICY.md
docs/DECISIONS.md
```

验收：

```text
1. 新项目使用独立 git 库和远程库。
2. 旧项目只作为备查。
3. 明确不迁移旧 reports / review bundles / Local CCRA 历史。
4. 明确 v0.1 不做前端、后端、RAG、完整模型库。
```

停止条件：

```text
如果 Codex 开始创建 round-*、ccra_review_bundle 或 full regression，立即停止。
```

---

## M1：模型管理内核 v0.1

目标：建立可运行的模型资产最小结构。

产物：

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

验收：

```text
1. 每个模型能说明输入、输出、调用、不调用、角色、成本。
2. registry 能支持主辅模型选择。
3. 不做完整 schema。
4. 不做完整 selector。
```

停止条件：

```text
如果模型管理开始要求所有字段完美、所有来源矩阵完整、所有边界 regression 完整，立即停止。
```

---

## M2：认知加工运行骨架

目标：让流程能手工跑通。

产物：

```text
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
```

验收：

```text
1. 一个输入可以从 Intake 跑到 Synthesis。
2. Lens Orchestrator 能推荐 2-4 个模型/棱镜。
3. QPI 只做路由和问题定性。
4. 思想考古真正进入深度加工。
```

停止条件：

```text
如果 QPI 再次成为主治理对象，立即停止。
```

旧项目问题之一正是 QPI 成为治理主角，而思想考古被低使用；新项目必须反过来，让 QPI 回到前置定性和路由，让思想考古成为真实加工引擎。

---

## M3：表达转译层 v0.1

目标：解决“思考方式 ≠ 可直接输出”的问题。

产物：

```text
docs/READER_TRANSLATION_LAYER_V0.md
prompts/reader-translation-engine.md
examples/translation-before-after-001.md
```

输入：

```text
内部模型分析稿
```

输出：

```text
普通读者可理解解释稿
```

转译规则：

```text
1. 保留洞察，不保留复杂术语。
2. 保留机制，不保留完整推导链。
3. 保留边界，不输出学术式免责声明。
4. 保留你的辨识度，不变成通用鸡汤。
5. 不做营销夸张。
```

验收：

```text
1. 普通用户能看懂。
2. 你能看出仍然是你的思考方式。
3. 没有把模型稀释成泛泛而谈。
4. 能清楚区分 internal output 和 reader output。
```

---

## M4：第一个真实样例

目标：验证产品价值，而不是验证文件完整性。

建议样例：

```text
当前项目失败与重启
```

产物：

```text
examples/sample-input-001.md
examples/sample-internal-output-001.md
examples/sample-reader-output-001.md
examples/sample-review-notes-001.md
runs/run-001.md
```

验收：

```text
1. 输出明显不同于普通 ChatGPT。
2. 内部输出能体现模型加工。
3. 读者输出能被低认知水平用户理解。
4. Owner 能判断“像不像我”。
5. 本次运行能反向改进模型卡或 orchestration notes。
```

---

## M5：第一次 Local CCRA 里程碑评审

目标：审真实运行结果，不审文件宇宙。

产物：

```text
local-ccra-reviews/milestone-01/01/
  review-brief.md
  file-manifest.md
  prompt-to-send.md
  returned-output.md
  owner-decision.md
```

验收：

```text
1. Local CCRA 只检查 milestone output。
2. 不生成 Web review bundle。
3. 不自动授权修复。
4. repair 必须由 owner-decision 确认。
```

新项目计划稿已经规定 Local CCRA 应是 milestone review lane，不是 default round factory；它不应为每次 prompt edit、小模型 note 或 routing adjustment 触发。

---

## M6：扩展到 3-5 个模型

目标：根据真实样例发现缺口，而不是为了凑模型数量。

进入条件：

```text
至少完成 2 个真实运行样例。
至少 1 个样例证明 QPI + 思想考古不足。
```

产物：

```text
candidate-models.md
models/{model-name}.md
model-registry.json 更新
sample-output-002 / 003
```

验收：

```text
1. 每个新增模型必须说明为什么需要。
2. 每个新增模型必须有默认角色：primary / support / contrast / calibration / translation。
3. 不扩到 10 个。
```

---

## M7：模型库 MVP，扩展到 8-10 个核心模型

目标：建立第一批核心模型库。

进入条件：

```text
至少 3-5 个真实运行样例。
至少 2 次输出被 Owner 判断为有明显认知价值。
模型组合开始出现稳定复用。
```

产物：

```text
8-10 个模型卡
model-registry.json
model-relationships.md
orchestration-notes.md
reader-translation-notes.md
light-regression-cases.json
```

验收：

```text
1. 每个模型有清楚的主辅角色。
2. 每个模型知道什么时候不该用。
3. 每个模型知道是否需要转译。
4. 每次运行默认不超过 4 个分析模型。
5. 不做 100 模型架构。
```

---

## M8：100 模型调度预研

目标：只做架构预研，不进入工程实现。

进入条件：

```text
8-10 个核心模型已经能稳定支持多个真实样例。
```

产物：

```text
docs/SCALING_TO_100_MODELS_PREVIEW.md
docs/MODEL_FAMILY_TAXONOMY_DRAFT.md
docs/PRIMARY_SUPPORT_ROUTING_POLICY.md
```

重点研究：

```text
模型家族
主辅模型关系
冲突模型
互补模型
默认调用上限
信息增益评分
成本控制
读者转译需求
```

验收：

```text
1. 100 模型阶段不使用 flat selector。
2. 先按模型家族筛选，再选候选，再选主辅。
3. 单次输出仍保持 1 主 + 2-3 辅。
```

---

## M9：产品形态决策

目标：决定是否进入软件开发。

候选形态：

```text
A. file-first + Codex 协作继续运行
B. 本地 CLI / TUI
C. 轻量 Web 工作台
D. 接入 RAG / 知识库
E. 面向读者的认知分析前端
F. 接入 writing-workbench 生成文章
```

进入条件：

```text
至少 5 个真实样例。
至少 3 个样例有可复用读者输出。
Owner 使用频率足够高。
```

不满足则不开发前端。

---

## 12. 成功标准

v0.1 成功：

```text
1. 新项目没有继承旧项目治理结构。
2. 一个真实输入跑完整认知流程。
3. 产生 internal output 和 reader output 两个版本。
4. QPI 保持轻量。
5. 思想考古被实际使用。
6. 模型管理服务于运行时，而不是反客为主。
7. Local CCRA 没有变成新 round 工厂。
```

v0.1 失败：

```text
1. QPI 再次成为主治理对象。
2. 项目先写大量规范而没有真实样例。
3. review artifacts 超过 runtime artifacts。
4. reader translation 被忽略。
5. 模型输出直接面向低认知用户。
6. Codex 开始补完整 selector / schema / regression。
```

旧项目立项稿也给出过类似成功/失败标准：v0.1 成功应表现为一个真实输入跑通完整 cognitive workflow，输出明显不同于普通 ChatGPT，思想考古作为实际 processing engine，QPI 保持轻量，Local CCRA 不生成新的 heavy review universe；失败则包括 QPI 再次成为主治理对象、项目花更多精力证明 routing safety 而不是生成 cognitive outputs。

---

## 13. 给 Codex 的执行边界

Codex 的职责：

```text
创建文件
整理目录
改写旧资产为新运行时语言
生成 prompt 文件
生成样例文件
维护 registry
记录运行结果
根据 Owner 指令修复
```

Codex 不负责：

```text
重新定义产品目标
扩大模型数量
引入完整治理体系
决定模型是否 stable
决定是否进入 10 模型扩展
决定是否进入前端开发
```

已有质量门文档也明确过分工：Codex 是本地执行者、校验脚本运行者、审核包生成器和疑点整理者；CCRA 才是产品质量门槛、模型产品化审查和是否进入下一阶段的判断者，Codex 不应替代 CCRA 做最终内容质量审查。

---

## 14. 给 Codex 的第一条执行指令草案

```md
创建新项目 cognitive-OS-wantsong。

注意：这是一个全新 git 仓库和全新远程库，不是 the-mindscape-of-bro-tsong 的 continuation branch。旧项目只作为备查 archive，不迁移历史流程。

本项目目标：
建立一个轻量认知加工运行时，验证 AI 是否能使用 Wantsong 的认知模型处理真实复杂输入，并输出两类结果：
1. internal cognitive-processing output；
2. reader-facing translated output。

禁止：
- 不创建 ccra_review_bundle/
- 不迁移旧 reports/
- 不迁移旧 local_ccra_reviews/
- 不迁移 full regression suite
- 不迁移 full selector calibration
- 不创建 Round Conductor
- 不做完整前端
- 不做后端
- 不做数据库
- 不做 RAG
- 不做 10 模型扩展
- 不使用 lite 后缀命名模型文件

第一批只创建 M0-M1 文件：

README.md
AGENTS.md
PROJECTS.md

docs/
- PROJECT_BRIEF.md
- COGNITIVE_WORKFLOW_V0.md
- MODEL_MANAGEMENT_V0.md
- MODEL_ORCHESTRATION_V0.md
- READER_TRANSLATION_LAYER_V0.md
- LOCAL_CCRA_MILESTONE_PROTOCOL.md
- ASSET_MIGRATION_POLICY.md
- DECISIONS.md

models/
- qpi.md
- intellectual-archaeology.md
- model-registry.json

请先只完成项目边界和模型管理内核，不要进入样例运行，不要扩展模型，不要生成 review bundle。
```

---

## 15. 我的最终判断

你这个修正非常关键。

尤其是第一点：“不要带 lite 后缀”。这个判断是对的。因为 `lite` 会暗示旧项目里存在一个“完整正式版”，新项目只是轻量版。但实际情况不是这样。旧项目是治理实验室，新项目才是产品运行时起点。

第二个关键修正是“表达转译层”。这应该进入总计划核心，而不是后面再补。否则系统即使内部想得像你，外部也会输出成用户看不懂的模型黑话。

第三个关键修正是“100 模型主辅关系”。这个不需要 v0.1 实现，但必须从模型卡和 registry 字段中提前埋钩子。否则到 100 个模型时会重新陷入 selector 宇宙。

所以结论是：

```text
这份总计划应该由我先出。
你审核。
我再根据你的审核意见改成 v0.2。
然后再交给 Codex 执行 M0-M1。
```

当前这版可以作为 `项目总计划 v0.1 初稿`。

# 16. `knowledge_assets`的处理意见

我的判断：**不迁移整个 `knowledge_assets/` 目录；只抽取少数稳定原则，改写成新项目语言后，再分两处存放。**

旧项目文档里其实已经有判断标准：回答“以后一直怎么做”的文档，可以进 `docs/` 或 `knowledge_assets/`；回答“这轮做了什么、哪些 PASS/FAIL”的文档，应留在 `reports/` 或 `ccra_review_bundle/`。 但新项目不能继续继承旧项目的“知识资产层 + 审核包层 + 治理层”重结构。

## 1. 结论

### 不迁移原目录

新项目里**不要直接创建旧式 `knowledge_assets/` 目录**。

原因是这个名字在旧项目中已经绑定了“长期治理解释层”，很容易让 Codex 误以为新项目还要继续维护一套治理知识库。

### 迁移少数内容，但必须重写

可以迁移的不是文件，而是**原则**。

尤其是：

```text
模型卡为什么必要
source / evidence 为什么必要
边界治理为什么必要
模型不能因为 validation pass 就 stable
review artifacts 不是产品
QPI 不能成为主角
selector 只能作为 hard guardrail
```

但这些都要改写成 `cognitive-OS-wantsong` 的运行时语言。新项目立项计划也明确说，允许迁移 `knowledge_assets/09_数据治理与模型调用机制说明.md` 的 selected explanation，但“Each migrated asset must be rewritten into the new project's runtime language. Do not bulk-copy and then repair.”

### 同步到我的知识库：可以，但只同步修订版

你可以同步到我的知识库，但不要同步旧项目原文。旧文档自己也写了：`knowledge_assets/` 是长期解释层，Owner 可以手动将其中稳定文档同步到 GPT 知识库；评审包不应默认重复打包 `knowledge_assets/`。

所以策略是：

```text
旧项目 knowledge_assets
-> 人工筛选
-> 改写为 cognitive-OS 运行时版本
-> 一份进入新项目 docs/
-> 一份作为 GPT 知识库候选文档
```

---

## 2. 我建议分三类处理

### A 类：不迁移，只旧项目备查

这些保留在旧仓库，不进入新项目：

```text
旧 round 机制说明
旧 review bundle 规则
旧 selector calibration 说明
旧 lifecycle scan 说明
旧 full regression 说明
旧 model_library_mvp 阶段的过程性解释
```

原因：这些会把新项目重新拉回治理轨道。

失败总结里已经把 `knowledge_assets/09_数据治理与模型调用机制说明.md` 定位为“heavy-governance explanation and anti-pattern reference”，不是新项目的直接操作规则。

### B 类：抽取后改写，进入新项目 `docs/`

这些要进入新项目，但不能叫旧名字，不能原样复制。

建议生成：

```text
docs/LEGACY_LESSONS_FROM_MODEL_GOVERNANCE_LAB.md
docs/MODEL_MANAGEMENT_V0.md
docs/MODEL_ORCHESTRATION_V0.md
docs/ASSET_MIGRATION_POLICY.md
docs/LOCAL_CCRA_MILESTONE_PROTOCOL.md
```

其中 `LEGACY_LESSONS_FROM_MODEL_GOVERNANCE_LAB.md` 专门记录旧项目教训，避免污染主流程。

它的定位是：

```text
旧项目哪些原则有价值；
哪些机制在新项目里禁止默认继承；
哪些东西只能作为以后扩展时的参考。
```

### C 类：修订后同步到 GPT 知识库

适合同步到我的知识库的是更稳定、跨项目可复用的版本：

```text
00_用户背景与产品上下文_v0.2.md
02_模型卡结构规范_runtime版_v0.2.md
06_模型稳固性评级规则_runtime版_v0.2.md
cognitive-OS-wantsong_项目总计划_v0.1.md
旧项目失败与重启原则_v0.1.md
模型管理与认知加工运行时边界_v0.1.md
```

不适合同步：

```text
具体某轮评审
Codex 执行记录
selector diff
validation report
临时 migration manifest
旧项目中间状态总结
```

旧质量门文件也有类似判断：稳定长期背景、核心模型地图、模型卡结构规范、稳固性评级规则、产品规划过程记录、已定稿的长期指导协议适合进知识库；validation report、command log、临时 selector regression report、未审定中间状态文件不适合进知识库。

---

## 3. 新项目里是否保留 `knowledge_assets/` 目录？

我建议 **v0.1 不保留**。

新项目目录里只保留：

```text
docs/
models/
prompts/
examples/
runs/
local-ccra-reviews/
reports/
```

原因是：新项目的主重力应该是 runtime。`knowledge_assets/` 这种目录容易让 Codex 开始做“长期知识治理”，而不是跑第一个真实样例。

以后如果项目成熟，可以再加：

```text
knowledge/
  stable-principles/
  model-theory/
  reader-translation/
```

但不是 v0.1。

---

## 4. 对 `09_数据治理与模型调用机制说明.md` 的处理

这份文档有价值，但不能原样搬。

它应该拆成两份：

### 4.1 新项目版本

```text
docs/LEGACY_LESSONS_FROM_MODEL_GOVERNANCE_LAB.md
```

内容只保留：

```text
1. 旧项目为什么会过度治理
2. 哪些治理机制有价值
3. 哪些机制在新项目 v0.1 禁止默认使用
4. QPI 为什么不能再成为主战场
5. selector 为什么只保留 hard guardrail
6. runtime-first 的边界
```

### 4.2 知识库版本

```text
旧项目失败与重启原则_v0.1.md
```

内容更抽象，给未来会话用：

```text
1. 旧项目失败机制
2. model governance 与 product runtime 的区别
3. Codex 容易过度治理的触发条件
4. cognitive-OS-wantsong 的重启原则
5. 后续规划时必须警惕的反模式
```

---

## 5. 给 Codex 的规则应该这样写

```md
关于旧项目 knowledge_assets 的迁移规则：

1. 不迁移整个 knowledge_assets/ 目录。
2. 不在新项目 v0.1 创建 knowledge_assets/ 目录。
3. 只允许抽取旧 knowledge_assets 中的稳定原则。
4. 所有被抽取内容必须改写为 cognitive-OS-wantsong 的 product-runtime 语言。
5. 禁止原样复制旧 model_library_mvp、review bundle、selector calibration、full regression、lifecycle governance 相关文本作为新项目规则。
6. 可以创建 docs/LEGACY_LESSONS_FROM_MODEL_GOVERNANCE_LAB.md，用于记录旧项目教训和反模式。
7. 可以在 docs/ASSET_MIGRATION_POLICY.md 中列出哪些旧知识资产允许作为参考。
8. 不得把旧 knowledge_assets 当作新项目 source of truth。
9. 后续需要同步到 GPT 知识库的内容，由 Owner 审核后手动同步修订版。
```

---

## 6. 最终建议

你应该做的是：

```text
不迁移目录；
迁移原则；
重写文档；
新项目放 docs/；
稳定版再同步到 GPT 知识库。
```

最关键的一条是：

```text
旧 knowledge_assets 是“治理实验室的知识沉淀”；
新项目需要的是“认知加工运行时的操作原则”。
```

二者不能直接等价。