Karpathy 的 LLM Wiki 两周后：bookkeeping 那个洞察是对的，但出了个人规模就开始脆

两周前我写了 ceiling 那篇，论点是：schema 层是一个伪装成配置文件的编程任务、Agent 已经不在你的笔记本上了、lint 在几百页之后就做不动了。

我想用一篇续作把这件事讲得更锋利一点——一部分是因为我欠几条修正，另一部分是因为这两周里社区做出来的东西，比我那篇文章本身要说的更多。

如果你看过那一篇，可以跳过 recap。如果没看过，一句话版本：LLM Wiki 这套 pattern 在"瓶颈在哪里"这件事上是对的，在"出了个人规模该怎么办"这件事上是欠定义的。 这一篇是数据和证据。

Karpathy 讲对的那一条（我想反复说）

任何长期运行的知识库，瓶颈不是检索，是 bookkeeping。

交叉引用会腐烂、摘要会和源头偏离、概念页会重复。大多数个人 wiki 死掉的原因从来不是"找不到"——是没人愿意继续维护它。Karpathy 把这一点讲得很清楚：LLM 是唯一一个有耐心、够细心、边际成本几乎为零的实体，可以一直做这种维护工作。

他给出的最有杀伤力的动作是 file-back：当一次查询产出有价值的东西时，把它写回 wiki 成为一个新的页面。对话不再是一次性消耗——它生产上下文，而不只是消耗上下文。

这一条是对的。我没看到任何严肃的反驳。这两周里所有有质量的回应，都是接受这个前提，再去争论实现方式。

个人规模这块甜蜜区——以及 Karpathy 自己给的那个补丁

我想纠正上一篇里我暗示但没有写清楚的一件事。

原 gist 描述这套设置 "works surprisingly well at moderate scale"——大约 100 篇源资料、几百页编译出来的 wiki。我之前有时候把这个写得像是 Karpathy 划了一个硬上限。他没有。这是一个经验上的甜蜜区，不是架构定理。

更重要的：在 gist 的 "Optional: CLI tools" 一节，Karpathy 明确推荐了 qmd —— 一个做 BM25 + 向量检索 + LLM 重排的 CLI，带 MCP server。他推荐的时机是：当你的 wiki 长大到 index.md + grep 撑不住的时候。

这件事重要在哪里？因为很多解读——包括我自己上一篇文章的某些 framing——把 LLM Wiki 摆成了"file 派 vs RAG 派"的争论。这是误读。Karpathy 不反向量。他反的是为个人规模的工作过早引入复杂的 RAG 基建。他自己说得很干脆：wiki 长大之后，你想要一个像样的检索层。

有意思的问题——他 gist 里没有回答的——是：当"个人规模"变成别的什么时候，那一层"像样的检索层"应该长什么样？多设备。多 Agent。一个团队。一个需要从托管 API 访问知识的产品。这正是这两周里社区工作收敛的方向。

出了个人规模会在哪里撑不住：三块证据

我不打算从第一性原理论证这件事。社区已经把活干完了，收敛方向很难看错。

1. rohitg00 的 LLM Wiki v2 —— 混合检索是必须的，不是可选的

Rohit 的 LLM Wiki v2 —— 项目自我描述是 "extending Karpathy's pattern with lessons from building agentmemory" —— 跑的是 BM25 + 向量检索 + 一个 582 节点的知识图谱，用 Reciprocal Rank Fusion 融合排名。每个节点带置信度评分。在 LongMemEval-S 这个长程记忆 benchmark 上，得分 95.2%。

他给出的架构理由很直接：扁平的 index.md 查找在 200–500 文档之后会显著退化。 不是因为 token 不够，而是因为当 LLM 要在上千个候选里做相关性判断时，注意力会稀释——而你判断不出来什么时候开始稀释、漏掉了什么。

这是关于 LLM Wiki 天花板最重要的一个数据点：现在已经有一个跑通了的、有 benchmark 支撑的替代方案，而它默认就把混合检索当作底层假设。

