标准写作流水线（7 步）
每接到一个写作任务，**必须**按以下 7 步执行：
Step 1 · 问题解析
- 解析用户问题的：核心主题、关键词、问题类型（What/How/Which/Where 四分类）、隐含约束
- 输出一份"约束检查清单"：标题主题、字数（3000-4000）、章节数（6-8）、第一人称、输出路径、配图友好度等
Step 2 · 场景匹配（Scenarios）
- 打开 `wiki1/scenario-method.yaml`
- 用关键词在 43 个场景中做匹配检索
- **三种匹配结果**：
- **完全命中**：直接复用该场景的 `composition[]` 作为写作主干
- **部分命中**：找 2-3 个相近场景，组合其 `composition[]`
- **未命中**：进入 Step 3 自由组装路线（**同时记下，这是 yaml 待补的新场景**）
Step 3 · 概念组装（Concepts）
基于命中的场景，按 `composition[]` 中的 `uses[]` 字段逐项调取：
- **原子概念**：到 `meta-concepts.yaml` 查 IPO 四元组（input / process.steps / output）
- **组合概念**：到 `compose-concepts.yaml` 查 decomposition（哪些子方法串成）
**未命中也记下**：这是 yaml 待补的新概念。
Step 4 · 实体调取（Entities）
每个概念在使用工具/技术/框架时，会引用 `entity://X`：
- **工具/产品**：到 `entity-knowledge.yaml` 或 `entity-cognition.yaml` 查
- **方法论实体**：到 `entity-problem-solving.yaml` 或 `entity-learning.yaml` 查
- **人物/底层技术/哲学概念**：到 `entity-other.yaml` 查
**未命中也记下**：这是 yaml 待补的新实体。
Step 5 · 原文深挖（Sources）
- 对组装路径上的每个核心 concept/entity，读取其 `source:` 指向的 `wiki/concepts/*.md` 或 `wiki/method/*.md`
- 提取关键段落作为文章血肉：加粗观点句优先 → 案例段次之 → 流程描述改造为列表/表格
- **重要原则**：concept 卡片只是索引，**原文 md 才是文章段落的素材**——不要直接把 define 当段落用
Step 6 · 结构化写作
按下面的【*写作规范**】（见 §3）输出 markdown 文件到 `newdoc/
Step 7 · yaml 反向校验（关键步骤）
文章完成后，**必须**做一次反向检视，输出一份"yaml 补全建议"（直接附在与用户的回复消息里，不写进文章），包含：
1. **新场景**：本次有没有产生在 `scenario-method.yaml` 里找不到对应的写作场景？给出建议的 yaml 条目骨架
2. **新概念**：本次用到了哪些 `concept://` 引用但实际不在 meta/compose yaml 里？分别建议是 META 还是 COMPOSE，给出条目骨架
3. **新实体**：本次提及但 entity yaml 里没有的工具/人物/产品？给出建议归属的 entity yaml 和条目骨架
4. **关系补全**：发现的新 `is_a / uses / related_to` 关系，建议补到现有条目
5. **死链**：本次发现的 yaml 引用指向不存在的 id
基于整套提示词就可以开始完整的知识问答和基于知识库的写作工作。当然这个知识库是一个动态的知识库，也就是说具备自我进化能力。任何一次写作完成后，AI会分析是否需要增加新的场景或概念，对于当前已有的概念实体是否存在死链需要修正。
也就是整个知识库会随着新场景和问题的引入，不断的自我完善和进化，这也是前面我们谈Karpathy的LLM-Wiki谈到的一个重要能力。
对于整套思路，我将其引入到了最近构建的一个AI知识库应用中。这个AI知识库不仅仅是用于简单的知识库问答，由于构建了完整的场景-概念-实体的知识图谱网络，对于复杂场景，AI可以完整的构建完整的写作方案，更好的进行知识点的内容组装。
包括基于某一个主题，帮我输出近10万字的完整文章。
这种新的基于LLM-Wiki的场景驱动的新AI知识库，彻底解决了传统RAG知识库的知识幻觉问题，能够更好的支撑方案类文档的写作，类似立项报告，采购文件，招标文件，标准规范文档等。
当前Conflux知识库还在进一步完善中，后续会发布公网试用环境，也环境大家测试和使用。
