Binflare Plus
Blog / Field NotesSignal / Reading

SIGNAL / llm-wiki-implementation-guide

如何搭建一个 LLM Wiki：从 Karpathy 的 idea 到可运行的知识编译系统

基于一个实际运行的 LLM Wiki 仓库，分享如何从零搭建由 LLM 持续维护的个人知识编译系统：四层架构、规则体系、核心 Workflow 和落地建议。

·Markdown / Public signal

前言

2026 年 4 月，Andrej Karpathy 发布了一篇名为 LLM Wiki 的 Gist，描述了一种让 LLM 持续维护个人知识库的模式。它的核心主张很简单：不要让 LLM 在每次提问时重新从原始文档检索和拼装答案，而是让它持续维护一个结构化的 wiki——一个会随着新来源和新问题不断演化的编译产物。

这个想法很吸引人，但 Karpathy 的原文是一个 idea file，不是工程文档。从 idea 到可运行系统之间有大量细节需要填充：目录怎么组织、页面类型有哪些、命名规则是什么、workflow 怎么定义、规则怎么约束 LLM 的行为。本文基于一个实际运行的 LLM Wiki 仓库，分享如何从零搭建这样一个系统。

四层架构

Karpathy 原文提出三层：raw sources、wiki、schema。在实际落地中，我把它扩展为四层：

raw/        原始资料层（只读）
wiki/       知识编译层（LLM 维护）
output/     产出层（面向交付）
schema/     规则与 workflow 层

raw/ 保存采集的原始内容。文章、论文、官方文档、个人笔记、GitHub 仓库的 README——不管来源是什么，进入 raw 后就不再修改。这是事实来源，是后续核对和重新编译的基础。

wiki/ 是 LLM 主动维护的知识编译层。它不保存原文，而是把原始资料加工成可浏览、可链接、可演化的知识结构。这里有来源导读页（单篇资料的提炼）、概念页（跨来源综合）、主题页（领域综述）和索引页（导航）。

output/ 是知识库的"最后一公里"。wiki 中的知识是结构化的、面向机器和深度阅读的；output 则把这些知识转化为面向特定受众的交付物——文章草稿、演讲大纲、技术报告、教程。output 单向消费 wiki，wiki 不反向引用 output。

schema/ 是规则和 workflow 的定义层。它告诉 LLM 目录怎么组织、页面怎么命名、frontmatter 有哪些字段、ingest/query/produce/lint 各自怎么执行。这是让 LLM 从通用聊天机器人变成知识库维护者的关键约束。

项目目录结构

以下是当前实际运行的 wiki 项目的完整目录结构：

wiki/
├── AGENTS.md                          # 全局约束入口，定义四层模型和 workflow
├── raw/                               # 原始资料层
│   ├── article/                       # 网页文章
│   │   ├── harness-engineering-is-cybernetics.md
│   │   ├── ai-first-engineering-strategy.md
│   │   └── ...
│   ├── paper/                         # 学术论文
│   ├── reference/                     # 官方文档、API 文档
│   │   └── openai-prompt-guidance-gpt-5-5.md
│   ├── note/                          # 个人笔记
│   │   └── llm-wiki.md               # Karpathy 的 LLM Wiki idea
│   ├── repository/                    # GitHub 仓库
│   │   └── karpathy-inspired-claude-code-guidelines.md
│   └── assets/                        # 二进制附件（PDF、图片）
│       └── <slug>/
├── wiki/                              # 知识编译层
│   ├── index.md                       # 全局导航入口
│   ├── sources/                       # 来源导读页
│   │   ├── llm-wiki.md
│   │   ├── harness-engineering-is-cybernetics.md
│   │   └── ...
│   ├── concepts/                      # 概念页
│   │   ├── llm-maintained-wiki.md
│   │   ├── harness-engineering.md
│   │   ├── agent-memory.md
│   │   └── ...
│   └── topics/                        # 主题
│       ├── knowledge-management/
│       │   ├── index.md               # 主题导航
│       │   └── overview.md            # 主题综述
│       ├── ai-assisted-software-engineering/
│       │   ├── index.md
│       │   └── overview.md
│       └── ai-models/
│           ├── index.md
│           └── overview.md
├── output/                            # 产出层
│   ├── article-draft/                 # 文章草稿
│   ├── talk-outline/                  # 演讲大纲
│   ├── tutorial/                      # 教程
│   ├── newsletter/                    # 通讯
│   ├── report/                        # 技术报告
│   ├── brief/                         # 简报
│   └── assets/                        # 产出物附件
└── schema/                            # 规则与 workflow 层
    ├── rules/                         # 规则定义
    │   ├── index.md                   # 规则导航和任务映射
    │   ├── structure.md               # 目录职责和路径规则
    │   ├── source-kind.md             # 来源类型判定
    │   ├── output-kind.md             # 产出类型判定
    │   ├── frontmatter.md             # 元数据契约
    │   ├── slug.md                    # 命名规则
    │   ├── governance.md              # 治理规则
    │   └── obsidian-markdown.md       # 写作风格
    └── skills/                        # Workflow 实现
        ├── ingest/
        │   ├── SKILL.md               # ingest 核心逻辑
        │   └── references/examples.md
        ├── query/
        │   ├── SKILL.md
        │   └── references/examples.md
        ├── produce/
        │   ├── SKILL.md
        │   └── references/examples.md
        └── lint/
            ├── SKILL.md
            └── references/examples.md

