Karpathy 的 LLM Wiki 知识库复利工作流：71.5x 不是噱头，真正狠的是“默认行为被改写”

省 token 只是副作用；真正的价值是让“正确的上下文”跨会话复利。

Karpathy 最近把这类思路讲得很直白：把 papers、截图、笔记丢进 /raw，先“编译”出一个结构化中间层，再去 query，而不是每次从 raw 里硬塞上下文。graphify 的 README 甚至直接把自己定位成“对这个问题的回答”，并给了一个可复现实测数字：71.5x fewer tokens per query。 

这篇我就用 graphify 官方的 worked/karpathy-repos 大基准，把“为什么能到 71.5x、为什么它会复利、以及怎么把它变成日常工作流”讲透。

0）这篇你会得到什么（写作可交付物 + 工作流可落地件）

跑完这一套大语料，你会稳定得到三种“资产”——它们不是一次性答案，而是能反复使用的项目基建： 

• graphify-out/GRAPH_REPORT.md
  ：一页纸“结构体检报告”（god nodes / communities / surprising connections / suggested questions）
• graphify-out/graph.json
  ：持久化图谱（后续 /graphify query|path|explain 读它，不用重读 raw）
• graphify-out/graph.html
  ：可视化图（内容创作者的截图宝藏）
• graphify-out/cache/
  ：SHA256 缓存（增量更新的底层）

以及更关键的：你可以把它变成always-on（默认提醒助手先看报告再 grep），再配上 --watch / Git hooks，让它进入“自动更新 → 自动复利”的节奏。 

1）71.5x 到底是什么意思？（阿木木式反营销：先把数字算清楚）

我不喜欢拿一个倍数当口号，所以先看官方评测 review.md 里怎么测的——它把“naive 全量塞上下文”与“图上 BFS 子图查询成本”做了对照：

• 全语料 52 files 的 naive full-context：约 123,488 tokens
• 平均 query（BFS subgraph）成本：约 1,726 tokens
• 所以 reduction ratio：123,488 / 1,726 ≈ 71.5x

它还顺手解释了“为什么这个倍数会随着语料增长而变大”：naive stuffing 线性随 corpus 变大，而 BFS 子图（你问一次只需要相关局部）大致保持在 ~1,700 tokens 级别。 

我的翻译：
你不是把模型变聪明了，你是把“上下文输送方式”换成了更像工程系统的“按需取局部”。

更有意思的是，它给了按问题拆分的倍数：最夸张的一个问题（“what connects micrograd to nanoGPT”）能到 126.7x，而“attention mechanism”这种跨论文+跨 repo 的大问题因为相关子图更大，依然有 43.5x。这非常符合直觉：问题越“跨域”，需要的子图越大，但仍远小于全量 raw。 

2）官方 71.5x 基准语料是什么？（你照抄就能复现）

worked/karpathy-repos/README.md 写得非常清楚：这份语料就是产生 71.5x benchmark 的 corpus。

52 个文件由三部分组成：

A. 代码：3 个 Karpathy repo（clone）

• nanoGPT
• minGPT
• micrograd

B. 论文：5 个 PDF（下载）

• Attention Is All You Need（1706.03762）
• FlashAttention（2205.14135）
• FlashAttention-2（2307.08691）
• Neural Attention Residuals（2505.03840）
• NeuralWalker（2502.02593） 

C. 图片：4 个（保存/截图）

• nanoGPT 的训练 loss 曲线图
• micrograd 的计算图（svg）
• micrograd 的 moon_mlp 决策边界图
• Attention 论文任意截图/示意图 

然后把它们统一放进一个 raw/ 文件夹里，形成一个“混合证据场”。 

3）实操：跑一次大语料建图（以及我建议你怎么录屏）

3.1 安装（注意包名）

截至 2026-04-09，PyPI 最新版本页面显示 graphifyy 0.3.21，包名暂时叫 graphifyy，但命令仍是 graphify。 

Bash

pip install graphifyy
graphify install

3.2 运行（在助手里打一条命令）

在 Claude Code / Codex / OpenCode / OpenClaw / Trae 等支持的环境里执行：

text

/graphify ./raw

跑完你会看到 token benchmark（每次 run 都会打印），并在 graphify-out/ 下得到报告、图、缓存。

4）读结果：这份图到底“值”在哪里？（用官方报告当范本）

大多数人跑完会第一时间点开 graph.html，但我强烈建议你先读 GRAPH_REPORT.md——因为它是“把图变成行动”的那张一页纸。
在这份 Karpathy 大基准的 GRAPH_REPORT.md 里，最值得你截图的有四块：

4.1 Summary：先确认“这次建图值得”

报告写得很直接：语料 ~92,616 words，并给出 verdict：“corpus is large enough that graph structure adds value”。它还给了节点/边/社区数量（285 nodes / 340 edges / 53 communities）以及抽取比例（EXTRACTED / INFERRED）。

这句话就是你内容里“复利成立”的门槛：小语料更多是结构清晰；大语料才会出现“读 raw 变贵”的拐点。

4.2 God Nodes：你的“核心抽象”

这份报告的 top god nodes 包括 Value、Training Script、GPT、Layer 等，并标注边数。它等价于回答：“我先读哪几个点，能最快掌握全局”。

