知识管理 on 鬼哥的空间

OKF：AI Agent 缺的不是模型，是可交接的上下文

Mon, 22 Jun 2026 00:00:00 +0000

AI Agent 最怕的不是模型不够强，而是它每次开工前，都像一个刚入职的新同事：不知道表在哪，不知道指标怎么算，也不知道谁脑子里藏着关键规则。

Google Cloud 最近发布的 Open Knowledge Format（OKF），表面上看只是一个“Markdown + YAML frontmatter”的小规范。

但我觉得它真正值得关注的地方在于：它把 AI 时代最难交接的东西，重新变成了文件。

问题不是没有知识，而是知识没法交给 Agent

今天大多数公司的知识并不少。

表结构在数据目录里，指标定义在 BI 文档里，事故处理流程在 runbook 里，API 变更写在 release note 里，一些关键口径藏在老员工脑子里。

问题是：这些知识对人来说都已经够散了，对 AI Agent 来说更是灾难。

当一个 Agent 要回答：

1

怎么从事件流里计算 weekly active users？

它可能要同时知道：

哪张表是事件源；
用户 ID 用哪个字段；
bot 流量怎么排除；
时区按 UTC 还是业务地区；
老口径有没有废弃；
这个指标和看板上的 WAU 是否一致；
如果 join 用户表，应该走哪条路径。

这些信息往往分布在不同系统里：metadata catalog、Notion、Google Drive、代码注释、SQL 文件、Slack 历史消息，甚至某个资深工程师的记忆里。

所以，Agent 真正缺的不是“再聪明一点”。

它缺的是一份能被读取、能被链接、能被版本管理、能被不同工具交接的 上下文资产。

OKF 是什么：不是服务，是格式

Google Cloud 对 OKF 的定义很克制。

OKF v0.1 把知识表示成一个目录，目录里是一组 Markdown 文件，每个文件都有 YAML frontmatter。它不要求新 runtime，不要求 SDK，不绑定某个云厂商，也不要求你把知识搬进一个新平台。

最小形态大概长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


sales/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
 ├── index.md
 └── weekly_active_users.md

一个概念就是一个文件。

文件路径就是这个概念的身份。

文件头部放少量可查询字段，正文放人和 Agent 都能读的解释：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery/...
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column | Type | Description |
|---|---|---|
| `order_id` | STRING | Globally unique order identifier. |
| `customer_id` | STRING | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

OKF 的野心不在“文件格式很复杂”，恰恰相反，它的野心在于 足够普通：

设计选择	意味着什么
Markdown	人能读，Agent 也能读
YAML frontmatter	少量结构化字段可检索、可过滤
普通目录	能进 Git，能打包，能挂载，能同步
Markdown 链接	文件之间自然形成知识图谱
最小约束	不强迫所有团队接受同一套知识模型

这就是 OKF 最有意思的地方：它不是想成为新的知识平台，而是想成为知识平台之间的交换格式。

为什么是 Markdown？因为 Agent 时代需要“知识即代码”

这几年很多团队都在重新发现一个模式：LLM wiki。

人类维护 wiki 很痛苦，因为我们会忘记更新链接，懒得补充引用，也不想每次改完一个文档还去同步另外 15 个文件。

但这些事情恰好是 LLM 擅长的。

它不会嫌整理 cross-reference 无聊，也不会因为要批量改十几个文件就开始摆烂。只要你给它一个清晰的文件结构、约束和审查机制，它可以把知识维护变成一个持续循环：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


发现新事实
 ↓
更新概念文件
 ↓
补充链接和引用
 ↓
提交 Pull Request
 ↓
人类审核
 ↓
Agent 下次直接读取更新后的上下文

这就是“知识即代码”的味道。

代码为什么能长期演进？不是因为代码天然比文档高级，而是因为它有一套成熟的协作机制：

Git 记录历史；
PR 承载讨论；
diff 暴露变化；
review 把关质量；
CI 做基础校验；
blame 能追溯责任。

OKF 想做的，是让企业知识也进入这套机制。

不是再建一个“大家都不会更新”的知识库，而是让知识文件和代码、SQL、配置、runbook 一起被管理。

OKF 和 RAG 的区别：一个是切片，一个是概念

很多人第一反应会是：这不就是 RAG 吗？

不完全是。

RAG 通常做的是：把文档切 chunk，做 embedding，查询时召回相关片段，再交给模型综合。

