1965 lines
52 KiB
Markdown
1965 lines
52 KiB
Markdown
# 1
|
||
|
||
`对当前QPI治理流程的质疑`是上个会话中，你具有第6轮评审上下文的讨论内容。
|
||
`当前项目失败总结与重启依据_2026-06-19`是我将质疑发给Codex后，它做了全文件的审计后的总结。
|
||
`cognitive-OS-wantsong_新项目立项计划稿_2026-06-19`，是我与Codex讨论计划新启动项目的计划。
|
||
|
||
我的初始计划是打造一个产品，下面是第一次交流时我发的内容：
|
||
```md
|
||
1. 包括了模型管理子系统和问题回答子系统两部分：
|
||
1. 模型管理，主要处理内容，将文章抽出来成为模型，有模型的说明和索引
|
||
2. 问题回答，则是具体使用
|
||
2. 两个子系统相辅相成。可以先抽出来10个左右的核心模型，搭建模型MVP库；然后再进入问题回答，看产品形态，模型库还需要如何调整。
|
||
3. GPT/你只负责规划，我拿着规划文档到Codex上具体操作。
|
||
```
|
||
|
||
现在你了解了上下文后，哪些地方有问题可以提出。
|
||
|
||
我计划是：你出一个全部的项目计划，定义里程碑节点。之前就是没有这个蓝图，导致做了6轮发现没个头。
|
||
|
||
现在，模型管理部分可以细一些，问题回答可以粗一些。
|
||
|
||
---
|
||
|
||
## GPT
|
||
|
||
根据 2026-06-19 的几份文档，我的判断是：**你现在确实需要一份总蓝图，但这份蓝图不能再是“全量治理计划”，而应是“带停止条件的产品验证路线图”。** 旧项目已经证明：它成功验证了 file-first 模型治理机制，但没有验证真正的产品问题——AI 能否把 QPI、思想考古和后续模型串联起来，像你一样处理真实问题。
|
||
|
||
## 1. 我理解这个产品暂时可以定义为
|
||
|
||
**一个面向你个人 OPC 路径的轻量认知加工系统：用极简模型管理库维护核心认知模型，并通过一条可运行的问题加工流程，把真实输入加工成接近你思考方式的结构化洞察。**
|
||
|
||
这里的顺序要改成：
|
||
|
||
```text
|
||
先证明认知加工有效
|
||
再治理那些被证明有用的模型资产
|
||
```
|
||
|
||
这也正是失败总结里的重启原则：旧顺序是“治理模型资产 -> 调 selector -> 审核 -> 也许使用模型”，新顺序应是“跑真实认知流程 -> 检查输出价值 -> 稳定有用的模型部件”。
|
||
|
||
---
|
||
|
||
## 2. 现在计划里我会直接提出的几个问题
|
||
|
||
### 问题一：不能把“全部项目计划”写成另一个无限蓝图
|
||
|
||
你要的不是完整宇宙规划，而是**可收口的分阶段蓝图**。每个里程碑必须回答三个问题：
|
||
|
||
```text
|
||
这一阶段验证什么？
|
||
做到什么就停？
|
||
什么情况必须禁止继续扩？
|
||
```
|
||
|
||
否则“计划书”会再次诱导 Codex 进入“补 schema、补 review、补 regression、补 diff”的惯性。
|
||
|
||
### 问题二：模型管理可以细，但不能再次细到治理吞掉产品
|
||
|
||
旧项目的问题不是模型卡、source、regression 没价值，而是治理物反客为主。失败总结里记录：排除 `.git` 后，旧项目 474 个文件约 8.5MB，其中 `ccra_review_bundle/`、`reports/`、`local_ccra_reviews/` 占了主要体量；相比之下，核心模型文件 `models/` 和 `cards/` 都只有约 21KB。这个比例说明“过程证据”已经大于“模型资产”。
|
||
|
||
所以新项目里的模型管理要细化的是：
|
||
|
||
```text
|
||
模型分级
|
||
模型卡结构
|
||
来源追溯
|
||
调用条件
|
||
不调用条件
|
||
输出契约
|
||
样例输入输出
|
||
轻量回归
|
||
运行反馈如何反哺模型
|
||
```
|
||
|
||
而不是继续细化：
|
||
|
||
```text
|
||
selector diff
|
||
round bundle
|
||
全量 lifecycle scan
|
||
完整 schema validator
|
||
before / after non-target behavior
|
||
```
|
||
|
||
### 问题三：问题回答可以粗，但不能粗到没有运行时
|
||
|
||
旧项目缺失的正是 runtime operating loop：给一个真实输入，系统能否产生 QPI-lite 判断、模型/棱镜推荐、思想考古深度处理、多模型综合、证据等级、行动边界和反馈记录。失败总结明确说当前项目“不包含这个 operating loop”。
|
||
|
||
所以问题回答子系统第一阶段可以不做 UI、不做后端、不做数据库、不做 RAG，但必须有：
|
||
|
||
```text
|
||
一个真实输入
|
||
一条手工可执行流程
|
||
一份完整输出样例
|
||
一次 Owner 判断
|
||
一次反馈记录
|
||
```
|
||
|
||
### 问题四：QPI 必须降级为轻量入口，思想考古必须升回发动机
|
||
|
||
旧项目里 QPI 变成了主战场：62 条 QPI regression、反复 selector calibration、QPI-before-IA gate、before/after selector behavior diff 等，这导致 QPI 被当成高风险治理对象，而不是轻量前置模型。
|
||
|
||
思想考古则相反，被过度当成“是否调用 IA”的门禁对象，而不是实际深度加工引擎。失败总结里说，项目花了更多精力“守门”，而不是测试“进门后能不能挖出东西”。
|
||
|
||
---
|
||
|
||
## 3. 总蓝图建议：双轨一门
|
||
|
||
我建议新项目采用：
|
||
|
||
```text
|
||
A. 模型管理轨：细
|
||
B. 认知加工运行轨：粗但必须跑通
|
||
C. 里程碑质量门：只在节点审核，不做轮次工厂
|
||
```
|
||
|
||
旧项目可以保留为 `model-governance-lab / asset-seed archive`，但不再作为产品运行时主仓库。失败总结也建议旧仓库不要删除，而是冻结为模型治理实验室和资产种子库。
|
||
|
||
---
|
||
|
||
## 4. 里程碑路线图
|
||
|
||
### M0：项目边界冻结
|
||
|
||
**目标**：防止新项目一开始继承旧项目治理惯性。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
README.md
|
||
AGENTS.md
|
||
docs/PROJECT_BRIEF.md
|
||
docs/COGNITIVE_WORKFLOW_V0.md
|
||
docs/MODEL_MANAGEMENT_V0.md
|
||
docs/LOCAL_CCRA_MILESTONE_PROTOCOL.md
|
||
docs/ASSET_MIGRATION_POLICY.md
|
||
docs/DECISIONS.md
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 明确新项目不是旧项目 continuation branch。
|
||
2. 明确旧项目只作为 asset seed。
|
||
3. 明确 v0.1 不做完整模型库、不做完整 selector、不做完整 regression、不做前后端。
|
||
4. 明确 Local CCRA 只在里程碑触发，不为小改动触发。
|
||
```
|
||
|
||
这与新项目计划稿一致：新项目应是 product-runtime gravity，而不是 model-governance gravity；并且不继承旧 round structure、review-bundle expansion、selector-diff loop 或 QPI-centered rhythm。
|
||
|
||
---
|
||
|
||
### M1：模型管理内核 v0.1
|
||
|
||
**目标**：把模型管理系统做细，但只做到“可被运行时调用”的最小形态。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
models/
|
||
qpi_lite.md
|
||
intellectual_archaeology_lite.md
|
||
model_registry.json
|
||
|
||
docs/
|
||
MODEL_CARD_LITE_SPEC.md
|
||
MODEL_ONBOARDING_LITE.md
|
||
MODEL_STATUS_RULES.md
|
||
MODEL_SOURCE_TRACE_POLICY.md
|
||
```
|
||
|
||
**模型卡 Lite 必填字段**：
|
||
|
||
```text
|
||
model_id
|
||
model_name
|
||
one_sentence_definition
|
||
model_type
|
||
pipeline_position
|
||
source_article
|
||
source_excerpt
|
||
core_question
|
||
core_mechanism
|
||
input_type
|
||
output_type
|
||
when_to_call
|
||
when_not_to_call
|
||
negative_triggers
|
||
output_contract
|
||
depth_control
|
||
failure_signals
|
||
stability_level
|
||
example_input
|
||
example_output
|
||
```
|
||
|
||
这些字段是从现有模型卡规范压缩来的。原规范要求 Markdown card 覆盖模型名称、ID、定义、流程位置、来源、核心机制、适用/不适用场景、负向触发、输出契约、深度控制、版本信息等，JSON card 需要回答什么时候调用、不调用、输入输出、调用优先级、前后模型、冲突模型和稳固性等问题。
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. QPI-lite 和 IA-lite 都能被人读懂。
|
||
2. model_registry.json 能说明模型位置、状态、调用优先级。
|
||
3. 不建立完整 schema validator。
|
||
4. 不做 full regression suite。
|
||
5. 不做 selector calibration。
|
||
```
|
||
|
||
---
|
||
|
||
### M2：运行时骨架 v0.1
|
||
|
||
**目标**：让问题加工流程能手工跑通，而不是先做系统工程。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
prompts/
|
||
intake_value_assessor.md
|
||
qpi_lite_router.md
|
||
lens_orchestrator.md
|
||
intellectual_archaeology_runner.md
|
||
synthesis_engine.md
|
||
calibration_checker.md
|
||
|
||
runs/
|
||
README.md
|
||
```
|
||
|
||
**运行流程**：
|
||
|
||
```text
|
||
1. Intake / Value Assessment
|
||
2. QPI-lite
|
||
3. Lens Orchestrator
|
||
4. Deep Processing
|
||
5. Synthesis & Calibration
|
||
6. Feedback & Asset Decision
|
||
```
|
||
|
||
这与新项目计划稿中的 runtime flow v0 基本一致：先判断投入强度，再做 QPI-lite 问题定性，然后由 Lens Orchestrator 推荐 2-4 个模型/棱镜，必要时进入 IA-lite，最后做综合、证据等级、行动边界和反馈记录。
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 一条输入可以从 intake 跑到 synthesis。
|
||
2. 输出不要求自动化，但每一步要有文件化结果。
|
||
3. Lens Orchestrator 使用 LLM 语义判断，规则层只做 hard guardrail。
|
||
4. 不做完整前端、后端、数据库、RAG。
|
||
```
|
||
|
||
---
|
||
|
||
### M3：第一个真实样例
|
||
|
||
**目标**：验证“输出是否像你”，而不是验证文件是否完整。
|
||
|
||
**建议首个样例**：就用“当前项目失败与重启”作为 sample_input_001。原因是上下文充分、你有强判断标准、QPI 与 IA 都能派上用场。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
examples/sample_input_001.md
|
||
examples/sample_output_001.md
|
||
examples/sample_review_notes_001.md
|
||
runs/run_001.md
|
||
```
|
||
|
||
**输出必须包含**：
|
||
|
||
```text
|
||
QPI-lite 判断
|
||
模型/棱镜推荐理由
|
||
IA-lite 下潜层级
|
||
至少一个非 IA 棱镜
|
||
多视角冲突
|
||
综合洞察
|
||
证据等级
|
||
行动边界
|
||
下一步建议
|
||
Owner 反馈槽
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 你能判断它是否接近你的思考方式。
|
||
2. 输出明显不同于普通 ChatGPT 总结。
|
||
3. IA 是实际加工引擎，不只是被 guarded。
|
||
4. QPI 保持轻量。
|
||
```
|
||
|
||
这也对应计划稿中 M2 的验收标准：Owner 能判断输出是否接近 Wantsong 的认知加工，并且输出包含 QPI-lite、模型/棱镜推荐、IA depth processing、synthesis、evidence level、action boundary 和 feedback note。
|
||
|
||
---
|
||
|
||
### M4：第一次 Local CCRA 里程碑评审
|
||
|
||
**目标**：让 CCRA 检查真实运行输出，而不是检查治理文件宇宙。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
local_ccra_reviews/milestone-03/01/
|
||
review-brief.md
|
||
file-manifest.md
|
||
prompt-to-send.md
|
||
LOCAL_CCRA_REVIEW_REPORT.md
|
||
returned-output.md
|
||
owner-decision.md
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. Local CCRA 只审 M3 的运行时输出。
|
||
2. 不创建 public Web bundle。
|
||
3. 不自动授权 repair。
|
||
4. 是否 repair 由 owner-decision.md 决定。
|
||
```
|
||
|
||
新计划稿也明确规定 Local CCRA 是 milestone review lane，不是 default round factory，并且不应为每个 prompt edit、小模型 note 或 routing adjustment 触发。
|
||
|
||
---
|
||
|
||
### M5：模型管理 v0.2，扩到 3-5 个模型/棱镜
|
||
|
||
**目标**：不是凑满 10 个模型，而是根据真实样例发现缺口。
|
||
|
||
**进入条件**：
|
||
|
||
```text
|
||
至少完成 2-3 个真实 sample run
|
||
每个新增模型都有明确“为什么 QPI + IA 不够”的证据
|
||
```
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
models/model_registry.json 更新
|
||
models/{new_model}_lite.md
|
||
docs/LENS_SELECTION_NOTES.md
|
||
examples/sample_input_002.md
|
||
examples/sample_output_002.md
|
||
examples/sample_input_003.md
|
||
examples/sample_output_003.md
|
||
```
|
||
|
||
**新增模型分级**：
|
||
|
||
```text
|
||
L0 素材模型：只记录来源和摘要，不进 registry 主流程。
|
||
L1 候选模型：mini card + 2-3 个示例，不进核心调用。
|
||
L2 可调用模型：Lite card + 输出契约 + 少量样例，可进入 Lens Orchestrator。
|
||
L3 核心模型：完整模型卡 + 轻量 regression + Owner review。
|
||
```
|
||
|
||
这个分级可以防止后续模型复制 QPI 的六轮成本。此前质疑文档已明确指出，只有 L3 核心模型才值得走较完整治理，而且也应是压缩版，不是 6 轮版。
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 模型数最多 5 个。
|
||
2. 每个新增模型必须来自真实运行缺口。
|
||
3. 不扩成完整模型库。
|
||
4. 不进入 10 模型扩张。
|
||
```
|
||
|
||
---
|
||
|
||
### M6：模型库 MVP，扩到 8-10 个核心模型
|
||
|
||
**目标**：这才是你最初说的“10 个左右核心模型 MVP 库”，但它不应该是第一阶段，而应该在运行时已证明有效之后开始。
|
||
|
||
**进入条件**：
|
||
|
||
```text
|
||
至少 3-5 个真实 runtime samples
|
||
至少 2 次输出被你判断为“有明显认知价值”
|
||
Lens Orchestrator 已出现稳定复用的模型组合
|
||
```
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
8-10 张模型卡 Lite+
|
||
model_registry.json
|
||
source_excerpts.json
|
||
model_relationships.md
|
||
routing_notes.md
|
||
misuse_notes.md
|
||
light_regression_cases.json
|
||
```
|
||
|
||
**模型卡 Lite+ 相比 Lite 增加**：
|
||
|
||
```text
|
||
related_models
|
||
conflict_models
|
||
discipline_calibration
|
||
common_misuse
|
||
failure_signals
|
||
stability_reason
|
||
minimum_regression_cases
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 每个模型都有来源、适用/不适用场景、输出契约。
|
||
2. 每个 L3 核心模型有 3-5 条轻量 regression。
|
||
3. 不要求 15 条 regression。
|
||
4. 不要求 A 级 stable。
|
||
5. 不做完整知识图谱。
|
||
```
|
||
|
||
质量门文档里原本规定样板阶段每个核心模型至少 5 条 regression，内容稳定化阶段每个核心模型至少 15 条；但在新项目里，只有进入 L3 核心模型的资产才适合使用这个标准，不能把所有候选模型都按核心模型治理。
|
||
|
||
---
|
||
|
||
### M7：认知加工 v0.2，多模型综合稳定化
|
||
|
||
**目标**：把问题回答从“粗流程”推进到“可复用输出格式”。
|
||
|
||
**产物**：
|
||
|
||
```text
|
||
prompts/synthesis_engine_v0.2.md
|
||
prompts/conflict_resolver.md
|
||
prompts/evidence_calibrator.md
|
||
docs/OUTPUT_CONTRACT_V0.md
|
||
examples/sample_output_004.md
|
||
examples/sample_output_005.md
|
||
```
|
||
|
||
**输出结构固定为**：
|
||
|
||
```text
|
||
1. 输入问题复述
|
||
2. 加工强度判断
|
||
3. 调用模型列表与理由
|
||
4. 分模型视角
|
||
5. 视角之间的冲突
|
||
6. 综合判断
|
||
7. 证据等级
|
||
8. 行动边界
|
||
9. 仍需补充的信息
|
||
10. 可沉淀资产建议
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 不同模型输出不互相重复。
|
||
2. 综合不是简单摘要。
|
||
3. 能标记冲突、边界和证据等级。
|
||
4. 至少 5 个真实输入跑通。
|
||
```
|
||
|
||
---
|
||
|
||
### M8：开发形态决策
|
||
|
||
**目标**：到这里才决定是否进入更正式的软件形态。
|
||
|
||
**候选形态**：
|
||
|
||
```text
|
||
A. 继续 file-first + Codex 协作
|
||
B. 做本地 CLI / TUI
|
||
C. 做轻量 Web 工作台
|
||
D. 接入知识库 / RAG
|
||
E. 做半自动内容产品生成系统
|
||
```
|
||
|
||
**验收标准**：
|
||
|
||
```text
|
||
1. 如果运行样例价值不足，不进入开发。
|
||
2. 如果模型调用频繁但文件操作低效，才考虑 CLI。
|
||
3. 如果需要浏览、检索、对比、复用大量历史案例，才考虑数据库/RAG。
|
||
4. 如果你本人使用频率不足，不进入商业化产品设计。
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 模型管理部分：应该细到什么程度
|
||
|
||
你说模型管理可以细一些，我同意，但建议只细化这六块。
|
||
|
||
### 5.1 模型分级
|
||
|
||
```text
|
||
L0：素材模型
|
||
L1：候选模型
|
||
L2：可调用模型
|
||
L3：核心模型
|
||
L4：稳定核心模型，暂不追求
|
||
```
|
||
|
||
MVP 只需要 L0-L3。
|
||
|
||
### 5.2 模型状态
|
||
|
||
```text
|
||
draft
|
||
callable_draft
|
||
core_candidate
|
||
core_active
|
||
deprecated
|
||
needs_rework
|
||
```
|
||
|
||
不要再追求 stable。旧质量门已经说明，模型不能因为 JSON 可解析、schema pass、Markdown heading 存在、selector demo 能运行或 index drift check pass 就升级为 stable。
|
||
|
||
### 5.3 模型卡结构
|
||
|
||
第一阶段使用 Lite，不直接继承旧完整模型卡。
|
||
|
||
```text
|
||
必填：定义、来源、机制、输入、输出、调用、不调用、失败信号、输出契约。
|
||
选填：冲突模型、学科底座、regression、版本历史。
|
||
```
|
||
|
||
### 5.4 来源治理
|
||
|
||
只保留：
|
||
|
||
```text
|
||
source_article
|
||
source_excerpt
|
||
quote_status
|
||
source_location
|
||
evidence_type
|
||
```
|
||
|
||
不做复杂 evidence matrix。
|
||
|
||
### 5.5 调用治理
|
||
|
||
新项目不做 full rule-based selector。采用：
|
||
|
||
```text
|
||
Hard rules：防止明显误用
|
||
LLM semantic router：推荐 2-4 个模型
|
||
Owner override：你可以直接指定模型
|
||
Run feedback：把你修正过的调用记录进 routing_notes
|
||
```
|
||
|
||
计划稿也明确 v0.1 的 Lens Orchestrator 应使用 LLM semantic judgment，并辅以 hard-rule guardrails。
|
||
|
||
### 5.6 轻量回归
|
||
|
||
只保护高风险边界：
|
||
|
||
```text
|
||
不该用 IA 时别用
|
||
QPI 不要主导最终输出
|
||
简单事实查询 no-call
|
||
深度问题要能进入 IA
|
||
多模型组合不能重复
|
||
```
|
||
|
||
思想考古本身仍要遵守“最小充分下潜”，即继续下潜不再改变判断、路径、验证方式或行动边界时就停止。
|
||
|
||
---
|
||
|
||
## 6. 问题回答部分：第一阶段只需要粗到这里
|
||
|
||
第一阶段不需要完整“问答产品”，只需要一个**认知加工运行时**。
|
||
|
||
```text
|
||
输入：
|
||
一个问题 / 观点 / 项目材料 / 文章片段
|
||
|
||
过程：
|
||
Intake -> QPI-lite -> Lens Orchestrator -> IA-lite / 其他模型 -> Synthesis -> Feedback
|
||
|
||
输出：
|
||
结构化认知加工报告
|
||
```
|
||
|
||
不要做：
|
||
|
||
```text
|
||
聊天 UI
|
||
多轮对话记忆
|
||
RAG
|
||
知识图谱
|
||
用户系统
|
||
权限
|
||
分享
|
||
支付
|
||
复杂前后端
|
||
```
|
||
|
||
新项目计划稿已经把这些列为 v0.1 out of scope，包括 full model library、10-model expansion、complete schema validator、database、frontend UI、vector database、full RAG、full regression suite、lifecycle promotion、before/after selector diff 和 Web review bundle by default。
|
||
|
||
---
|
||
|
||
## 7. 我建议给 Codex 的第一条总指令
|
||
|
||
```md
|
||
创建新项目 cognitive-OS-wantsong。
|
||
|
||
项目目标不是继续 the-mindscape-of-bro-tsong 的模型治理线，而是建立轻量认知加工运行时。
|
||
|
||
总原则：
|
||
1. 旧项目冻结为 model-governance-lab / asset-seed archive。
|
||
2. 新项目只迁移 QPI-lite、Intellectual Archaeology-lite、少量 source/excerpt 和必要样例。
|
||
3. 不迁移 reports、ccra_review_bundle、local_ccra_reviews 历史、full regression suite、full selector calibration、Round Conductor。
|
||
4. 新项目第一阶段采用 runtime-first、asset-minimalism。
|
||
5. 模型管理部分要建立 Lite 模型卡、model_registry、model onboarding 分级、source trace policy。
|
||
6. 问题加工部分只做手工可运行流程，不做前后端、不做数据库、不做 RAG。
|
||
7. Local CCRA 只在里程碑评审时触发，不为每个 prompt 或 routing 小调整触发。
|
||
8. 第一批里程碑为：
|
||
- M0 Project Boundary
|
||
- M1 Model Management Kernel v0.1
|
||
- M2 Runtime Skeleton
|
||
- M3 First Real Sample
|
||
- M4 Local CCRA Milestone Review
|
||
- M5 Expand to 3-5 Models
|
||
- M6 Model Library MVP 8-10 Core Models
|
||
- M7 Multi-model Synthesis v0.2
|
||
- M8 Development Form Decision
|
||
9. 每个里程碑必须有 deliverables、acceptance criteria、stop rules。
|
||
10. v0.1 成功标准是：一个真实输入能跑完整认知流程，输出明显不同于普通 ChatGPT，IA 被实际用作加工引擎，QPI 保持轻量。
|
||
```
|
||
|
||
## 8. 最终判断
|
||
|
||
你的方向是对的：**需要总蓝图，需要里程碑，需要先把“没完没了”的机制切断。**
|
||
|
||
但我会把你的计划改成一句更硬的项目原则：
|
||
|
||
```text
|
||
模型管理要足够细，保证资产可用；
|
||
问题回答要足够粗，保证流程能跑；
|
||
里程碑要足够硬，保证项目能停。
|
||
```
|
||
|
||
下一步最适合做的不是继续讨论 QPI，也不是直接写大 PRD，而是先产出一份 **《cognitive-OS-wantsong 项目总计划 v0.1》**，它应包含：项目定义、失败复盘吸收、双轨架构、M0-M8 里程碑、模型管理规范、运行时流程、迁移边界、Codex 任务切片和每阶段停止条件。
|
||
|
||
# 2
|
||
|
||
1. 新项目里的模型不要带`lite`后缀了，因为旧项目的东西没法真正用起来。
|
||
2. 旧项目不会删除，但是会与新项目隔离开，用两个git库，两套远程库。只做备查。
|
||
3. 这个项目里，我觉得最大的挑战：
|
||
1. 不在用不用哪个模型上，而在于用了模型后得到解释后，需要转译前端用户/读者才能看懂。因为我的有些模型就是公式；前端用户的认知水品比较低。即思考方式，不等于可以直接输出；需要做一次转译。
|
||
2. 10个模型还好说，当有100个模型时，谁为主，谁为辅，这个需要调优。
|
||
|
||
其他没有什么问题了，那么这个《cognitive-OS-wantsong 项目总计划 v0.1》是否应该你出，而不是Codex。
|
||
你出一个初稿后我审核没问题，再交给Codex？
|
||
|
||
是的，这份《cognitive-OS-wantsong 项目总计划 v0.1》**应该由我先出，不应该让 Codex 先写**。
|
||
|
||
原因很简单：Codex 是执行器，它天然会把模糊目标翻译成文件、目录、脚本、协议、校验和工程任务。旧项目已经证明，一旦没有上层产品蓝图，Codex 会把项目推向“模型治理重力场”，而不是“产品运行时重力场”。旧项目的问题不是完全无效，而是优化了错误目标：它证明了 QPI 和思想考古可以被治理成 file-first 资产，但没有证明 AI 能否串联你的模型、产生接近你思考方式的真实输出。
|
||
|
||
所以正确流程是：
|
||
|
||
```text
|
||
我出项目总计划初稿
|
||
-> 你审核、删改、确认
|
||
-> 我再压缩成 Codex 执行版
|
||
-> Codex 只负责按计划创建仓库、文件、流程和样例
|
||
```
|
||
|
||
下面是初稿。
|
||
|
||
---
|
||
|
||
# 《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 初稿`。
|
||
|
||
# 3
|
||
|
||
原先项目里还保存了`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 是“治理实验室的知识沉淀”；
|
||
新项目需要的是“认知加工运行时的操作原则”。
|
||
```
|
||
|
||
二者不能直接等价。
|
||
|
||
|
||
# 4
|
||
|
||
M0-M1搭建完了，在M2时，我发现：
|
||
|
||
1. 当前模型质量很差，尽管`the-mindscape-of-bro-tsong` 已经跑了4~5亿Tokens，但是我觉得全部是白费功夫。你可以看下基于现在的`intellectual-archaeology.md`能否跑出来这样的考古报告：`人类通用认知的七层架构-思想考古报告.md`。我们的重点不是模型的边界，而是模拟使用这些模型，参考我的考古过程`人类通用认知的七层架构-思想考古过程.md`
|
||
2. 之前一直都在讨论模型的准入，而不是模型的质量；关注在模型的结构，比如有哪些字段，而不是内容上，内容全不全，有没有遗漏；关注在两个模型的顺序，而不是具体模型怎么使用。
|
||
3. 从 2 推出，之前的项目我认为基本上没有可取之处了。而且这个过程，实际上是Codex在执行，发出具体指令建议的是WEB CCRA，决策的是我。开始我没搞清楚一个治理体系是什么样的，现在看下来完全脱离业务目标。
|
||
4. 我们需要将模型固定在一个稳定可用的版本上，再去基于此打造Agent/Skill。
|
||
5. 所以，我们需要重新提炼模型。这次选用的QPI和思想考古，正是我之前已经有了提炼出来的模型，跑出来的报告。我觉得可以快一些，没想到全浪费了。也可以对比之前QPI模型与智能体的结合——`房玄龄.md`，现在`QPI.md`能打造出来这样的效果么？
|
||
|
||
现在这个计划，我认为也没啥用，属于看似正确，实则跑偏。
|
||
|
||
---
|
||
|
||
对此，作为Web CCRA，你怎么看？
|
||
|
||
|