2. gulliveruk 的原则 —— scoping 应该是确定性的，reasoning 才是概率性的

gist 评论区里被引用最多的一句话，是 gulliveruk 的：

Scoping should be deterministic. Reasoning should be probabilistic.

翻译成实操：当一个 Agent 要判断哪些知识和当前 query 相关，那是一个集合操作——你想要一个确定性的预过滤（向量相似度、tag 匹配、图边）来缩小候选集。你不想让 LLM 拿 token 去扫一份上千行的索引、然后悄悄从注意力里漏掉一些。

LLM 是在预过滤之后的小集合上做推理的正确工具。它不是做预过滤本身的正确工具。

这一句话同时诊断了为什么纯 index.md pattern 会快速变脆：它让 LLM 去做应该被一个 query 接住的集合操作。

3. Graphify —— 同一个天花板，从另一个角度凿

safishamsi/graphify —— 发布 48 小时拿下 2,000+ stars —— 把 Karpathy 的 pattern 里 index.md + LLM 重排的整套换成了图拓扑。代码侧用本地 tree-sitter 解析（零 token），非代码侧用并行 LLM 子代理做语义抽取，然后用 Leiden 社区发现算法 在边密度上做聚类。SHA-256 缓存、文件监听模式、Git 钩子集成。一行命令：/graphify .

Graphify 为什么会存在、为什么 48 小时就火起来——和 rohitg00 的混合检索是同一个原因：原版 index.md + grep 工作流到一定规模就放不下了。 Graphify 选择完全跳过 embedding，押在图拓扑上；rohitg00 选择两个一起上。哪个更好不是重点。重点是：同一周里两个独立做的、最 starred 的 pattern 扩展项目，都在原版没有的地方加了一层结构化检索。

这是高质量技术响应能拼出来的、最接近"共识"的东西。

productize and extend，不是"我们干赢了 Karpathy"

我在做 KnowMine，我想在这个语境里把"它是什么"讲精确。

KnowMine 不是"一个更好的 LLM Wiki"。Karpathy 的 gist，按他自己的 framing，是一个 idea file——故意抽象，被设计成 copy-paste 给任意 coding Agent，让 Agent 自己去 instantiate。它不是产品。KnowMine 是同一个洞察，被产品化和扩展之后的样子。

productize 具体指：

• Schema 层 ship pre-built。 你不用从空白文件开始写 AGENTS.md。19 个工具的 MCP 接口面就是 schema。每次 add_knowledge 调用都自动做标题抽取、tag 推断、folder 归类——不需要你写 config。
• 检索从第一条知识起就是 hybrid 的——语义预过滤、类型化关联、版本历史——而不是等到 500 文档门槛才上。
• 接口是 MCP，不是本地文件系统。 任何 MCP 兼容 runtime——Claude Code、ChatGPT、Cursor、OpenCode、跑在 VPS 上的定时 Agent——读写的是同一个知识库。三档权限模板（read-only / read-write / full）让你在 Agent 跑在不完全可信的环境时也能约束它能碰什么。

extend 具体指：

• file-back 是一个 tool call，不是手动步骤。 add_knowledge 在 LLM 判断有东西值得保留时就立即写回。没有"先 drop 文件再跑 ingest"那个循环。
• 类型化关联是显式的，不是从 [[wikilinks]] 解析出来的。 add_knowledge_link 让 LLM 显式声明两条知识为什么关联——based_on（基于）、refutes（反驳）、extends（扩展）、evolved_from（演化自）、related_to（相关）。这个图是故意的，不是意外的。
• 版本历史是内置的。 每次有意义的更新都通过 get_knowledge_history 留下版本记录。"lint" 这件事——什么是过期的、什么是被反驳的、一个决策是怎么演化的——有了能跑的底层。
• Memory 和 Knowledge 是分开的。 add_knowledge 存文档、文章、想法。save_memory / recall_memory 存决策、教训、偏好、领域见解。大多数个人 wiki 把这两类糊在一起、然后慢慢付代价——模型分不清一页是"关于世界的事实"还是"你持有的立场"。KnowMine 在工具层就强制把这条线划开。
• Soul。 同一套接口里还有 generate_soul / get_soul——一个由累积的 memory 和 knowledge 生成的用户画像，可以按需刷新。当你换 Agent 时，新 Agent 读你的 Soul，行为表现得像它认识你。Karpathy 的 wiki 给 Agent 的是你的知识。KnowMine 还给它一个关于你的模型。

