当我们和模型对话、处理文档时，可能会产生一种感觉：模型读过了，好像它就学会了。
比如在一个对话里，告诉模型一种不存在的语言，或者告诉它一台尚未发布的苹果手机的详细参数。它可能根据这些信息继续推理、翻译、分析，甚至回答得很像真的「懂了」。
但如果你关闭这个对话后重新开启新对话，再问它同样的问题，模型大概率不知道。
这不是模型装傻，而是因为模型没有被训练。
模型可以粗略理解为一个巨大的压缩包： 训练阶段把大量知识压缩进参数里；推理阶段，模型根据你的提示词和上下文，把相关能力临时展开。
但这个压缩包本身不会因为你和它聊了一次，就自动改写。
你给它的新材料、新规则、新案例，进入的是当前上下文，不是模型参数。它可以在这一轮对话里使用这些信息，但不会因此把它们变成自己的长期知识。
所以，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 才知道什么能动、什么不能动、怎么写、往哪写、凭什么写。
六条关键规则
raw/ 只读不改
AI 可以读 raw/ 提取事实，但不能创建、删除、改名或修改其中任何文件。raw/ 是原始材料，不是 AI 产物。
合并优先于新建
新材料进来时，先查 wiki 是否已有相关页面。有就合并，没有才新建。避免 wiki 变成按时间堆叠的「另一份 raw」。
默认可追溯
wiki 里每条重要信息必须标注来源，没有来源支撑的内容不能写入事实区。来源链接必须是可点击的，冲突信息不能静默覆盖，应并列展示不同版本。
项目级权限控制
AI 在用户确认前不能修改任何文件。确认后也只能改 wiki/、index.md、log.md 等处理对象字段。
操作留痕
每次操作后更新 log.md；新建 wiki 页面后必须更新 index.md。log 只记录已完成事项、变更结果和遗留问题，不写行动计划。
页面不删，只标注废弃或合并
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
目标这个知识库用于维护一个可持续更新、可查询、可追溯的个人知识库。知识库分为两层：- 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）协议发布。 允许原文转载，转载请在文章末尾完整标注作者署名（极客律师）及原文链接。
