61 KiB
61 KiB
《核心模型抽取样板 v0.1》
版本：v0.1 用途：交给 Codex 建立“模型库 / 模型管理子系统 MVP”的工程样板 当前样板模型：QPI、思想考古 第一使用者：你本人 当前阶段：模型管理子系统 MVP 前置规范，不是完整产品计划书
这份样板承接你默认产品计划书中的几个核心模块：模型卡结构、数据结构初稿、Agentic 工作流草案、模型调用与冲突处理规则、回归测试与评估机制、给 Codex 的开发前置说明。
0. 核心判断
当前阶段不要让 Codex 直接开发“完整模型管理后台”。
第一阶段真正要验证的是：
能否把你的核心认知模型，从文章和既有表述中抽取成一套既能被人理解、又能被系统调用、还能被回归测试的模型资产结构。
所以这个样板工程的目标不是做漂亮后台，而是跑通一条最小链路：
原始文章 / 代表文本
→ 来源文章索引
→ 关键证据片段
→ 人读模型卡
→ 机器可读模型 JSON
→ 回归测试用例
→ 最小模型选择器
如果这条链路跑通，再扩展到 8-10 个核心模型。 如果这条链路不稳，贸然扩展模型数量只会制造一批“看起来完整、实际不可调用”的模型卡。
1. 文档目标
1.1 本文档要解决什么
本文档用于指导 Codex 完成一个 核心模型抽取样板工程。
它要让 Codex 明确：
- 模型库应该采用什么目录结构；
- 模型卡应该包含哪些字段；
- QPI 和思想考古两个模型如何被抽成样板；
- 来源文章和证据片段如何关联；
- 模型如何被系统调用；
- 模型如何做回归测试；
- 后续扩展到 8-10 个核心模型时应该遵守什么规范。
1.2 本文档不解决什么
本阶段不做：
完整模型管理后台
完整知识图谱
100 多个模型全量管理
自动从所有文章抽取模型
复杂 RAG 知识库
复杂用户系统
公开平台
权限系统
计费系统
多人协作系统
完整问题回答产品
本阶段只做 核心模型库的工程样板。
2. 样板工程的 MVP 定义
2.1 一句话定义
核心模型抽取样板 v0.1 是一个 file-first 的模型库工程样板，用 QPI 和思想考古两个核心模型验证“文章 → 证据片段 → 模型卡 → 机器 JSON → 回归测试 → 最小选择器”的完整链路。
2.2 MVP 验证命题
第一阶段要验证的核心命题是：
少量核心认知模型，能否被整理成结构化、可追溯、可调用、可测试的模型资产，并为后续问题回答系统提供稳定底座。
2.3 MVP 最小产物
Codex 完成后，至少应该产出：
1. 模型库目录结构
2. model_card.schema.json
3. source_article.schema.json
4. source_excerpt.schema.json
5. regression_case.schema.json
6. QPI 人读模型卡
7. QPI 机器可读 JSON
8. 思想考古人读模型卡
9. 思想考古机器可读 JSON
10. 来源文章索引
11. 关键证据片段索引
12. 两个模型的回归测试用例
13. 最小模型选择器
14. 校验脚本或校验说明
15. README.md
3. 核心抽取原则
3.1 模型抽取不是文章摘要
文章摘要回答的是：
这篇文章讲了什么？
模型抽取回答的是：
这篇文章中有哪些可复用的认知机制？
这些机制能处理什么输入？
能输出什么结果？
什么时候该调用？
什么时候不该调用？
如何测试它是否被误用？
所以模型抽取不能停留在“总结观点”，必须形成可调用规格。
3.2 模型卡必须有来源证据
每个核心字段都要尽量能追溯到来源：
模型定义 ← 来源文章 / 关键段落
核心机制 ← 来源文章 / 关键段落
适用场景 ← 来源文章 / 代表案例 / 后续推导
不适用场景 ← 红队推导 / 反例测试
调用规则 ← 产品化推导
回归测试 ← 模型边界推导
不能让模型卡变成脱离原文的二次包装。
3.3 区分“传播用模型”和“系统调用用模型”
传播用模型可以有表达性、隐喻性、文学性。
系统调用用模型必须满足：
概念清楚
输入清楚
输出清楚
适用边界清楚
误用风险清楚
调用条件清楚
测试方式清楚
QPI 和思想考古进入模型库时，都要按“系统调用用模型”重构，而不是保留为文章中的原始表达。
3.4 第一版允许半自动，不追求全自动
Codex 不应该在 v0.1 阶段尝试自动完成全部模型抽取。
更合理的路径是：
人工提供两个样板模型
Codex 建立 schema、目录、校验器、选择器
后续再用同一结构扩展更多模型
当前目标是“规范稳定”，不是“自动化程度高”。
4. 文章到模型的抽取协议
建议把抽取分成 5 层。
第 1 层：来源文章层
第 2 层：证据片段层
第 3 层：人读模型卡层
第 4 层：机器调用规格层
第 5 层：回归测试层
4.1 第 1 层：来源文章层
记录模型来自哪些文章、代表文本或讨论材料。
每篇来源文章至少包含：
{
"source_id": "article_qpi_primary_001",
"title": "问题之锚：从混沌现实到认知秩序的重构",
"author": "Wantsong",
"date": "unknown",
"source_type": "original_article",
"file_path": "sources/articles/qpi_primary.md",
"related_models": ["qpi"],
"source_status": "representative",
"notes": "QPI 的主要来源文本，用于抽取 Question / Problem / Issue 三分结构。"
}
字段说明：
| 字段 | 说明 |
|---|---|
| source_id | 来源文章唯一 ID |
| title | 文章标题 |
| author | 作者 |
| date | 日期，不确定可写 unknown |
| source_type | original_article / transcript / note / discussion / excerpt |
| file_path | 本地文件路径或引用路径 |
| related_models | 关联模型 |
| source_status | primary / representative / supplementary / deprecated |
| notes | 备注 |
4.2 第 2 层：证据片段层
从来源文章中抽出关键片段。
注意：这里不只是摘录，而是要标记片段在模型中的功能。
片段类型建议：
| excerpt_type | 作用 |
|---|---|
| definition | 定义片段 |
| problem_origin | 问题来源片段 |
| mechanism | 机制片段 |
| taxonomy | 分类片段 |
| procedure | 操作流程片段 |
| boundary | 边界片段 |
| misuse | 误用片段 |
| example | 示例片段 |
| metaphor | 隐喻片段 |
| test | 测试片段 |
示例：
{
"excerpt_id": "qpi_excerpt_problem_confusion_001",
"source_id": "article_qpi_primary_001",
"related_model_id": "qpi",
"excerpt_type": "problem_origin",
"raw_excerpt": "待填入原文片段",
"summary": "同一个'问题'在不同角色眼中可能是事实缺口、路径障碍或系统性冲突，若不先定性，会导致认知错位和行动失灵。",
"used_for": [
"core_question",
"call_when",
"regression_tests"
],
"confidence": "medium",
"notes": "用于支撑 QPI 作为前置问题定性模型。"
}
4.3 第 3 层：人读模型卡层
人读模型卡用于你自己阅读、审查、修改和后续知识库沉淀。
它应该是 Markdown 格式。
每张人读模型卡至少包含：
## 模型名称
### 模型 ID
### 一句话定义
### 模型类型
### 所在流程位置
### 来源文章
### 来源证据片段
### 核心问题
### 核心机制
### 输入类型
### 输出类型
### 适用场景
### 不适用场景
### 调用关键词
### 负向触发条件
### 相关模型
### 冲突模型
### 学科底座关联
### 常见误用
### 失败信号
### 可信度等级
### 稳固性状态
### 回归测试状态
### 示例输入
### 示例输出
### 产品化建议
4.4 第 4 层：机器调用规格层
机器调用规格用于问题回答系统读取。
它应该是 JSON 或 YAML。 v0.1 建议统一先用 JSON，便于 schema 校验。
机器调用规格必须回答：
这个模型什么时候被调用？
什么时候不被调用？
输入是什么？
输出是什么？
调用优先级是多少？
适合放在流程哪个位置？
需要哪些前置模型？
后续可以接哪些模型？
与哪些模型冲突？
如何判断调用失败？
4.5 第 5 层：回归测试层
回归测试用于判断模型是否稳定。
每个核心模型至少有三类测试：
正向适用测试
边界测试
误用测试
建议每个模型 v0.1 至少有 5 个测试用例：
2 个正向适用
2 个边界案例
1 个误用案例
5. 建议目录结构
Codex 可以按下面结构创建样板工程。
model_library_mvp/
README.md
schemas/
model_card.schema.json
source_article.schema.json
source_excerpt.schema.json
regression_case.schema.json
models/
qpi.model.json
intellectual_archaeology.model.json
cards/
qpi.card.md
intellectual_archaeology.card.md
sources/
source_articles.json
source_excerpts.json
tests/
qpi.regression.json
intellectual_archaeology.regression.json
selector/
selection_rules.json
selector_examples.json
scripts/
validate_models.py
validate_sources.py
validate_tests.py
run_selector_demo.py
reports/
validation_report.md
extraction_notes.md
v0.1 可以没有前端界面。 只要目录、schema、样例数据、校验脚本、选择器 demo 能跑通，就算完成第一步。
6. 模型卡核心字段规范
6.1 必填字段
[
"model_id",
"model_name",
"model_type",
"pipeline_position",
"one_sentence_definition",
"core_question",
"core_mechanism",
"source_articles",
"source_evidence",
"input_types",
"output_types",
"call_when",
"do_not_call_when",
"common_misuses",
"failure_modes",
"selection_priority",
"confidence_level",
"stability_profile",
"regression_status",
"productization_notes"
]
6.2 推荐字段
[
"trigger_keywords",
"negative_triggers",
"related_models",
"conflicting_models",
"disciplinary_anchors",
"example_inputs",
"example_outputs",
"output_contract",
"depth_control",
"stabilization_path",
"version",
"last_updated"
]
7. 枚举值建议
7.1 model_type
[
"routing_model",
"deep_modeling_model",
"lens_model",
"diagnostic_model",
"evaluation_model",
"generation_model",
"conflict_resolution_model",
"stabilization_model"
]
7.2 pipeline_position
[
"pre_analysis",
"analysis",
"deep_analysis",
"synthesis",
"red_team",
"evaluation",
"post_processing"
]
7.3 confidence_level
[
"high",
"medium",
"low"
]
7.4 regression_status
[
"not_started",
"pending",
"in_progress",
"passed",
"failed",
"needs_rebuild"
]
7.5 stability_level
[
"A",
"B",
"C",
"D"
]
建议含义：
| 等级 | 含义 |
|---|---|
| A | 高稳固，可进入核心调用 |
| B | 基本稳固，需要边界测试 |
| C | 有解释力，但概念或边界不稳 |
| D | 暂不适合系统调用，需要重构 |
8. model_card.schema.json 草案
Codex 可以先按这个草案实现，后续再细化。
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Cognitive Model Card",
"type": "object",
"required": [
"model_id",
"model_name",
"model_type",
"pipeline_position",
"one_sentence_definition",
"core_question",
"core_mechanism",
"source_articles",
"source_evidence",
"input_types",
"output_types",
"call_when",
"do_not_call_when",
"common_misuses",
"failure_modes",
"selection_priority",
"confidence_level",
"stability_profile",
"regression_status",
"productization_notes"
],
"properties": {
"model_id": {
"type": "string"
},
"model_name": {
"type": "string"
},
"model_type": {
"type": "string",
"enum": [
"routing_model",
"deep_modeling_model",
"lens_model",
"diagnostic_model",
"evaluation_model",
"generation_model",
"conflict_resolution_model",
"stabilization_model"
]
},
"pipeline_position": {
"type": "string",
"enum": [
"pre_analysis",
"analysis",
"deep_analysis",
"synthesis",
"red_team",
"evaluation",
"post_processing"
]
},
"one_sentence_definition": {
"type": "string"
},
"core_question": {
"type": "string"
},
"core_mechanism": {
"type": "string"
},
"source_articles": {
"type": "array",
"items": {
"type": "string"
}
},
"source_evidence": {
"type": "array",
"items": {
"type": "string"
}
},
"input_types": {
"type": "array",
"items": {
"type": "string"
}
},
"output_types": {
"type": "array",
"items": {
"type": "string"
}
},
"call_when": {
"type": "array",
"items": {
"type": "string"
}
},
"do_not_call_when": {
"type": "array",
"items": {
"type": "string"
}
},
"trigger_keywords": {
"type": "array",
"items": {
"type": "string"
}
},
"negative_triggers": {
"type": "array",
"items": {
"type": "string"
}
},
"related_models": {
"type": "array",
"items": {
"type": "string"
}
},
"conflicting_models": {
"type": "array",
"items": {
"type": "string"
}
},
"disciplinary_anchors": {
"type": "array",
"items": {
"type": "string"
}
},
"common_misuses": {
"type": "array",
"items": {
"type": "string"
}
},
"failure_modes": {
"type": "array",
"items": {
"type": "string"
}
},
"selection_priority": {
"type": "integer",
"minimum": 1,
"maximum": 10
},
"confidence_level": {
"type": "string",
"enum": [
"high",
"medium",
"low"
]
},
"stability_profile": {
"type": "object",
"required": [
"stability_level",
"needs_stabilization",
"main_risks"
],
"properties": {
"stability_level": {
"type": "string",
"enum": [
"A",
"B",
"C",
"D"
]
},
"needs_stabilization": {
"type": "boolean"
},
"main_risks": {
"type": "array",
"items": {
"type": "string"
}
},
"stabilization_notes": {
"type": "string"
}
}
},
"regression_status": {
"type": "string",
"enum": [
"not_started",
"pending",
"in_progress",
"passed",
"failed",
"needs_rebuild"
]
},
"example_inputs": {
"type": "array",
"items": {
"type": "string"
}
},
"example_outputs": {
"type": "array",
"items": {
"type": "string"
}
},
"output_contract": {
"type": "array",
"items": {
"type": "string"
}
},
"productization_notes": {
"type": "string"
},
"version": {
"type": "string"
},
"last_updated": {
"type": "string"
}
}
}
9. source_article.schema.json 草案
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Source Article",
"type": "object",
"required": [
"source_id",
"title",
"source_type",
"related_models",
"source_status"
],
"properties": {
"source_id": {
"type": "string"
},
"title": {
"type": "string"
},
"author": {
"type": "string"
},
"date": {
"type": "string"
},
"source_type": {
"type": "string",
"enum": [
"original_article",
"representative_text",
"discussion_note",
"transcript",
"excerpt",
"other"
]
},
"file_path": {
"type": "string"
},
"related_models": {
"type": "array",
"items": {
"type": "string"
}
},
"source_status": {
"type": "string",
"enum": [
"primary",
"representative",
"supplementary",
"deprecated",
"unknown"
]
},
"notes": {
"type": "string"
}
}
}
10. source_excerpt.schema.json 草案
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Source Excerpt",
"type": "object",
"required": [
"excerpt_id",
"source_id",
"related_model_id",
"excerpt_type",
"summary",
"used_for"
],
"properties": {
"excerpt_id": {
"type": "string"
},
"source_id": {
"type": "string"
},
"related_model_id": {
"type": "string"
},
"excerpt_type": {
"type": "string",
"enum": [
"definition",
"problem_origin",
"mechanism",
"taxonomy",
"procedure",
"boundary",
"misuse",
"example",
"metaphor",
"test",
"other"
]
},
"raw_excerpt": {
"type": "string"
},
"summary": {
"type": "string"
},
"used_for": {
"type": "array",
"items": {
"type": "string"
}
},
"confidence": {
"type": "string",
"enum": [
"high",
"medium",
"low"
]
},
"notes": {
"type": "string"
}
}
}
11. regression_case.schema.json 草案
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Regression Case",
"type": "object",
"required": [
"case_id",
"model_id",
"case_type",
"input",
"expected_behavior",
"failure_signal"
],
"properties": {
"case_id": {
"type": "string"
},
"model_id": {
"type": "string"
},
"case_type": {
"type": "string",
"enum": [
"positive",
"boundary",
"misuse",
"conflict",
"stress"
]
},
"input": {
"type": "string"
},
"expected_behavior": {
"type": "string"
},
"expected_output_elements": {
"type": "array",
"items": {
"type": "string"
}
},
"failure_signal": {
"type": "string"
},
"notes": {
"type": "string"
}
}
}
12. 样板模型一：QPI
12.1 QPI 人读模型卡 v0.1
## QPI 问题定性模型
### 模型 ID
qpi
### 一句话定义
QPI 是一个问题定性与认知路由模型，用来判断当前输入到底是缺信息的 Question、缺路径的 Problem，还是缺稳定性 / 共识的 Issue，并据此决定后续处理路径。
### 模型类型
routing_model
### 所在流程位置
pre_analysis
QPI 应该放在问题回答系统的前置阶段。
它不是直接回答问题，而是先判断“这是什么类型的问题”。
### 来源文章
- article_qpi_primary_001：问题之锚：从混沌现实到认知秩序的重构
- article_qpi_supplementary_001：QPI 后续讨论或补充材料，待补充
### 来源证据片段
- qpi_excerpt_problem_confusion_001
- qpi_excerpt_taxonomy_001
- qpi_excerpt_misuse_001
- qpi_excerpt_action_path_001
### 核心问题
当前输入到底是：
1. 缺事实、数据、信息的 Question；
2. 缺路径、方案、资源的 Problem；
3. 缺稳定性、共识、动态平衡的 Issue？
### 核心机制
QPI 通过识别“核心匮乏物”来区分问题类型：
- Question：核心匮乏是信息；
- Problem：核心匮乏是路径；
- Issue：核心匮乏是稳定性、共识或动态平衡。
不同类型的问题对应不同处理范式：
- Question 适合搜索、查证、信息补全；
- Problem 适合工程求解、路径设计、资源调度；
- Issue 适合生态干预、博弈分析、结构调整、长期适应。
### 输入类型
- 模糊问题
- 复杂问题
- 产品问题
- 组织问题
- 认知困惑
- 战略判断
- 多方冲突文本
- 用户不知道该如何定义的问题
### 输出类型
- Q / P / I 分类
- 分类理由
- 误判风险
- 推荐处理路径
- 是否需要调用后续模型
- 是否需要深度下潜
### 适用场景
适合在以下场景调用：
1. 用户输入的问题定义不清；
2. 同一问题被不同主体以不同方式理解；
3. 用户急于求解，但尚未判断问题性质；
4. 问题中混杂了事实、路径、利益、共识和系统结构；
5. 需要决定后续调用哪些认知模型；
6. 需要防止把复杂 Issue 简化成普通 Problem。
### 不适用场景
不适合在以下场景调用：
1. 用户只是查询明确事实；
2. 用户已经给出明确执行任务；
3. 输入是纯创意写作，不需要问题定性；
4. 问题已经被清楚分类，只需要执行后续步骤；
5. 时间窗口极短，只允许直接行动。
### 调用关键词
- 问题到底是什么
- 为什么解决不了
- 到底卡在哪里
- 这是技术问题还是组织问题
- 是不是方向错了
- 为什么反复出现
- 该怎么定义这个问题
- 这个问题应该怎么拆
### 负向触发条件
以下情况要降低 QPI 调用优先级：
- 用户要求直接查事实；
- 用户要求直接改写文本；
- 用户要求直接生成清单；
- 输入中没有明显的问题定义困难；
- 输入已经指定使用其他模型。
### 相关模型
- 思想考古
- 认知棱镜
- 认知显影
- 问题分层类模型
- 冲突汇总类模型
### 冲突模型
暂不指定具体冲突模型。
但 QPI 与“直接给答案”的流程存在流程冲突：如果 QPI 判断尚未完成，不应急于进入回答。
### 学科底座关联
- 问题定义理论
- 决策科学
- 系统论
- 复杂系统
- 组织行为
- 设计思维
- 工程问题分解
### 常见误用
1. 把所有复杂问题都判断成 Issue；
2. 把系统性 Issue 暴力降维成个体 Problem；
3. 把具体可解决的 Problem 恶意升维成无法处理的 Issue；
4. 在 Question 阶段过度建模；
5. 把 QPI 当成最终分析模型，而不是前置路由模型。
### 失败信号
如果系统出现以下情况，说明 QPI 调用失败：
1. 面对事实查询却输出复杂系统分析；
2. 面对组织性 Issue 却只给个人行动清单；
3. 面对具体执行 Problem 却泛化到宏大结构；
4. 分类没有给出理由；
5. 分类之后没有给出后续处理路径。
### 可信度等级
medium
### 稳固性状态
B
说明：
QPI 的基本结构清晰，适合作为入口模型。
但它需要大量边界案例测试，尤其要防止“所有问题都升维成 Issue”。
### 回归测试状态
pending
### 示例输入
“我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？”
### 示例输出
该输入更接近 Issue，而不是普通 Problem。
理由：
1. 它不是单纯缺信息；
2. 也不是简单缺执行路径；
3. 它涉及激励结构、时间尺度冲突、组织共识和多主体行为；
4. 如果把它当成 Problem，只给执行清单，很可能治标不治本。
推荐后续调用：
- 思想考古：下潜其深层结构；
- 冲突汇总模型：识别长期主义与短期 KPI 的冲突；
- 学科底座校准：组织行为与激励机制。
### 产品化建议
QPI 应作为问题回答系统的默认前置路由模型之一。
它的核心价值不是生成深刻答案，而是防止系统在问题类型错误的情况下直接回答。
12.2 QPI 机器调用 JSON v0.1
{
"model_id": "qpi",
"model_name": "QPI 问题定性模型",
"model_type": "routing_model",
"pipeline_position": "pre_analysis",
"one_sentence_definition": "QPI 是一个问题定性与认知路由模型，用来判断当前输入到底是缺信息的 Question、缺路径的 Problem，还是缺稳定性 / 共识的 Issue，并据此决定后续处理路径。",
"core_question": "当前输入到底是 Question、Problem 还是 Issue？",
"core_mechanism": "QPI 通过识别问题中的核心匮乏物进行分类：Question 缺信息，Problem 缺路径，Issue 缺稳定性、共识或动态平衡。不同类型的问题对应不同处理范式。",
"source_articles": [
"article_qpi_primary_001",
"article_qpi_supplementary_001"
],
"source_evidence": [
"qpi_excerpt_problem_confusion_001",
"qpi_excerpt_taxonomy_001",
"qpi_excerpt_misuse_001",
"qpi_excerpt_action_path_001"
],
"input_types": [
"模糊问题",
"复杂问题",
"产品问题",
"组织问题",
"认知困惑",
"战略判断",
"多方冲突文本"
],
"output_types": [
"问题类型判断",
"分类理由",
"误判风险",
"推荐处理路径",
"后续模型调用建议"
],
"call_when": [
"用户输入的问题定义不清",
"同一问题被不同主体以不同方式理解",
"用户急于求解但尚未判断问题性质",
"问题中混杂事实、路径、利益、共识和系统结构",
"需要决定后续调用哪些认知模型"
],
"do_not_call_when": [
"用户只是查询明确事实",
"用户已经给出明确执行任务",
"输入是纯创意写作且不需要问题定性",
"问题已经被清楚分类且只需要执行后续步骤"
],
"trigger_keywords": [
"问题到底是什么",
"为什么解决不了",
"卡在哪里",
"技术问题还是组织问题",
"方向是不是错了",
"为什么反复出现",
"该怎么定义这个问题",
"这个问题怎么拆"
],
"negative_triggers": [
"请直接查询",
"请直接改写",
"只要清单",
"不要分析原因",
"不要展开"
],
"related_models": [
"intellectual_archaeology",
"cognitive_prism",
"cognitive_development"
],
"conflicting_models": [],
"disciplinary_anchors": [
"问题定义理论",
"决策科学",
"系统论",
"复杂系统",
"组织行为",
"工程问题分解"
],
"common_misuses": [
"把所有复杂问题都判断成 Issue",
"把系统性 Issue 暴力降维成个体 Problem",
"把具体可解决的 Problem 恶意升维成无法处理的 Issue",
"在 Question 阶段过度建模",
"把 QPI 当成最终分析模型而不是前置路由模型"
],
"failure_modes": [
"面对事实查询却输出复杂系统分析",
"面对组织性 Issue 却只给个人行动清单",
"面对具体执行 Problem 却泛化到宏大结构",
"分类没有给出理由",
"分类之后没有给出后续处理路径"
],
"selection_priority": 9,
"confidence_level": "medium",
"stability_profile": {
"stability_level": "B",
"needs_stabilization": true,
"main_risks": [
"边界案例需要测试",
"容易把复杂问题过度升维为 Issue",
"Question / Problem / Issue 的判断标准需要进一步示例化"
],
"stabilization_notes": "优先补充正向、边界、误用三类测试案例，形成分类判准。"
},
"regression_status": "pending",
"example_inputs": [
"我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
"我知道要做模型库，但不知道先用数据库还是文件系统，这属于什么问题？"
],
"example_outputs": [
"第一个输入更接近 Issue，因为它涉及激励结构、时间尺度冲突和组织共识。",
"第二个输入更接近 Problem，因为目标明确，主要缺的是实现路径和技术取舍。"
],
"output_contract": [
"判断输入属于 Question、Problem、Issue 或混合型",
"说明分类理由",
"指出可能误判",
"给出推荐处理路径",
"建议后续调用模型"
],
"productization_notes": "QPI 应作为问题回答系统的前置路由模型，用于防止系统在问题类型错误的情况下直接给答案。",
"version": "0.1",
"last_updated": "2026-06-15"
}
12.3 QPI 来源片段样例
[
{
"excerpt_id": "qpi_excerpt_problem_confusion_001",
"source_id": "article_qpi_primary_001",
"related_model_id": "qpi",
"excerpt_type": "problem_origin",
"raw_excerpt": "待填入原文片段",
"summary": "同一个'问题'在不同角色眼中可能是事实缺口、路径障碍或系统性冲突，若不先定性，会导致认知错位和行动失灵。",
"used_for": [
"core_question",
"call_when",
"example_inputs"
],
"confidence": "medium",
"notes": "用于支撑 QPI 作为问题定性模型。"
},
{
"excerpt_id": "qpi_excerpt_taxonomy_001",
"source_id": "article_qpi_primary_001",
"related_model_id": "qpi",
"excerpt_type": "taxonomy",
"raw_excerpt": "待填入原文片段",
"summary": "QPI 将问题划分为 Question、Problem、Issue 三类，分别对应信息匮乏、路径匮乏、稳定性或共识匮乏。",
"used_for": [
"core_mechanism",
"output_contract",
"regression_tests"
],
"confidence": "high",
"notes": "用于支撑 QPI 的核心三分结构。"
},
{
"excerpt_id": "qpi_excerpt_misuse_001",
"source_id": "article_qpi_primary_001",
"related_model_id": "qpi",
"excerpt_type": "misuse",
"raw_excerpt": "待填入原文片段",
"summary": "QPI 的误用包括把 Issue 降维成 Problem，或把 Problem 升维成不可处理的 Issue。",
"used_for": [
"common_misuses",
"failure_modes"
],
"confidence": "medium",
"notes": "用于支撑 QPI 的边界和误用检查。"
}
]
12.4 QPI 回归测试样例
[
{
"case_id": "qpi_positive_question_001",
"model_id": "qpi",
"case_type": "positive",
"input": "这段代码为什么报错？",
"expected_behavior": "应判断为 Question 或偏 Question，因为当前主要缺少具体错误信息、日志、代码上下文等事实材料。",
"expected_output_elements": [
"判断为 Question",
"要求补充事实信息",
"不应过度建模"
],
"failure_signal": "系统开始讨论组织结构、人生意义或复杂系统，而没有要求补充事实信息。",
"notes": "测试 QPI 是否能识别简单信息缺口。"
},
{
"case_id": "qpi_positive_problem_001",
"model_id": "qpi",
"case_type": "positive",
"input": "我知道要先做模型库，但不知道应该用数据库还是 JSON 文件。",
"expected_behavior": "应判断为 Problem，因为目标基本明确，主要缺的是实现路径和技术取舍。",
"expected_output_elements": [
"判断为 Problem",
"指出目标明确但路径未定",
"建议进行工程取舍分析"
],
"failure_signal": "系统把问题上升到知识哲学层面，忽略具体实现路径。",
"notes": "测试 QPI 是否能识别路径缺口。"
},
{
"case_id": "qpi_positive_issue_001",
"model_id": "qpi",
"case_type": "positive",
"input": "团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
"expected_behavior": "应判断为 Issue，因为它涉及激励结构、时间尺度冲突、多主体行为和组织共识。",
"expected_output_elements": [
"判断为 Issue",
"指出不是简单执行问题",
"建议分析激励结构和组织反馈"
],
"failure_signal": "系统只给出个人执行清单，例如'制定计划、加强沟通、定期复盘'。",
"notes": "测试 QPI 是否能识别系统性稳定问题。"
},
{
"case_id": "qpi_boundary_mixed_001",
"model_id": "qpi",
"case_type": "boundary",
"input": "我的产品方向不确定，也不知道用户到底要什么，还担心技术做不出来。",
"expected_behavior": "应判断为混合型问题，包含 Question、Problem 和 Issue，但需要指出当前优先处理的问题类型。",
"expected_output_elements": [
"识别混合型",
"拆分信息缺口、路径缺口和稳定性缺口",
"给出处理优先级"
],
"failure_signal": "系统强行只判为一种类型，且不说明混合成分。",
"notes": "测试 QPI 对混合问题的处理能力。"
},
{
"case_id": "qpi_misuse_over_issue_001",
"model_id": "qpi",
"case_type": "misuse",
"input": "我不知道 Notion 的这个按钮在哪里。",
"expected_behavior": "应判断为 Question，不应升维为 Issue。",
"expected_output_elements": [
"判断为 Question",
"建议查找界面位置或文档",
"不做宏大分析"
],
"failure_signal": "系统讨论现代工具复杂性、用户控制感、信息架构困境等宏大问题。",
"notes": "防止 QPI 过度升维。"
}
]
13. 样板模型二：思想考古
13.1 思想考古人读模型卡 v0.1
## 思想考古模型
### 模型 ID
intellectual_archaeology
### 一句话定义
思想考古是一个纵向下潜模型，用来从表层现象一路追问到过程层、机理层、目的层、人类能力层乃至哲学基岩，从而识别问题或模型背后的深层结构和隐含假设。
### 模型类型
deep_modeling_model
### 所在流程位置
deep_analysis
思想考古不适合作为所有问题的默认入口。
它应在 QPI 定性之后，被用于高复用、高复杂度、需要沉淀方法论或模型的问题。
### 来源文章
- article_archaeology_primary_001：建模者的工坊：一场将直觉锻造成罗盘的认知炼金术
- article_archaeology_supplementary_001：思想考古相关后续讨论，待补充
### 来源证据片段
- archaeology_excerpt_depth_001
- archaeology_excerpt_layers_001
- archaeology_excerpt_boundary_001
- archaeology_excerpt_modeling_001
### 核心问题
当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？
具体包括：
1. 它表面上在处理什么；
2. 它依赖什么评价标准；
3. 它背后有哪些过程和机制；
4. 它服务什么目的；
5. 它依赖什么核心机理；
6. 它对应人类哪种能力；
7. 它背后有哪些哲学前提。
### 核心机制
思想考古通过纵向下潜，把一个表层问题拆到更深层的结构。
建议七层结构如下：
1. 应用层：具体工具、流程、指标、场景；
2. 评价层：如何判断好坏、成功与失败；
3. 过程层：实际运作过程、操作链条、反馈机制；
4. 目的层：最终服务的目标和价值原子；
5. 核心机理层：系统如何学习、演化、自适应；
6. 人类能力层：它对应人类怎样的问题解决能力；
7. 哲学基岩层：它关于问题、知识、现实、主体的根本假设。
### 输入类型
- 复杂问题
- 系统性议题
- 反复失败的问题
- 需要沉淀方法论的问题
- 专家隐性知识
- 认知模型草稿
- 产品底层逻辑
- 长期可复用的分析对象
### 输出类型
- 层级化问题地图
- 深层假设清单
- 最小充分下潜层级
- 模型稳固性判断
- 需要验证的薄弱环节
- 后续建模建议
### 适用场景
适合在以下场景调用：
1. QPI 判断问题偏 Issue；
2. 问题具有高复用价值；
3. 用户希望从文章中抽取模型；
4. 当前解释停留在表层工具或症状；
5. 需要把专家隐性知识显性化；
6. 需要为一个模型寻找更稳固的底层结构；
7. 一个问题反复解决但反复失败。
### 不适用场景
不适合在以下场景调用：
1. 简单事实查询；
2. 明确执行任务；
3. 低风险、低复用问题；
4. 用户只要快速输出，不需要深层建模；
5. 继续下潜不会改变决策；
6. 缺乏证据，无法支持深层推断。
### 调用关键词
- 背后的深层结构
- 底层逻辑
- 这个模型稳不稳
- 为什么反复失败
- 这个问题的根在哪里
- 这个想法能不能沉淀成模型
- 如何从文章抽取模型
- 这个方法论的基岩是什么
### 负向触发条件
以下情况要降低调用优先级：
- 用户明确要求快速答案；
- 问题只需要查事实；
- 问题不值得重型建模；
- 当前信息不足以支持深层推断；
- 使用 QPI 后判断为轻量 Question。
### 相关模型
- QPI
- 认知棱镜
- 认知显影
- 建模者委员会
- 回归测试模型
- 学科底座校准模型
### 冲突模型
思想考古与“快速执行模型”存在成本冲突。
如果任务目标是快速完成一个低复用动作，思想考古可能过重。
### 学科底座关联
- 哲学
- 认识论
- 系统论
- 复杂系统
- 认知心理学
- 专家知识显性化
- 因果推理
- 设计理论
### 常见误用
1. 为了显得深刻而无限下钻；
2. 把所有轻量问题都拖入七层分析；
3. 只做纵向下潜，缺少横向模型竞争；
4. 用哲学基岩替代现实验证；
5. 把隐喻性表达误当作稳定机制；
6. 下潜后没有回到可行动结论。
### 失败信号
如果系统出现以下情况，说明思想考古调用失败：
1. 分析很深，但不能改变判断或行动；
2. 层级之间没有清楚递进关系；
3. 把所有问题都下钻到哲学层；
4. 输出只有抽象概念，没有模型结构；
5. 没有说明应该在哪一层停止；
6. 没有指出需要证据验证的地方。
### 可信度等级
medium
### 稳固性状态
B
说明：
思想考古的方向清晰，适合做深度建模。
但七层结构需要进一步稳定，避免不同文章或不同任务中层级名称漂移。
### 回归测试状态
pending
### 示例输入
“我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？”
### 示例输出
该问题适合调用思想考古。
初步层级判断：
1. 应用层：把文章整理成模型库；
2. 评价层：判断模型是否稳固；
3. 过程层：从文章到证据片段，再到模型卡和测试用例；
4. 目的层：让模型能被问题回答系统调用；
5. 核心机理层：把隐性认知加工方式外化为可测试模块；
6. 人类能力层：外化专家直觉、提高问题加工稳定性；
7. 哲学基岩层：知识不是静态内容，而是可调用、可校准、可迭代的认知工具。
建议最小充分下潜到第 5 层。
暂时不必强行进入第 7 层，因为当前任务主要是产品化和工程样板。
### 产品化建议
思想考古应作为中重度问题的深层建模模块。
它不应该默认每次调用，而应由 QPI、问题复杂度和复用价值共同决定是否启动。
13.2 思想考古机器调用 JSON v0.1
{
"model_id": "intellectual_archaeology",
"model_name": "思想考古模型",
"model_type": "deep_modeling_model",
"pipeline_position": "deep_analysis",
"one_sentence_definition": "思想考古是一个纵向下潜模型，用来从表层现象一路追问到过程层、机理层、目的层、人类能力层乃至哲学基岩，从而识别问题或模型背后的深层结构和隐含假设。",
"core_question": "当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？",
"core_mechanism": "思想考古通过纵向下潜，把一个表层问题拆到更深层的结构。建议从应用层、评价层、过程层、目的层、核心机理层、人类能力层、哲学基岩层逐层分析，并遵守最小充分下潜原则。",
"source_articles": [
"article_archaeology_primary_001",
"article_archaeology_supplementary_001"
],
"source_evidence": [
"archaeology_excerpt_depth_001",
"archaeology_excerpt_layers_001",
"archaeology_excerpt_boundary_001",
"archaeology_excerpt_modeling_001"
],
"input_types": [
"复杂问题",
"系统性议题",
"反复失败的问题",
"需要沉淀方法论的问题",
"专家隐性知识",
"认知模型草稿",
"产品底层逻辑"
],
"output_types": [
"层级化问题地图",
"深层假设清单",
"最小充分下潜层级",
"模型稳固性判断",
"需要验证的薄弱环节",
"后续建模建议"
],
"call_when": [
"QPI 判断问题偏 Issue",
"问题具有高复用价值",
"用户希望从文章中抽取模型",
"当前解释停留在表层工具或症状",
"需要把专家隐性知识显性化",
"需要为一个模型寻找更稳固的底层结构",
"一个问题反复解决但反复失败"
],
"do_not_call_when": [
"简单事实查询",
"明确执行任务",
"低风险低复用问题",
"用户只要快速输出",
"继续下潜不会改变决策",
"缺乏证据支撑深层推断"
],
"trigger_keywords": [
"深层结构",
"底层逻辑",
"模型稳不稳",
"为什么反复失败",
"问题的根在哪里",
"沉淀成模型",
"从文章抽取模型",
"方法论的基岩"
],
"negative_triggers": [
"快速回答",
"不要展开",
"只查事实",
"只要执行步骤",
"不要深入分析"
],
"related_models": [
"qpi",
"cognitive_prism",
"cognitive_development",
"modeling_committee",
"regression_testing"
],
"conflicting_models": [
"fast_execution_flow"
],
"disciplinary_anchors": [
"哲学",
"认识论",
"系统论",
"复杂系统",
"认知心理学",
"专家知识显性化",
"因果推理",
"设计理论"
],
"common_misuses": [
"为了显得深刻而无限下钻",
"把所有轻量问题都拖入七层分析",
"只做纵向下潜而缺少横向模型竞争",
"用哲学基岩替代现实验证",
"把隐喻性表达误当作稳定机制",
"下潜后没有回到可行动结论"
],
"failure_modes": [
"分析很深但不能改变判断或行动",
"层级之间没有清楚递进关系",
"把所有问题都下钻到哲学层",
"输出只有抽象概念而没有模型结构",
"没有说明应该在哪一层停止",
"没有指出需要证据验证的地方"
],
"selection_priority": 7,
"confidence_level": "medium",
"stability_profile": {
"stability_level": "B",
"needs_stabilization": true,
"main_risks": [
"七层结构需要进一步稳定",
"容易过度下潜",
"容易输出抽象概念而缺少行动回路",
"需要更多真实案例验证"
],
"stabilization_notes": "优先补充不同复杂度问题的测试案例，明确最小充分下潜原则和停止条件。"
},
"regression_status": "pending",
"example_inputs": [
"我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？",
"现代人为什么一边渴望连接，一边又渴望逃离连接？"
],
"example_outputs": [
"第一个输入适合下潜到核心机理层，判断文章、模型卡、系统调用、回归测试之间的关系。",
"第二个输入可从应用层、评价层、过程层、目的层和人类能力层分析连接与逃离连接的双重机制。"
],
"output_contract": [
"判断当前问题所在表层",
"给出建议下潜层级",
"按层级输出结构化分析",
"指出每一层的关键假设",
"给出最小充分下潜停止点",
"标记需要证据或现实反馈校准的部分"
],
"depth_control": {
"principle": "最小充分下潜",
"stop_conditions": [
"已经足以改变决策",
"继续下潜不会增加解释力",
"缺少证据支撑更深推断",
"问题不值得重型建模",
"用户当前只需要执行层结果"
],
"overuse_warning": "思想考古不是所有问题的默认流程，必须先经过问题价值评估和 QPI 定性。"
},
"productization_notes": "思想考古适合作为中重度问题的深层建模模块，不应默认全量调用。它应该由 QPI、问题复杂度和复用价值共同触发。",
"version": "0.1",
"last_updated": "2026-06-15"
}
13.3 思想考古来源片段样例
[
{
"excerpt_id": "archaeology_excerpt_depth_001",
"source_id": "article_archaeology_primary_001",
"related_model_id": "intellectual_archaeology",
"excerpt_type": "mechanism",
"raw_excerpt": "待填入原文片段",
"summary": "思想考古要求从表层现象向深层结构下潜，通过层层追问识别问题背后的机制、目的和基岩假设。",
"used_for": [
"core_mechanism",
"call_when",
"output_contract"
],
"confidence": "medium",
"notes": "用于支撑思想考古作为纵向下潜模型。"
},
{
"excerpt_id": "archaeology_excerpt_layers_001",
"source_id": "article_archaeology_primary_001",
"related_model_id": "intellectual_archaeology",
"excerpt_type": "taxonomy",
"raw_excerpt": "待填入原文片段",
"summary": "思想考古可被整理为应用层、评价层、过程层、目的层、核心机理层、人类能力层和哲学基岩层。",
"used_for": [
"core_mechanism",
"example_outputs",
"regression_tests"
],
"confidence": "medium",
"notes": "七层结构需要在后续版本中继续校准。"
},
{
"excerpt_id": "archaeology_excerpt_boundary_001",
"source_id": "article_archaeology_primary_001",
"related_model_id": "intellectual_archaeology",
"excerpt_type": "boundary",
"raw_excerpt": "待填入原文片段",
"summary": "思想考古应遵守最小充分下潜原则，不应把所有问题都拖入重型建模流程。",
"used_for": [
"do_not_call_when",
"depth_control",
"common_misuses"
],
"confidence": "medium",
"notes": "用于防止思想考古过度使用。"
}
]
13.4 思想考古回归测试样例
[
{
"case_id": "archaeology_positive_modeling_001",
"model_id": "intellectual_archaeology",
"case_type": "positive",
"input": "我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？",
"expected_behavior": "应调用思想考古，将问题从文章整理下潜到模型稳固性、系统调用和认知能力外化层面。",
"expected_output_elements": [
"给出层级化分析",
"指出模型稳固性问题",
"说明最小充分下潜层级",
"回到可执行的模型抽取流程"
],
"failure_signal": "系统只给出普通资料整理建议，没有触及模型稳固性、调用规则和回归测试。",
"notes": "测试思想考古是否能用于模型抽取场景。"
},
{
"case_id": "archaeology_positive_issue_001",
"model_id": "intellectual_archaeology",
"case_type": "positive",
"input": "现代人为什么一边渴望连接，一边又渴望逃离连接？",
"expected_behavior": "应将问题下潜到连接的功能、连接带来的负荷、主体边界、社会反馈和人类关系需求等层级。",
"expected_output_elements": [
"识别表层矛盾",
"分析连接的收益与成本",
"指出深层心理或社会机制",
"避免只做情绪化解释"
],
"failure_signal": "系统只输出鸡汤式解释，例如'人既需要爱也需要自由'。",
"notes": "测试思想考古能否处理复杂认知现象。"
},
{
"case_id": "archaeology_boundary_light_task_001",
"model_id": "intellectual_archaeology",
"case_type": "boundary",
"input": "帮我把这句话改得更简洁。",
"expected_behavior": "不应调用思想考古，或只轻量说明无需深层建模。",
"expected_output_elements": [
"识别为轻量任务",
"不进入七层分析",
"直接执行改写"
],
"failure_signal": "系统开始分析语言背后的哲学基岩。",
"notes": "防止思想考古过度调用。"
},
{
"case_id": "archaeology_boundary_stop_depth_001",
"model_id": "intellectual_archaeology",
"case_type": "boundary",
"input": "我在设计模型库时，不确定模型卡字段要不要加'哲学基岩'。",
"expected_behavior": "应分析到产品调用和字段成本层面即可，不必强行进入完整七层。",
"expected_output_elements": [
"判断字段是否服务调用",
"说明哲学基岩可作为可选字段",
"提出最小充分方案"
],
"failure_signal": "系统展开大段哲学分析，却没有回答字段设计取舍。",
"notes": "测试最小充分下潜原则。"
},
{
"case_id": "archaeology_misuse_abstract_001",
"model_id": "intellectual_archaeology",
"case_type": "misuse",
"input": "我的模型管理 MVP 下一步要做什么？",
"expected_behavior": "如果调用思想考古，也必须回到可执行任务，不应只输出抽象层级。",
"expected_output_elements": [
"识别当前阶段",
"说明下潜对决策的帮助",
"输出下一步任务清单"
],
"failure_signal": "系统只讨论知识、现实、主体性等抽象概念，没有任务切片。",
"notes": "防止思想考古脱离产品规划。"
}
]
14. QPI 与思想考古的组合关系
这两个模型在系统中不是并列替代关系，而是前后衔接关系。
输入问题
→ QPI 判断问题类型
→ 判断是否需要深度下潜
→ 如果问题复杂、高复用、偏 Issue，则调用思想考古
→ 输出层级结构和深层假设
→ 后续再接其他横向棱镜模型
14.1 系统位置
| 模型 | 系统位置 | 作用 |
|---|---|---|
| QPI | pre_analysis | 判断问题类型，决定处理路径 |
| 思想考古 | deep_analysis | 对复杂问题进行纵向下潜 |
14.2 调用优先级
| 场景 | 推荐调用 |
|---|---|
| 问题定义不清 | 优先 QPI |
| 只是查事实 | 不调用思想考古 |
| 目标明确但路径未定 | QPI 后进入工程求解 |
| 多主体冲突 / 系统性反复失败 | QPI + 思想考古 |
| 需要从文章抽模型 | 思想考古 |
| 需要判断模型是否稳固 | 思想考古 + 回归测试 |
15. 最小模型选择器规则
v0.1 的模型选择器不需要复杂算法。
可以先使用规则 + 简单评分。
15.1 输入
{
"user_input": "团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
"task_type": "question_analysis",
"depth_preference": "medium"
}
15.2 输出
{
"recommended_models": [
{
"model_id": "qpi",
"score": 0.92,
"reason": "输入包含'到底是什么问题'，且存在问题定性需求。"
},
{
"model_id": "intellectual_archaeology",
"score": 0.78,
"reason": "该问题涉及长期主义、KPI、组织激励和反复失败，适合进行深层结构分析。"
}
],
"not_recommended_models": [],
"routing_notes": "先用 QPI 判断问题类型。如果判定为 Issue，再调用思想考古进行最小充分下潜。"
}
15.3 简单评分规则
建议先按 4 类信号评分：
1. trigger_keywords 命中
2. input_types 匹配
3. do_not_call_when 是否触发
4. pipeline_position 是否适合当前阶段
伪规则：
初始分 = 0
命中 trigger_keywords：+0.2
匹配 input_types：+0.2
任务阶段匹配 pipeline_position：+0.2
用户表达中出现复杂性 / 反复失败 / 多主体冲突：+0.2
模型 selection_priority 高：+0.1
命中 negative_triggers：-0.3
命中 do_not_call_when：-0.5
v0.1 只需要返回候选模型和推荐理由，不需要自动生成最终分析。
16. 最小 selector_examples.json
[
{
"example_id": "selector_example_001",
"user_input": "我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
"expected_models": [
"qpi",
"intellectual_archaeology"
],
"expected_reasoning": "先用 QPI 判断该问题更偏 Issue，再用思想考古分析其激励结构、时间尺度和组织共识。"
},
{
"example_id": "selector_example_002",
"user_input": "这段代码为什么报错？",
"expected_models": [
"qpi"
],
"expected_reasoning": "QPI 应将其判断为偏 Question，但不应继续调用思想考古。"
},
{
"example_id": "selector_example_003",
"user_input": "我想从一篇文章里抽出一个可复用的认知模型，应该怎么做？",
"expected_models": [
"intellectual_archaeology",
"qpi"
],
"expected_reasoning": "该问题涉及模型抽取和隐性知识显性化，思想考古适合主导；QPI 可用于前置判断任务性质。"
},
{
"example_id": "selector_example_004",
"user_input": "帮我把这句话改得更简洁。",
"expected_models": [],
"expected_reasoning": "这是轻量执行任务，不需要调用 QPI 或思想考古。"
}
]
17. 稳固性评级规则 v0.1
每个模型都要有稳定性评估，不要只写“可信度高 / 中 / 低”。
建议从 5 个维度评估：
概念清晰度
机制稳定性
边界清晰度
来源证据质量
回归测试表现
17.1 评分维度
| 维度 | 问题 |
|---|---|
| 概念清晰度 | 模型的核心概念是否清楚？ |
| 机制稳定性 | 模型是否有明确运作机制？ |
| 边界清晰度 | 是否知道什么时候不能用？ |
| 来源证据质量 | 是否能追溯到文章和关键片段？ |
| 回归测试表现 | 是否通过正向、边界、误用测试？ |
17.2 等级规则
| 等级 | 标准 |
|---|---|
| A | 五个维度都较稳定，可进入核心调用 |
| B | 基本可用，但需要边界案例测试 |
| C | 有启发，但系统调用风险较高 |
| D | 不适合进入模型库，需要重构 |
17.3 QPI 当前建议评级
{
"model_id": "qpi",
"stability_level": "B",
"reason": "三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。",
"next_stabilization_action": "补充混合问题、误用问题和轻量问题测试。"
}
17.4 思想考古当前建议评级
{
"model_id": "intellectual_archaeology",
"stability_level": "B",
"reason": "纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。",
"next_stabilization_action": "补充不同复杂度问题的下潜深度测试，明确最小充分下潜原则。"
}
18. Codex 开工任务
Task 1：创建工程目录
目标：
创建 model_library_mvp 目录
按本文档建立 schemas / models / cards / sources / tests / selector / scripts / reports
验收标准：
目录结构完整
README.md 存在
所有关键目录都有占位说明
Task 2：创建 JSON Schema
目标：
创建：
- model_card.schema.json
- source_article.schema.json
- source_excerpt.schema.json
- regression_case.schema.json
验收标准：
schema 可以被 jsonschema 校验工具读取
必填字段生效
枚举值生效
错误数据能被识别
Task 3：录入两个样板模型
目标：
创建：
- models/qpi.model.json
- models/intellectual_archaeology.model.json
- cards/qpi.card.md
- cards/intellectual_archaeology.card.md
验收标准：
两个 JSON 文件通过 model_card.schema.json 校验
两个 Markdown 卡片可读
字段与本文档基本一致
Task 4：创建来源索引和证据片段索引
目标：
创建：
- sources/source_articles.json
- sources/source_excerpts.json
验收标准：
source_articles.json 至少包含 QPI 和思想考古的来源记录
source_excerpts.json 至少包含两个模型各 3 条证据片段
模型卡中的 source_articles 和 source_evidence 能对应到实际 ID
Task 5：创建回归测试用例
目标：
创建：
- tests/qpi.regression.json
- tests/intellectual_archaeology.regression.json
验收标准：
每个模型至少 5 个测试用例
包含 positive、boundary、misuse 三类
测试用例通过 regression_case.schema.json 校验
Task 6：创建校验脚本
目标：
创建：
- scripts/validate_models.py
- scripts/validate_sources.py
- scripts/validate_tests.py
验收标准：
能检查 JSON 是否符合 schema
能检查 model_id 是否唯一
能检查 source_evidence 是否存在
能检查 regression_tests 是否引用了存在的 model_id
输出 validation_report.md
Task 7：创建最小模型选择器 demo
目标：
创建：
- selector/selection_rules.json
- selector/selector_examples.json
- scripts/run_selector_demo.py
验收标准：
输入一个问题
读取两个模型 JSON
根据关键词、输入类型、负向触发条件、selection_priority 返回候选模型
输出推荐理由
至少能跑通 selector_examples.json 中的样例
19. 验收标准总表
Codex 完成后，必须满足：
1. 项目目录结构完整
2. schema 文件存在并可校验
3. QPI 模型 JSON 存在并通过校验
4. 思想考古模型 JSON 存在并通过校验
5. 两张人读模型卡存在
6. 来源文章索引存在
7. 来源证据片段索引存在
8. 模型卡引用的 source_id 和 excerpt_id 能找到
9. 每个模型至少 5 个回归测试用例
10. 回归测试用例通过 schema 校验
11. 最小模型选择器能返回推荐模型和理由
12. README.md 说明如何运行校验和 selector demo
13. reports/validation_report.md 记录校验结果
不要求：
不要求前端界面
不要求数据库
不要求向量检索
不要求真实 LLM 调用
不要求完整问题回答系统
不要求自动抽取所有模型
20. Codex 返回 ChatGPT 时的交接材料
Codex 完成后，请整理一份：
Codex_工程产物摘要_v0.1.md
建议包含：
## Codex 工程产物摘要 v0.1
### 1. 当前完成阶段
### 2. 已创建目录结构
### 3. 已创建文件清单
### 4. Schema 实现情况
### 5. QPI 模型卡实现情况
### 6. 思想考古模型卡实现情况
### 7. 来源索引实现情况
### 8. 回归测试实现情况
### 9. 模型选择器实现情况
### 10. 校验结果
### 11. 与原计划不一致的地方
### 12. 当前发现的问题
### 13. 需要 ChatGPT / CCRA 判断的问题
### 14. 下一步建议
你回到 ChatGPT 新会话时，建议上传：
1. Codex_工程产物摘要_v0.1.md
2. README.md
3. model_card.schema.json
4. qpi.model.json
5. intellectual_archaeology.model.json
6. source_articles.json
7. source_excerpts.json
8. qpi.regression.json
9. intellectual_archaeology.regression.json
10. selector_examples.json
不要直接上传整个工程目录。 先让我判断结构是否合理，再决定是否需要看代码细节。
21. 下一阶段判断点
当 Codex 完成这个样板工程后，下一步不要立刻扩展到 100 多个模型。
应该先判断 5 个问题：
1. 当前模型卡 schema 是否过重？
2. QPI 和思想考古的字段是否足够支撑系统调用？
3. 来源证据片段是否真的能帮助追溯？
4. 回归测试是否能暴露模型误用？
5. 最小模型选择器是否足以推荐 3-5 个候选模型？
如果这 5 个问题基本通过，下一阶段再做：
扩展到 5 个核心模型
→ 扩展到 8-10 个核心模型
→ 接入最小问题回答链路
→ 让输入问题经过 QPI、模型选择器、多棱镜分析、冲突汇总、综合洞察输出
如果这 5 个问题没有通过，先修 schema 和抽取协议，不要扩展模型数量。
22. 给 Codex 的一句话指令
可以把下面这段直接放给 Codex：
请根据《核心模型抽取样板 v0.1》，创建一个 file-first 的 model_library_mvp 工程。不要开发完整后台，不要接数据库，不要做复杂 RAG。第一阶段只需要建立目录结构、JSON Schema、QPI 和思想考古两个样板模型、人读模型卡、来源文章索引、证据片段索引、回归测试用例、校验脚本和最小模型选择器 demo。完成后输出 README.md 和 Codex_工程产物摘要_v0.1.md，说明已完成内容、校验结果、与计划差异和需要下一轮产品判断的问题。
23. 最后提醒
这个样板工程的成败，不取决于代码复杂度，而取决于一件事：
QPI 和思想考古是否真的从“文章里的概念”变成了“系统能稳定调用的认知模型”。
所以第一版宁可简陋，也要保证：
结构清楚
来源可追溯
边界可检查
误用可测试
后续可扩展
这就是模型管理子系统 MVP 的第一块地基。