2482 lines
61 KiB
Markdown
2482 lines
61 KiB
Markdown
# 《核心模型抽取样板 v0.1》
|
||
|
||
版本：v0.1
|
||
用途：交给 Codex 建立“模型库 / 模型管理子系统 MVP”的工程样板
|
||
当前样板模型：QPI、思想考古
|
||
第一使用者：你本人
|
||
当前阶段：模型管理子系统 MVP 前置规范，不是完整产品计划书
|
||
|
||
这份样板承接你默认产品计划书中的几个核心模块：**模型卡结构、数据结构初稿、Agentic 工作流草案、模型调用与冲突处理规则、回归测试与评估机制、给 Codex 的开发前置说明**。
|
||
|
||
---
|
||
|
||
## 0. 核心判断
|
||
|
||
当前阶段不要让 Codex 直接开发“完整模型管理后台”。
|
||
|
||
第一阶段真正要验证的是：
|
||
|
||
> 能否把你的核心认知模型，从文章和既有表述中抽取成一套既能被人理解、又能被系统调用、还能被回归测试的模型资产结构。
|
||
|
||
所以这个样板工程的目标不是做漂亮后台，而是跑通一条最小链路：
|
||
|
||
```text
|
||
原始文章 / 代表文本
|
||
→ 来源文章索引
|
||
→ 关键证据片段
|
||
→ 人读模型卡
|
||
→ 机器可读模型 JSON
|
||
→ 回归测试用例
|
||
→ 最小模型选择器
|
||
```
|
||
|
||
如果这条链路跑通，再扩展到 8-10 个核心模型。
|
||
如果这条链路不稳，贸然扩展模型数量只会制造一批“看起来完整、实际不可调用”的模型卡。
|
||
|
||
---
|
||
|
||
## 1. 文档目标
|
||
|
||
### 1.1 本文档要解决什么
|
||
|
||
本文档用于指导 Codex 完成一个 **核心模型抽取样板工程**。
|
||
|
||
它要让 Codex 明确：
|
||
|
||
1. 模型库应该采用什么目录结构；
|
||
2. 模型卡应该包含哪些字段；
|
||
3. QPI 和思想考古两个模型如何被抽成样板；
|
||
4. 来源文章和证据片段如何关联；
|
||
5. 模型如何被系统调用；
|
||
6. 模型如何做回归测试；
|
||
7. 后续扩展到 8-10 个核心模型时应该遵守什么规范。
|
||
|
||
### 1.2 本文档不解决什么
|
||
|
||
本阶段不做：
|
||
|
||
```text
|
||
完整模型管理后台
|
||
完整知识图谱
|
||
100 多个模型全量管理
|
||
自动从所有文章抽取模型
|
||
复杂 RAG 知识库
|
||
复杂用户系统
|
||
公开平台
|
||
权限系统
|
||
计费系统
|
||
多人协作系统
|
||
完整问题回答产品
|
||
```
|
||
|
||
本阶段只做 **核心模型库的工程样板**。
|
||
|
||
---
|
||
|
||
## 2. 样板工程的 MVP 定义
|
||
|
||
### 2.1 一句话定义
|
||
|
||
**核心模型抽取样板 v0.1 是一个 file-first 的模型库工程样板，用 QPI 和思想考古两个核心模型验证“文章 → 证据片段 → 模型卡 → 机器 JSON → 回归测试 → 最小选择器”的完整链路。**
|
||
|
||
### 2.2 MVP 验证命题
|
||
|
||
第一阶段要验证的核心命题是：
|
||
|
||
> 少量核心认知模型，能否被整理成结构化、可追溯、可调用、可测试的模型资产，并为后续问题回答系统提供稳定底座。
|
||
|
||
### 2.3 MVP 最小产物
|
||
|
||
Codex 完成后，至少应该产出：
|
||
|
||
```text
|
||
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 模型抽取不是文章摘要
|
||
|
||
文章摘要回答的是：
|
||
|
||
```text
|
||
这篇文章讲了什么？
|
||
```
|
||
|
||
模型抽取回答的是：
|
||
|
||
```text
|
||
这篇文章中有哪些可复用的认知机制？
|
||
这些机制能处理什么输入？
|
||
能输出什么结果？
|
||
什么时候该调用？
|
||
什么时候不该调用？
|
||
如何测试它是否被误用？
|
||
```
|
||
|
||
所以模型抽取不能停留在“总结观点”，必须形成可调用规格。
|
||
|
||
---
|
||
|
||
### 3.2 模型卡必须有来源证据
|
||
|
||
每个核心字段都要尽量能追溯到来源：
|
||
|
||
```text
|
||
模型定义 ← 来源文章 / 关键段落
|
||
核心机制 ← 来源文章 / 关键段落
|
||
适用场景 ← 来源文章 / 代表案例 / 后续推导
|
||
不适用场景 ← 红队推导 / 反例测试
|
||
调用规则 ← 产品化推导
|
||
回归测试 ← 模型边界推导
|
||
```
|
||
|
||
不能让模型卡变成脱离原文的二次包装。
|
||
|
||
---
|
||
|
||
### 3.3 区分“传播用模型”和“系统调用用模型”
|
||
|
||
传播用模型可以有表达性、隐喻性、文学性。
|
||
|
||
系统调用用模型必须满足：
|
||
|
||
```text
|
||
概念清楚
|
||
输入清楚
|
||
输出清楚
|
||
适用边界清楚
|
||
误用风险清楚
|
||
调用条件清楚
|
||
测试方式清楚
|
||
```
|
||
|
||
QPI 和思想考古进入模型库时，都要按“系统调用用模型”重构，而不是保留为文章中的原始表达。
|
||
|
||
---
|
||
|
||
### 3.4 第一版允许半自动，不追求全自动
|
||
|
||
Codex 不应该在 v0.1 阶段尝试自动完成全部模型抽取。
|
||
|
||
更合理的路径是：
|
||
|
||
```text
|
||
人工提供两个样板模型
|
||
Codex 建立 schema、目录、校验器、选择器
|
||
后续再用同一结构扩展更多模型
|
||
```
|
||
|
||
当前目标是“规范稳定”，不是“自动化程度高”。
|
||
|
||
---
|
||
|
||
## 4. 文章到模型的抽取协议
|
||
|
||
建议把抽取分成 5 层。
|
||
|
||
```text
|
||
第 1 层：来源文章层
|
||
第 2 层：证据片段层
|
||
第 3 层：人读模型卡层
|
||
第 4 层：机器调用规格层
|
||
第 5 层：回归测试层
|
||
```
|
||
|
||
---
|
||
|
||
### 4.1 第 1 层：来源文章层
|
||
|
||
记录模型来自哪些文章、代表文本或讨论材料。
|
||
|
||
每篇来源文章至少包含：
|
||
|
||
```json
|
||
{
|
||
"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 | 测试片段 |
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"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 格式。
|
||
|
||
每张人读模型卡至少包含：
|
||
|
||
```text
|
||
## 模型名称
|
||
|
||
### 模型 ID
|
||
|
||
### 一句话定义
|
||
|
||
### 模型类型
|
||
|
||
### 所在流程位置
|
||
|
||
### 来源文章
|
||
|
||
### 来源证据片段
|
||
|
||
### 核心问题
|
||
|
||
### 核心机制
|
||
|
||
### 输入类型
|
||
|
||
### 输出类型
|
||
|
||
### 适用场景
|
||
|
||
### 不适用场景
|
||
|
||
### 调用关键词
|
||
|
||
### 负向触发条件
|
||
|
||
### 相关模型
|
||
|
||
### 冲突模型
|
||
|
||
### 学科底座关联
|
||
|
||
### 常见误用
|
||
|
||
### 失败信号
|
||
|
||
### 可信度等级
|
||
|
||
### 稳固性状态
|
||
|
||
### 回归测试状态
|
||
|
||
### 示例输入
|
||
|
||
### 示例输出
|
||
|
||
### 产品化建议
|
||
```
|
||
|
||
---
|
||
|
||
### 4.4 第 4 层：机器调用规格层
|
||
|
||
机器调用规格用于问题回答系统读取。
|
||
|
||
它应该是 JSON 或 YAML。
|
||
v0.1 建议统一先用 JSON，便于 schema 校验。
|
||
|
||
机器调用规格必须回答：
|
||
|
||
```text
|
||
这个模型什么时候被调用？
|
||
什么时候不被调用？
|
||
输入是什么？
|
||
输出是什么？
|
||
调用优先级是多少？
|
||
适合放在流程哪个位置？
|
||
需要哪些前置模型？
|
||
后续可以接哪些模型？
|
||
与哪些模型冲突？
|
||
如何判断调用失败？
|
||
```
|
||
|
||
---
|
||
|
||
### 4.5 第 5 层：回归测试层
|
||
|
||
回归测试用于判断模型是否稳定。
|
||
|
||
每个核心模型至少有三类测试：
|
||
|
||
```text
|
||
正向适用测试
|
||
边界测试
|
||
误用测试
|
||
```
|
||
|
||
建议每个模型 v0.1 至少有 5 个测试用例：
|
||
|
||
```text
|
||
2 个正向适用
|
||
2 个边界案例
|
||
1 个误用案例
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 建议目录结构
|
||
|
||
Codex 可以按下面结构创建样板工程。
|
||
|
||
```text
|
||
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 必填字段
|
||
|
||
```json
|
||
[
|
||
"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 推荐字段
|
||
|
||
```json
|
||
[
|
||
"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
|
||
|
||
```json
|
||
[
|
||
"routing_model",
|
||
"deep_modeling_model",
|
||
"lens_model",
|
||
"diagnostic_model",
|
||
"evaluation_model",
|
||
"generation_model",
|
||
"conflict_resolution_model",
|
||
"stabilization_model"
|
||
]
|
||
```
|
||
|
||
### 7.2 pipeline_position
|
||
|
||
```json
|
||
[
|
||
"pre_analysis",
|
||
"analysis",
|
||
"deep_analysis",
|
||
"synthesis",
|
||
"red_team",
|
||
"evaluation",
|
||
"post_processing"
|
||
]
|
||
```
|
||
|
||
### 7.3 confidence_level
|
||
|
||
```json
|
||
[
|
||
"high",
|
||
"medium",
|
||
"low"
|
||
]
|
||
```
|
||
|
||
### 7.4 regression_status
|
||
|
||
```json
|
||
[
|
||
"not_started",
|
||
"pending",
|
||
"in_progress",
|
||
"passed",
|
||
"failed",
|
||
"needs_rebuild"
|
||
]
|
||
```
|
||
|
||
### 7.5 stability_level
|
||
|
||
```json
|
||
[
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"D"
|
||
]
|
||
```
|
||
|
||
建议含义：
|
||
|
||
| 等级 | 含义 |
|
||
| -- | ------------- |
|
||
| A | 高稳固，可进入核心调用 |
|
||
| B | 基本稳固，需要边界测试 |
|
||
| C | 有解释力，但概念或边界不稳 |
|
||
| D | 暂不适合系统调用，需要重构 |
|
||
|
||
---
|
||
|
||
## 8. model_card.schema.json 草案
|
||
|
||
Codex 可以先按这个草案实现，后续再细化。
|
||
|
||
```json
|
||
{
|
||
"$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 草案
|
||
|
||
```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 草案
|
||
|
||
```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 草案
|
||
|
||
```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
|
||
|
||
```markdown
|
||
## 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
|
||
|
||
```json
|
||
{
|
||
"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 来源片段样例
|
||
|
||
```json
|
||
[
|
||
{
|
||
"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 回归测试样例
|
||
|
||
```json
|
||
[
|
||
{
|
||
"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
|
||
|
||
```markdown
|
||
## 思想考古模型
|
||
|
||
### 模型 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
|
||
|
||
```json
|
||
{
|
||
"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 思想考古来源片段样例
|
||
|
||
```json
|
||
[
|
||
{
|
||
"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 思想考古回归测试样例
|
||
|
||
```json
|
||
[
|
||
{
|
||
"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 与思想考古的组合关系
|
||
|
||
这两个模型在系统中不是并列替代关系，而是前后衔接关系。
|
||
|
||
```text
|
||
输入问题
|
||
→ QPI 判断问题类型
|
||
→ 判断是否需要深度下潜
|
||
→ 如果问题复杂、高复用、偏 Issue，则调用思想考古
|
||
→ 输出层级结构和深层假设
|
||
→ 后续再接其他横向棱镜模型
|
||
```
|
||
|
||
### 14.1 系统位置
|
||
|
||
| 模型 | 系统位置 | 作用 |
|
||
| ---- | ------------- | ------------- |
|
||
| QPI | pre_analysis | 判断问题类型，决定处理路径 |
|
||
| 思想考古 | deep_analysis | 对复杂问题进行纵向下潜 |
|
||
|
||
### 14.2 调用优先级
|
||
|
||
| 场景 | 推荐调用 |
|
||
| --------------- | ----------- |
|
||
| 问题定义不清 | 优先 QPI |
|
||
| 只是查事实 | 不调用思想考古 |
|
||
| 目标明确但路径未定 | QPI 后进入工程求解 |
|
||
| 多主体冲突 / 系统性反复失败 | QPI + 思想考古 |
|
||
| 需要从文章抽模型 | 思想考古 |
|
||
| 需要判断模型是否稳固 | 思想考古 + 回归测试 |
|
||
|
||
---
|
||
|
||
## 15. 最小模型选择器规则
|
||
|
||
v0.1 的模型选择器不需要复杂算法。
|
||
|
||
可以先使用规则 + 简单评分。
|
||
|
||
### 15.1 输入
|
||
|
||
```json
|
||
{
|
||
"user_input": "团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
|
||
"task_type": "question_analysis",
|
||
"depth_preference": "medium"
|
||
}
|
||
```
|
||
|
||
### 15.2 输出
|
||
|
||
```json
|
||
{
|
||
"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 类信号评分：
|
||
|
||
```text
|
||
1. trigger_keywords 命中
|
||
2. input_types 匹配
|
||
3. do_not_call_when 是否触发
|
||
4. pipeline_position 是否适合当前阶段
|
||
```
|
||
|
||
伪规则：
|
||
|
||
```text
|
||
初始分 = 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
|
||
|
||
```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 个维度评估：
|
||
|
||
```text
|
||
概念清晰度
|
||
机制稳定性
|
||
边界清晰度
|
||
来源证据质量
|
||
回归测试表现
|
||
```
|
||
|
||
### 17.1 评分维度
|
||
|
||
| 维度 | 问题 |
|
||
| ------ | --------------- |
|
||
| 概念清晰度 | 模型的核心概念是否清楚？ |
|
||
| 机制稳定性 | 模型是否有明确运作机制？ |
|
||
| 边界清晰度 | 是否知道什么时候不能用？ |
|
||
| 来源证据质量 | 是否能追溯到文章和关键片段？ |
|
||
| 回归测试表现 | 是否通过正向、边界、误用测试？ |
|
||
|
||
### 17.2 等级规则
|
||
|
||
| 等级 | 标准 |
|
||
| -- | ---------------- |
|
||
| A | 五个维度都较稳定，可进入核心调用 |
|
||
| B | 基本可用，但需要边界案例测试 |
|
||
| C | 有启发，但系统调用风险较高 |
|
||
| D | 不适合进入模型库，需要重构 |
|
||
|
||
### 17.3 QPI 当前建议评级
|
||
|
||
```json
|
||
{
|
||
"model_id": "qpi",
|
||
"stability_level": "B",
|
||
"reason": "三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。",
|
||
"next_stabilization_action": "补充混合问题、误用问题和轻量问题测试。"
|
||
}
|
||
```
|
||
|
||
### 17.4 思想考古当前建议评级
|
||
|
||
```json
|
||
{
|
||
"model_id": "intellectual_archaeology",
|
||
"stability_level": "B",
|
||
"reason": "纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。",
|
||
"next_stabilization_action": "补充不同复杂度问题的下潜深度测试，明确最小充分下潜原则。"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 18. Codex 开工任务
|
||
|
||
### Task 1：创建工程目录
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建 model_library_mvp 目录
|
||
按本文档建立 schemas / models / cards / sources / tests / selector / scripts / reports
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
目录结构完整
|
||
README.md 存在
|
||
所有关键目录都有占位说明
|
||
```
|
||
|
||
---
|
||
|
||
### Task 2：创建 JSON Schema
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- model_card.schema.json
|
||
- source_article.schema.json
|
||
- source_excerpt.schema.json
|
||
- regression_case.schema.json
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
schema 可以被 jsonschema 校验工具读取
|
||
必填字段生效
|
||
枚举值生效
|
||
错误数据能被识别
|
||
```
|
||
|
||
---
|
||
|
||
### Task 3：录入两个样板模型
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- models/qpi.model.json
|
||
- models/intellectual_archaeology.model.json
|
||
- cards/qpi.card.md
|
||
- cards/intellectual_archaeology.card.md
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
两个 JSON 文件通过 model_card.schema.json 校验
|
||
两个 Markdown 卡片可读
|
||
字段与本文档基本一致
|
||
```
|
||
|
||
---
|
||
|
||
### Task 4：创建来源索引和证据片段索引
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- sources/source_articles.json
|
||
- sources/source_excerpts.json
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
source_articles.json 至少包含 QPI 和思想考古的来源记录
|
||
source_excerpts.json 至少包含两个模型各 3 条证据片段
|
||
模型卡中的 source_articles 和 source_evidence 能对应到实际 ID
|
||
```
|
||
|
||
---
|
||
|
||
### Task 5：创建回归测试用例
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- tests/qpi.regression.json
|
||
- tests/intellectual_archaeology.regression.json
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
每个模型至少 5 个测试用例
|
||
包含 positive、boundary、misuse 三类
|
||
测试用例通过 regression_case.schema.json 校验
|
||
```
|
||
|
||
---
|
||
|
||
### Task 6：创建校验脚本
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- scripts/validate_models.py
|
||
- scripts/validate_sources.py
|
||
- scripts/validate_tests.py
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
能检查 JSON 是否符合 schema
|
||
能检查 model_id 是否唯一
|
||
能检查 source_evidence 是否存在
|
||
能检查 regression_tests 是否引用了存在的 model_id
|
||
输出 validation_report.md
|
||
```
|
||
|
||
---
|
||
|
||
### Task 7：创建最小模型选择器 demo
|
||
|
||
目标：
|
||
|
||
```text
|
||
创建：
|
||
- selector/selection_rules.json
|
||
- selector/selector_examples.json
|
||
- scripts/run_selector_demo.py
|
||
```
|
||
|
||
验收标准：
|
||
|
||
```text
|
||
输入一个问题
|
||
读取两个模型 JSON
|
||
根据关键词、输入类型、负向触发条件、selection_priority 返回候选模型
|
||
输出推荐理由
|
||
至少能跑通 selector_examples.json 中的样例
|
||
```
|
||
|
||
---
|
||
|
||
## 19. 验收标准总表
|
||
|
||
Codex 完成后，必须满足：
|
||
|
||
```text
|
||
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 记录校验结果
|
||
```
|
||
|
||
不要求：
|
||
|
||
```text
|
||
不要求前端界面
|
||
不要求数据库
|
||
不要求向量检索
|
||
不要求真实 LLM 调用
|
||
不要求完整问题回答系统
|
||
不要求自动抽取所有模型
|
||
```
|
||
|
||
---
|
||
|
||
## 20. Codex 返回 ChatGPT 时的交接材料
|
||
|
||
Codex 完成后，请整理一份：
|
||
|
||
```text
|
||
Codex_工程产物摘要_v0.1.md
|
||
```
|
||
|
||
建议包含：
|
||
|
||
```markdown
|
||
## Codex 工程产物摘要 v0.1
|
||
|
||
### 1. 当前完成阶段
|
||
|
||
### 2. 已创建目录结构
|
||
|
||
### 3. 已创建文件清单
|
||
|
||
### 4. Schema 实现情况
|
||
|
||
### 5. QPI 模型卡实现情况
|
||
|
||
### 6. 思想考古模型卡实现情况
|
||
|
||
### 7. 来源索引实现情况
|
||
|
||
### 8. 回归测试实现情况
|
||
|
||
### 9. 模型选择器实现情况
|
||
|
||
### 10. 校验结果
|
||
|
||
### 11. 与原计划不一致的地方
|
||
|
||
### 12. 当前发现的问题
|
||
|
||
### 13. 需要 ChatGPT / CCRA 判断的问题
|
||
|
||
### 14. 下一步建议
|
||
```
|
||
|
||
你回到 ChatGPT 新会话时，建议上传：
|
||
|
||
```text
|
||
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 个问题：
|
||
|
||
```text
|
||
1. 当前模型卡 schema 是否过重？
|
||
2. QPI 和思想考古的字段是否足够支撑系统调用？
|
||
3. 来源证据片段是否真的能帮助追溯？
|
||
4. 回归测试是否能暴露模型误用？
|
||
5. 最小模型选择器是否足以推荐 3-5 个候选模型？
|
||
```
|
||
|
||
如果这 5 个问题基本通过，下一阶段再做：
|
||
|
||
```text
|
||
扩展到 5 个核心模型
|
||
→ 扩展到 8-10 个核心模型
|
||
→ 接入最小问题回答链路
|
||
→ 让输入问题经过 QPI、模型选择器、多棱镜分析、冲突汇总、综合洞察输出
|
||
```
|
||
|
||
如果这 5 个问题没有通过，先修 schema 和抽取协议，不要扩展模型数量。
|
||
|
||
---
|
||
|
||
## 22. 给 Codex 的一句话指令
|
||
|
||
可以把下面这段直接放给 Codex：
|
||
|
||
```text
|
||
请根据《核心模型抽取样板 v0.1》，创建一个 file-first 的 model_library_mvp 工程。不要开发完整后台，不要接数据库，不要做复杂 RAG。第一阶段只需要建立目录结构、JSON Schema、QPI 和思想考古两个样板模型、人读模型卡、来源文章索引、证据片段索引、回归测试用例、校验脚本和最小模型选择器 demo。完成后输出 README.md 和 Codex_工程产物摘要_v0.1.md，说明已完成内容、校验结果、与计划差异和需要下一轮产品判断的问题。
|
||
```
|
||
|
||
---
|
||
|
||
## 23. 最后提醒
|
||
|
||
这个样板工程的成败，不取决于代码复杂度，而取决于一件事：
|
||
|
||
> QPI 和思想考古是否真的从“文章里的概念”变成了“系统能稳定调用的认知模型”。
|
||
|
||
所以第一版宁可简陋，也要保证：
|
||
|
||
```text
|
||
结构清楚
|
||
来源可追溯
|
||
边界可检查
|
||
误用可测试
|
||
后续可扩展
|
||
```
|
||
|
||
这就是模型管理子系统 MVP 的第一块地基。
|
||
|