深度解析：Karpathy 的 LLM Wiki 隐藏陷阱，高效构建个人知识库（附最佳实践建议）

公众号名称：sudden的AI日常

作者名称：是sudden哦

发布时间：2026-05-12 20:02

Karpathy的LLM Wiki思路有个隐藏的坑，如果没有深入理解那你的token会燃烧！

这套LLM Wiki方法论我已经深度实践过了，还出了一份手把手实操指导教程：我用Andrej Karpathy的LLM wiki思路实现了“活”的个人知识库（附模板）

这套维基方法论，

非常适合

人类研究垂直领域知识（如学术研究、项目前期调研等）
AI coding的背景知识（把你的思路、规范、你认同的架构等文档做成wiki给AI看）
项目知识库

不适合

企业级海量知识库管理（还是乖乖搞RAG吧）
简单的问答（直接问AI就行了）

当时发布的这份手把手实操指导教程重在思路实现和使用体验，没有过多关注token消耗，但如果你了解LLM Wiki方法论的核心思路，就会心生一个疑问，

随着原始文档库的增加，或wiki页面的增加，每次更新wiki都要遍历这些内容，如果还要跨文档的知识对比，那token消耗将是指数级增长的！

对，你想得非常对，任由你的智能体自由地wiki、挖掘、对比，token一定会燃烧！

于是，就着deepseek v4狠狠打折，我把它接入Claude Code，实际测一下，构建+更新 LLM Wiki 的真实token消耗情况，以及如何优化wiki逻辑，降低token消耗。

如果你想做LLM Wiki，一定认真看完，省钱啊～～

OK，拯救钱包计划启动！❥(^_-)

01

结论先行

几条实用的LLM Wiki最佳实践建议

一句话总结

LLM Wiki 的核心不是“更多页面”，而是“更高知识密度”，原则是“按需综合、谨慎沉淀”

以下建议提炼自下文的实践过程，很有参考价值，

1.收资料（Ingest）阶段必须“极简化”

只做轻量、确定性、常数级工作，比如，

建实体页
写来源
提取少量 metadata
更新索引

别搞这些自动，我们最开始就是进这个坑了，直接拉到300万token消耗量，

自动对比文章写综合页面
自动全局关联
自动矛盾分析
自动反向链接维护

否则 wiki 会从O(N)迅速膨胀为O(N²) ～ O(N³)，因为每新增一个页面，都会触发整个依赖图重新遍历。

2.综合（Synthesis）必须从“推模式”改为“拉模式”

我们最开始是自动对比文章写综合页面，意味着每读一份文档，就要对比N次，复杂度是O(N²)，文档量上来后，复杂度是指数级上升啊喂

更合理的方式（也是我们优化后的方式）：只有用户真正提问时，才按需做 synthesis，复杂度降为O(K)，K是问题涉及的wiki页面数

3.“好的回答”才值得写回 Wiki

什么是好的回答？比如，

新发现的跨论文联系
有价值的概念统一
清晰的冲突分析
高质量方法论总结

那么我们的写回流程可以设计为，

问答
↓
模型生成高质量分析
↓
模型提议：
“是否存为 synthesis 页面？”
↓
人工确认
↓
写回 wiki（“知识沉淀”）

4.反向链接不要实时维护

新页只写正向链接，反向链接只在体检(Lint)、用户要求时才做，否则也是token消耗大户

5.概念页（Concept Pages）必须提高创建门槛

很多 wiki 会过度生成概念页，导致概念越来越抽象、依赖图越来越密、全局更新越来越贵，

我的建议（和实践）是只有满足以下条件才创建概念页，

被 ≥3 个实体引用
在问答中反复出现
确实存在稳定定义
人工确认值得长期维护

6.冲突检测（Conflict）必须批处理

自动 conflict/reinforce 是另一个巨大 token 消耗源，不要在每次更新wiki时做冲突检测，而是放到定期体检中

只看结论，你的感受并不深，我们实践一下你就懂啦，下面开始 ❥(^_-)

02

为什么选DeepSeek V4

4月底，DeepSeek发布了大模型deepseek v4 pro 和 deepseek v4 flash，五一节前发出消息，狠狠打折！

这个折扣（特别是KV Cache缓存命中可以说是不要钱）诚意满满，Pro版输入12块钱（现在是3块），输出24块（现在是6块），缓存命中永久1折仅2分钱（2分钱！这不是白送吗），

1百万的上下文窗口 + 接近第一梯队的高性能模型（SWE-bench 81%）+ 打骨折的价格

再加上4月29日增加的视觉能力，只能说，太能打了！

于是赶紧用起来～

值得一提的是，这俩模型都是MoE（混合专家）架构，可以理解为需要哪里激活哪里，

V4-Flash：284B 总参数 / 13B 激活
V4-Pro：1.6T 总参数 / 49B 激活

最后，deepseek是基于华为昇腾芯片适配的，有信创、国产化适配需求的同学们，愣着干什么，用啊！