OKF 更像是提前把知识整理成 概念级资产。一个表、一个指标、一个 runbook、一个 API、一个 join path，都可以是独立概念。概念之间用 Markdown 链接互相指向。

可以粗暴对比一下：

维度	RAG 常见做法	OKF 的思路
基本单位	文档切片 chunk	概念 concept
组织方式	向量索引	文件目录 + 链接图
语义关系	查询时临时召回	事先显式维护
可读性	主要给系统读	人和 Agent 都能读
版本管理	往往在索引外部	天然进 Git
适合场景	大规模检索	稳定知识、指标、 schema、runbook

RAG 像是让 Agent 在图书馆里临时找资料。

OKF 像是给 Agent 一本经过整理、带目录、带交叉引用、能持续更新的工作手册。

两者不是互斥关系。OKF bundle 完全可以被索引进 RAG 系统。但它的价值在于：进入索引之前，知识已经被整理成可审查、可迁移、可复用的形态。

OKF 真正解决的是“上下文交接成本”

我觉得 OKF 的关键词不是 Markdown，也不是 YAML。

它的关键词是：handoff。

一个企业里最贵的成本，往往不是模型调用费，而是上下文交接费。

新同事入职，要问一堆人。

新 Agent 上线，要重新接一堆系统。

换一个工具，要重新导出、清洗、适配。

换一个供应商，原来的知识资产又被锁在对方的数据模型里。

OKF 试图把这些上下文从“平台内资产”变成“文件资产”。

这件事如果做成，会有几个直接变化：

过去	OKF 想推动的状态
知识绑定在工具里	知识以文件存在
Agent 依赖专用 SDK	Agent 直接读目录
数据目录和文档分离	概念文件里同时有元数据和解释
更新靠人工记忆	更新走 PR 和 review
换工具就重做集成	格式是合同，工具可替换

这也是为什么 Google Cloud 在官方文章里反复强调：OKF 是 format，不是 platform。

如果一个格式只能在某家云、某个数据库、某个 Agent 框架里跑，那它解决不了上下文迁移问题。

Databricks 和 Snowflake 都很强，但知识仍然不可复用

这里可以拿两个今天业界很强的产品来对照：Databricks Genie One 和 Snowflake Cortex Analyst。

先说清楚：这两个方向都很顶。

Databricks Genie One 的定位是面向业务团队的 AI coworker。它强调“grounded in your data”，能让业务用户提问、拿到上下文相关的答案，并进一步把洞察转成 action、agent 或 app。它背后的 Genie Ontology 被 Databricks 描述为一个持续改进、自动推断的业务术语、实体和 KPI 知识图谱，用来支撑 Genie 的回答和动作。Databricks 文档里的 Genie Spaces，也明确要求数据分析师用 Unity Catalog 数据集、示例 SQL、业务语义表达式和组织术语说明来 curate 一个 domain-specific 的问答空间。

Snowflake Cortex Analyst 也在解决同一个核心问题：业务用户用自然语言问数据问题，但数据库 schema 本身不足以告诉模型“业务到底是什么意思”。所以 Cortex Analyst 依赖 semantic model / Semantic Views，把业务实体、维度、事实、指标、表关系、verified queries 等语义信息显式建出来。Snowflake 官方文档也明确说，semantic model 是用来弥合 business users 和 database 之间的差距。

这两套东西都不是玩具。

它们代表了企业数据 AI 的一个共识：自然语言问数想要靠谱，必须有业务语义层。

但问题也在这里。

如果你的团队在 Databricks 里花了很多时间维护 Genie Space、Genie Ontology、Unity Catalog Semantics；同时另一个团队在 Snowflake 里维护 Semantic Views、Cortex Analyst semantic model、verified queries，那么这些业务知识很难天然复用。

不是因为 Databricks 或 Snowflake 做得不好。

恰恰相反，是因为它们都做得太完整了：语义层、权限、执行引擎、治理、Agent 体验，都和自家平台深度耦合。

于是用户会遇到一个很现实的问题：

业务知识	在 Databricks 里	在 Snowflake 里	跨平台复用
指标定义	Genie / Unity Catalog 语义体系	Semantic Views / semantic model	需要重新映射
表关系	Databricks 平台上下文	Snowflake semantic layer	不能直接通用
Verified queries	Genie Space 示例和验证	Cortex Analyst verified queries	格式不同
业务术语	Genie Ontology	Semantic View definitions	各自维护
Agent 行为	Genie Agents / apps	Cortex Analyst API / apps	体验绑定平台