几个关键设计决策：

raw 按来源类型分目录。 article、paper、reference、note、repository 五种类型，每种一个子目录。判定优先级是固定的：GitHub 仓库 → 官方文档 → 学术论文 → 个人笔记 → 其余网页。这消除了分类时的歧义。

wiki 按页面职责分目录。 sources 存单篇来源的导读，concepts 存跨来源综合的概念，topics 存领域综述。每个 topic 有自己的子目录，包含 index.md（导航）和 overview.md（综述）。

schema 分 rules 和 skills。 rules 是稳定的规则定义，不在 workflow 中重复；skills 是 workflow 的具体实现，执行时按需加载对应规则。这避免了规则散落在多处导致的不一致。

AGENTS.md 是唯一入口。 LLM 启动时只需读这一个文件，就知道项目结构、允许的页面类型、workflow 入口和规则加载顺序。它不包含具体规则，只指向 schema/rules/index.md。

规则驱动，而不是 prompt 驱动

Karpathy 原文把 schema 描述为"一个文档"（比如 CLAUDE.md）。在实践中，我发现单一文档很快会变得臃肿且难以维护。更好的做法是把规则拆成独立文件，按职责分离：

schema/rules/
├── structure.md       目录职责和路径规则
├── source-kind.md     来源类型定义和判定优先级
├── output-kind.md     产出类型定义和判定规则
├── frontmatter.md     所有页面的元数据契约
├── slug.md            命名规则
├── governance.md      冲突处理、回写边界、治理规则
└── obsidian-markdown.md  写作风格规范

每个规则文件只负责一个维度。LLM 执行 workflow 时，按任务类型加载对应的规则子集，而不是每次都读完全部规则。这让规则可以独立演化，也让 lint 可以逐条检查。

规则的核心价值是可预测性。没有规则约束的 LLM 会随机决定页面放在哪里、字段叫什么名字、什么时候新建页面什么时候更新已有页面。有了规则，每次 ingest 的行为是确定的：来源类型怎么判定、slug 怎么生成、frontmatter 填什么字段、来源页按什么模板写、概念页和主题页怎么同步更新。

四个核心 Workflow

ingest：采集与编译

ingest 是知识库的输入通道。给 LLM 一个 URL 或本地文件，它会：

  1. 采集原始内容，判定来源类型（article/paper/reference/note/repository）
  2. 生成语义化 slug，写入 raw/<source_kind>/<slug>.md
  3. 创建来源导读页 wiki/sources/<slug>.md，提炼核心观点、论证结构、证据和限制条件
  4. 更新相关的概念页和主题页，把新来源的贡献融入已有综合
  5. 同步索引页

一次 ingest 通常触及 5-10 个 wiki 页面。我偏好一次处理一个来源，检查 LLM 的提炼是否准确，引导它强调什么、忽略什么。这比批量导入再事后修正更高效。

query：检索与综合

query 基于 wiki 中已编译的知识回答问题。LLM 先读索引定位相关页面，再读具体的概念页、主题页和来源页，最后综合出答案。

关键设计：高价值的 query 结果可以回写到 wiki。一次深入的对比分析、一个新发现的概念关联——这些不应该消失在聊天历史里，而应该成为知识库的一部分。但回写有边界：只允许写入已有的主题页或概念页，不允许创建新的页面类型。

produce：知识转化为交付物

produce 是 output 层的 workflow。它消费 wiki 中的编译知识，按目标受众和格式生成交付物。比如：

  • 基于 harness engineering 相关的多篇来源，写一篇面向技术 lead 的实践文章
  • 把本周新增的来源整理成 newsletter
  • 准备一个 20 分钟的 agentic coding 技术分享大纲

produce 不修改 wiki 或 raw，只读取和转化。如果 wiki 中的知识不足以支撑产出，它会明确告知缺口，建议先 ingest 补充来源。

lint：健康检查

