Karpathy 的 LLM Wiki 方法论：复利工程与知识开放

Karpathy 的 LLM Wiki 方法论：复利工程与知识开放

阅读指南 这是本系列的第三版，三版分工不同：

• 1.0 版：按"七个场景"逐一拆解机制，技术细节最全
• 2.0 版：把方法论提炼为「复利工程」框架
• 3.0 版（本文）：2.0 的框架 + 实证 + 开放。框架不变——复利工程的四个层次、三个前提；实证收敛到国际机票域，用「运价资源 → 销售产品」和「辅营搭售 → 货架」两条真实概念线，把每一层复利从论断讲成事实；最后新增开放知识格式 (Open Knowledge Format, OKF) 一章，回答复利之后的下一个问题——攒下来的知识如何开放出去、获取价值。

对外分享按这版讲；机制细节回 1.0 查。

一、RAG 的天花板，与 Karpathy 的回答

假设有人问："一张国际机票的售价，从渠道运价到用户看见的价格，中间经过了什么？"

直接把仓库丢给 AI 做检索增强生成 (RAG)：每次都做向量召回 → 拼答案。能用，但有三个不可解的问题：

1. 不沉淀：你这次追问三轮才理清的定价链路，下次同事问，AI 还是从头再来
2. 不更新：PRD 改过五版，老口径和新口径一起被召回
3. 不生长：再用五年，每次依然从零开始

Karpathy 在 2026 年 4 月给出的方案只有一句话：在原始资料和 LLM 之间插一个 Wiki 层，让 LLM 自己维护。

Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

抛开技术细节，RAG 和 Wiki 最本质的差别是这张表：

重点不是"答得更好"，而是"会越用越好"。 这是 wiki 作为"工程"而非"文档"的全部意义。

二、复利工程：定义，与三个月的账本

复利工程 每一笔投入，都让未来同类投入的产出更高。

我们仓库 4 月初按这套方法搭起来，到现在跑了整三个月：

其中国际机票域 62 篇概念，是最大的域。本文的全部实证取自这个域的两条概念线：

• 定价链路线（运价资源 → 销售产品）：国际机票定价是一条流水线——渠道运价进来，组装成用户视角的产品，比价淘汰，调价，变成舱位页上的一张卡片。它将证明内容复利与关联复利。

graph LR
    A[报价渠道] --> B[运价资源<br>12 种圈选]
    B --> C[销售产品<br>15 种组装]
    C --> D[产品PK<br>比价淘汰]
    D --> E[产品调价]
    E --> F[舱位卡片]

• 辅营线（辅营搭售 → 货架）：辅营 = 机票之外的一切附加产品（保险、退改保障、付费选座……），货架 = 它的统一配置实现层。它将证明第三个前提——演化通道：概念边界抽错了，能改。

复利不是抽象概念。这三个月里，它在四个层次上具体地发生。

三、Wiki 是工程，因为它在四个层次上复利

第一层：内容复利——同一篇概念越读越厚

销售产品 的 sources 现在有 5 个，值得看的是它们进来的顺序：

04-08  舱位产品化两篇 PRD + 舱位重构迭代 PRD     ← 产品怎么定义
06-03  代码逻辑《生成PK调价链路》（Java 代码分析）  ← 系统怎么跑
07-02  B2B 分销售卖流程 PRD                      ← 长出新维度

第 4 个源进来时发生了一件重要的事：概念里"强显"字段的语义被校正了——代码分析发现 V2.0 之后强显只表示"是否参与产品 PK"，去重职责已剥离给 互斥组。今天任何人问"强显到底什么意思"，拿到的是校正后的准确语义，而不是某一版 PRD 里的旧话。PRD 视角（产品怎么定义）和代码视角（系统怎么跑）融合在同一篇概念里，这是任何单篇文档都给不了的。

第 5 个源是 B2B 分销 PRD。这是一次大扩展——同一产品可以同时在 C 端主流程和 B2B 分销流程售卖——但它没有新开一篇"销售产品（B2B 版）"，而是给既有概念长出一个「售卖流程」维度。

每次新 PRD 不是新开一篇文章，而是把新细节合并进既有定义。读者打开概念页看到的，永远是当前最准的综合版，而不是某一次迭代的快照。

类比：每读一本书新增一个书签 vs 每读一本书加深维基百科上的一个条目。前者是 RAG，后者是 Wiki。

第二层：关联复利——新概念让旧概念更值钱

新建一篇概念，会顺手在旧概念页里追加交叉引用。这不只是"礼貌"，是产生复利的核心机制。看定价链路线上的三个证据：

