LLM Wiki：让对话真正沉淀下来

先说一个场景，相信很多人都有同感：你让模型读了一份材料，告诉它一些新信息，哪怕是一种完全虚构的语言，或者一台尚未发布的手机参数——模型当时表现得好像真的学会了，能分析、能推理、能翻译。但当你关闭这次对话，重新打开一个新窗口，再问同样的问题时，模型大概率一脸茫然。

这不是模型在装傻，它没有被训练过。不妨把模型看作一个巨大的压缩包，训练阶段把海量知识压缩进参数里，推理阶段则根据你的提示词和上下文，临时把相关能力展开。这个压缩包不会因为你跟它聊了一次就自动改写。你给它的新规则、新案例，只进入当前这个临时上下文窗口，而不是模型参数本身。它能在这个回合使用这些信息，但不会因此把它们内化为自己的长期记忆。

所以AI问答的真正问题，不只是“检索准不准”，而是它根本不是一个在持续生长的知识系统上工作，而是在一次次临时上下文里工作。对话一结束，工作台就收掉了。除非你有意识地把结果沉淀下来，否则这些对话产生的价值几乎无法自然积累。

很多人像我一样，习惯性地把模型对话提取出来扔进笔记软件，但很快就发现，这很难做到持续、系统的维护。问题的关键不是文字本身，而是

。

Karpathy提出的LLM Wiki框架，正是对此的一个漂亮回应：别指望模型记住一切，而是让模型去维护一个外部wiki。模型负责读取、提取、合并、链接和更新；wiki则负责保存、积累、迁移和审计。

我的版本

Karpathy给出了框架，但没有规定具体怎么让AI严格执行规则。以下是在这个思路上的实际落地版本。

目录结构

首先创建raw和wiki两个文件夹，以及index.md和log.md两个文档。实际使用时，可以根据材料类型在raw/和wiki/下做更细的划分（完整结构见附录一）。

llm-wiki/
├── raw/          # 原始资料，只放不改
├── wiki/         # AI 维护后的知识页面
├── index.md      # 知识库入口
├── log.md        # 每次处理记录
└── AGENT.md      # 给 AI 的工作规则

这个目录结构本身很简单：把原始材料放进只读的raw/，AI读取并讨论关键收获，然后写入wiki/，最后更新index.md和日志。

但真正决定这套系统能否长期运作的，不是目录结构，而是

。没有规则，AI会把知识库变成另一堆随手写的文件；有了规则，AI才知道什么能动、什么不能动、怎么写、往哪写、凭什么写。

六条关键规则

AI可以读raw/提取事实，但不能创建、删除、改名或修改其中任何文件。raw/是原始材料，不是AI的产物。

新材料进来时，先查wiki是否已有相关页面。有就合并，没有才新建。避免wiki变成按时间堆叠的“另一份raw”。

wiki里每条重要信息必须标注来源，没有来源的内容不能写入事实区。来源链接必须是可点击的，冲突信息不能静默覆盖，应并列展示不同版本。

AI在用户确认前不能修改任何文件。确认后也只允许改动wiki/、index.md、log.md等处理对象字段。

每次操作后更新log.md；新建wiki页面后必须更新index.md。log只记录已完成事项、变更结果和遗留问题，不写行动计划。

wiki页面原则上不删除。过时、重复或边界错误时，优先合并内容，标记“已废弃”或归档。

以上六条规则落到文件里，就是

（详见附录一）。

TASK.md：一张工单

Karpathy并没有把LLM Wiki框定为“用户手动维护”或“AI全自动维护”，他强调的是

：可以一次只摄入一个来源并保持参与，也可以批量摄入但监督更少。在这个光谱中，选择的是方案，原因有三。

原因一：认知参与

这不是一个技术理由。如果流程变成“材料扔进raw → AI自动处理 → wiki自动更新”，看起来很顺，但最后很容易变成“没有然后”。知识库被更新了，摘要生成了，链接建立了——可你并没有真正参与理解。你没有诚实地回答：这份材料为什么重要？它改变了我原来的什么看法？它和已有知识有什么冲突？这些问题如果没被提出，wiki会不会变成另一种形式的笔记坟墓？

原因二：会话跑偏

实际跟AI聊天时，很少从头到尾只谈一件事。开头聊A话题，中间冒出B话题，后面大部分讨论都围绕B展开。AI执行AGENT.md时，容易被最长的那条对话带偏，而不是聚焦在应该处理的那份材料上。

原因三：理解偏差检测

AI读材料时，会在自己内部形成一个自洽的理解——但这个理解很可能完全猜错了你想保留的角度。因此更希望“先讨论，后执行”：让它先说出来，不合意就纠正，而不是让它直接动手改完再找问题。

基于以上三个原因，创建了

，用两个机制分别回应：

机制	解决的问题
“当前处理对象”	会话跑偏（原因二）
任务类型、目标与特别要求	认知缺席与理解偏差（原因一、三）

（详见附录二）

TASK.md只负责指令，规则全部留在AGENT.md，两者各司其职。

一次实践

看到哈佛物理系正教授尹希加入OpenAI的新闻后，跟AI做了一次长对话。决定把这次对话作为材料，跑一遍LLM Wiki流程。

把对话记录放进raw/，让AI读取AGENT.md、TASK.md、目标材料，同时检查已有wiki是否已有相关页面。

AI输出处理方案：这篇材料说了什么？跟已有Wiki什么关系？合并还是新建？有没有重复或冲突风险？