lint 周期性检查知识库的结构健康：命名是否符合规则、frontmatter 是否完整、是否有孤立页面、是否有概念被提及但没有自己的页面、是否有过时的来源计数。它只诊断和建议，不直接修复。

Frontmatter 是知识的骨架

每个 wiki 页面都有 YAML frontmatter，记录类型、关联主题、关联概念、来源计数、创建和更新日期。这不是装饰，而是知识库的结构骨架。

# 来源页
type: source
source_id: llm-wiki
title: "LLM Wiki"
topic: [knowledge-management]
source_kind: note
concepts: [llm-maintained-wiki, retrieval-augmented-generation]
created_date: 2026-04-27
updated_date: 2026-04-27

# 概念页
type: concept
concept: llm-maintained-wiki
topics: [knowledge-management]
aliases: [LLM Wiki, AI-maintained wiki]
source_count: 3
created_date: 2026-04-27
updated_date: 2026-04-30

frontmatter 让 Obsidian 的 Dataview 插件可以动态查询（"列出所有 source_count > 3 的概念"），让 lint 可以自动检查一致性（"概念页的 source_count 是否与实际引用它的来源页数量匹配"），也让 LLM 在 ingest 时可以快速定位需要更新的页面。

实际效果

这个规模下，wiki/index.md 作为全局导航完全够用，不需要引入向量搜索或 BM25。LLM 读索引 → 定位页面 → 读具体内容的三步检索在 100 个来源以内都能高效工作。

更重要的是知识的复利效应。当我 ingest 第 8 篇关于 harness engineering 的文章时，概念页已经综合了前 7 篇的观点。LLM 不需要从零理解这个概念，而是在已有综合的基础上判断新来源贡献了什么增量——是新的视角、新的证据、还是与已有结论的冲突。这正是 Karpathy 说的"知识被编译一次，然后持续维护"。

工具选择

Obsidian 作为阅读和浏览界面。wikilink 让页面之间的关系可点击，graph view 让知识结构可视化，frontmatter 作为 Properties 可以被 Dataview 查询。LLM 写 wiki，人在 Obsidian 里读 wiki——这个分工很自然。

Claude Code 作为 LLM Agent。它可以直接读写本地文件系统，执行 schema 中定义的 workflow，遵守 AGENTS.md 中的全局约束。每次 ingest 就是一次 Claude Code 会话：给它一个 URL，它按规则采集、编译、同步。

Git 作为版本控制。wiki 就是一个 git repo，每次 ingest 一个提交。可以 diff、可以回滚、可以看演化历史。这比任何数据库方案都简单。

落地建议

如果你想从零开始搭建自己的 LLM Wiki，以下是我的建议：

从小开始。 不要一开始就设计完美的规则体系。先 ingest 3-5 篇你真正关心的文章，让 LLM 帮你建立最初的来源页和概念页。在这个过程中你会发现哪些规则是必要的（命名规则、frontmatter 字段），哪些可以后加。

规则要具体。 "保持一致性"不是规则，"所有日期字段使用 YYYY-MM-DD"才是规则。LLM 需要明确的、可检查的约束，而不是模糊的原则。

一次一个来源。 批量导入看起来高效，但你会失去对编译质量的控制。一次处理一个来源，检查 LLM 的提炼，纠正偏差，引导强调点。前 10 个来源的质量决定了后续 100 个来源的编译基线。

分离关注点。 raw 只存原文，wiki 只存编译结果，schema 只存规则。不要让 LLM 在 raw 里写摘要，不要让 wiki 页面保存原文，不要把规则散落在各处。

让 LLM 做维护，人做判断。 你负责选择什么值得 ingest、提出什么问题、判断编译质量是否合格。LLM 负责摘要、交叉引用、归档、一致性维护——这些是它擅长且人类容易放弃的工作。

接受不完美。 知识库是持续演化的，不需要一步到位。概念页的综合会随着新来源不断丰富，主题页的结论会随着新证据修正。这正是"持续编译"的意义：知识不是写完就定稿，而是随时间变得更准确、更完整。

从个人到团队

Karpathy 的原文主要面向个人使用。但这个模式可以扩展到团队场景。一个团队的 LLM Wiki 可以被 Slack 消息、会议记录、项目文档、客户反馈持续喂养，由 LLM 维护知识结构，人类审核更新。

团队场景需要额外的治理机制：知识的成熟度分级（draft → verified → proven）、引用追踪（哪些知识被实际使用了）、自动衰减（长期未引用的知识降级）、贡献暂存和异步合并。这些机制让知识库不会变成只进不出的资料堆。

但核心思想不变：让 LLM 做维护，让知识持续编译，让每次交互都为下一次交互积累价值。