在 Andrej Karpathy 的构想中，LLM Wiki 不仅仅是一个文档库，而是一个持续演进、自我维护的知识编译系统。传统的搭建方式往往需要编写复杂的 Python 脚本、配置向量数据库以及编写繁琐的 ETL 管道。然而，借助 Claude Code 强大的 Agent 能力，我们可以通过自然语言交互，完全“零代码”地构建这一系统。

本文将详细介绍如何在不编写任何代码的情况下，利用 Claude Code 搭建一个具备 Schema 驱动、自动链接、冲突检测能力的进阶版 LLM Wiki。

Karpathy 的 LLM Wiki 强调“编译”而非“检索”。在零代码环境下，我们需要将原本由代码执行的逻辑转化为 Claude Code 的工作流指令。核心架构分为三层：

• Raw Sources (原始资料层)：存放 PDF、网页快照等未处理的原始文件。
• Wiki (编译知识层)：存放经过 Claude 处理后的 Markdown 文件，包含双向链接和元数据。
• Schema (规范层)：通过 system_prompt 或配置文件定义的规则，指导 Claude 如何处理文档。

首先，我们需要在本地创建一个清晰的项目结构。这一步通常在终端手动完成，或者直接指导 Claude 创建。

目录结构规划：

 llm-wiki-project/ ├── 01_raw_sources/ # 原始文档存放区 ├── 02_wiki/ # 编译后的 Wiki 页面 ├── 03_logs/ # 变更日志与冲突报告 └── .claude/ # Claude Code 项目配置 

你可以直接告诉 Claude：

"请在当前目录创建一个名为 llm-wiki-project 的文件夹，并在其中建立 01_raw_sources、 02_wiki 和 03_logs 三个子目录。"

在不编写代码的情况下，system_prompt 或项目级的 .claude/instructions 文件就是我们的“代码”。我们需要将 Karpathy 提倡的 Schema 规则转化为自然语言指令。

创建 .claude/instructions 文件（或直接在对话中设定）：

 # Role: LLM Wiki 知识编译器 核心目标 将 ` 01_raw_sources` 中的非结构化文档“编译”为 ` 02_wiki` 中的结构化 Markdown 知识库。 操作规范 1. 摄取与编译 - 读取原始文档，提取核心概念、定义和结论。 - 忽略无关的寒暄和广告内容。 - 输出文件必须使用 Markdown 格式，存放在 ` 02_wiki` 目录下。 2. 双向链接 - 识别文档中提到的关键实体（如人名、技术术语、项目名）。 - 如果该实体已有对应的 Wiki 页面，使用 `[[实体名]]` 格式进行链接。 - 如果该实体尚无页面，创建一个新的 Markdown 存根，并在其中定义 `{{stub}}` 标签。 3. 元数据管理 在每个 Wiki 页面顶部添加 YAML Front Matter，格式如下： yaml --- title: "页面标题" status: "stable" # 或 "draft", "stub" source: "来源文档名" last_updated: "YYYY-MM-DD" tags: ["标签1", "标签2"] --- 

4. 冲突检测

在写入知识前，先搜索现有 Wiki。