对企业来说，选择 Databricks 或 Snowflake 当然都可以。

真正麻烦的是：一旦业务语义被写进某个平台的私有结构里，它就很难成为企业自己的可迁移资产。

今天你可能还在二选一。

明天你可能是多云、多仓、多团队并存；有的团队在 Databricks，有的团队在 Snowflake，有的知识还在 Obsidian、Notion、dbt repo、GitHub、Confluence 里。

这时候 OKF 的价值就出来了。

OKF 不试图取代 Databricks Genie，也不试图取代 Snowflake Cortex。它更像一个中间层协议：

1
2
3
4
5


Databricks Genie / Unity Catalog
 ↓ export / sync
 OKF bundle
 ↑ import / consume
Snowflake Cortex / Semantic Views

理想情况下，企业可以把最核心的业务知识沉淀成 OKF bundle：指标定义、表关系、术语、runbook、verified query、历史变更、负责人、引用来源。

然后 Databricks 可以读它，Snowflake 可以读它，内部 Agent 可以读它，未来换一个新的数据平台也能读它。

这样，平台仍然可以竞争体验、性能、治理和执行引擎。

但业务知识本身，不再被锁死在某一个平台里。

这才是 OKF 最值得期待的地方：它让企业有机会把“语义层”从平台能力，升级成自己的知识资产。

它现在还很早，但方向很对

OKF 目前是 v0.1。

Google Cloud 同时发布了几个参考实现：一个 BigQuery enrichment agent，一个静态 HTML visualizer，以及 GA4、Stack Overflow、Bitcoin public dataset 等 sample bundles。Google Cloud 的 Knowledge Catalog 也已经支持 ingest OKF 并服务给自家 Agent。

这说明它已经不只是一个 PDF 规范，而是有了可跑的 producer、consumer 和样例。

但我们也要清醒：OKF 还不是事实标准。

它接下来要面对的问题不少：

各家 catalog 和 wiki 是否愿意导出 OKF；
企业内部是否愿意把知识当代码维护；
frontmatter 字段会不会逐渐膨胀；
权限、隐私、敏感信息如何和文件分发兼容；
Agent 自动更新知识时，怎样保证审查和可信度；
不同行业的概念模型能否在“最小约束”下保持互操作。

所以，OKF 不是答案的终点。

但它至少指出了一个很重要的方向：Agent 的能力边界，不只取决于模型，也取决于知识能不能被规范地交给它。

我们可以怎么用？

如果你在团队里做 AI Agent、数据平台、知识库、内部工具，我建议不要急着问“要不要全面采用 OKF”。

更实际的做法是：先挑一个小场景试。

比如：

1
2
3
4
5
6
7
8


把一个核心指标做成 OKF bundle：

metrics/weekly_active_users.md
tables/events.md
tables/users.md
runbooks/data-quality-check.md
references/product-definition.md
log.md

然后让 Agent 基于这些文件回答问题、生成 SQL、检查口径、解释异常。

你很快就会发现：真正困难的不是写 Markdown，而是把团队脑子里的隐性知识显性化。

这也是 OKF 最有价值的地方。

它逼你回答：

我们的核心概念到底有哪些？
每个概念的权威定义在哪里？
哪些链接关系必须显式维护？
哪些知识应该进版本控制？
哪些更新必须经过人类 review？

这些问题，本来就是企业做 AI Agent 绕不开的问题。

OKF 只是给了一个足够朴素、足够可落地的容器。

Takeaway：先别急着堆 Agent，先整理上下文

如果只记住一句话，我希望是这句：

AI Agent 的下一场竞争，不只是模型能力，而是上下文工程。

模型会越来越强，工具调用会越来越顺，multi-agent 框架也会越来越多。

但真正能让 Agent 在企业里稳定工作的，往往是那些看起来不性感的东西：指标定义、表关系、runbook、决策记录、历史变更、权限边界、业务口径。

OKF 的启发是：不要把这些东西继续锁在工具里、聊天记录里、某个人脑子里。

把它们变成文件。

让人能读，让 Agent 能读，让 Git 能管理，让工具能迁移。

这可能就是 AI 时代知识管理最朴素、也最关键的一步。

参考资料

