Knowledge Compilation
核心操作：Raw → Wiki 的知识转化过程
定义
Knowledge Compilation（知识编译）是 LLM Wiki 的核心操作：
原始知识源经过 LLM 处理，转化为结构化 Wiki 层，实现一次编译、持续复用。
Karpathy 关于 学习短视频化 的提醒让这个定义更尖锐：保存资料不等于学习资料。Raw source 只是材料在场，编译才是主动加工。没有浓缩、质疑、对标和概念回填，知识库会退化成“看起来收藏了很多，实际每次还要从头理解”的资料堆。
与程序编译的类比
| 程序编译 | 知识编译 |
|---|---|
| 源代码 | Raw Sources（原始文档） |
| 编译器 | LLM Agent |
| 目标代码 | Wiki 层（Entities、Topics） |
| 运行时 | Query（查询） |
| 调试 | Lint（健康检查） |
编译流程（Ingest）
编译是 Raw → Wiki 的知识转化动作。具体执行流程、单次修改范围与运行约束，统一以 schema/compile-workflow.md 为准；lint 门禁以 schema/lint-workflow.md 与 tools/wiki-lint.py 为准。本文档只说明概念定位，不复制运行规则。
核心定位：compile 创建/更新 source summary 与少量已有稳定页面，必要时补充 typed relations 与重要综合判断；新研究问题交给 explore，不在 compile 中扩张。
编译产物类型
| 产物类型 | 描述 | 示例 |
|---|---|---|
| Entity | 概念定义页面 | Agentic-Engineering.md |
| Topic | 主题整合页面 | Agentic-Engineering-Patterns.md |
| Comparison | 对比分析页面 | RAG-vs-LLM-Wiki.md |
| Index | 内容索引 | index.md |
| History | 操作记录 | git commit log |
编译 vs 检索
| 维度 | RAG（检索） | Compilation（编译） |
|---|---|---|
| 处理时机 | Query 时 | Ingest 时 |
| 处理成本 | 每次查询都付出 | 首次编译成本较高；后续查询无需重复承担完整编译成本 |
| 结果稳定性 | 可能不同 | 固定不变 |
| 知识累积 | 无 | 持久沉淀 |
| 冗余处理 | 切片可能冗余 | 编译时已提炼 |
编译质量保障
质量门禁
定期执行 tools/wiki-lint.py 校验并生成 wiki/lint-report.md；具体检查项与门禁规则以 schema/lint-workflow.md 为准。
版本控制
Wiki 是 git repo，支持：
- 版本历史（追溯变更）
- 分支管理（实验性编译）
- 协作编辑（团队 Wiki）
编译策略
单源精细编译
Karpathy 推荐的方式：
"I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize."
优势：
- 深度参与知识提炼
- 确保 quality 和 relevance
- 建立个人理解
批量快速编译
适用于：
- 初始知识库建设
- 已有大量 raw sources
- 对质量要求较低的场景
编译与 Query 的循环
关键洞察
好的查询答案可以回填为新的 Wiki 页面
Query → Answer → File back to Wiki → Compounding
示例：
- 用户请求对比 → 生成 Comparison 页面
- 用户请求分析 → 生成 Topic 页面
- 用户发现关联 → 更新 Entity 关联
这样探索也能累积，不只是 source 编译累积。
三步编译法（进阶）
饼干哥哥在 Karpathy 方案基础上的改进，增加了"质疑"和"对标"两步
核心流程
原文 → 浓缩 → 质疑 → 对标 → 结构化 Wiki
第一步：浓缩 (Condense)
- 原则：用剃刀法则——删掉这条信息会影响理解吗？不会就删
- 输出：核心结论（不超过 3 条）+ 支撑每条结论的关键证据
- 格式：每条结论一行，证据缩进在下方
第二步：质疑 (Question) — 关键差异
针对每条核心结论，回答：
- 前提假设：这个结论依赖哪些前提假设？
- 边界条件：如果这些前提不成立（换行业/换市场/换规模），结论还成立吗？
- 数据可靠：作者的数据来源可靠吗？样本量、时间范围、地域限制？
- 反例存在：有没有作者没提到的反例或边界条件？
质疑的价值
避免孤立事实误导——如"转化率提升40%"的前提是"目标市场是北美"
第三步：对标 (Cross-reference)
- 跨域洞察：其他领域有没有类似现象？（技术↔商业↔管理↔科学）
- 知识迁移：这个知识可以迁移到哪些场景？
- 跨域关联：如果有跨域关联，创建或更新对应的概念条目
跨域洞察示例
- 领域 A："AI Agent 多步推理链在第 5 步后容易失控"
- 领域 B："跨境电商供应链超过 4 个环节后出错率指数上升"
- 洞察：复杂链条的可靠性随环节数指数下降
与 Karpathy 原方案的对比
| 步骤 | Karpathy 原始方案 | 饼干哥哥改进版 |
|---|---|---|
| 第一步 | 读原文 → 写摘要 | 浓缩（更精炼） |
| 第二步 | 提取概念 | 质疑（新增） |
| 第三步 | 更新索引 | 对标（新增） |
编译产物示例
一篇 TikTok Shop 选品策略文章编译后产出：
- 1 篇编译摘要（浓缩 + 质疑 + 对标结果）
- 3 个概念条目（TikTok Shop 选品、AI 选品工具、跨境电商利润率）
- 更新全局索引和操作日志
关键价值：下次编译相关文章时，AI 不是从零开始，而是读取已有概念条目，把新信息跟旧信息合并，标注异同
与多层记忆的关系
| 记忆层 | 对应 | 编译角色 |
|---|---|---|
| 短期记忆 | 当前对话 | 无 |
| 工作记忆 | RAG 检索 | 未编译知识 |
| 长期记忆 | Wiki 层 | 编译产物 |
编译成本分析
| 维度 | 首次编译 | 后续使用 |
|---|---|---|
| Token 成本 | 高（深度分析） | 低（直接查询） |
| 时间成本 | 高（触及多页面） | 低（结构化呈现） |
| 人工成本 | 需参与指导 | 无需参与 |
| 累积价值 | 基础建立 | 持续增值 |
关键数据点
- Wiki 规模在 ~100 篇 sources、数百个页面时，index.md 仍可有效工作
- 一次编译后，后续查询无需重复承担该 source 的完整理解与结构化成本（Query 自身的搜索、上下文读取与推理成本仍在）
- 三步编译法（浓缩 → 质疑 → 对标）的具体运行约束以
schema/three-step-method.md为准
前提与局限性
- 前提: LLM 具备足够的理解和综合能力，能准确提炼源材料的核心概念
- 前提: index.md 的方式在"中等规模"（~100 sources）有效，超大规模可能需要向量检索
- 边界条件: 编译质量依赖 Schema 文档的质量，Schema 不完善会导致编译结果不一致
- 局限性: "一次编译、持续复用"假设知识源之间没有根本性冲突，矛盾处理需要人工介入
- 局限性: Karpathy 的方案是个人 Wiki 场景，团队/企业场景的协作和权限管理未深入讨论
关联概念
- RAG-vs-LLM-Wiki — 编译 vs 检索的对比
- Context-Engineering — 编译时的上下文优化
- Multi-Layer-Memory — 编译产物的记忆层级
- Software-Development-Autonomy-Levels — 跨域同构：其"specification distillation"（agent 把对话/示例/修正持续编译成持久结构化规格）是知识编译在软件规格域的实例
- 20260625-ford-ai-quality-jd-power — 反面案例：Ford 未能将资深工程师的制度性知识"编译"进 AI 系统，导致质量缺陷；印证编译流程中"人参与指导"的必要性