Ingest 现场直播：一篇 8000 字长文，如何在 27 分钟内变成 wiki 里的 14 个知识节点
一只阿木木约 20 分钟Ingest 现场直播
一篇 8000 字长文，如何在 27 分钟内变成 wiki 里的 14 个知识节点
作者：一只阿木木 | 数字大脑架构师 🌊
收藏越多，越空虚。整理越勤，越焦虑。
恭喜你，你正在经历这个时代最普遍的一种知识病。
我曾经也深陷其中。
直到我看见 Karpathy 的那份文件，我才第一次意识到：问题从来不是"你整理得不够好"，而是——整理这件事，本身就是一个错误的方向。
你脑子里可能还有一个问号：
“这一切……真的能跑起来吗？”
今天，不讲理论。 我选了一篇真实的长文， 全程带你看它从「一坨文字」变成「14 个相互链接的知识节点」的完整过程。
全程截图级还原。 我的工作量：把文章扔进 /raw，然后去泡了一杯咖啡。
开始之前：为什么需要一篇「现场直播」
我收到过最多的私信，不是问"这套系统好不好"。
是问"我跑不起来怎么办"。
有人说：“CLAUDE.md 写好了，文章也扔进去了，但 AI 产出的东西看起来不对。”
有人说：“我不知道正常的 Ingest 过程应该长什么样，没有参照物。”
还有人说：“我不确定系统是不是在正确地工作，因为我没有见过它正确工作的样子。”
这些问题的本质是同一个：
你缺少一个「标准参照」——一次完整的、正确的 Ingest 过程，长什么样。
今天这篇文章，就是那个标准参照。
我会用分钟级的粒度，带你看到这 27 分钟里发生的每一件事。包括 AI 做对的部分，也包括它做得不够好、我需要微调的部分。
真实，比完美重要。
实验设定
选用素材：
我选了一篇真实的、信息量极高的长文——一篇社区中对 Karpathy LLM Wiki 模式的深度分析文章，原文约 8000 字，涵盖了架构解析、RAG 对比、实操路径、局限性分析等多个维度。
选择这篇文章的原因：
信息密度高（适合展示 Fine 粒度提取的效果） 我的 /wiki中已经有相关页面（可以展示更新和矛盾检测）内容跨越多个概念领域（可以展示交叉引用的建立过程）
当前系统状态：
text
/raw/articles/ → 34 个文件
/wiki/concepts/ → 41 个页面
/wiki/entities/ → 22 个页面
/wiki/synthesis/ → 11 个页面
/wiki/maps/ → 3 个页面
总计：77 个 wiki 节点
最近一次 Lint：5 天前，0 个未解决问题
CLAUDE.md 版本：v2.3
这是一个已经运行了大约两个月的系统——不是全新的，也不是超大规模的。正好是大多数读者在坚持了 8-10 周之后会到达的状态。
使用工具：
Obsidian（知识库，打开 Graph View 实时观察） Claude Code（执行 Ingest 的 AI agent） CLAUDE.md v2.3（编译规范）
00:00 — 起点：一篇原始文章进入 /raw
首先，我把这篇长文保存为 Markdown 文件，命名为 llm-wiki-deep-analysis.md，放进 /raw/articles/ 目录。
文件开头是标准的 YAML frontmatter：
YAML
---
title: "LLM Wiki 深度架构分析"
source: "https://[文章来源URL]"
date: 2026-05-18
type: article
tags: [llm-wiki, karpathy, knowledge-management, rag]
status: raw
---
这就是我在这一步做的全部工作——保存文件，加上 frontmatter。
不需要阅读全文。不需要提前标记重点。不需要预判它会产生哪些 wiki 页面。
这些全是 AI 的活。
我现在要做的唯一一件事： 打开 Claude Code，输入指令。
01:00 — 触发 Ingest：给 AI 下达指令
我在 Claude Code 中输入：
text
请先完整阅读 /schema/CLAUDE.md，
然后对 /raw/articles/llm-wiki-deep-analysis.md 执行 Ingest 操作。
这是一篇高密度的技术分析文章，请使用 Fine 粒度。
完成后给我一份完整的 Ingest 报告。
注意几个细节：
先读 Schema — 这是最重要的习惯。每次 Ingest 前让 AI 重新加载 CLAUDE.md，确保它按你的规范工作，而不是按它自己的默认方式。
指定粒度 — 这篇是高密度长文，我选了 Fine 粒度。如果是一篇日常短文，我会用 Standard。这个判断是人做的，是你作为「策展人」最重要的决策之一。
要求报告 — 每次 Ingest 结束后的报告，是你了解系统做了什么的唯一窗口。不要省这一步。
输入完成。
现在，去泡咖啡。
02:00 — AI 开始阅读（Step 1：完整阅读）
Claude Code 开始工作。
如果你能看到它的思维过程，大概是这样的：
text
[内部状态]
正在阅读 /schema/CLAUDE.md ... 完成。
已理解角色定义、Ingest 工作流、命名规范、页面模板。正在阅读 /raw/articles/llm-wiki-deep-analysis.md ...
文章长度：约 8000 字
信息密度：高
预计实体数量（Fine 粒度）：60-90
阅读中 ...
这个阶段你不会看到任何输出。AI 在沉默地阅读整篇文章，形成整体理解。
这和很多人的直觉相反——很多人希望 AI 一边读一边输出，这样"感觉更快"。但根据 CLAUDE.md 的规范，我明确要求了「先读完，再提取」。
为什么？
如果 AI 边读边提取，它可能在文章前半段为某个概念创建了页面，但在文章后半段发现作者其实否定了这个概念。到那时候再改，就会产生混乱。
先理解全貌，再动手操作。 这是 Ingest 质量的基础。
04:00 — 读取索引（Step 2：了解已有知识库）
AI 完成全文阅读后，打开 /wiki/index.md。
text
[内部状态]
正在读取 /wiki/index.md ...
当前知识库包含 77 个节点。
正在扫描与本文相关的已有页面 ...高度相关（需要检查更新）：
- /wiki/concepts/llm-wiki.md
- /wiki/concepts/rag.md
- /wiki/concepts/compilation-pattern.md
- /wiki/concepts/three-layer-architecture.md
- /wiki/entities/karpathy-andrej.md
- /wiki/entities/obsidian.md
中度相关（可能需要新增链接）：
- /wiki/concepts/knowledge-compounding.md
- /wiki/concepts/schema-design.md
- /wiki/synthesis/llm-wiki-vs-rag.md
这一步至关重要。
Index 是地图。当你摄入新素材时，AI 首先读取 index.md 找到相关页面，然后再深入其中。不需要向量数据库或嵌入——索引在数百个页面的规模下效果出奇地好。
如果没有这一步，AI 就不知道 wiki 里已经有什么了——它可能会重复创建已有的页面，或者错过应该建立的交叉引用。
06:00 — 实体识别（Step 3：这篇文章里有什么？）
现在，AI 开始对文章进行实体提取。
这是整个 Ingest 过程中最核心的一步——也是上一篇文章花了大量篇幅讲的那个「从摘要到提取」的质变时刻。
text
[实体识别结果]人物实体（3个）：
① karpathy-andrej → 已存在，标记「需更新」
② tiago-forte → 已存在，标记「需更新」
③ [新人物] → 不存在，标记「新建」
工具/产品实体（4个）：
④ obsidian → 已存在，标记「需更新」
⑤ claude-code → 已存在，标记「需更新」
⑥ [新工具A] → 不存在，标记「新建」
⑦ [新工具B] → 不存在，标记「新建」
核心概念（8个）：
⑧ llm-wiki → 已存在，标记「需更新」
⑨ rag → 已存在，标记「需更新」
⑩ compilation-pattern → 已存在，标记「需更新」
⑪ incremental-ingest → 不存在，标记「新建」
⑫ knowledge-entropy → 不存在，标记「新建」
⑬ wiki-drift → 不存在，标记「新建」
⑭ confidence-scoring → 不存在，标记「需检查」
⑮ lint-audit → 已存在，标记「需更新」
方法论实体（2个）：
⑯ para-method → 已存在，标记「需更新」
⑰ schema-evolution → 不存在，标记「新建」
核心声明（5条）：
S1: "维护成本是个人 wiki 系统的最大杀手"
S2: "LLM Wiki 在 200 页以下效果最佳"
S3: "幻觉可能在 LLM Wiki 中被固化为事实"
S4: "50 页写得紧凑胜过 500 页写得肤浅"
S5: "知识编译的成本在第一次之后就能回本"
总计：17 个实体/概念候选 + 5 条核心声明
其中：需更新 9 个，需新建 7 个，需检查 1 个
让我解释几个细节：
为什么 confidence-scoring 被标记为「需检查」而不是直接「新建」？
因为 AI 在读取 index.md 时，发现了一个页面叫 /wiki/concepts/confidence-levels.md——这和「confidence-scoring」可能是同一个概念的不同表述。AI 需要先打开那个页面看看，再决定是更新现有页面还是新建一个。
这就是 Index 的价值。 没有它，AI 会直接新建一个重复页面，你的系统里就会出现两个讲同一件事的页面。Lint 审计最终能发现这个问题，但如果一开始就对照索引检查，就能从源头避免。
为什么声明（Statements）被单独提取？
声明不是实体，它们是「可以被引用、可以被验证、可以被质疑的观点」。把它们显式提取出来，有两个用处：
它们会被写进相关概念页的「核心声明」节，作为可追溯的观点锚点。 未来 Lint 审计时，可以专门对照新素材验证这些声明是否仍然成立。
09:00 — 开始创建新页面（Step 4：构建新知识节点）
从这一刻开始，你的 /wiki 目录会发生真实的变化。
AI 开始按照 CLAUDE.md 中的页面模板，逐个创建新页面。
第一个新页面：/wiki/concepts/incremental-ingest.md
我截取关键部分展示：
Markdown
---
title: "增量式 Ingest"
type: concept
created: 2026-05-23
updated: 2026-05-23
sources: [raw/articles/llm-wiki-deep-analysis.md]
confidence: medium
related: [compilation-pattern, llm-wiki, knowledge-ingest]
---## 定义
增量式 Ingest 是 LLM Wiki 系统中的一种素材摄入模式：
当新素材进入系统时，LLM 不从零重建整个知识库，
而是读取新来源、更新现有页面、标记矛盾、扩展整体知识库。
知识只编译一次然后保持更新，不在每次查询时重新推导。
## 核心机制
与一次性批量处理不同，增量式 Ingest 的关键在于：
1. 每次只处理新增素材
2. 更新已有页面而非重建
3. 维持交叉引用的完整性
4. 在更新过程中检测矛盾
## 与相关概念的关系
- [[compilation-pattern]] — 增量式 Ingest 是编译模式的执行层面实现
- [[llm-wiki]] — 是 LLM Wiki 三大核心操作之一
- [[knowledge-ingest]] — 增量式是 Ingest 操作的默认模式
## 应用场景
当知识库已有一定规模（>30 页）后，
增量式 Ingest 成为唯一可行的 Ingest 方式。
从零重建成本过高且会丢失积累的交叉引用。
## 来源
- "LLM Wiki 深度架构分析"（raw/articles/llm-wiki-deep-analysis.md, 2026-05-18）
## 矛盾与争议
[暂无]
注意几个值得关注的点：
置信度是 medium — 因为这是单一来源，CLAUDE.md 规定单一来源最高只能标注 medium。要升级到 high，需要至少三个独立来源一致支持。
related字段包含三个链接 — AI 不是随便选的。它读了 index.md，确认了这三个页面确实存在，然后建立了关联。定义精确且简洁 — 不是一段冗长的摘要，是一个可以被引用的精准定义。
第二个新页面：/wiki/concepts/knowledge-entropy.md
Markdown
---
title: "知识熵"
type: concept
created: 2026-05-23
updated: 2026-05-23
sources: [raw/articles/llm-wiki-deep-analysis.md]
confidence: medium
related: [compilation-pattern, rag, llm-wiki]
---## 定义
知识熵描述的是信息系统中知识的无序程度。
原始素材（文章、转录稿、笔记）是高熵输入——
信息散布在大量文本中，缺乏结构和相互连接。
LLM Wiki 的核心功能之一是降低知识熵：
将高熵的原始素材编译为低熵的结构化 wiki 页面。
## 核心机制
- 高熵状态：信息碎片化，找到关联需要大量人工扫描
- 低熵状态：概念有定义，实体有页面，关系有链接，矛盾有标记
- 熵降低的路径：实体提取 → 页面创建 → 交叉引用 → 矛盾检测
## 与相关概念的关系
- [[compilation-pattern]] — 编译是降低知识熵的核心操作
- [[rag]] — RAG 不降低熵，只在高熵环境中临时检索
- [[llm-wiki]] — LLM Wiki 是一个系统性的知识降熵架构
## 来源
- "LLM Wiki 深度架构分析"（raw/articles/llm-wiki-deep-analysis.md, 2026-05-18）
## 矛盾与争议
[暂无]
这个页面让我特别满意的一点是 AI 和现有概念建立的三角关系：
text
知识熵 ←──对比──→ RAG（不降熵）
│
└───── 编译模式 ─────┘（降熵机制）
这种关系不是我预设的，是 AI 在理解了文章内容和现有 wiki 之后，自主发现并建立的。
这就是编译型知识管理的魅力——AI 能发现你没有预见到的概念连接。
13:00 — 更新现有页面（Step 4 续：不只是新建，还有更新）
新建页面只是故事的一半。另一半同样重要：更新已有页面。
在这次 Ingest 中，有 7 个现有页面被更新。我展示最典型的两个。
更新 1：/wiki/concepts/llm-wiki.md（核心概念页，已存在 6 周）
这是整个系统里最重要的概念页之一，在过去 6 周已经被 4 次不同的 Ingest 更新过。
这次更新的内容：
Markdown
[变更记录]1. 「核心机制」节新增一段关于"增量式编译"的说明
新增链接：[[incremental-ingest]]
2. 「适用边界」节（新增小节）
来源声明 S2："LLM Wiki 在 200 页以下效果最佳"
来源声明 S4："50 页写得紧凑胜过 500 页写得肤浅"
置信度标注：medium（单一来源）
3. 「来源」节追加
- "LLM Wiki 深度架构分析"（raw/articles/llm-wiki-deep-analysis.md, 2026-05-18）
此页面现有来源总计：5 篇
4. 「related」字段新增
新增：incremental-ingest, knowledge-entropy, wiki-drift
5. updated 日期更新为 2026-05-23
注意第 3 点——这个页面现在有 5 个不同来源。
根据 CLAUDE.md 的规定，当一个概念页拥有 3 个以上高质量来源且一致支持时，它的置信度可以升级为 high。
AI 在这次更新中做了一件事：检查了 5 个来源之间的一致性。发现它们在核心定义和机制描述上一致，但在「适用边界」上有不同的说法。因此：
核心定义部分：置信度维持 high 适用边界部分：置信度标注 medium（因为有些来源说"200 页以下最佳"，有些来源没有提到这个限制）
这就是多次 Ingest 积累后，置信度系统开始真正工作的样子。
不是简单的"有来源 = 高置信"，而是"多来源一致 = 高置信，来源之间有分歧的部分 = 降级"。
更新 2：/wiki/concepts/rag.md（对比概念页）
这次更新发生了一件更有意思的事——矛盾检测被触发了。
Markdown
[变更记录]1. 「与相关概念的关系」节新增
- [[knowledge-entropy]] — RAG 不降低知识熵，只在高熵环境中检索
2. ⚡ 矛盾标记（新增）
来源声明 S2 提出："LLM Wiki 在 200 页以下效果最佳，
超过此规模需要向量搜索辅助"
现有 wiki 页面观点：
/wiki/synthesis/llm-wiki-vs-rag.md 中记录：
"LLM Wiki 不需要向量搜索或嵌入，index.md 足够"
矛盾性质：条件性矛盾
——一个说不需要向量搜索（不加限定），
另一个说超过 200 页可能需要。
两者不是绝对矛盾，但存在适用边界上的分歧。
处理方式：
- 在 rag.md 的「矛盾与争议」节添加标记
- 在 llm-wiki-vs-rag.md 的「适用边界」节添加标记
- 两处置信度均从 high 调整为 contested
- 等待用户决策或未来新来源解决
这是整个 Ingest 过程中最有价值的时刻。
因为 LLM 将来源压缩为 wiki 页面，存在幻觉被固化为"事实"的风险。在纯 RAG 系统中，一个错误答案只是一个错误答案。但在 LLM Wiki 中，一个小误解可能安静地传播到关联页面。这正是 Karpathy 强调 Lint 步骤——定期审计——的原因。
矛盾标记机制，是 LLM Wiki 系统防止"知识幻觉固化"的核心防线。
它不会替你做判断，但它确保了：当你的知识系统中存在不一致的时候，你能看到它。
被看到的矛盾，是健康的。 被隐藏的矛盾，才是危险的。
17:00 — 交叉引用的自动建立（Step 5：连接！连接！连接！）
新页面创建了，旧页面更新了。现在到了最魔法的部分——交叉引用的自动建立。
AI 不只是在新页面里放了指向旧页面的链接，它还回头去更新了旧页面，让旧页面链接到新页面。
这听起来像个小事，但它是知识网络和知识孤岛之间的决定性区别。
以这次 Ingest 为例，AI 建立的交叉引用：
text
新建的链接（本次 Ingest 产生）：新页面 → 现有页面（出链）：
incremental-ingest → compilation-pattern ✅
incremental-ingest → llm-wiki ✅
incremental-ingest → knowledge-ingest ✅
knowledge-entropy → compilation-pattern ✅
knowledge-entropy → rag ✅
knowledge-entropy → llm-wiki ✅
wiki-drift → llm-wiki ✅
wiki-drift → lint-audit ✅
wiki-drift → confidence-scoring ✅
schema-evolution → schema-design ✅
schema-evolution → llm-wiki ✅
现有页面 → 新页面（反向链接，AI 主动添加）：
llm-wiki → incremental-ingest ✅
llm-wiki → knowledge-entropy ✅
llm-wiki → wiki-drift ✅
compilation-pattern → incremental-ingest ✅
compilation-pattern → knowledge-entropy ✅
rag → knowledge-entropy ✅
lint-audit → wiki-drift ✅
schema-design → schema-evolution ✅
总计：19 条新链接（11 条出链 + 8 条反向链接）
19 条新链接。 一篇文章，建立了 19 条知识连接。
如果你用传统的摘要方式处理同一篇文章，你会得到：1 个笔记文件，0 条链接。
这就是为什么你的 Obsidian Graph View 以前看起来是一盘散沙——不是你笔记不够多，是每篇笔记之间没有建立连接。
LLM 的真正超能力，不是总结——是连接。它不只是创建一个页面——它会主动建立多维交叉引用。人类永远不会主动维护这些交叉引用，但 AI 每次都会做。
20:00 — 矛盾检测完成（Step 6：碰撞与质疑）
在上面更新 rag.md 的时候，矛盾检测已经触发了一次。
但 AI 还在继续扫描其他声明。最终的矛盾报告如下：
text
[矛盾检测报告]矛盾 1：适用边界分歧（已处理）
新来源声明："LLM Wiki 在 200 页以下效果最佳"
现有 wiki 立场："不需要向量搜索或嵌入"
矛盾性质：条件性矛盾
处理：双方页面添加矛盾标记 → ✅ 已完成
矛盾 2：无
新来源声明 S1："维护成本是个人 wiki 的最大杀手"
现有 wiki：/wiki/concepts/llm-wiki.md 中记录
"LLM 改变了维护的成本结构"
判断：不是矛盾，是「问题→解决方案」的关系
处理：无需矛盾标记
矛盾 3：无
新来源声明 S5："知识编译的成本在第一次之后就能回本"
现有 wiki：/wiki/concepts/compilation-pattern.md 中记录
"编译步骤昂贵，但在每次后续使用中回本"
判断：一致，互相强化
处理：在 compilation-pattern.md 追加来源，
该声明置信度从 medium 升至 high（现有 3 个一致来源）
总结：扫描 5 条声明，发现 1 个矛盾，0 个颠覆，
1 条声明因新来源升级置信度。
让我解释最后那一条——声明 S5 的置信度升级。
这篇新文章说"知识编译成本在第一次之后就能回本"，而 /wiki/concepts/compilation-pattern.md 里已经有了来自另外两篇文章的类似表述。
三个独立来源，表达了同一个观点。
根据 CLAUDE.md 的规范：3 个以上高质量来源一致支持 → 置信度升级为 high。
于是 AI 把 compilation-pattern.md 中关于"编译成本回本"这条声明的置信度从 medium 升级为 high。
这就是多次 Ingest 积累后的知识复利。
不是你的笔记在增多，是你的判断力在增强——因为系统在帮你追踪哪些观点被反复验证了，哪些观点还只是孤证。
23:00 — 系统文件更新（Step 7：记录一切）
AI 更新了两个系统文件。
/wiki/index.md 更新：
Markdown
## 最近更新 (2026-05-23)### 新建页面
- [[incremental-ingest]] — 概念：增量式 Ingest
- [[knowledge-entropy]] — 概念：知识熵
- [[wiki-drift]] — 概念：Wiki 漂移
- [[schema-evolution]] — 概念：Schema 进化
- [新人物] — 实体
- [新工具A] — 实体
- [新工具B] — 实体
### 更新页面
- [[llm-wiki]] — 新增适用边界章节，追加来源
- [[rag]] — 新增矛盾标记
- [[compilation-pattern]] — S5 置信度升级至 high
- [[karpathy-andrej]] — 追加来源
- [[obsidian]] — 追加来源
- [[lint-audit]] — 新增反向链接
- [[schema-design]] — 新增反向链接
/wiki/log.md 追加：
Markdown
## 2026-05-23 | ingest | LLM Wiki 深度架构分析来源：raw/articles/llm-wiki-deep-analysis.md
粒度：Fine
用时：约 27 分钟
结果：
- 新建页面：7
- 更新页面：7
- 新增交叉引用：19 条
- 矛盾发现：1（条件性矛盾，已标记）
- 置信度变更：1（compilation-pattern S5: medium → high）
- 知识缺口识别：2（见下）
知识缺口：
1. 「向量搜索与 LLM Wiki 的协作模式」— wiki 中没有专页
建议素材方向：寻找讨论大规模 LLM Wiki + 向量搜索混合架构的文章
2. 「LLM Wiki 的团队协作模式」— wiki 中没有专页
建议素材方向：寻找讨论多人共建 LLM Wiki 的经验和案例
这份日志，是你系统运行历史的「黑匣子」。
如果未来某一天你对 wiki 里某个页面的内容感到困惑——“这个观点是从哪来的？”——你可以打开 log.md，追溯到具体是哪一次 Ingest、从哪篇素材中编译进来的。
可追溯性，是长期信任的基础。
25:00 — AI 输出最终报告（Step 8）
咖啡喝完了。回到屏幕前。
AI 给了我一份完整的 Ingest 报告。我把关键数据汇总一下：
text
═══════════════════════════════════════════
INGEST 完成报告
素材：LLM Wiki 深度架构分析
时间：27 分钟
═══════════════════════════════════════════📊 数据总览
新建页面：7
更新页面：7
新增链接：19
矛盾发现：1
置信度升级：1
知识缺口：2
📈 系统变化
wiki 节点：77 → 84（+7）
总交叉引用：预估 +19
置信度分布变化：
high: 18 → 19（+1）
medium: 43 → 48（+5）
contested: 2 → 4（+2）
⚠️ 需要用户关注
1. 矛盾 #1（适用边界分歧）等待用户决策
2. 知识缺口 #1, #2 建议补充素材
═══════════════════════════════════════════
27:00 — 打开 Graph View（见证时刻）
最后一步。不是技术步骤，是情感步骤。
我打开 Obsidian 的 Graph View。
text
Ingest 前：
77 个节点，分散在几个小型「星系」中，
核心概念如 llm-wiki、rag、compilation-pattern 是连接度最高的枢纽Ingest 后：
84 个节点。新节点不是散落在图谱边缘——
它们嵌入在了现有的网络之中，
通过 19 条新链接与旧节点紧密相连。
新出现的 knowledge-entropy 节点，
同时连接了 compilation-pattern、rag 和 llm-wiki，
形成了一个新的概念三角。
wiki-drift 节点连接了 llm-wiki 和 lint-audit，
在两个原本关联不多的区域之间建立了一条新路径。
整个图谱的密度明显增加。
知识网络不只是变大了——它变得更密、更有结构了。
这就是编译型知识系统和摘要型笔记系统之间，视觉上最直观的区别。
摘要型：每次新增一个孤点。点越来越多，但图谱永远是稀疏的。 编译型：每次新增的节点立刻被编织进现有网络。图谱越来越密，越来越有结构。
复盘：27 分钟里到底发生了什么
让我把这整个过程再从全局视角看一遍：
text
00:00 我把文章扔进 /raw [我的工作：1 分钟]
01:00 我输入 Ingest 指令 [我的工作：30 秒]
02:00 AI 阅读全文 [AI 的工作]
04:00 AI 读取索引，了解现有知识库 [AI 的工作]
06:00 AI 识别 17 个实体 + 5 条声明 [AI 的工作]
09:00 AI 创建 7 个新页面 [AI 的工作]
13:00 AI 更新 7 个现有页面 [AI 的工作]
17:00 AI 建立 19 条交叉引用 [AI 的工作]
20:00 AI 完成矛盾检测 [AI 的工作]
23:00 AI 更新系统文件 [AI 的工作]
25:00 AI 输出报告 [AI 的工作]
27:00 我打开 Graph View 看结果 [我的工作：2 分钟]
我的总工作量：不到 4 分钟。
AI 的总工作量：约 23 分钟的持续操作。
产出：7 个新知识节点，7 个被加深的旧节点，19 条新连接，1 个被标记的矛盾，1 条声明的置信度升级，2 个被识别的知识缺口。
这是一次 Ingest。
如果你每周做 2-3 次这样的 Ingest，一个月后你的 wiki 会从 77 个节点增长到 110-130 个。三个月后可能到 200 个。
而且不只是节点在增长——连接密度在增长，置信度在分化，矛盾在浮现，知识缺口在被识别。
你的系统不只是在变大，它在变聪明。
新素材不仅仅是被存储——它被综合进结构化页面，与现有概念相链接，对照既有知识进行更新。这将个人知识管理从被动的笔记存储，转变为一个主动构建理解的系统。
常见问题：你可能遇到的真实情况
在你自己第一次运行 Ingest 之前，我想提前回答几个最常见的问题：
Q1：“我的第一次 Ingest，wiki 里还是空的，会不会效果很差？”
不会差，只是特征不同。
第一次 Ingest 几乎全是「新建」操作，很少有「更新」和「矛盾检测」。
这完全正常。你的系统还在建立基础节点。
前 5-10 次 Ingest，重点是积累基础概念页面。大约在第 10 次 Ingest 之后，你会开始频繁看到「更新已有页面」和「矛盾检测」——那就是系统真正开始产生复利的信号。
Q2：“AI 创建的页面质量不好，定义模糊，怎么办？”
这几乎一定是 CLAUDE.md 的问题，不是 AI 的问题。
如果 AI 给出模糊的定义，检查你的 CLAUDE.md 里是否有明确的「页面模板」。如果模板里没有要求「一句话核心定义，精确，不啰嗦」，AI 就会用它默认的方式——通常是冗长的、学术化的表述。
每次你对输出不满意，不要只是手动修改输出——回去修改 CLAUDE.md。
Karpathy 把 Schema 描述为"共同进化"的——你根据 wiki 的发展情况随时间不断精炼它。
修改 Schema，是唯一可持续的质量提升方式。
Q3：“27 分钟太久了，有没有更快的方式？”
有。但不建议你现在追求速度。
Fine 粒度的 Ingest 确实慢，但质量最高。如果你想加快速度：
对日常文章使用 Standard 粒度（大约 12-15 分钟） 对随手浏览的短文使用 Coarse 粒度（大约 5-8 分钟） 批量处理旧笔记时用 Minimal 粒度（最快 2-3 分钟一篇）
建议对大量文件夹使用最小或粗略粒度来节省时间和成本，对值得深入分析的关键文档选择性地使用精细粒度。
核心原则是：不是所有素材都值得 Fine 粒度。 你的判断力用在选择粒度上，AI 的算力用在执行上。
Q4：“我没有 Claude Code，用 Claude 网页版可以吗？”
可以，但体验不同。
Claude Code 的优势是可以直接在你的文件系统里操作——读取文件、创建文件、修改文件，所有操作都是真实的文件变更。
用网页版的话，你需要：
手动把文章内容和 CLAUDE.md 内容粘贴给 Claude 让 Claude 输出创建/更新的页面内容 你手动把这些内容保存为对应的文件
能用，但手动步骤多了很多。
建议的入门路径：先用网页版理解流程和感觉 → 确认这套方法适合你 → 再投入 Claude Code 实现自动化。
Q5：“如果 AI 提取了一个明显错误的概念怎么办？”
这是真实会发生的事。
Karpathy 也坦承，幻觉被固化为"事实"是 LLM Wiki 最值得认真对待的风险。
你有三道防线：
- Ingest 报告
— 每次 Ingest 结束后，快速扫描新建的页面列表。如果有明显荒谬的概念页面，当场删除。 - 置信度系统
— 单一来源的声明最高只能是 medium。只有经过多来源验证的声明才能升级。这天然限制了单次幻觉的影响范围。 - Lint 审计
— 每月运行一次，系统性地检查矛盾和不一致。任何严肃的实现都应该对照原始来源抽查生成的页面。
三道防线不能保证零错误，但能确保错误不会扩散、不会固化、不会被你无意识地接受。
尾声：你的第一次 Ingest
你读完了整个过程。
现在你知道了一次正确的 Ingest 从头到尾长什么样：阅读、索引、提取、创建、更新、链接、检测、记录、报告。
你也知道了你在这个过程中的工作量：选择素材，选择粒度，输入一行指令，然后——去泡一杯咖啡。
下一步不是读更多文章。
下一步是去跑你自己的第一次 Ingest。
选一篇你这周读过的、觉得"这篇文章有东西，但我不知道怎么把它变成我的知识"的文章。
存进 /raw，触发 Ingest，看着 /wiki 里的节点出现。
打开 Graph View，看看你的知识图谱上，多出了几个点、几条线。
那不只是几个文件——那是你的认知结构在以肉眼可见的速度生长。
你负责好奇心。AI 负责苦活。
系统已经就绪。去喂它。🌊
下一篇预告：
系统跑起来了。节点在增长，连接在变密。
但有一天你会发现—— 有些链接指向了不存在的页面。 有些页面上个月就该更新了。 有两个页面对同一件事说了相反的话。
你的数字大脑，需要一次「体检」了。
下一篇：《给你的数字大脑做一次体检：Lint 审计的完整操作手册》
我会给你一个可以直接运行的审计脚本， 和一份每月 30 分钟的「系统健康清单」。
关注一只阿木木，别让这个系列在你的收藏夹里睡觉。去做，才是真的学。🌊
本文参考资料：Andrej Karpathy，「LLM Wiki」，GitHub Gist，2026 年 4 月。