Karpathy 的 LLM Wiki：用大模型编译知识，而不是检索知识

Mon, 06 Apr 2026 00:00:00 +0000

“我最近大部分的 token 消耗，不再是在操作代码，而是在操作知识。” —— Andrej Karpathy, 2026.04.03

2026 年 4 月 3 日，Karpathy 发了一条推文，描述了他最近用 LLM 构建个人知识库的工作流。第二天，他把这个想法整理成了一个 GitHub Gist，并提出了一个有趣的理念：在 LLM Agent 时代，分享 idea 比分享代码更有价值——你把 idea 交给自己的 Agent，它会为你定制和构建一切。

这条推文迅速引爆了技术社区。但在热度之下，Karpathy 真正提出的东西值得我们认真拆解：一种**用 LLM 编译知识（而非检索知识）**的全新范式。

本文将系统性地拆解这套思维体系——从它的历史渊源到技术架构，从与 RAG 的本质区别到社区的尖锐争论，最后给出可落地的实践路径。

一、从 1945 年说起：Bush 的 Memex 构想

要理解 Karpathy 在做什么，我们需要先回到 81 年前。

1945 年 7 月，Vannevar Bush 在《The Atlantic》发表了一篇名为 “As We May Think” 的文章，提出了 Memex（memory + index 的合成词）——一台桌面大小的设备，能存储一个人所有的书籍、记录和通信，并以"极快的速度和灵活性"供人检索。

Memex 最独特的设计是关联路径（Associative Trails）：用户可以在任意文档之间创建链式连接，模拟人类联想式思维，而非传统的层级索引。用户可以给这些路径加批注、创建分支，然后分享给同事。

这个构想直接影响了后来的一系列技术发明：

Douglas Engelbart（1945）读到这篇文章后开始研究，最终发明了鼠标、文字处理器和超链接
Ted Nelson（1965）明确引用 Memex，创造了"超文本"（Hypertext）这个概念
Tim Berners-Lee（1989）在此基础上构建了万维网
DARPA（2014）直接以 Memex 命名了一个研究项目

但 Bush 的构想有一个致命缺陷：维护成本。谁来持续更新这些关联路径？谁来在新文档加入时更新所有相关的交叉引用？谁来标注新旧信息之间的矛盾？

答案在 81 年后到来：LLM。

Bush 的 Memex 构想其实比万维网更接近 Karpathy 的方案——Web 是公开的、混乱的、弱链接的；Memex 是私人的、策展的、富链接的。

二、核心洞察：编译知识，而非检索知识

RAG 的根本问题

目前大多数人使用 LLM 处理文档的方式是 RAG（Retrieval-Augmented Generation）：上传文件 → 切块建索引 → 查询时检索相关片段 → 生成回答。

Karpathy 一针见血地指出了 RAG 的本质问题：

“LLM 每次查询都从零重新发现知识。什么都不积累。”

这就像一个图书管理员，每次有人来问问题，他都要从头翻阅所有的书，找到相关段落，拼凑出一个答案。下次同样的人来问相关的问题，他又从头来一遍——完全不记得上次的工作。

RAG 的具体局限：

维度	RAG 的问题
知识综合	只检索扁平文档，不在文档间创建关联和综合
复利效应	答案每次重新推导，知识不累积
检索噪声	基于嵌入的检索容易出现语义/词汇不匹配的静默失败
基础设施	需要向量数据库、嵌入模型、分块策略等一整套基建
上下文窗口	即使 2M token 也只能装约 300-400 页，一份财报就可能耗尽

知识编译：一种新范式

Karpathy 的替代方案是：不要只在查询时检索原始文档，而是让 LLM 增量地构建和维护一个持久的 Wiki。

当添加新资料时，LLM 不仅仅是索引它。它会：

阅读全文并提取关键信息
整合到现有的 wiki 知识体系中
更新相关的实体页面
修正已有的摘要
标注新旧信息之间的矛盾
强化跨文档的综合分析

知识编译一次，持续维护，而非每次查询都重新推导。

一个形象的比喻：

RAG = 一个有超快叉车的巨型仓库——什么都能找到，但不能解释货物之间的关系
LLM Wiki = 一个有专职图书管理员的策展图书馆——管理员不断写新的综述来描述和关联旧有的藏书

关键区别：Wiki 是一个持续复利的知识制品

