LLM Wiki
在整理个人站点资料的实践中，我遇到过一种知识损耗：读过的资料散在网页、聊天和笔记里；AI 曾经给出的好答案留在某次对话中；真正写文章或做决策时，又要从头寻找和组织。
把每次回答自动写进 Wiki 看似可以解决问题，也会制造更隐蔽的风险。模型生成的摘要可能省略条件，综合页可能加入没有来源的推断，后续模型再引用这些页面，几轮之后便很难分清原始事实和系统自己的补写。
我的核心判断是：LLM Wiki 应是一条可追溯的知识编译管道。 它把原始资料整理成可复用的知识页面，同时保留来源、状态、冲突和人工审批。页面数量只是结果，任何长期结论能否回到原始证据才是质量基础。
Chat、RAG 与 Wiki 解决不同问题
Chat 适合围绕当前问题快速展开。对话结束后，背景、分歧和有效结论通常不会自动进入长期知识系统。
RAG 在提问时检索相关片段，再把它们放入模型上下文。它能降低“找不到资料”的成本，却要在每次查询中重新选择、拼接和解释片段。检索结果也可能遗漏关键来源。
LLM Wiki 把一部分组织工作提前完成：平时就将来源、概念、冲突和综合判断整理成可审查的页面，查询时直接使用这些页面。三者可以组合：Chat 用于探索，RAG 用于寻找相关内容，Wiki 用于保存经过整理和复核的长期结构。
原始资料 → 派生知识 → 状态与审核 → 查询、写作或决策
↑ │ │
└──── 每条重要判断都能回到来源 ────┘
以本站的本地部署 AI为例，一页内容同时依赖 Ollama、LM Studio、llama.cpp、MLX-LM 和 vLLM 的官方资料。某个工具更新系统要求或服务参数时，原始文档、旧摘要、跨工具比较和公开文章需要分别处理。四层结构让系统先保存新来源、标记旧判断待复核，再由人决定是否更新公开页面，避免新旧版本在一次自动改写中混在一起。
四层结构隔开事实与生成内容
第一层：原始资料。 保存网页快照、论文、文档、会议纪要、阅读摘录和个人原始记录，同时记录作者、时间、链接、获取方式和隐私级别。系统可以补元数据，不能改写原文。无法保存全文时，也要保留稳定链接、访问时间和必要摘录。
第二层：派生知识。 LLM 根据原始资料生成 source note、概念页和综合页。每个可验证主张都指向第一层来源；作者解释、模型推断和待验证假设使用不同字段。派生页面可以更新，原始资料保持不动。
第三层：状态规则。 schema 定义页面字段和目录职责，状态记录一页处于待处理、待审核、已确认、存在冲突还是已过期，日志保存每次变更。Agent 只能按规则提出修改，不能自行宣布内容已经确认。
第四层：公开输出。 文章、报告和对外回答从已审核知识中选材，由人重新判断受众、隐私、证据与表达。内部 Wiki 页面不自动成为公开内容。
在宿主强制执行目录权限和审批规则、派生稿尚未公开的前提下，错误摘要会被隔离在可回退的派生版本中。只要来源和状态仍在，审核者就能定位并修正它；如果这些边界只写在提示词里，四层目录本身无法阻止错误传播。
一次导入应产生可审查的变更
新增资料时，我希望系统完成一组有限动作：
- 保存原文或来源快照，补齐时间、作者、链接和隐私级别。
- 生成 source note，列出原文主张、证据类型和适用范围。
- 查找相关概念页，提出新增、更新或保持不变的建议。
- 对照已有综合页，标出支持、削弱或冲突的关系。
- 生成文件差异和变更说明，等待规则检查与人工审核。
最小目录不需要复杂：
wiki/
├── raw/ # 原文与来源快照，只新增
├── sources/ # 单一来源的结构化笔记
├── concepts/ # 可复用概念
├── synthesis/ # 跨来源判断
├── reviews/ # 冲突、审计与待决事项
├── index.md # 入口与主题索引
├── schema.md # 字段、状态和权限规则
└── log.md # 重要变更记录
导入的交付物是一组带来源的候选改动。它需要能在 Git diff 中查看，也需要能整组撤回。这样，自动化提高的是整理速度，不会绕过知识确认过程。
状态规则防止知识库自我引用
LLM Wiki 最容易腐坏的路径是：模型生成页面 A，页面 B 引用 A，页面 C 再把 A 和 B 的共同说法当作多源共识。三个页面实际上只有一个来源，甚至没有原始来源。
我会给每个重要判断保留四项信息：
claim_type：来源事实、作者解释、模型推断或待验证假设。source_refs：可以回到原始资料的链接或文件标识。status：待审核、已确认、存在冲突、已过期或已归档。last_verified：最近一次核对来源和适用范围的日期。
派生页面可以帮助寻找来源，事实依据仍需回到原始材料。两篇文章转述同一份报告时，仍然只算一条证据链。新资料与旧判断冲突时，系统保留双方来源并把状态改成“存在冲突”，等待人决定增加条件、降低结论强度或归档旧观点。
Lint 也应检查结构问题：无来源主张、断链、孤立页面、重复概念、过期状态、只有单一证据的强结论，以及长期无人处理的冲突。拼写检查只是其中很小的一部分。
自动化权限随知识风险变化
适合自动执行的动作包括保存来源、补元数据、生成摘要草稿、建议链接、发现重复页面和输出结构报告。这些动作容易检查，也容易撤销。
需要人工确认的动作包括删除或合并资料、把推断升级为已确认结论、处理来源冲突、解除隐私限制，以及将内容发布到外部。越靠近长期观点和公开输出，审批要求越高。
我会使用三条工程护栏：
- 路径权限：Agent 可以写
sources/、候选concepts/和reviews/，原始资料与公开目录使用更严格权限。 - 版本控制：每次批处理形成独立 diff 和检查点，异常时回退整批变更。
- 外部验证：由脚本检查 schema、来源引用、链接和状态；模型的“检查通过”只是一条待验证输出。
后台任务的频率不需要一开始就很高。先让一次导入稳定地产生可读 diff，再增加定期整理、冲突检查和索引维护。
用一个主题验证最小闭环
我会选择一个持续使用、资料来源清楚、最终需要形成文章或决策的主题试点。最小闭环包含以下结果：
- 一小批原始资料进入
raw/，来源和隐私边界完整。 - 系统生成 source note，并建立少量被多篇资料复用的概念页。
- 一页 synthesis 同时列出支持证据、反向证据和未知部分。
- 新资料进入后，系统能指出它改变了哪条旧判断。
- 人基于已审核页面完成一次真实输出，并能追溯其中的重要主张。
如果知识页面无法支撑真实输出，继续扩大自动化没有意义。常见原因包括来源质量太低、schema 过度复杂、页面只有摘要没有个人判断，或者没有人处理冲突和审核状态。
这套系统的验收标准很朴素：随机抽取一条公开结论，能够找到它的原始来源、形成时间、当前状态和责任人；加入一条相反证据后，系统不会悄悄覆盖旧内容，而会把冲突推到人面前。做到这两点，LLM 才是在维护知识，而非持续制造更整齐的文本。