KnowMine 真正诚实的定位是这一句：它把 bookkeeping 瓶颈从 LLM 上下文窗口迁移到了一个可工程化的检索与数据层。 这不是"没有瓶颈"。这是"一个我们知道怎么 instrument、scale、付费的瓶颈"。

一条迁移路径，benchmark 在路上

如果你已经在 Karpathy 风格的 wiki 上投入了时间，并且已经长出了个人规模的甜蜜区，你不应该把它扔掉。

我会作为本文的后续，发布一个 Karpathy-pattern → KnowMine migration skill。它接受一个本地 wiki 目录（标准的 raw/ + wiki/ + index.md 结构），用 add_knowledge 批量写入每一页，把 [[wikilinks]] 解析成 add_knowledge_link 的类型化关联，最后给你一个可以从任意 MCP runtime 访问的 workspace。

为了让对比是数据驱动而不是 marketing，skill 发布时会配一个公共数据集 benchmark（≈100 篇 arXiv 上的 ML 论文，按 Karpathy 风格的 schema ingest）。同样 20 个问题，三档配置：

1. index.md + LLM 导航（Karpathy 原生）
2. BM25 + 向量（qmd 或等效）
3. KnowMine MCP（语义预过滤 + 类型化关联 + 版本历史）

四个指标：召回（相关知识有没有被找到）、引用准确度（答案有没有指对源）、成本（token + API 调用 + 实际时间）、人工修正量（答案需要多少修改才能用）。

数字会出现在 migration skill 的发布文章里——不在这一篇。我宁可现在发方法论、等数据真出来再发结果，也不要先 ship 一些听起来合理但没有 receipts 的说法。

诚实的边界

如果你处在个人研究规模、用一个 coding Agent、在一台笔记本上、Karpathy 的 pattern 对你跑得通——留下。 那个场景下它就是正确答案。gist 写得很好，qmd 推荐能接住你大部分的成长。

KnowMine 是写给以下三件事中至少有一件改变了的人：

• 规模。 几百条之后，你想要确定性的预过滤。LLM 应该用来 reasoning，不是用来 scoping。
• Runtime。 你的 Agent 不只是笔记本上的 Claude Code——它也是手机上的 ChatGPT、Slack 机器人、跑在 VPS 上的定时任务。文件到不了那些地方，协议可以。
• Schema 所有权。 你不想从零写 AGENTS.md。你想要合理的默认值，外加可以后期调整的选项。

如果以上三件都没变，LLM Wiki pattern 正在做它被设计来做的事。这不是销售话术——是我自己也会从那里开始。

收尾

Karpathy 的 LLM Wiki 在唯一一件真正重要的事情上是对的：bookkeeping 才是真正的工作，而 LLM 是唯一会有耐心做下去的实体。其余都是实现选择。

两周的社区工作把实现选择讲得更清楚了。混合检索在几百条之后不是可选的。集合操作属于 query 层，不属于 LLM 注意力。图结构是扁平索引的真正替代。pattern 在你的 Agent 走出笔记本的那一刻就开始撑不住了。

KnowMine 是这套实现选择中的一种，做得一致、作为产品 ship 出来。同样会复利的知识。同样的 file-back 循环。没有本地的锁定。

如果你已经在撞天花板，migration skill 下周发。benchmark 数字一起发。