NOTES / 笔记
LLM Wiki 工作流
整理从资料和对话到结构化笔记、主题页面与长期维护的过程，区分 capture、ingest 和 lint 的职责。这是本地知识工作流笔记，不是自动执行指令。
文章目录
概述
LLM wiki 最适合被理解成一套分层工作流，而不是一个“把资料丢进去就会自动变聪明”的检索箱。真正有价值的对话和资料，应先变成结构化 note，再被明确地摄入 wiki，最后沉淀成可复用的主题页面。
核心要点
- 把 wiki 当成位于原始输入和最终产出之间的“维护型记忆层”。
- 只有在摄入意图明确时才执行 ingest，不要根据文件变化自动猜测。
- 先把有价值的对话 capture 成 note，再执行 ingest。
- 把 ingest、lint 和最终写作拆成不同动作，避免彼此混淆。
工作流
- 从一个主题、问题或原始资料开始。
- 通过对话探索，或收集外部来源。
- 用 capture 把有价值的内容整理成结构化 note。
- 用 ingest 把 note 合并进 wiki 页面。
- 在未来写作、检索、综合时优先使用 wiki。
- 定期用 lint 检查结构漂移、弱链接和缺失页面。
面向初学者的讲解顺序
如果要把这套工作流讲给新手听，最清楚的顺序通常是：
- 先讲问题：资料很多，但真正留下来的理解很少。
- 再讲定义：LLM wiki 是一个被持续维护的中间层，而不是更聪明的搜索框。
- 再讲动作：collect、capture、ingest、maintain、lint。
- 再讲分层：inbox、processed、wiki、index、log。
- 最后讲使用：以后写文章、查主题、做提纲时，如何复用已经沉淀的页面。
推理逻辑
- 聊天记录太易流失，不适合直接承担长期记忆功能。
- 仅靠文件变化无法可靠判断什么内容应该进入 wiki。
- 中间 note 提供了一个稳定、可复查、可再次利用的过渡层。
- 把维护动作拆开，可以让日常使用保持轻量，让系统整理保持有边界。
比喻与表达
- wiki 不是对话本身，它是从对话中维护出来的记忆层。
- 可以把 LLM 看成维护者，把 Obsidian 看成 IDE，把 wiki 看成持续演化的代码库。
- wiki 不是最终文章，它更像支撑未来文章的“引擎室”。
关联页面
待回答问题
- 当页面越来越多时，什么样的 page 结构最适合长期维护？
- 多久跑一次 lint，既能保持整洁，又不会让流程太重？