03

用 LLM Wiki 做垂域研究

对于我们最常用常见的需求场景就是——垂直领域学术研究、项目前期调研等，因此这里基于这个场景进行维基构建和优化。

LLM Wiki 过程设计

以下是我总结的通用的垂直领域知识研究Wiki过程，你可以带入你想做的任何领域的研究，

日常：arvix自动找高价值垂直论文，下载到指定路径（如./paper），人类阅读后选择是否存入raw
存入raw，CC 执行ingest
用户提问query，CC回答，并经人类确认后将有价值的回答存入wiki
定期体检（Lint），合成/标注/反向链接/综合页面等，全部推迟到问答或体检时(Lint)按需执行

但要注意，你放到raw里的文档内容一定要垂直，比如，

AI安全、大模型安全、提示词注入，是垂直领域 √
AI安全、Python教程、数字信号处理，不是垂直领域 × >>> 你应该分别建wiki

成果

我研究的是AI安全方向（AI Safty），咱们直接看成果，

如果你想看过程，了解如何用llm wiki构建个人知识库，我在这篇教程里详细讲解过啦：我用Andrej Karpathy的LLM wiki思路实现了“活”的个人知识库（附模板）

初次放入raw中13个PDF格式的英文论文和行业标准，总共产出 36 个文件：1 规则文档 + 1 执行入口 + 31 wiki 页面 + 3 基础设施 = 从零到可用的完整 AI安全知识库，

知识库结构如下，

llm-wiki-aisafty/
├── llm-wiki-aisafty.md          # 最高规则（423行）
├── claude.md                     # 执行入口
├── raw/                          # 13份原始资料，人类放入的原始信息（只读）
└── wiki/                         # 31个页面，会随着研究的深入扩充
├── _wiki_index.md            # 索引
├── _wiki_log.md              # 日志
├── _tag_registry.md          # 标签注册表
├── entities/   (13页)        # 实体：论文/标准/工具
├── concepts/   (11页)        # 概念：跨文档抽象主题
└── syntheses/  (4页)         # 综合：对比/矩阵/综述

这里使用的Obsidian看一下知识中的实体概念等关联关系

然后咱们就可以对这个wiki库：提问、新增资料、定期体检了

你可以做的操作

提问：对着 wiki 问任何 AI 安全相关问题，模型会读索引定位页面并给出带引用的答案
加新资料：把新 PDF 丢到 raw/，告诉模型处理
定期体检：让模型检查矛盾、过时内容、孤立页面、链接缺口等
修改页面：发现错误或需要补充时直接告诉模型

模型的工作方式

模型始终遵循 llm-wiki-aisafty.md 定义的规则，每次操作后自动更新索引（_wiki_index.md）、日志（_wiki_log.md）和标签注册表（_tag_registry.md）

Wiki更新过程

1、新增文档到raw后，有两种方式更新wiki

主动提出，如“我新增了几份文档到raw，你更新一下wiki”
wiki库例行检查(Lint)时自动发现和更新

2、Claude Code执行wiki规则

3、Claude Code向人类确认理解是否准确

4、确认准确后，创建wiki页面

更新结果

04

Token用量

现在我们来到重点环节，

前文我们提到，如果你了解LLM Wiki方法论的核心思路，就会心生一个疑问，

随着原始文档库的增加，或wiki页面的增加，每次更新wiki都要遍历这些内容，如果还要跨文档的知识对比，那token消耗将是指数级增长的！

用量小节

1、首次构建wiki库比较费token，主要取决于raw中文件的数量和大小

花费2.34元，287万 tokens，其中KV Cache（缓存命中）214万

2、后续更新维护wiki其实比较省费用（但不省token，需优化），因为缓存命中足够高

花费0.35元，326万 tokens，其中KV Cache（缓存命中）310万

3、这个token消耗量，且更新比新建wiki的实际消耗量还大，我觉得需要优化wiki逻辑（还好有缓存命中兜底费用……）

初始化wiki库消耗

包括规则制定、pdf全量阅读、wiki编制，raw里有13个pdf论文、标准类文档

token消耗如下，

在DS 5月打2.5折且缓存命中打1折的情况下，花费2.34元，pro和flash消耗分别如下，缓存命中很高

wiki更新消耗

在raw里新增6个pdf论文

token消耗如下，

在DS 5月打2.5折且缓存命中打1折的情况下，消耗如下（减去初始化的用量），

本次花费0.35元，326万 tokens，其中KV Cache（缓存命中）310万

这个token消耗量，且更新比新建wiki的实际消耗量还大，我觉得需要优化wiki逻辑（还好有缓存命中兜底费用……）

已经看到这里啦，如果觉得不错，随手点个点赞、转发、喜欢吧～

如果想第一时间收到推送，可以给我个星标⭐哦～

你们的支持和鼓励，是我持续更新的最大动力 ❥(^_-)

05

Wiki逻辑优化成果