交叉引用真实存在，矛盾被标注，综合分析反映了所有已读内容。Wiki 随着每一个新来源和每一次提问而变得更丰富。

三、三层架构

Karpathy 在 Gist 中明确定义了三层架构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


┌─────────────────────────────────────────┐
│ The Schema（配置层） │
│ CLAUDE.md / AGENTS.md │
│ 定义 wiki 结构、惯例、工作流 │
├─────────────────────────────────────────┤
│ The Wiki（知识层） │
│ LLM 生成和维护的 .md 文件 │
│ 摘要 / 实体页 / 概念页 / 综述 / 索引 │
├─────────────────────────────────────────┤
│ Raw Sources（原始资料层） │
│ 不可变的策展文档 │
│ 文章 / 论文 / 图片 / 数据集 / 代码库 │
└─────────────────────────────────────────┘

第一层：Raw Sources（原始资料）

这是不可变的事实来源。文章、论文、图片、数据文件——只进不改。所有的原始材料都保存在 raw/ 目录中。

采集工具：

Obsidian Web Clipper 浏览器扩展：一键将网页文章转为 markdown
配合 Obsidian 快捷键将相关图片下载到本地，方便 LLM 直接引用
手动放入的论文 PDF、数据集等

第二层：The Wiki（知识层）

这是 LLM 生成和维护的核心层——一组结构化的、互相链接的 markdown 文件。包括：

摘要页：每个原始资料的关键要点提炼
实体页：人物、组织、技术的专属页面
概念页：抽象概念的解释和关联
综述页：跨多个来源的主题综合分析
索引文件：全局目录和导航

关键原则：人类几乎不直接编辑 wiki，这是 LLM 的领地。 你负责策展来源、提出问题、引导方向；LLM 负责所有的簿记工作。

第三层：The Schema（配置层）

一个配置文档（如 CLAUDE.md 或 AGENTS.md），定义：

Wiki 的目录结构和命名规范
页面的模板格式
摄入新资料时的工作流程
质检的标准和流程

这个配置层将 LLM 从通用聊天机器人转变为结构化的知识维护者。

四、三大核心操作

操作一：Ingest（摄入）

当你往 raw/ 目录放入新资料时：

LLM 阅读原始资料
与你讨论关键要点
写摘要页，放入 wiki
更新 index.md（全局目录）
遍历已有的 wiki 页面，更新所有相关的实体页和概念页
在 log.md 中追加操作记录

一次摄入可能会触及 10-15 个 wiki 页面——这正是 LLM 维护的核心价值：人类不可能每加入一份资料就手动更新十几个页面，但 LLM 可以。

操作二：Query（查询）

当你向 LLM 提问时：

LLM 首先读取 index.md 了解知识库全局结构
根据问题定位相关的 wiki 页面
阅读相关页面，综合回答，附上引用来源
如果答案质量足够好，将其作为新页面归档到 wiki 中

最后一点至关重要——你的探索和提问不是一次性的消耗，而是持续增值的投资。每一次高质量的问答都会回流到知识库中，让它在下一次查询时更加丰富。

Karpathy 的研究 wiki 在单个主题上已经增长到 ~100 篇文章、~40 万词。令人惊讶的是，在这个规模下，他发现不需要花哨的 RAG——LLM 自动维护的索引文件和简要摘要，已经足够让它找到所有重要的相关数据。

操作三：Lint（质检）

定期对 wiki 进行"健康检查"：

矛盾检测：不同页面之间的数据冲突
过时标注：可能已经不准确的断言
孤立页面：没有任何入链的页面
缺失引用：应该存在但缺失的交叉引用
数据空白：知识库中缺失的重要概念
新文章建议：基于已有数据，发现值得深入探索的新方向

LLM 擅长的不只是回答问题，还包括提出问题。Lint 操作让知识库自我进化。

五、关键基础设施：索引与日志

index.md —— 知识的目录

这是 LLM 回答问题时首先读取的文件：

以类别组织的全局目录
每个页面附有链接、简要摘要和元数据
每次 Ingest 后自动更新

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


## 机器学习

- [Transformer 架构](concepts/transformer.md) — 自注意力机制的核心原理及变体
- [LoRA 微调](concepts/lora.md) — 低秩适应的参数高效微调方法
- [MoE 架构](concepts/moe.md) — 混合专家模型的路由策略和效率权衡

## 论文摘要

