LLM Wiki
一种用 AI agent 维护持久 Markdown Wiki 的模式：让有价值的综合能够不断积累，而不是每次都从原始资料重新开始。
LLM Wiki 把知识库看成一个可以被 AI agent 持续更新的成果物。原始资料保留为可追溯证据，而 Markdown Wiki 层负责承载不断积累的综合理解。
关键转变不是再回答一遍，而是维护已经理解过的东西。
编译后的知识
有价值的输出不只是一次回答，而是一个之后还能复用的知识层。
筛选与判断
人负责选择资料、提出更好的问题、判断重点，并决定什么值得被保留下来。
维护结构
AI agent 负责更新摘要、概念、链接、矛盾、索引和相关笔记。
持续增长的主题
当一个主题会不断积累资料和关系时，这个模式才有价值。一次性的小记录保持简单就好。
这个模式依赖三个层次。
它把证据、综合后的知识，以及约束 AI agent 的规则分开，让维护工作更稳定。
原始资料保持稳定
文章、论文、转录文本、数据集、网页存档、截图和其他资料都应该保持可追溯。
Wiki 成为被维护的综合理解
Markdown Wiki
指令约束更新方式
Schema 和 agent 指令规定内容放在哪里、链接怎么处理、来源怎么记录，以及什么时候应该更新已有笔记。
源文件保持可审计。Wiki 负责总结和连接它们，但不替代它们。
可复用的理解进入链接笔记，让未来的问题从已维护的上下文开始。
Schema 告诉 agent 什么时候创建、更新、引用、链接、记录，或者保持不动。
Wiki 通过一次次维护不断复利。
这个循环不是捕捉、总结、然后忘掉。每一次有价值的处理，都应该让知识库更容易查询、浏览、审计和继续维护。
吸收资料
新资料进入时，agent 要判断它改变了什么：概念、实体、链接、比较和来源记录。
回应问题
有价值的回答可以沉淀成持久笔记，而不是消失在聊天记录里。
维护结构
定期检查过时说法、互相矛盾的笔记、缺失链接、孤立笔记和薄弱导航。
每一次处理都会让 Wiki 更容易查询、浏览、审计和维护。输出不只是一个回答，而是一个更好的知识库。
适合文章、论文、剪藏、转录文本，或其他会影响多个笔记的持久研究资料。
好的比较、框架、看板或项目笔记，不应该消失在聊天记录里。
健康检查会在笔记和来源越来越多时，让整个知识图谱保持可用。
当每一层都有清晰位置时，这个模式才会变得具体。
这是我自己笔记系统里那张映射的公共化版本：把证据、综合、实体、入口、指令和日志分成不同职责。
来源层
持久的来源包、PDF、剪藏、存档和文件，供之后的笔记引用。
知识层
可复用的概念、框架、项目和综合笔记，逐渐成为工作知识。
entities
人物、组织、产品和反复出现的引用对象。
maps
供人浏览、也供 agent 定位的入口页面。
system
路由、YAML、模板和任务指令。
logs
有意义的 AI 修改按时间留下记录。
有用的单位不是单个总结文件。一份有意义的资料，可以在一次有纪律的处理中更新来源包、库笔记、实体页、地图和变更日志。
RAG 和 LLM Wiki 解决的是知识问题的不同部分。
提问时检索
持续维护的综合
要有意识地使用它，而不是处理每一条小记录。
- 一个主题会在几周或几个月里持续积累资料。
- 每次都重新综合会很浪费。
- 概念、实体和比较需要保持连接。
- 未来的 AI agent 需要继承已经维护过的上下文。
- 这只是一条一次性的小记录。
- 快速回答已经足够。
- 没有必要保留来源追溯。
- 这个主题不需要持续维护。
把握意义
选择资料、提出问题、检查重点，并判断什么值得变成持久知识。
执行维护
阅读资料、更新笔记、创建链接、处理矛盾、刷新索引，并为有意义的修改留下简洁记录。
约束流程
文件夹职责、YAML、模板、任务指令和安全规则，让更新足够一致，能够积累而不是漂移。
这个想法有意思，是因为它让 AI 知识工作变得可以积累。
我喜欢 LLM Wiki 的地方，是它把 AI 从“回答机器”重新理解成知识维护层。重要的问题变成：处理完这份资料或这次对话之后，知识库有没有比之前更好？
这对会不断扩展的主题尤其有用。一个好的回答不应该只帮一次。如果它澄清了概念、比较了想法、或者更新了理解，就应该留下某种可以继续复用的东西。