• 底座概念被反哺：运价资源 的源数从 1（04-08）→ 3（05-07）之后就停了，但它没有停止增值——机票升级、辅营搭售、舱位页辅营搭售 相继把它作为底层依赖反向链入，相关概念从 5 条长到 8 条。有的概念复利表现为源变多，有的表现为被引用变多——后者是"底座概念"的形态。
• 新概念统一旧口径：6 月中新建的 价格分层定价模型 把散落在 产品调价、产品PK 里的口径统一命名为 L0 成本事实 / L1 渠道出票成本 / L2 政策让利 / L3 产品调价 四层分量；7 月初链路末端又挂上 价格抹平（价格围栏，只压不抬）和 成本倒挂监控（渠道 × 航司报表 + 告警）。这些新概念每建一篇，旧概念就被反向链接补厚一次。
• 机制兜底补链：5 月下旬 wiki-lint 报出 9 对缺失互链，一次全量补齐，其中 3 对都指向 运价资源。人漏掉的关联，体检机制兜底补上。

结果：你今天读 销售产品 时拿到的，已经不是 4 月初编译的那篇文章——它被后续每次编译"以反向链接的形式"补充过，自己什么都没改。RAG 召回一篇文档时，召回的是它自己；Wiki 召回一篇概念时，顺带召回的是三个月里所有相关概念给它打的"补丁"。

今天再问开头那个问题——"一张国际机票的售价是怎么形成的"——AI 两跳进国际机票域索引，沿这条链读完 5 篇概念就能给出全链路回答，每个环节还能沿 sources 回溯到源 PRD 或源代码分析。三个月前，这需要人肉翻 5 篇 PRD 加 1 篇代码，还得自己拼。

第三层：机制复利——每一次踩坑都被永久过滤掉

最容易被忽视、但单位 ROI 最高的一层。

每一行都是同一个故事：一类伪工作被识别 → 在脚本里堵住 → 此后再也不付这部分代价。

ROI 算一笔账：04-21 那次 241 个文件如果每篇平均花 5k token 提取，单次省下约 120 万 token。这不是省一次，是从此每个月省一次。机制复利不是更努力，而是不再做白工。

第四层：结构复利——规模长大、查询不变贵

主索引演化的四个台阶：

切完之后，主索引体积与 wiki 规模解耦——从 146 篇长到 189 篇，路由层没有变大一个字节；以后涨到 500 篇，依然 1.5KB。查询成本不再随知识库一起涨。

这是结构层面的复利：你不只是"现在便宜"，未来也不会变贵。Karpathy 原文说"index.md 必须时刻保持 slim 才能塞进每次查询的上下文"——他个人场景没碰到边界，团队场景四个月就到了分水岭。

四、复利成立的三个前提

复利不是免费的。三件事必须同时成立——少一件，整套体系都会在三个月内退化为"过时文档"。

前提一：维护的边际成本必须接近零

如果每次新增 PRD 要人工维护概念页、手动加交叉引用、更新索引——这套体系一周就会烂掉。让它跑下来的关键是：新增 / 重构 / 同步全部由 LLM 一次性完成。

空口无凭，解剖一次真实的编译。以 6 月 3 日那次增量编译为例——就是第三章里把"强显"语义校正掉的那次。输入是全仓 320 个源文件，其中真正有变化的只有 4 个：新增 2（《生成PK调价链路》代码分析、搜索成单分析）、变更 2。

一次编译的账单：2 篇新概念 + 6 篇概念更新 + 5 张索引 + 5 条术语 + 源文件回填 + 元数据 + 日志，合计改动近 20 个文件，LLM 几分钟跑完；换成人做——包括读完一篇 Java 代码分析、再回头校正三篇概念的语义——至少半天。

这张表还藏着一个关键的分工设计：确定性的活全部脚本化（哈希、diff、回填、记账），LLM 只花在真正需要理解的地方（抽概念、并语义、补链）。这次编译 LLM 实际只读了 3 个文件的全文和 1 个文件的 diff——其余 316 个文件在脚本层就被拦下了，连 LLM 的面都没见到。

人会放弃维护任何东西的根本原因都是同一条：簿记成本 > 使用价值。 上面这条流水线就是把簿记成本压到接近零的全部工程——复利才有机会跑起来。

前提二：写读分离——LLM 写、人只判方向

wiki 层的全部内容由 LLM 写，人不直接编辑。这看起来反直觉（"我看到错了为什么不能改？"），但这是让复利能扩展的关键：

• 如果人也能改 wiki：下次编译会覆盖人的修改 → 人不再信任 wiki → 弃用
• 如果只有 LLM 改 wiki：源 PRD 是真相之源，wiki 永远反映 PRD 的最新综合 → 信任稳定

