# 《核心模型抽取样板 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 的第一块地基。