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

告别AI对话“用完即走”，揭秘如何让模型对话真正沉淀为可生长的知识库。
核心内容：
1. LLM知识存储的局限性：模型为何无法记住单次对话
2. LLM Wiki框架核心理念：让模型维护外部知识库
3. 实践方案：目录结构、规则层与维护流程

当我们和模型对话、处理文档时，可能会产生一种感觉：模型读过了，好像它就学会了。

比如在一个对话里，告诉模型一种不存在的语言，或者告诉它一台尚未发布的苹果手机的详细参数。它可能根据这些信息继续推理、翻译、分析，甚至回答得很像真的「懂了」。

但如果你关闭这个对话后重新开启新对话，再问它同样的问题，模型大概率不知道。

这不是模型装傻，而是因为模型没有被训练。

模型可以粗略理解为一个巨大的压缩包： 训练阶段把大量知识压缩进参数里；推理阶段，模型根据你的提示词和上下文，把相关能力临时展开。

但这个压缩包本身不会因为你和它聊了一次，就自动改写。

你给它的新材料、新规则、新案例，进入的是当前上下文，不是模型参数。它可以在这一轮对话里使用这些信息，但不会因此把它们变成自己的长期知识。

所以，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 的工作规则

从目录结构看，LLM Wiki 很简单：

把原始材料放进只读的 raw/ → AI 读取并讨论关键收获 → 写入 wiki/ → 更新 index.md 和日志

但真正决定这套系统能否长期运行的，不是目录，而是规则层。没有规则，AI 会把知识库变成另一堆随手写的文件；有了规则，AI 才知道什么能动、什么不能动、怎么写、往哪写、凭什么写。

六条关键规则

1. raw/ 只读不改

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

2. 合并优先于新建

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

3. 默认可追溯

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

4. 项目级权限控制

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

5. 操作留痕

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

6. 页面不删，只标注废弃或合并

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

以上六条规则落在文件里就是 AGENT.md（详见附录一）。

TASK.md：一张工单

Karpathy 没有把 LLM Wiki 框定为「用户手动维护」或「AI 全自动维护」。他强调的是监督程度：可以一次只摄入一个来源并保持参与，也可以批量摄入但监督更少。

我在这个光谱中选择了半自动化方案，基于三个原因。

原因一：认知参与

这不是技术上的理由。如果流程变成「材料扔进 raw → AI 自动处理 → wiki 自动更新」，看起来很顺，但最后很容易变成「没有然后」。

知识库被更新了，摘要被生成了，链接被建立了——可我并没有真正参与理解。我并没有诚实地回答：

如果这些问题没有被提出，wiki 会不会变成另一种形式的笔记坟墓。

原因二：会话跑偏

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

原因三：理解偏差检测

AI 读材料时会在自己内部形成一个自洽的理解——但这个理解可能完全猜错了我想保留的角度。

因此我更希望「先讨论，后执行」：让它先说出来，不合意就纠正，而不是让它直接动手改完再找问题。

基于以上三个原因，我创建了 TASK.md，用两个机制分别回应：

（详见附录二）

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

一次实践

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

步骤 1：阅读

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

步骤 2：讨论

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

具体到这次对话，ChatGPT 的回复里有一段很精准的引文：

很多人以为自己的职业身份是本质——律师、程序员、物理学家。
但顶尖人才往往把职业看成载体。
真正可迁移的，是背后的认知结构。

但 AI 在整理时漏掉了这段。我追加指令让它重新提取并纳入总结，同时 AI 对自媒体讨论部分也做了遗漏——这恰好印证了「先讨论后执行」的必要性：AI 会形成自己的理解，但这个理解不一定是你要的。讨论环节就是用来纠偏的。

步骤 3：确认

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

步骤 4：执行

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/`

本文采用 Creative Commons Attribution-NoDerivatives 4.0 International（CC BY-ND 4.0）协议发布。 允许原文转载，转载请在文章末尾完整标注作者署名（极客律师）及原文链接。

登录查看剩余 70% 内容