正确做法是改源 PRD 然后重编。这条规则只有一句，但它是整套工程能否长期运转的关键。

前提三：演化通道——错了能改、不必推翻

前两层复利都假设"概念抽得对"。但抽错怎么办？辅营线就是完整的答案。

今天的辅营知识结构很清晰：辅营搭售 回答 What（卖什么、在哪卖、怎么收钱），货架 回答 How（运营怎么配、命中规则怎么走、SKU 怎么投放），6 种货架形态（PACK / HANDSEL / OPTIONAL / INSURE_SLOT / POPUP_RETAIN / SEAT_SLOT）跨页面复用同一套「货架配置 + 货架策略」模型。

但这个结构不是一开始就有的——它是 4 月 23 日一天之内三次 archive 重构出来的：

第②步的教训被写进了编译日志，成为后续所有重构的判例：

抽离基础设施型概念时，要先确认上层业务是"被实现层切割成多个业务"，还是"业务统一、实现层是横切关注点"。本案是后者：辅营搭售业务是统一的，货架只是它的 How。

重构的红利：之后的业务"即插即用"。 边界划对之后，每个新辅营业务落地时不再重述配置模型，只声明自己插在货架的哪个形态上——5 月中退改无忧两篇概念落地（国内基线 + 国际版），配置模型零复述，直接声明"接入 PACK + OPTIONAL 两种货架形态"，差异只写业务规则（取小赔付、航变迁移而非出险）；占座搭售（SEAT_SLOT）、选购货架（OPTIONAL）同理。

还有一个容易被忽略的反向案例：6 月初，挽留弹窗方向收缩，一篇迁移 PRD 被砍——wiki 做了定向清理，3 篇概念的 sources 同步剔除（辅营搭售 8→7、货架 4→3、保险位 2→1），并加 warning 标注"货架迁移设计视为未落地规划"。wiki 不只随业务生长，也随业务收缩——RAG 对"被砍掉的方向"无能为力，只会继续召回尸体。

概念库和代码库一样需要重构；wiki-archive 就是 wiki 的重构通道。没有它，4 月抽错的边界会锁死后面所有辅营业务的表达方式；有了它，所有概念都是可重组的——错了不必推翻重建，复利可以一直跑下去。

五、对团队意味着什么

这套方法论对个人是"笔记工具"，对团队是"组织记忆基础设施"。用法相同，但价值量级不同：

• 新人 ramp-up：路径变成"读主索引 → 进国际机票域子索引 → 读概念页 → 需要时回溯 PRD"。62 篇概念覆盖了从定价链路到辅营货架的全部业务原语——原本要 3 个月才长出来的业务直觉，可能 3 周。
• 跨域分析：一次"风控 + 支付 + 国际机票"的分析，原本要叫齐三个域的同事开会，现在 AI 打开三张域子索引就能起步。
• 抗迭代：半年后产品迭代了 N 版，wiki 仍然反映最新综合——"强显"字段的语义校正、挽留弹窗方向的收缩，都已经证明了这一点——而不是堆满"过时但还在的"PRD。

RAG 是组织外包给 AI 的临时工，每天来面试一次。 Wiki 是组织自己的工程师，每天上班把昨天的事记进笔记本。

复利的差别，到第三个月开始显著；到第六个月开始压倒性。我们现在正站在第三个月的节点上，两条案例线就是这条曲线开始变陡的样子。

六、OKF：攒下来的知识，怎么开放出去

前五章回答"知识怎么攒、为什么越攒越值钱"；这一章回答一个新问题：攒了 189 篇概念之后，这份资产除了自己用，还能怎么获取价值？

方法论正在变成行业标准

2026 年 6 月 12 日，Google Cloud 发布了 开放知识格式 (Open Knowledge Format, OKF) v0.1——规范原文直接引用了 Karpathy 的 LLM-wiki gist，把这个模式正式化为厂商中立的开放规范。

我们 4 月按 gist 落地，6 月它成了开放标准。这说明两件事：这条路线不是小众玩法；而且我们提前一个季度就长在了标准的形状上。

OKF 是什么？一句话：bundle = 一个 markdown 文件目录。一个概念一个文件，文件路径即概念身份；YAML frontmatter 承载结构化字段（唯一硬性要求是 type）；概念间用普通链接连成图谱；index.md / log.md 可选。官方口号是三个"就是"：

Just markdown, just files, just YAML frontmatter——无压缩方案、无新运行时、无强制 SDK，完整规范一页纸。

它最关键的设计不是任何技术细节，而是定位：它是格式，不是又一个知识服务。格式即契约——生产者和消费者彻底解耦：人手写的 bundle 可以被智能体消费，一个 LLM 编译的 bundle 可以被另一个 LLM 查询，两端工具独立替换。