- [Attention Is All You Need](summaries/attention-paper.md) — Transformer 原始论文要点
- [LoRA Paper](summaries/lora-paper.md) — 低秩适应方法的理论基础

log.md —— 操作的时间线

一个**只追加（append-only）**的时间记录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


## [2026-04-01] ingest | Attention Is All You Need
添加 Transformer 原始论文。新建概念页：transformer.md, self-attention.md。
更新：index.md, nlp-overview.md

## [2026-04-02] query | MoE vs Dense 的效率权衡
回答了关于 MoE 架构的查询，综合了 3 篇论文的观点。
输出归档为：analysis/moe-vs-dense.md

## [2026-04-03] lint | 健康检查
发现 2 个矛盾（transformer.md 与 attention-paper.md 的参数数量不一致），
标注 3 个孤立页面，建议新文章：positional-encoding.md

这个日志有两个作用：一是让你追踪知识库的演化历程，二是其一致的格式使得程序化解析成为可能。

六、工具生态

Obsidian：知识的可视化前端

Karpathy 使用 Obsidian 作为阅读和导航界面——不是用来写（写是 LLM 的事），而是用来看：

Graph View：以图谱形式展示所有文章的互链关系，一眼看到知识结构
实时渲染：LLM 在后台编辑 markdown 文件时，Obsidian 实时更新显示
反向链接面板：查看哪些页面引用了当前页面
Dataview 插件：查询 YAML frontmatter，生成动态表格

Marp：从知识到演示

Marp 是一个基于 markdown 的幻灯片工具。你可以让 LLM 从 wiki 中提取内容，直接生成演示文稿——知识到输出的转化链路极短。

QMD：本地搜索引擎

当知识库规模增大时，需要更精确的搜索。QMD 是 Shopify 创始人 Tobi Lutke 开发的本地 markdown 搜索引擎：

qmd search：BM25 全文关键词搜索（快速，无需模型）
qmd vsearch：语义向量搜索（找概念相关但无关键词重叠的内容）
qmd query：混合搜索 + LLM 重排序（最高质量）

所有处理在本地运行，支持 MCP Server 协议，可直接被 Claude Code 等 Agent 调用。

号称能实现 95%+ 的 token 节省——哲学是：与其把整个知识库塞进上下文窗口，不如精确搜索后只传递相关内容。

Git：时间机器

整个 wiki 就是一个 git 仓库。每一次 Ingest、Query、Lint 都产生可追踪的 diff。你可以：

用 git log 追踪知识的演化
用 git blame 追溯每一行的来源
用 git diff 查看每次操作的具体变更
随时回滚到任意历史状态

纯文本 + Git = 可移植、有版本控制、工具无关、面向未来。文件比应用活得更久。

七、为什么这套方法真的有效

Karpathy 给出了一个简洁有力的解释：

“维护知识库的枯燥部分不是阅读或思考——而是簿记。”

更新交叉引用、保持摘要最新、标注矛盾、维护一致性——这些工作是人类放弃维护 wiki 的根本原因。企业内部的 Confluence 为什么总是过时？个人的 Notion 笔记为什么半年后就成了废墟？因为维护成本太高。

LLM 解决了这个问题：

不会厌倦：更新 15 个页面的交叉引用对 LLM 来说和更新 1 个一样轻松
不会遗忘：每次 Ingest 都会检查所有相关页面
成本趋近于零：维护的边际成本几乎可以忽略
无限耐心：Lint 操作需要 N×N 的比较？没问题

人类负责有创造力的部分：选择什么值得读、提出什么问题、决定往什么方向深入。 LLM 负责一切机械性的簿记工作。

八、社区的尖锐争论

这条推文引发了激烈的讨论。支持者和批评者都提出了有价值的观点。

支持方

“每家企业都有一个 raw/ 目录，但没人编译过它。这就是产品。” —— 创业者 Vamshi Reddy 一语道破了商业潜力。

“这样你拥有记忆；在现有的平台部署中，拥有记忆的是平台。” —— TeMPOraL 指出了数据主权的关键优势。所有数据都是本地 markdown 文件，不依赖任何平台。

批评方：思考的摩擦力

最有哲学深度的批评来自知识管理社区。

Extended Brain 的一篇分析文章直接指出了**“思考的摩擦力”问题：Niklas Luhmann 的 Zettelkasten（卡片盒笔记法）之所以有效，是因为手动用自己的话重写想法这个动作本身就是思考的机制。当你写到一半写不下去的时候，那个卡壳的瞬间恰恰暴露了你理解上的空白——这种有价值的阻力**，是 LLM 生成的综合分析无法替代的。