• 如果发现新知识与现有知识存在明显矛盾（例如对同一概念的定义冲突），不要直接覆盖。
• 相反，请在 03_logs/conflicts.md 中记录冲突详情，并在原 Wiki 页面底部添加 标签引用该日志。

  这段 Prompt 充当了“宪法”的角色，替代了传统开发中的硬编码逻辑。 4. 实战流程：从摄入到演化 4.1 知识摄入 假设你有一篇关于“RAG 检索优化”的论文 PDF 存放在 ` 01_raw_sources` 中。 指令示例： > "请阅读 ` 01_raw_sources/rag_optimization.pdf`，根据项目指令将其编译为 Wiki 页面。请确保提取出所有关键技术术语，并检查是否与 ` 02_wiki` 中的现有页面（如 'RAG', 'Vector Database'）存在关联。" Claude 的执行逻辑： 1. 解析：Claude 会利用其内置的 PDF 读取能力解析文档。 2. 实体识别：识别出 "Hybrid Search", "Re-ranking", "Chunking Strategy" 等术语。 3. 链接与创建： * 发现 ` 02_wiki/RAG.md` 已存在，生成链接 `[[RAG]]`。 * 发现没有 "Re-ranking" 页面，自动创建 ` 02_wiki/Re-ranking.md` 并写入基础定义。 4. 写入：生成符合 YAML 规范的 Markdown 文件。 4.2 知识查询与推理 由于是 Wiki 模式，查询不再是简单的向量匹配，而是基于链接图谱的推理。 指令示例： > "我想了解 RAG 系统中的检索优化手段。请阅读 ` 02_wiki/RAG.md` 以及所有被它链接的子页面（如 `[[Hybrid Search]]`），结合这些信息为我总结一套优化方案。" Claude 会像人类浏览维基百科一样，顺着链接跳转阅读，综合多个页面的信息生成答案，这比单纯的 RAG 检索具有更强的上下文连贯性。 4.3 维护与冲突解决 这是 LLM Wiki 的精髓所在。当你摄入了一篇新论文，其中提到 "Dense Retrieval 效果远优于 Sparse Retrieval"，而你之前的 Wiki 中写着 "Sparse Retrieval 在特定场景下不可替代"。 指令示例： > "请检查新摄入的知识与现有 Wiki 之间是否存在定义冲突，如果有，请更新冲突日志。" Claude 会自动： 1. 对比语义差异。 2. 在 ` 03_logs/conflicts.md` 生成记录： markdown 2023-10-27: Retrieval Effectiveness Conflict - Source: `new_paper.pdf` - Conflict: Claims Dense Retrieval is always superior. - Existing: `Sparse_Retrieval.md` argues for its necessity in exact matching. - Resolution: Pending human review. 3. 更新相关页面底部的状态标签。 5. 进阶技巧：利用 Claude Code 的 MCP 工具 虽然我们限制“不写代码”，但 Claude Code 支持 MCP (Model Context Protocol) 工具。我们可以配置现成的 MCP 工具来增强 Wiki 能力，而无需自己编写工具逻辑。 例如，配置一个 `filesystem` MCP 工具（通常内置），让 Claude 能更高效地批量处理文件。 批量初始化指令： > "使用文件系统工具，扫描 ` 01_raw_sources` 目录下所有的 `.txt` 文件，对每个文件执行一次编译任务，将结果存入 ` 02_wiki`，并以文件名作为 Wiki 标题。" 这相当于一行命令完成了整个 ETL 管道的运行。 6. 总结 通过 Claude Code 搭建 Karpathy 风格的 LLM Wiki，关键在于思维模式的转变： 1. Prompt 即代码：精心设计的 `system_prompt` 比任何 Python 脚本都更重要。 2. 文件系统即数据库：利用 Markdown 文件和文件夹结构来组织知识，而不是黑盒的向量数据库。 3. Agent 即运维：让 Claude 承担代码审查、冲突检测和格式整理的工作。 这种方式不仅降低了技术门槛，更重要的是，它保留了 Wiki 的透明度和可解释性。你的知识库不再是不可知的“黑盒”，而是一本由 AI 助手共同维护、随时可读、随时可改的“活书”。 ---- 参考来源 - [RAG已死！karpathy说：LLM Wiki永生](https://blog.csdn.net/python_cocola/article/details/) - [Karpathy 的 LLM Wiki，可能改变了知识管理这件事](https://blog.csdn.net/fzuim/article/details/) - [你花了几个月搭的 RAG 知识库，可能从一开始方向就错了：Karpathy 的 LLM Wiki 模式全解析](https://blog.csdn.net/m0_/article/details/) - [用LLM Wiki构建个人知识库](https://blog.csdn.net/shebao3333/article/details/) - [利用AI祖师爷Karpathy的理念——零代码构建个人AI知识库](https://blog.csdn.net/lxwalaz1s1s/article/details/) - [深入分析Karpathy 推荐的知识管理的LLM-Wiki方式在Claude Code +Graphify中如何实现](https://blog.csdn.net/zhu0/article/details/)