4.3 Surprising Connections：跨 repo 的“暗线”

报告直接列了跨 repo 的推断连接，例如 from_pretrained() 与另一个 repo 的 get_default_config() 之间的关系、以及 minGPT 与 nanoGPT 的 CausalSelfAttention 概念关联等。

这部分是你作为博主最容易“讲出高级感”的地方：
它不是“总结”，它是在帮你发现“同构与复用”——两个 repo 可能在写同一个 GPT block 模式，只是散落在不同目录、不同命名与不同训练脚手架里。

4.4 Suggested Questions：图谱反过来教你怎么问

报告会用 betweenness centrality 标出“跨社区桥接点”，并给出可操作的问题提示，比如：为什么 Training Script 是连接 Config/DataPrep 与 Training Pipeline 的桥；哪些节点的 INFERRED 边多、需要人工复核等。
我特别喜欢这一段，因为它把“图的可解释性”落到了动作层：
你不是被动看图，你是拿图做审计、做复核、做下一步阅读计划。

5）为什么它能“复利”？关键不在 71.5x，而在三件事

5.1 “编译一次 → 查询多次”

graphify 明确写了：第一次 run 会有抽取成本（尤其是 docs/papers/images 的语义抽取），但之后每次 query 读的是紧凑的 graph.json，这才是 token savings “compound”的来源。 

5.2 增量更新：SHA256 cache + --watch

它提供 SHA256 cache，让重复运行只处理变更文件；并支持 --watch 做自动同步：代码文件的变动可以走 AST 即时重建（无 LLM），而 doc/image 变动会提示你用 --update 做语义重跑。 

这就是“复利”的工程含义：你不是每次都重建世界，而是在维护一个随项目生长的结构层。

5.3 把助手的默认行为改掉：always-on（CLAUDE.md / AGENTS.md + hooks）

graphify 提供“让助手总是先用图”的安装命令，例如 graphify claude install、graphify codex install 等：

• Claude Code：写入 CLAUDE.md 并装 PreToolUse hook（在 Glob/Grep 前提醒先读 GRAPH_REPORT.md）
• Codex：写 AGENTS.md，并在 .codex/hooks.json 装 hook
• OpenCode：写 AGENTS.md 并装 tool.execute.before 插件
• 其他平台若不支持 hooks，则以 AGENTS.md 作为 always-on 机制

阿木木式翻译：
你不用每天靠意志力提醒自己“先看结构再 grep”，系统会替你养成习惯。

6）把它落到日常：我的“阿木木三板斧工作流”（你可以直接抄到文末）

目标：让 graphify 不再是“我偶尔跑一次的酷工具”，而是“项目日常基建”。

第一步：建图 + 固化入口

• /graphify ./raw
   生成 GRAPH_REPORT.md + graph.json
• 然后立刻做 always-on：graphify claude install（或你所用平台对应命令）

第二步：让图跟着项目走（两种二选一）

• 背景常驻：/graphify ./raw --watch
• 或者用 Git hooks：graphify hook install（commit/切分支后自动重建）

第三步：遇到“跨域问题”才用深挖命令

always-on 给你“地图”；真正要走路径时，再用：

• /graphify query
  ：问概念、问模块
• /graphify path
  ：问 X 到 Y 的连接链
• /graphify explain
  ：要证据、要边的置信度与来源

7）别把它神化：官方评测里写了哪些“真实瑕疵”（你写出来反而更像名 IP）

我很建议你把 review.md 里“missed or got wrong”那段当作你文章的“可信度锚点”，因为它不是广告，是工程现实：

• stdlib import 会带来大量 validation warnings
  ：AST 抽取会先发出一些 import 边，后续会被 prune，但会让中间统计膨胀。
• config-only 文件容易变 isolate
  ：没有函数/结构的脚本会成为单节点社区，导致社区数看起来“很多且碎”。
• INFERRED 边需要复核
  ：报告会点名哪些核心节点有多条推断边，建议你验证。 

阿木木式结论：
图谱是地图，不是判决书；它擅长给你路线与线索，最终的“对/错”仍要你回到源码与论文。

8）隐私与成本：该说人话就说人话（这段写清楚，你的读者会更敢用）

graphify 在项目描述里写得很明确：

• docs/papers/images 的语义抽取会发送到你所用平台背后的模型 API（例如 Claude Code/ Codex 对应的提供方）
• 代码文件通过 tree-sitter AST 在本地处理，代码内容不离开机器
• 项目声明无 telemetry；网络请求主要发生在抽取阶段，使用你的 API key 

所以我自己的安全姿势很简单（你可以当“阿木木固定话术”放每篇文末）：

• 先写 .graphifyignore：敏感目录一律排除；
• 敏感截图先打码再入库；
• 先在脱敏样本库跑通，再上真仓库。

收束：这篇真正想说的，是“把理解变成资产”

如果你只把 graphify 当成“省 token”，你会错过它最关键的东西：它把理解从一次性会话，变成了一个可维护的结构层。

对我来说，AI 时代的分水岭不是“谁更会问”，而是：

谁能让正确的上下文留下来，并且默认被使用。

这才是复利。

松花酿酒，春水煎茶。

眉上风止，见字如晤。

一只阿木木