Hacker News 的 qaadika 也提出了类似观点：

“正是在做这些事情的过程中，新想法才会涌现……我的许多洞见都来自于偶然看到一条笔记紧接着另一条笔记。”

批评方：幻觉污染

另一个实际的担忧：LLM 在生成 wiki 内容时可能引入幻觉，而这些幻觉会被后续的查询当作事实引用，形成幻觉的复利效应——不是知识在复利增长，而是错误在复利增长。

jdthedisciple 在 HN 上说：“我宁愿每次都引用原始文档，而不是一个我可能没时间去核实的 LLM 生成的 wiki。”

我的看法：两者不矛盾

这两种批评都有道理，但并不意味着 LLM Wiki 模式无价值。关键是找到正确的分工：

LLM 负责基础设施和地图：索引、交叉引用、摘要、矛盾标注
人类负责综合和思考：基于 LLM 的地图，做出自己的判断和创造
溯源机制不可省略：每一个 wiki 断言都应该能追溯到 raw/ 中的原始来源

社区中一些成熟的实现已经在解决这些问题：基于内容 hash 的新鲜度验证、propositions 级别的来源追踪、AI 生成内容和人类编写内容的明确标记等。

九、社区实践中沉淀的高级模式

Gist 的评论区和 HN 讨论中，实践者们贡献了不少有价值的改进模式：

1. 分类后再提取

不同类型的文档需要不同的处理策略——报告和信件的提取方式完全不同。先分类，再用对应的模板提取。

2. Token 预算分级

为索引设计四级上下文策略：

级别	内容	用途
L0	页面标题列表	快速概览
L1	标题 + 一句话摘要	定位相关页面
L2	完整摘要	深入了解
L3	全文	精确引用

LLM 根据查询复杂度选择合适的级别，避免要么读太少要么烧光上下文。

3. 类型化模板

使用基于实体类型的页面结构（人物模板、技术模板、论文模板），而非通用模板。这比自由格式能更好地维护一致性。

4. 决策记录

不只记录"知识变了什么"，还记录"为什么变"。当 wiki 页面被修改时，同时生成 decision record 记录推理过程和被否决的替代方案。

5. 隐私分层

敏感内容用本地模型（如 Ollama）处理，通用内容用云端模型（如 Claude）。这让机构级部署成为可能。

6. 规模瓶颈感知

纯 markdown 方案在 ~500 个文档 以内表现良好。超过这个规模，考虑引入 SQLite 存储元数据，或使用 QMD 等搜索工具辅助定位。

十、未来方向：从上下文到权重

Karpathy 在推文中提到了一个意味深长的方向：

“当知识库足够大时，自然会想到合成数据生成 + 微调，让 LLM 把数据’知道’在权重里，而非仅靠上下文窗口。”

这描述了一条完整的知识管道：

1

原始资料 → LLM 编译为 wiki → wiki 作为高质量训练数据 → 微调领域专用模型

一个维护良好的 wiki 本身就是高质量的合成训练数据——它结构化、有引用、有交叉验证、不断被 lint。这可能是通往个人化、领域化 LLM 的最自然路径。

加上上下文窗口的指数级增长（GPT-3 的 2K → Gemini 2.0 Pro 的 2M，1000 倍增长），“把整个 wiki 加载到单次上下文"的方式在当前规模下完全可行，无需向量数据库。

十一、动手实践：从零构建你的 LLM Wiki

理论说完了，下面是可执行、可落地、可见成效的实践路径。

阶段一：最小可行 Wiki（第 1-2 天）

目标：跑通完整的 Ingest → Query 循环，感受知识编译的效果。

具体步骤：

1
2
3


mkdir -p my-wiki/{raw,wiki,wiki/summaries,wiki/concepts}
cd my-wiki
git init

编写 Schema 文件

创建 CLAUDE.md（如果用 Claude Code）或等效的系统提示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Wiki Schema

## 结构
- raw/: 原始资料，只读
- wiki/index.md: 全局目录，按类别组织
- wiki/log.md: 操作日志，只追加
- wiki/summaries/: 每个原始资料的摘要
- wiki/concepts/: 概念页面

