Andrej Karpathy 在 2026 年 4 月提出了一个思路：把 LLM 从"解释器"变成"编译器"。这个想法很小，但改变了知识库的工作方式。
解释器和编译器，差在哪
传统的 AI 问答，每次提问都是从一堆文档里现找答案，拼出来给你。像解释器一样，一行一行解释，下次来还是从头开始。知识不会积累。
Karpathy 的方案是反过来：摄入材料时，LLM 就把信息编译成结构化的笔记——摘要、概念页、对比、交叉引用。之后的查询直接面对已编译的知识，不需要重新检索。知识越用越丰富，像代码库一样持续生长。
他的比喻很简单：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。人负责判断方向，LLM 干所有的苦力活。
三层结构，分管各自的事
Raw 层，只读不改。论文、文章、笔记、图片——放进去就不动了，是事实来源。
Wiki 层，LLM 全权维护。它负责创建页面、更新摘要、补交叉引用、标出矛盾和过时之处。人负责读，AI 负责写。
Schema 层，人和 AI 一起迭代。一个配置文件，定义结构和工作流。这是让 LLM 从"啥都能聊的聊天机器人"变成"有纪律的维基维护员"的关键。
三个操作，一个循环
Ingest，把新资料变成知识。LLM 读取源文件，跟人讨论要点，写入摘要，更新索引，补交叉引用。一次摄入可能同时更新十几个页面。
Query，向 Wiki 提问。LLM 搜索相关页面，综合回答并带引用。关键洞察是：好的回答也应该归档回 Wiki——一次对比分析不该消失在聊天记录里。
Lint，定期健康检查。找页面间的矛盾、过时的断言、孤立无链的页面、缺失的交叉引用。像代码检查工具一样，保持知识库的整洁。
为什么有效
维护知识库最累的不是读或想，是记账——更新交叉引用、保持摘要不过时、标注新旧冲突、保证几十个页面的信息一致。人类放弃 Wiki，是因为维护成本涨得比价值快。LLM 不会烦，不会忘，一次能处理十几个文件。维护成本趋近于零。
这个想法可以追溯到 1945 年 Vannevar Bush 设想的 Memex——一个由人策展、带有联想路径的个人知识库。Bush 没解决"谁来维护"的问题，LLM 接手了。
实践中的问答
Q1：TASK.md 适合我吗？
流程设计合理，但操作摩擦偏高——每次要手动改 TASK.md 的处理对象行。不过保留这个摩擦是故意的：
- 对话常混杂 A/B 问题——TASK.md 指定处理对象，强制 AI 聚焦，比 prompt 约束更有效。
- AI 理解有偏差——讨论阶段是偏差检测机制，AI 输出理解、用户纠正。
- 全自动等于坟墓——保留"手动指定→看方案→确认"的环节，本质是策展而非负担。
结论：适合。
Q2：TASK.md 和 AGENT.md 有重复吗？
不是内容重复，是职责边界的问题。AGENT.md 定永久规则，TASK.md 定本次任务，这层分工是清晰的。模糊之处在于 TASK.md 里也写了大量流程规范（阅读→讨论→执行的具体步骤），这些更接近操作标准。但设计意图就是让流程跟每次任务绑定，不改。
Q3：为什么不让 AI 全自动维护？
设计 TASK.md 这套手动确认流程，不是没想过自动化，而是自动化本身有三个在实践里绕不过去的问题。
问题一：一次对话里常混着多个问题
实际跟 AI 聊天时，很少从头到尾只讨论一件事。更常见的情况是：开头在说 A，聊到一半冒出 B，后面大段的讨论都围绕 B 展开。这有可能是提问习惯不好，但也有的是 B 确实从 A 里自然生长出来的。
但 AI 在消化这种混合对话时，天然会追讨论最多的那条线——B。因为 B 占的篇幅大、来回多，AI 判断"这是重点"。
真正麻烦的是，A 可能比 B 更重要，只是当时没展开。A 被 B 淹没了。
TASK.md 的处理对象就是针对这个问题的：你指定"从这里面提取关于 A 的"，等于告诉 AI 把 B 的篇幅优势去掉，只看 A。这比任何 prompt 约束都管用——不是让 AI 更聪明，而是缩小了 AI 的决策范围。
问题二：AI 的理解和你的意图有偏差
AI 读一份材料，会形成自己的理解。这个理解在它内部是自洽的，拿出来说的时候也头头是道。但它可能完全猜错了你想保留的那个角度。
实际发生过：一份关于海报设计的对话，AI 提炼出的是"反馈质量方法论"，但用户真正想记的其实是"纠错句式 vs 编辑句式触发不同模型模式"这个更具体的发现。没有讨论阶段的纠正，偏差会直接写进 wiki，以后查到的就是 AI 的理解而非你的理解。
讨论阶段本质上是一个偏差检测机制。AI 输出方案，你瞟一眼，必要时说"不是，核心是那个"。这一步不能自动化，因为偏差只有你才能发现。
问题三：全自动等于坟墓
如果流程是：把材料扔进去 → AI 自动处理 → wiki 自动更新 → 没有然后。
这个体系产出的是干净的、结构化的、标注了来源的知识页面。但因为中间没有人看过、判断过、确认过，这些页面会变成一种特殊的东西：技术上正确，实际上没人关心。
一个知识库的价值在于它被查阅。查阅的前提是它的内容曾被人判断过"重要"。全自动处理跳过了判断环节，产出的是机器认为重要的东西，不是人认为重要的东西。时间长了，wiki 就成了一个自动生成、无人翻阅的坟场。
反过来，人为保留的那点摩擦——手动指定处理对象、看一遍讨论方案、说一句"确认"——不是操作的负担。是策展。是你在说：这个值得记，那个不要。
在这一点上，效率不是目标。
你的目标可以明确为一句话：
把 raw/ 中由你手动加入的新材料，经过“先讨论、后确认、再写入”的流程，沉淀为可追溯、可维护、避免重复的长期 wiki 知识。
边界也可以明确为一句话：
AI 只负责读取和整理，不负责创建、移动、修改 raw/；未经你确认，不得修改 wiki/、index.md、log.md、TASK.md。
一、你的真实目标
你的 Karpathy LLM Wiki 不是“资料库”，而是一个长期知识系统。
它的核心目标有四个：
- 保留原始材料
raw/是事实来源；- 原文不因整理而被污染；
- 后续所有 wiki 内容都能回溯来源。
- 把材料转化为知识
wiki/不复制全文；- 只提炼长期可复用的概念、主题、判断、结构；
- 材料进入 wiki 前要经过判断：合并、新建，还是仅保留 raw。
- 避免 AI 自动乱写
- AI 不能看见新材料就直接生成页面；
- 必须先读规则、读任务、读原文；
- 必须先给讨论方案；
- 你确认后才允许执行。
- 维护知识库结构稳定
- 优先更新已有页面；
- 避免重复页面；
- 来源必须可点击；
- 日志记录实际完成的变更；
- 任务完成后重置
TASK.md，等待下一次指派。
二、应当写清楚的边界
建议你在规则里明确这几个边界。
1. 用户与 AI 的分工
用户负责：
- 将新材料手动放入 `raw/`
- 在 `TASK.md` 中指定本次处理对象
- 审阅 AI 提出的讨论方案
- 明确确认是否执行写入
AI 负责：
- 读取 `AGENT.md`
- 读取 `TASK.md` 与处理对象
- 检查现有 wiki 是否已有相关页面
- 提出处理方案
- 在用户确认后更新 `wiki/`、`index.md`、`log.md`
- 任务完成后重置 `TASK.md` 中的处理对象2. raw/ 的绝对边界
这个应该写得硬一点：
`raw/` 由用户手动维护。
AI 不得创建、移动、重命名、删除或改写 `raw/` 中的任何文件。
AI 仅可读取 `raw/` 作为事实来源。理由：这是你的事实层。一旦 AI 可以动 raw，后续 wiki 的可追溯性就会变弱。
3. 执行权限边界
你现在的规则已经有“确认后再执行”，但建议再细化：
在用户明确确认前，AI 不得修改任何文件。
用户确认后，AI 仅可修改以下文件或目录：
- `wiki/`
- `index.md`
- `log.md`
- `TASK.md` 中的处理对象字段
除此之外，未经用户另行确认，不得修改其他文件。这个边界很重要，因为 TASK.md 本身也需要被重置，否则和“仅能修改 wiki/index/log”会有冲突。
4. AGENT.md 与 TASK.md 的优先级
建议明确：
`AGENT.md` 是长期总规则。
`TASK.md` 是单次任务指令。
如二者冲突，以 `AGENT.md` 为准。这样可以避免 AI 把某次任务的临时要求误当成长期规则。
三、对两个文件的具体修改意见
1. 建议修改
AGENT.md
重点不是大改，而是补一节“角色与权限边界”。
建议加在 2. 基本原则 后面，作为 2.8：
### 2.8 用户与代理的权限边界
- `raw/` 由用户手动维护，用于保存原始材料。
- 代理不得创建、移动、重命名、删除或改写 `raw/` 中的任何文件。
- 代理仅可读取 `raw/` 作为事实来源。
- 代理不得在用户确认前修改任何文件。
- 用户确认后，代理仅可根据本次任务需要修改：
- `wiki/`
- `index.md`
- `log.md`
- `TASK.md` 中的处理对象字段
- `AGENT.md` 是长期总规则，`TASK.md` 是单次任务指令。
- 如 `TASK.md` 与 `AGENT.md` 存在冲突，以 `AGENT.md` 为准。同时建议清理维护清单里的格式问题：
原文：
- - `TASK.md` 仅用于本次任务，不作为长期规则文件改为：
- `TASK.md` 仅用于本次任务，不作为长期规则文件删除孤立的空列表项：
-2. 建议修改
TASK.md
你的 TASK.md 可以更像一张“任务工单”，建议保留现在三阶段结构，但补强边界。
建议改为：
## 任务流程
**1. 阅读阶段**
- 先读取仓库根目录下的 `AGENT.md`，再读取仓库根目录下的 `TASK.md` 与其中指定的处理对象。
- 处理对象应为用户已经手动放入 `raw/` 的新材料。
- 必须基于文件内容形成理解，绝不能仅凭文件名判断。
- 必须检查现有 `wiki/` 中是否已有相关页面，避免重复建页。
- 此阶段不修改任何文件。
**2. 讨论阶段**
- 向用户输出讨论方案，原则上应包含以下 5 项：
1. 摘要
2. 与现有 wiki 的关系
3. 处理建议：明确指出保留 raw / 合并至某 wiki / 新建 wiki
4. 拟新增内容：若进入 wiki，需提供页面名称、存放于 `topics/` 还是 `concepts/`、内容提纲及 `Sources` 写法
5. 风险与边界：必须指出是否存在重复、冲突或概念不清
- 与用户讨论方案，等待最终确认。
- 此阶段不修改任何文件。
**3. 执行阶段**
- 仅在用户明确回复确认后，才允许实际修改文件。
- 允许修改范围仅限：
- `wiki/`
- `index.md`
- `log.md`
- `TASK.md` 中的处理对象字段
- 不得创建、移动、重命名、删除或改写 `raw/` 文件；`raw/` 仅作为只读来源。
- 执行完毕后，按 `AGENT.md` 规则将结果写入 `log.md`。
- 如本次任务已完成且用户无继续追加要求，则将本文件的“处理对象”重置为“（待指派）”，保留所有指令。四、我建议你采用的最终规则结构
最稳的结构是：
AGENT.md
= 长期规则 / 宪法
= 定义知识库目标、目录边界、写入原则、来源规则、权限范围
TASK.md
= 单次任务单
= 指定本次处理对象
= 要求 AI 按“阅读—讨论—确认—执行”流程工作不要让 TASK.md 承担太多长期规范，否则以后每次任务都可能夹带临时规则，逐渐污染主流程。
五、最终判断
你的两个文件目前方向正确，不需要重构。
真正需要修改的是三点：
1. 明确 `raw/` 只由用户手动维护，AI 只读不写。
2. 明确 `AGENT.md` 高于 `TASK.md`。
3. 明确执行阶段可以修改 `TASK.md` 的处理对象字段，否则“重置处理对象”与“只改 wiki/index/log”存在冲突。照这个改完，你的流程会比较稳： 用户负责输入事实源，AI 负责提出知识化方案，经确认后才写入整理层。
我：但是你给我的task.md 太重了
对，确实偏重了。TASK.md 不应该再重复 AGENT.md 的规则，它只需要做一件事：告诉 AI 本次处理谁，以及必须先讨论、确认后执行。
更轻的版本如下：
## 任务流程
### 处理对象
（待指派）
### 工作要求
1. 先读取 `AGENT.md`，再读取本文件指定的处理对象。
2. 处理对象默认为用户已手动放入 `raw/` 的新材料；`raw/` 只读，不得创建、移动、重命名或改写。
3. 阅读后先向用户输出处理方案，不修改任何文件。
4. 处理方案应说明：
- 材料摘要；
- 是否已有相关 wiki；
- 建议保留 raw、合并旧页，还是新建页面；
- 若写入 wiki，拟写入的位置、页面名称、内容提纲和 Sources 写法；
- 可能的重复、冲突或概念不清。
5. 仅在用户明确确认后，才允许修改 `wiki/`、`index.md`、`log.md`，以及将本文件的处理对象重置为“（待指派）”。
6. 执行完成后，在 `log.md` 记录本次完成事项。我建议你就用这个版本。
更进一步压缩，也可以改成这种“极简任务单”：
## 处理对象
（待指派）
## 规则
- 先读 `AGENT.md`，再读处理对象。
- 处理对象默认为用户已手动放入 `raw/` 的新材料；`raw/` 只读。
- 先讨论，后执行；未经用户确认，不修改任何文件。
- 讨论方案需说明：摘要、已有 wiki 关系、处理建议、拟写入内容、风险边界。
- 用户确认后，仅可修改 `wiki/`、`index.md`、`log.md`，并重置本文件的处理对象。
- 执行完成后更新 `log.md`。我更推荐第二个极简版。
理由是：AGENT.md 已经承担长期规则，TASK.md 只要像“工单”一样轻。否则 AI 每次读任务时会被流程文本牵着走，反而降低稳定性。
公众号原文：阅读公众号原文 ↗
EOF