具体到这次对话，ChatGPT的回复里有一段很精准的引文：很多人以为自己的职业身份是本质——律师、程序员、物理学家。但顶尖人才往往把职业看成载体。真正可迁移的，是背后的认知结构。但AI在整理时漏掉了这段。追加指令让它重新提取并纳入总结，同时AI对自媒体讨论部分也做了遗漏——这恰好印证了“先讨论后执行”的必要性：AI会形成自己的理解，但这个理解不一定是你要的。讨论环节就是用来纠偏的。

AI列出调整后的最终方案：拟修改哪些Wiki页面、拟写入的提纲、来源链接、潜在风险。逐项确认后，说出“确认”，AI才动手。

AI按确认的方案写入Wiki、更新index.md、追加log.md、将TASK.md的“当前处理对象”重置为“（待指派）”。整个过程raw/未被触碰，所有改动可追溯到原始材料。

最后

目前使用的是Obsidian + Agent Client插件（一个让AI直接读写Obsidian文件的插件），但这并不是唯一方案。很多人基于Karpathy的框架做出了自己的版本，有的更自动化，有的更工程化，也有只是简单维护几个Markdown文件的。

说到底，LLM Wiki的价值不是多生成几篇笔记，而是让每次与AI的讨论都能留下

的痕迹。工具和目录结构只是实现方式。真正重要的是先把它跑起来：找一份材料，放进raw/，让AI读一遍、讨论一遍、沉淀一遍。规则会在一次次处理中被问题推出来、被错误磨出来。正因如此，初版不需要完美。

如果你也经常觉得和AI的对话很有价值，但结束后很难留下什么，不妨先试一次。LLM Wiki的真正门槛不是搭目录，而是你愿不愿意每次都坐下来，真的参与一次讨论。

附录一：AGENT.md

## 1. 目标
这个知识库用于维护一个可持续更新、可查询、可追溯的个人知识库。
知识库分为两层：
- `raw/`：原始材料层，只增不改，作为事实来源保存
- `wiki/`：知识整理层，按主题维护，供查询与持续更新
辅助文件：
- `index.md`：全局索引与导航
- `log.md`：操作日志，记录每次 ingest / update / lint / archive
- `TASK.md`：单次任务指令
- `AGENT.md`：长期工作规则
---
## 2. 核心规则
### 2.1 raw 只读
- `raw/` 由用户手动维护，AI 只能读取，不能创建、移动、重命名、删除或改写
- 所有写入 `wiki/` 的重要内容，需可回溯到 `raw/` 来源
### 2.2 wiki 只写长期知识
- 只保留经过整理、适合长期复用的内容
- 不要把整篇 raw 原文直接复制进 wiki
- 优先更新已有页面，避免重复建页
- 新建页面默认包含：核心判断、主要内容、适用边界、相关页面、Sources
### 2.3 写入必须可追溯
- 事实性内容、概念定义、材料结论均应标注来源
- 个人理解、推论应单独标注为「理解 / 推论」
- 无来源支撑的内容不写入正式 wiki 事实区
### 2.4 冲突不得静默覆盖
> 冲突 / 待核实：
> - 版本 A：……
> - 来源：……
> - 版本 B：……
> - 来源：……
> - 当前状态：待核实
### 2.5 Sources 链接规则
- 使用 Obsidian WikiLink：`[[路径|别名]]`，去掉 `.md` 后缀
- 优先使用稳定的文件级链接
- 不要使用「结论：」「ChatGPT 回答：」等脆弱标题作为锚点
---
## 3. 权限与流程
- 修改任何文件前，AI 必须先提交处理方案并取得用户确认
- 用户确认后，AI 只能修改：`wiki/`、`index.md`、`log.md`，以及 `TASK.md` 中的 `## 当前处理对象`
- 任务完成后，将「当前处理对象」重置为「（待指派）」
---
## 4. 维护要求
- 新增 wiki 前先查是否已有相关页面
- 新建 wiki 后必须更新 `index.md`
- 每次操作后必须更新 `log.md`（只记录已完成事项、变更结果与遗留问题）
- 原则上不删除 wiki 页面，过时标注废弃或归档
- 定期检查死链、页面重叠、索引遗漏
---
## 5. 目录约定
/
├─ AGENT.md
├─ index.md
├─ log.md
├─ TASK.md
├─ raw/
│  ├─ inbox/
│  ├─ meetings/
│  ├─ clips/
│  ├─ docs/
│  └─ daily/
└─ wiki/
   ├─ topics/
   ├─ people/
   ├─ projects/
   ├─ companies/
   └─ concepts/

附录二：TASK.md

## 当前任务
- 处理对象：（待指派）
- 任务类型：（待指派）
- 任务目标：（待指派）
- 特别要求：（无）
任务类型可选：
- `ingest`：处理新材料并整理进 `wiki/`
- `update`：更新已有 `wiki`
- `lint`：检查链接、索引、重复页面、边界冲突
- `archive`：标注过时、重复或废弃页面
## 执行前检查
修改任何文件前，必须先完成并向用户确认：
- ⬜ 已读取 `AGENT.md`
- ⬜ 已读取当前处理对象
- ⬜ 已检查相关 `wiki/` 页面
- ⬜ 已形成处理判断：合并 / 新建 / 暂不写入
- ⬜ 已列明拟修改文件
- ⬜ 已提交处理方案，等待用户确认
## 处理方案要求
- 材料摘要
- 处理判断：合并 / 新建 / 暂不写入
- 拟修改文件
- 拟写入提纲
- Sources 设计
- 风险与边界
## 执行后要求
- 按 `AGENT.md` 更新 `log.md`
- 将「当前任务」下所有字段重置为「（待指派）」或「（无）」
- 不得改动 `raw/`