## Ingest 工作流
当我说"ingest <文件>"时：
1. 阅读 raw/ 中的指定文件
2. 在 wiki/summaries/ 创建摘要页
3. 识别关键概念，创建或更新 wiki/concepts/ 中的概念页
4. 更新 wiki/index.md
5. 在 wiki/log.md 追加记录

## 页面格式
每个 .md 文件开头包含 YAML frontmatter：
- title, date, sources, related

采集 3-5 篇你感兴趣领域的文章到 raw/

可以用 Obsidian Web Clipper，也可以手动复制粘贴为 markdown。

逐个 Ingest

在 Claude Code（或你选择的 LLM Agent）中：

1

ingest raw/article-1.md

观察 LLM 如何创建摘要、识别概念、更新索引。

提一个需要跨文档综合的问题

1

这几篇文章在 XX 主题上有什么共识和分歧？

预期成果：3-5 篇原始资料 → 3-5 个摘要页 + 若干概念页 + 1 个索引 + 1 个日志。你会直观感受到"编译"和"检索"的区别。

阶段二：建立 Obsidian 工作流（第 3-5 天）

目标：让知识库可视化，建立高效的采集通道。

具体步骤：

用 Obsidian 打开 wiki 目录

安装 Obsidian，将 my-wiki/ 作为 Vault 打开
打开 Graph View，观察页面互链的图谱

安装关键插件

插件	用途
Obsidian Web Clipper	一键采集网页到 `raw/`
Dataview	动态查询 frontmatter 数据
Marp Slides	将 wiki 内容转为幻灯片

建立采集习惯

浏览到有价值的文章 → Web Clipper 保存到 raw/
下载相关图片到本地（Obsidian 快捷键）
定期（每天或每周）批量 Ingest

开始提问和归档

每次查询后评估答案质量
好的答案让 LLM 归档为新 wiki 页面

预期成果：原始资料增长到 10-20 篇，wiki 开始呈现有意义的图谱结构。

阶段三：引入 Lint 和工具链（第 2-3 周）

目标：让知识库自我进化，提升数据完整性。

具体步骤：

运行第一次 Lint

1
2
3
4
5


对整个 wiki 做一次健康检查：
- 找出页面之间的矛盾
- 标注可能过时的断言
- 列出缺失交叉引用的孤立页面
- 建议值得新增的概念页

安装 QMD（可选，当规模超过 50 篇时建议引入）

1
2
3


npm install -g @tobilu/qmd
qmd index wiki/
qmd search "你的查询"

建立定期维护节奏

每周一次 Lint
每次 Lint 后根据建议执行 2-3 个改进
追踪 log.md 的增长趋势

预期成果：wiki 开始自我修复和自我增强。你会发现 LLM 建议的新方向经常出乎意料地有价值。

阶段四：输出和复用（第 4 周+）

目标：让知识库产出实际价值。

具体场景：

写报告：让 LLM 基于 wiki 生成特定主题的分析报告
做演示：用 Marp 格式输出幻灯片
生成可视化：让 LLM 用 matplotlib 生成数据图表
回答复杂问题：wiki 越大，能回答的问题越复杂
发现盲区：通过 Lint 发现你知识体系中的空白

每一次输出都可以考虑归档回 wiki，形成正向循环。

进阶方向

当你的 wiki 稳定运行一个月以上，可以考虑：

多主题 Wiki：为不同研究方向建立独立的 wiki
MCP 集成：将 wiki 搜索暴露为 MCP Server，让其他 Agent 也能查询
自定义 CLI 工具：基于你的特定需求开发辅助脚本
微调实验：将 wiki 内容转化为 QA 对，微调一个领域专用的小模型

十二、总结

Karpathy 提出的不是一个工具，而是一个设计模式：

人类策展，LLM 编译——人负责选择、提问、思考；LLM 负责簿记、索引、维护
编译优于检索——知识编译一次、持续更新，而非每次查询都从零推导
复利效应——每一次 Ingest 和 Query 都让知识库变得更丰富
维护成本趋零——LLM 解决了 Bush 1945 年就发现的维护问题
纯文本哲学——Markdown + Git，可移植、有版本、面向未来

从 1945 年 Vannevar Bush 的 Memex 构想，到 2026 年 Karpathy 的 LLM Wiki 实践，人类花了 81 年找到了解决个人知识管理维护难题的方案。答案是：把维护交给不会厌倦的 LLM，把思考留给自己。