2026 年 4 月 3 日，Andrej Karpathy 发布了一篇关于他称为“LLM Knowledge Bases”的内容，并在数小时内引爆了 AI 社区。其核心想法出奇地简单：与其在每次提问时使用 RAG 从原始文件中检索 chunks，不如让 LLM 将这些文件编译成一个结构化、相互链接的 markdown wiki；它可以跨 session 持久存在，随着时间积累知识，并让之后的每一次查询成本更低。
Karpathy 描述了这样一种方式：把论文、截图、repos 和文章都扔进一个 /raw 文件夹，然后让一个 LLM 处理它，生成一个包含摘要、backlinks、概念图和索引文件的 wiki，模型可以自行导航其中的内容。没有 vector embeddings，没有复杂的 retrieval pipeline，只是会不断复利积累的 markdown 文件。这条 tweet 火了，后续的 GitHub gist 也火了，突然之间，所有人都在讨论用 compiled knowledge 替代 retrieval。
我的第一反应是兴趣夹杂着一点轻微的沮丧，因为我在用 Claude Code 处理较大 repos 时一直在围绕类似想法打转，也遇到了所有人都会遇到的同一堵墙：模型在每个 session 都会从头重新发现你的 codebase，而在模型真正理解架构之前，context window 就已经被填满了。Karpathy 的表述让我一下子明白了这个方向，但他自己也承认他的 setup 是“a hacky collection of scripts”，而我并不打算从零开始拼一个自己的 wiki compiler。
然后，48 小时后，真的有人把它做出来了。
Graphify 是什么（以及不是什么）
一位名叫 Safi Shamsi 的开发者发布了 Graphify，这是一个开源工具，专门针对 codebases 将 Karpathy 的模式工程化。你把它指向任意文件夹，它会解析其中的所有内容：19 种语言的代码、PDF、markdown、图片（包括白板照片和图表，通过 Claude Vision 处理），然后构建一个完整的知识图谱，包含 community detection、交互式 HTML 可视化、带有智能 backlinks 的 Obsidian vault，以及一个任何 agent 都可以从 index.md 开始导航、无需解析 JSON 的 wiki。安装只需一行：
pip install graphifyy && graphify install
然后你在 Claude Code（或 Codex、OpenCode、OpenClaw）中输入 /graphify，并将它指向你的项目目录。输出会落在一个 graphify-out/ 文件夹中：用于交互式探索的 graph.html，突出 god nodes 和意外连接的 GRAPH_REPORT.md，作为持久化可查询图谱的 graph.json，以及一个 incremental cache，使后续更新不必重新处理所有内容。
Graphify 不是什么：它不是 RAG system，不是 vector database，也不是 chatbot wrapper。它是一个编译步骤，正如 Karpathy 所描述的那样，把一个混乱的目录转换成一个结构化的知识产物，任何 LLM agent 都可以在不读取每个文件的情况下对其进行推理。
71.5x 这个数字：先保持怀疑，再看计算
标题级别的主张是：与读取原始文件相比，每次查询所需 tokens 减少 71.5x。这个数字听起来好得有点不真实，所以我查看了 benchmark 实际上是如何构造的。
在小规模场景下（6 个用于建模 HTTP transport layer 的 Python 文件），压缩幅度很小，而且多少有点不是重点：这些文件本来就能放进一个 context window，真正的价值在于结构清晰度：你能看到 Client、AsyncClient、Response 和 Request 是这个项目的 god nodes，也能看到将相关 modules 聚合在一起的 community clusters。这很有用，但不是 71x 的提升。
在 52 个文件的场景下，也就是由代码、研究论文和图片混合组成的 corpus，token 减少确实达到了 71x 多一点。这个 repo 随附了包含原始输入和实际输出的完整 worked examples，因此你可以自己验证这些数字；这正是我希望更多开源项目采用的透明度。压缩能够随着规模扩大而显现的原因很直接：图谱会把所有内容提炼成 nodes、edges、community summaries 和 report，LLM 可以用读取原始内容所需 tokens 的一小部分在其中遍历。
这在 agentic workflows 中最重要。如果你有多个 agents 并行写代码，或者你正在运行一个跨越多个 commits 的长 Claude Code session，那么在每一轮都把 52 个原始文件喂进 context 是浪费。喂入一个能捕捉相同结构信息、但只需 1/71 tokens 的 graph report，是一种从根本上不同的成本结构。
底层实现：没有魔法，只是优秀的工程
其架构令人耳目一新地透明。代码文件会通过 tree-sitter AST parsing 处理，支持 19 种语言：Python、JavaScript、TypeScript、Go、Rust、Java、C、C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、Elixir 和 Objective-C。这完全在本地运行；对于代码，任何文件内容都不会离开你的机器。文档和图片会通过你所在平台已有的 model API 进行语义提取：如果你在 Claude Code 中就是 Claude，如果你在 Codex 中就是 GPT-4。
NetworkX 构建图谱，graspologic 提供的 Leiden algorithm 负责 community detection，vis.js 渲染交互式可视化。不需要 Neo4j，不需要外部 server，一切都在本地运行。图谱中的每条 edge 都会被标注 confidence level：EXTRACTED、INFERRED 或 AMBIGUOUS，因此你始终知道哪些是从源材料中发现的，哪些是模型根据上下文推测的。
incremental update system 最能体现工程质量。--watch 模式会在后台 terminal 中运行，并在你的 codebase 变化时保持图谱更新：保存代码文件会立即触发 AST 重建，无需 LLM 调用；而文档和图片变更会提示你运行 --update 来进行语义重处理。Git hooks（graphify hook install）会在每次 commit 和每次 branch switch 后重建图谱；如果重建失败，hook 会以非零状态退出，让 git 暴露错误，而不是带着 stale graph 静默继续。最后这个细节听起来很小，但之前的行为是在失败时仍然 exit zero，这意味着你的图谱可能在没有任何警告的情况下变旧：这正是会侵蚀开发者工具信任度的那类静默失败。
实际效果如何：在我自己的 Repo 上运行它
阅读 benchmarks 是一回事，所以我在一个真实项目上运行了 Graphify，看看输出实际是什么样子。这个 repo 是我用 Claude Code 构建的一个 QR code generator：总共 27 个文件，包括 src/、test/ 和 configs 下的 18 个代码文件，4 个文档（包括 AGENTS.md、CLAUDE.md 和 FLOW.md），以及 5 张图片，包括 UI 截图、Towards Deep Learning logo 和几个 test-fixture PNG。
pipeline 分四个阶段运行。首先，它扫描文件夹并对所有内容进行分类。然后，它用 tree-sitter AST 在本地解析全部 18 个代码文件，不涉及 LLM，完全免费：仅这一轮就提取出每个 function、class、import 和 call relationship，生成了 162 个 nodes 和 240 条 edges（例如 src_main → calls → selectPalette()）。第三，它启动 6 个并行 Claude subagents 来读取文档和图片：这就是 LLM 部分，大约 193k tokens。vision agents 查看 UI 截图，并真正把它们理解为 interface elements，将“logo dropzone shares data with QR preview panel”连接起来，并识别出 UI 中的“error correction H”是 decode-verification badge 背后的理由。doc agent 从 AGENTS.md 和 FLOW.md 中提取出架构概念：比如“Scan Verification Gate”、“Darken-and-Retry Loop”和“Yellow Pitfall”。第四，它将所有内容合并为一张图：229 个 nodes、296 条 edges，运行 Leiden community detection 并发现 26 个 communities，计算 god nodes 和跨 community bridges，并将每条 edge 标记为 EXTRACTED、INFERRED 或 AMBIGUOUS。
交互式图谱可视化（如下）会落在 graphify-out/graph.html。你可以点击任意 node，查看它的 type、community、source file、degree 和 neighbors。侧边栏列出了全部 26 个 communities 及其 node counts，你可以打开或关闭它们以隔离 clusters。
除了可视化之外，它还在磁盘上留下了这些内容：作为 graphify query 遍历的可查询图谱的 graph.json，包含 god nodes、surprises 和 suggested questions 等审计报告的 GRAPH_REPORT.md，以及 cache/ 和 manifest.json，这样后续的 --update 只会重新处理发生变化的文件。
但真正让我惊讶的是，图谱揭示出了一些仅靠运行 ls 或阅读代码并不明显的东西。这个 repo 的重心原来是 color science，而不是 QR encoding：图谱的密集核心是 contrast、palette 和 color-extraction math，而 QR encoding 只是位于外围的两个 library dependencies。src_main、src_palette 和 src_verify 是结构性 hubs，scan-verification gate 是架构的核心，这恰好是 AGENTS.md 所要求的，但如果不把 spec 和实现并排阅读，你不会知道这一点。tests 直接连接到它们所测试的 modules，而不是漂浮在旁边，这让良好架构变得可见。AGENTS.md 和 FLOW.md 中的概念形成了自己的岛：spec 与代码在含义上匹配，但两者之间没有结构性链接，这就是 19 条 dangling edges 的来源。并且，UI 截图把“never leaves your browser”和“error correction H”这样的产品主张编码成了 graph nodes，并将它们绑定到其所支撑的 UI elements 上：这是 vision model 在做一件我从没想过要手动去做的事。
运行之后，它还注册了 /graphify skill，因此在未来任何 Claude Code session 中，我都可以运行 graphify query "why does the download button start disabled?"，并从图谱中获得答案，而不是从头重新读取整个 repo。这就是 compiled-knowledge 思想的实际运作方式：一次性支付提取成本，之后免费查询。
坦诚的注意事项
Graphify 目前是 version 0.3.1，而且迭代很快，这意味着你应该预期会遇到一些粗糙边缘。语义提取质量完全取决于你底层的 LLM。根据我的经验，Claude Vision 对图表和白板照片处理得很好，但其他模型的质量会有所不同；如果你的项目高度依赖视觉文档，图谱的准确性就只能和解析这些图片的 vision model 一样好。
71.5x 的压缩数字取决于 corpus。如果你的项目只有十个 Python 文件和一个清晰的 README，你可能并不需要知识图谱：你需要的是阅读 README。这个工具最适合中大型 repos，在这些场景中，结构复杂度已经超过了开发者（或 LLM）在 working memory 中可容纳的范围，并且代码、文档和研究论文的混合会产生难以通过线性阅读文件发现的跨领域连接。
针对 HTML visualization 中 SSRF 和 YAML injection 的安全补丁已经在最近的版本中落地。这个项目很年轻，维护活跃，也正在接受社区代码审查；但如果你打算将它指向敏感 codebases，应该自己审查安全面，而不是假设它已经达到生产级加固。
还有最重要的注意事项：知识图谱会告诉你什么连接到什么，但不会告诉你架构师为什么做出某个 trade-off，哪些约束塑造了设计，或者哪些失败尝试导致了当前方案。这些上下文仍然存在于你团队成员的脑中、pull request discussions 和 commit messages 里。Graphify 给你的是结构地图；institutional knowledge 仍然需要你自己掌握。
为什么这件事的意义超越工具本身
我最感兴趣的是更广泛的模式。Karpathy 清楚表达了一种转变：从“tokens spent generating code”转向“tokens spent compiling knowledge”，而 Graphify 是第一个可信地将这种转变针对 codebases 工程化的工具。它在原始 tweet 发布 48 小时后就交付出来，已经拥有 1,500 stars 和一个 .NET port，并且正在多个 agentic coding platforms 中作为 skill 安装；这些都说明需求早就存在，只是在等待有人提供供给。
我们正在从“AI reads your code”走向“AI understands your codebase”，而这两者是根本不同的能力。阅读是线性的：模型逐个处理文件，并把能容纳的内容保存在 context 中。理解是结构性的：模型知道哪些 modules 依赖哪些，god nodes 在哪里，哪些 communities 聚集在一起，以及那些意外的跨领域连接长什么样。
Graphify 本身是否会成为长期标准还不确定；老实说，如果这个领域长期保持如此简单，反而会令人惊讶。看起来很明确的是，将代码编译成持久、可查询的知识表示这种模式会长期存在，因为替代方案——在每个 session 中重新把原始文件喂进 context，并希望模型记得上次学到的内容——已经触及天花板。
这个 repo 是开放的，采用 MIT license，而且真的只需要五分钟就能试用：github.com/safishamsi/graphify。把它指向你最混乱的项目，看看它能发现哪些连接。最坏的情况也不过是，你会了解到一些自己原本不知道的 codebase 信息。