我们与 OKF 的对照

拿 wiki/ 和 OKF v0.1 逐项对：

结论很清楚：在内部消费能力上 wiki/ 全面强于 OKF——这不奇怪，OKF 本来就只定义最小交换面，不定义内容模型。我们真正缺的只有两个 frontmatter 字段：kind（概念是数据表、接口、链路还是方法论——"种类"轴）和 description。而这两个字段都能零成本回填：description 从域子索引的摘要列直接生成，kind 按域 + 源目录批量推断，都不需要重编译。

开放的三条价值路径

本地知识按 OKF 的形状开放出去，价值从三个方向回来：

1. 对外交换。把 wiki/ 导出为 OKF bundle，其他团队、合作伙伴的任何智能体无需集成、无需翻译即可直接消费。想象把国际机票域 62 篇概念交给一个新合作方：对接同事不用再从零讲解什么是运价资源、什么是销售产品、货架怎么配——对方的 AI 读完 bundle 就有了三个月的业务直觉。
2. 消费端生态。标准化意味着现成的 OKF 消费者都能直接用：官方的静态 HTML 可视化器（单文件交互图谱，数据不出页面）、搜索索引、任意智能体框架。知识不再绑定在"当前这套 Claude Code + Obsidian 工具链"上——工具可以换，资产留下。
3. 方法论输出。这条已经发生：我们把这套 wiki 技能按 OKF 约定泛化成一套配置驱动的工具链（wiki-init / wiki-compile / wiki-query / wiki-lint + OKF 可视化器），随桌面端 AI 工作台分发给外部用户。方法论第一次离开这个仓库，变成可交付的产品能力。

七、一页速查

唯一一条纪律 Wiki 由 LLM 写，人只读。 要改 wiki，去改源 PRD 后重新编译。

收束

回到开头那句金句：「Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。」

2.0 版为它补过一句：代码库的价值不在写完那一刻，而在它每天都比昨天更值钱——这就是复利工程。

3.0 版再补后半句：复利决定这份资产值多少钱，开放决定这份资产能不能流通。

三个月，93 篇长到 189 篇；四层复利各有实证——「运价资源 → 销售产品」证明内容和关联会越用越厚，机制层每月省下百万级 token，索引切片让查询成本与规模解耦，「辅营搭售 → 货架」证明概念边界错了能改。而 OKF 的出现证明了第三件事：我们攒下的这份资产，天生就是可交换的形状——Karpathy 给了方法，OKF 给了它的通用记账单位。

这套体系不是更努力地维护文档，而是让每一次维护都让下一次维护更便宜；知识在本地复利，按标准开放。

最后，把镜头从这个仓库拉远，回答一个更根本的问题：为什么我们如此看重 wiki 工程？

过去一年的行业趋势很清楚：模型能力每隔几个月上一个台阶，曾经需要精心工程化的东西——提示词技巧、检索管道、工作流编排——正在一层层被模型自身的能力吸收。AI 应用层的驾驭系统 (Harness) 大概率会越做越薄。当所有人都能以几乎相同的成本调用几乎相同的智能时，模型本身不再构成差异，用模型的技巧也不再构成差异。

薄下去的是 Harness，薄不下去的是知识。模型再强，也不会知道"强显"字段在 V2.0 之后语义变了，不会知道辅营和货架的 What/How 边界是 4 月 23 日三次重构才划对的，不会知道挽留弹窗这个方向已经收缩——这些只存在于我们的业务里、并且每天还在变化的知识，是任何通用模型永远无法自带的。企业的核心竞争力，正在从"会不会用 AI"转移到"喂给 AI 的东西有多好"——核心数据、核心知识，以及让它们持续保鲜的那套工程。

这就是答案：wiki 工程不只是一个提效工具，它是在为"模型越来越强、应用层越来越薄"的那一天，提前把公司真正不可替代的资产——业务知识——整理成 AI 能直接消费、能持续复利、能按标准流通的形状。

模型是租来的，Harness 会变薄，知识才是留在自己手里、并且越用越厚的那部分。

Related Documents

• 1.0 版（按七个场景的详细机制拆解）
• 2.0 版（复利工程框架）
• Karpathy LLM Knowledge Bases (X 推文原文)
• Karpathy LLM Wiki (Gist 原文)
• wiki 概念：开放知识格式 OKF
• OKF 发布原文剪藏 (Google Cloud, 2026-06-12)
• 本仓库 Wiki 主索引
• 定价链路线概念：运价资源、销售产品、产品PK、产品调价、价格分层定价模型
• 辅营线概念：辅营搭售、货架、舱位页辅营搭售、国际机票退改无忧产品、国际机票占座搭售