刚才的用量分析，已经感到不对劲，如果raw文档越来越多，可以想象每次更新Wiki，你的心都会颤抖。

高token消耗原因分析

猜测

13 篇英文长论文，最终跑到 300万 token，偏高，整个流程可能踩中高token消耗的点（token会指数级膨胀）：

DeepSeek 长上下文
多轮反思/重写
recursive wiki synthesis
cross-paper synthesis（token会指数级膨胀）

验证

根因：“递归合成”导致指数膨胀

膨胀源是当前规则中(llm-wiki-aisafty.md)设计的连锁触发链：

新资料 → 建实体页 → 检查新概念（需遍历所有已有概念）→ 建概念页 → 概念页引用多个实体 → 更新每个被引用实体的反向链接 → 这些实体又链接着其他概念 → 继续触发更新检查 → 检查综合页是否需更新 → 读多个概念 + 多个实体 → 发现矛盾 → 读矛盾双方所有源实体 → 标注 [!conflict] → 发现加固 → 读多方源实体 → 标注 [!reinforce]

这不是 O(N)，是 O(N³)，每次收资料触发的更新量随 wiki 总页面数指数增长！

三个递归源

缺陷	表现	膨胀类型
递归 wiki synthesis	建概念页后反向更新所有关联实体，关联实体又牵连更多概念	深度优先遍历整个依赖图
cross-paper synthesis	自动触发综合页创建和更新	N 篇论文有 N² 个潜在两两对比组合
自动反向链接维护	每次新建页面搜索并更新所有"相关"页面的链接	"相关"判断本身需要理解整个 wiki

果然

自动构建synthesis（综合页面）是消耗大户，每次构建页面都会把所有wiki都拿出来反复品读，这token能不烧起来吗，

改，改成每次用户提问时模型生成的有价值的对比综合页，才写入synthesis中（这也正是karpathy提出的想法之一，好的答案可以直接当成新页面存回维基里）

Wiki逻辑优化方案：推模式 → 拉模式

核心原则

模式	触发时机	做什么	复杂度
推（收资料时 ingest）	每份新资料入库	建实体页、更新索引、写日志	O(1)
拉（问答时 query）	用户提问	按需读取相关实体页，经确认后存为综合页	O(K) K=问题涉及的页面数
拉（体检时 lint）	用户要求	矛盾/加固标注、反向链接补充、概念页批量刷新	O(N) 但低频执行

具体改动

改动项	优化前（推模式）	优化后（拉模式）
实体页格式	60-100 行（摘要+贡献+方法+性质表+局限性+相关页面+来源）	≤30 行卡片式（摘要+3-5 条要点+来源）
概念页创建	收资料时自动检查并创建	仅当问答中明确讨论，且被 3+ 实体引用时，经人确认后创建
综合页创建	自动发现关联→自动创建	仅在问答产生有价值的分析后，模型提议 + 人确认
[!conflict] / [!reinforce]	收资料时同步标注	体检时集中标注
反向链接	建新页时主动搜索添加	新页只加正向链接，反向链接体检时集中补充
收资料汇报	每份 3-5 条详细发现 + 人工确认	标题 + 一句话核心发现，不经中间确认
单批上限	无限制	≤5 份

关键优化项

核心优化点：收资料(Ingest)只做常数级工作，合成/标注/反向链接全部推迟到问答或体检时(Lint)按需执行

收资料时只建卡片式实体页，把合成留给真正需要它的问答场景，这样综合页只在产生实际价值时才被创建，不会随着资料数量组合爆炸。

这样正是Karpathy的维基思路里提到的：

“好的答案可以直接当成新页面存回维基里。你之前要求做的对比、分析、发现的新关联——这些都是有用的东西，别让它们消失在聊天记录里。”

优化后用量情况验证

任务

在raw中新增了一篇英文论文，让cc更新wiki

任务前|后用量

对比优化前的wiki更新消耗：共消耗326万 token，其中KV Cache（缓存命中）310万

优化后共消耗输入42万 token，其中KV Cache（缓存命中）41万，

相比优化前消耗合理，优化成功～～

好了我们前面深一脚浅一脚终于上岸，赶紧总结一下，便于避坑

>>> 几条实用的LLM Wiki最佳实践建议见文首～

已经看到这里啦，如果觉得不错，随手点个点赞、转发、喜欢吧～

如果想第一时间收到推送，可以给我个星标⭐哦～

你们的支持和鼓励，是我持续更新的最大动力 ❥(^_-)

往期推荐

我用Andrej Karpathy的LLM wiki思路实现了“活”的个人知识库（附模板）

你一定用得上的智能体skills推荐，主流技能市场盘点

黑马Hermes Agent挑战OpenClaw：6万星的智能体有多强？（附快速部署教程）

智能体搭建| 如何用OpenClaw搭建你的“一人公司”（附完整配置模板）

OpenClaw进化| Obsidian+Ollama，用RAG打造真正懂你的小龙虾

内容效果不满意？点此反馈