Karpathy 的 LLM Wiki 知识库对齐：代码 + 论文笔记 + 阿语图片，graphify 怎么把它们拉回同一张地图？
一只阿木木约 7 分钟多模态不是“更热闹”，而是让散落在 PDF、截图、白板照片里的“证据”，重新和代码对齐。
如果你做过这些事，就会懂我为什么执着“对齐”这两个字：复现论文、写技术方案、改架构、排线上事故……真正决定你能不能推进的，往往不是“你有没有总结”，而是——你能不能把“概念—证据—实现”串成一条可走的路径。而这些证据，经常根本不在代码里。
这一篇我会用 graphify 官方的 worked/mixed-corpus 基准案例，跑一遍“最小可复现的多模态入图”，并教你怎么把它迁移到你自己的真实项目（论文复现 / 设计决策回溯 / 团队知识库）。
0）这篇文章你能拿到什么“可交付物”（写作 & 实操双用）
跑完你会得到固定的三件套（非常适合截图、做动图、录屏讲解）：
graphify-out/graph.html：交互式图谱（可搜索、可按社区过滤） graphify-out/GRAPH_REPORT.md：结构审计报告（god nodes、意外连接、建议提问、需要复核的推断边） graphify-out/graph.json：持久化图数据（后续 query/path 不需要每次重读原文件）
这三件套的意义是：你不再依赖“临时会话里的一次性理解”，而是把理解编译成一个可保存、可复查、可增量更新的结构层。
1）先讲清楚：graphify 的多模态不是噱头，它在解决“证据失踪”问题
我经常看到两种知识断裂：
- 论文/资料在 Notion、PDF、群聊截图里
- 实现细节在代码里
中间那条“为什么这么做”的链条，通常写在：白板照片、PR 评论截图、设计文档里的一段话、甚至一张别的语言的图里。你问 AI 助手，它会很努力“总结”，但它缺的是“证据地图”。
graphify 的定位就很直白：它支持把 代码、PDF、Markdown、截图、图表、白板照片一起丢进去，用视觉模型抽取概念与关系，把它们连成一个图。
2）我们用的案例是什么：worked/mixed-corpus（官方最小多模态基准）
graphify 在 README 里把这个基准定义为：graphify 源码的一小部分 + Transformer 论文笔记，用来测试“一次 run 混合文件类型”。它在 worked examples 表里给的数字是：4 个文件，token reduction 5.4x。
进入 worked/mixed-corpus/README.md，官方把语料写得很清楚：
raw/analyze.py：图分析模块（god_nodes、surprising_connections 等） raw/build.py：图构建（NetworkX wrapper 等） raw/cluster.py：Leiden 社区发现（cluster、score_all 等） raw/attention_notes.md：带 arXiv 引用的 Transformer 论文笔记（Vaswani et al., 2017，含 arXiv 号 1706.03762）以及一个“可选图片” raw/attention_arabic.png：注意力论文里的阿语图（仓库不存 PNG，你需要自己从论文里截图保存进去）
这套语料非常适合做第二篇：它不是“堆大规模”，而是专门用来验证——多模态能不能在同一张图里共存、并且被可审计地标注出来。
3）实操：10 分钟跑通“代码 + 论文笔记 + 图片”的一次建图
3.1 安装与运行
graphify 的 PyPI 包名目前叫 graphifyy（多一个 y），但命令仍叫 graphify；README 写明这是临时命名。
Bash
pip install graphifyy
graphify install
然后在 worked/mixed-corpus/ 目录里运行：
text
/graphify ./raw
如果你要复现“图片也入图”，按官方说明把任意一张《Attention Is All You Need》的图保存为：
text
raw/attention_arabic.png
再跑一次 /graphify ./raw 即可。
3.2 你应该看到什么（官方给的预期）
官方在 mixed-corpus README 里给了“你跑完大概率会出现的现象”：
仅 AST（3 个 Python）就会有 ~20 nodes、~19 edges 社区划分大致对应三个模块角色：Graph Analysis / Clustering & Scoring / Graph Building attention_notes.md会被识别为 paper（arXiv heuristic 对1706.03762生效）加图片会多一个“图像节点”（来自 vision 抽取） token reduction：5.4x
这里你可以直接写一句“阿木木式提醒”：这还不是 graphify 最爽的规模，但它是最干净的‘对齐演示台’——你能清楚看到每一步到底贡献了什么。
4）先别急着看 graph.html：阿木木读图谱的第一原则——先读 GRAPH_REPORT.md
你打开 GRAPH_REPORT.md，会看到一份很“审计味”的报告，它会明确告诉你：
这次语料规模是否“值得建图”（Corpus Check） 图的规模、社区数量、推断比例（Summary） 哪些节点是“核心枢纽”（God Nodes） 哪些连接是你可能没想到的（Surprising Connections） 哪些推断边需要你复核（Suggested Questions 里会点名）
以仓库自带的这份报告为例，它写的是：22 nodes、38 edges、5 个社区；推断/抽取各 50%；并且直接列出了最核心的函数节点（比如 _cross_file_surprises()、_is_file_node() 等）。
我特别喜欢它的“Suggested Questions”写法：它不是泛泛地让你“深入阅读”，而是明确指出哪些节点是跨社区桥（高 betweenness centrality），以及哪些节点的 INFERRED 边多、值得复核。
这就很像我一直强调的那句：**AI 不该只给结论，它要给你“下一步怎么验证”的路线图。
5）“论文被识别为 paper”不是小功能：它决定了你能不能把资料当“证据”管理
在 review.md（官方评测记录）里，对 attention_notes.md 的判定写得非常细：它之所以被归类为 paper，是因为命中了诸如 arXiv 标记、DOI、abstract、引用序号、以及 1706.03762 这类 arXiv 号的模式。
这件事的价值在于：当你的文件夹里混进“论文笔记 / 设计文档 / 普通说明文档 / 代码注释”，系统能先把它们分门别类，后续的抽取策略、连接权重（比如 code-paper 边更重要）才有可能做得更像“知识工程”，而不是“混在一起的文本”
6）多模态的高光时刻：阿语图片 OCR + 概念节点抽取（不需要任何预处理）
review.md 里有一段我觉得特别适合拿来做你文章的“名场面”：它展示了 graphify 用 Claude vision 直接读 阿拉伯语图片里的内容，并抽出关键概念与超参（例如 multi-head attention、h=8、d_model=512、d_k=d_v=64、6 encoder + 6 decoder、positional encoding、layer norm 等）。
官方评测的关键结论也写得很直白：不需要额外的 Arabic reshape / bidi 预处理库，视觉模型可以直接读并结构化这些信息。
对我来说，这不是“炫技”，而是一个现实问题的解法：很多团队的“关键证据”就存在截图里，而且经常是跨语言的——你如果只能处理英文 markdown，那你就会永久丢一块知识版图。
7）再往前一步：把“提问”也变成资产（这点很少有人讲，但很重要）
review.md 里还有一个非常“复利”的实验：它做了 3 个 query 测试，然后把 query 的结果保存到 graphify-out/memory/，接着再次扫描时，系统能检测到这些 memory 文件——也就是说，你问过的问题与答案，会变成下一轮建图的输入，形成反馈闭环。
这句话你可以直接写成你的个人观点（我建议你大声写出来）：
**知识库不应该只由“你收集了什么”决定，还应该由“你真正问过什么”来生长。
它会让你的第二篇，从“多模态演示”升维成“知识系统会自我增量”的方法论铺垫。
8）把这个基准迁移到你的真实项目：阿木木的 3 个“对齐型”实战模板
下面这三种文件夹组织方式，你可以直接给读者当“作业”。重点不是目录长得多漂亮，而是：确保概念证据和实现共处一处，graphify 才能把它们编译到同一张图里。
模板 A：论文复现 / 模型实现对齐
text
raw/
├── paper.pdf
├── figures/
│ ├── fig1.png
│ └── ablation_table.png
├── notes.md # 你自己的复现笔记，带 arXiv/doi/引用
└── impl/
├── model.py
├── attention.py
└── training.py
你文章里可以给 3 个“强标题式提问”示例（读者很爱抄）：
“paper 里的公式 X，对应代码里哪个函数/类？” “fig1 里的模块图，和 impl 的文件结构有哪些对应关系/缺失？” “notes 里提到的超参（h、d_model…），在训练脚本里最终是从哪里注入的？”
这些问题的价值是“对齐”，不是“总结”。
模板 B：架构决策回溯（白板/截图才是关键证据）
text
raw/
├── design/
│ ├── ADR_001.md
│ └── meeting_notes.md
├── screenshots/
│ ├── whiteboard_2026-04-xx.png
│ └── pr_comment.png
└── code/
├── service_a/
└── service_b/
你要强调：graphify 明确支持把截图、白板照片入图，并用视觉抽取概念与关系。
模板 C：跨语言资料（别再手动翻译了，让证据先入图）
text
raw/
├── cn_notes.md
├── en_notes.md
├── jp_screenshots/
└── code/
这一招的核心不是“自动翻译”，而是先把信息变成结构节点，之后你再做解释与写作，会轻很多。
9）必须写清楚的底线：隐私与合规（这不是客套，是你的可信度）
graphify 在 README 里写得很明确：文档/论文/图片的语义抽取，会把内容发到你所用平台背后的模型 API（比如 Claude Code 对应 Anthropic、Codex 对应 OpenAI 等）；但代码文件走本地 tree-sitter AST 处理，代码内容不会上传；同时项目声明无遥测、无使用跟踪，网络请求主要发生在抽取阶段且用你的 API key。
建议你在文末固定给一个“阿木木式操作规范”（读者会觉得你专业、也更敢跟着用）：
默认先写 .graphifyignore排除敏感目录（语法同.gitignore）敏感截图先打码再入库 先在一个“脱敏样本文件夹”跑通流程，再上真项目
结尾：这一篇真正想说的，不是多模态，而是“可走的证据路径”
我写第二篇，不是为了证明 graphify “很强”，而是为了给你一个更大的视角：
当资料变多时，问题不再是“信息不够”，而是“证据散落”。
而散落的证据，只靠“总结”是捡不回来的；你需要一张地图，能把论文、笔记、截图、代码放在同一套结构里，让你能追溯、能复核、能持续更新。
下一篇我会把这个思路推到“复利”那一层：大语料 + 增量更新 + hooks + always-on 提示，也就是 graphify 在 README 里强调的 71.5x token 复利场景，看看它到底是营销数字，还是工作流质变。
AII
松花酿酒，春水煎茶。
眉上风止，见字如晤。
一只阿木木