我的知识库有上千个文件，涵盖多个品牌的内容资产、数十条工作流、大量命令行工具（CLI）的配置——Claude Code 能在 3 秒内精确定位到任何一个文件，不用向量数据库，不用检索增强生成（RAG）管线，靠的是纯文件系统加一套项目记忆文件（CLAUDE.md）多级路由。

这篇文章拆解这套方案的完整设计。你读完就能从零搭一个同款知识库，让 AI Agent 像翻目录一样找到它需要的一切。

如果你还不了解 CLAUDE.md 是什么，建议先看 CLAUDE.md 怎么写？项目记忆文件新手指南。如果你已经在用 Claude Code 但还没系统配置过，可以先看 Claude Code 最佳实践 了解六大模块的配置方法。

一、为什么不用向量数据库

先回答最多人问的问题：到现在了，为什么不直接上 RAG？

答案很直接——对 AI 编程 Agent 的工作场景来说，向量数据库解决的不是我的问题。

RAG 管线的核心假设是：你有一大堆非结构化文本，需要用语义相似度从中捞出相关片段喂给大模型。这个假设在客服知识库、法律文档检索、海量论文查询的场景下完全成立。

但 AI Agent 的知识库不一样。它有四个特征，让文件系统方案的优势碾压 RAG：

结构化程度高——每个文件有明确职责，放在哪个目录、叫什么名字、管什么事情都是确定的。不需要用嵌入向量（embedding）去猜测文件之间的语义关系。

访问模式确定——Agent 要么按触发词路由到目标文件，要么按工作流步骤顺序读取。不存在「我也不知道在哪，帮我模糊搜一下」的场景。

精度要求极高——Agent 取到错误的文件会直接执行错误的操作。RAG 的召回率 80% 在聊天机器人上可以接受，在 Agent 工作流里是灾难——每 5 次有 1 次取错文件，意味着每 5 次有 1 次执行错误的工作流。

迁移审计零成本——文件就是正本。用 cat 能读、用 rg 能搜、用 git 能追踪版本。向量数据库的 embedding 是黑箱，换个嵌入模型全部要重建索引。

💡 通俗讲：向量数据库像百度——你输入关键词，它给你「可能相关」的结果，你得自己判断哪个对。CLAUDE.md 路由像一本书的目录——你知道要找什么，它告诉你在第几章第几节，翻过去就是。

这不是我一个人的判断。MindStudio 的调研指出，Claude Code、Cursor、Devin 这些当前最活跃的 AI 编程 Agent 都没有用向量数据库来理解代码库——它们用的是 grep。VentureBeat 的多篇分析也指出，RAG 架构在 Agent 规模下表现不佳，独立向量数据库正在失去份额。当然，这些观点针对的是代码导航场景。对于海量非结构化文档的语义检索，RAG 仍然是正确选择。但对于「个人工作流知识库」的规模和结构，文件系统方案的精度和可维护性碾压。

和 Karpathy 的 LLM Wiki 的关系

Andrej Karpathy 提出了 LLM Wiki 模式——用结构化 Markdown 文件组成一个 AI 可维护的个人知识库。他在一份公开的 gist 中描述了核心思想：不在查询时从原始文档做检索，而是让 LLM 持续构建和维护一组结构化、互相链接的 Markdown 文件。这组文件处于用户和原始资料之间，形成三层架构：源材料输入层、LLM 维护的 wiki 层、CLAUDE.md 行为协议层。

我的方案和它有血缘关系，但走得更远：

Karpathy 的方案适合「个人笔记整理」场景。当知识库需要承载多品牌运营、多工作流编排、多 Agent 协同时，单层 CLAUDE.md 撑不住——你需要多级路由和治理机制。

不这么做会怎样

没有路由系统的知识库，Agent 只能暴力搜索。上千个文件挨个扫一遍，上下文窗口瞬间被撑爆。更常见的后果是——Agent 搜到了一个名字看起来像的文件，但其实不是它要的，然后用错误的内容执行了后续操作。你以为 Agent 在认真工作，实际上它在用三个月前过期的规范写你今天的文章。

🎯 实战提示词

评估你的知识库该用哪种方案：

分析我当前项目的文件结构。统计文件总数、文件类型分布（Markdown / JSON / 配置文件 / 其他）、目录层级深度。然后判断：我的场景更适合纯文件系统 + CLAUDE.md 路由，还是 RAG + 向量数据库？给出判断依据和推荐方案。

→ 深入阅读：Agent 知识库与 AI 写作 · CLAUDE.md 最佳实践

整个方案的核心架构就是一句话：用链式 CLAUDE.md 文件构建一棵导航树，Agent 从根节点出发、按触发词逐级深入、最多 3 跳到达目标。

六层路由架构（L0-L5）

Agent 的寻路过程是这样的：用户说「写一篇官网文章」，Agent 先读 L1 根 CLAUDE.md，在触发词表中命中「官网文章发布」，跳转到工作流目录下的 L2 CLAUDE.md，获得完整执行路径和子工作流列表，然后开始执行。

整个过程确定性 100%。不依赖语义相似度，不存在「召回了错误文档」的可能。

为什么六层而不是两层

你可能会问：为什么不把所有路由信息都写在根 CLAUDE.md 里？

因为上下文窗口是有限资源。CLAUDE.md 的每一行都会占用上下文空间。如果你把上千个文件的索引全部平铺在一个文件里，这个文件可能超过 2000 行——Agent 根本记不住，指令遵循度会从 95% 骤降到 65% 以下（社区实测数据，详见 CLAUDE.md 最佳实践）。

六层路由的精髓是按需加载：Agent 只读当前需要的那一层 CLAUDE.md，读完就跳到下一层。上千个文件的索引分散在几十个 CLAUDE.md 里，每个 CLAUDE.md 只管自己这一层的内容，通常不超过 100 行。Agent 处理一次请求平均只需要读 2-3 个 CLAUDE.md 文件，远比把全部索引塞进上下文高效。

L1 根 CLAUDE.md 的结构设计

根 CLAUDE.md 是整个知识库的灵魂，它必须做到两件事：让 Agent 能快速定位目标、让人能快速理解全局。

一个生产级的根 CLAUDE.md 包含这些板块：

1. 行为准则——Agent 的操作规则，比如工具优先、改前读规范、向前演进
2. 工具体系——MCP 服务器（Model Context Protocol，模型上下文协议）列表和本地工具路由表
3. 知识库导航——所有顶层目录的触发词路由表
4. 命令速查——常用 CLI 命令
5. 直读指引——高频内容的绝对路径快速定位

触发词路由表是关键设计。它用三列表格组织：目录名、职责描述、触发词列表。Agent 读到用户的请求后，在这张表里做关键词匹配。匹配成功就跳到对应目录的 L2 CLAUDE.md 继续深入。

🔍 深入一步：触发词不是随便写的。每个触发词必须满足两个条件——唯一性（不和其他目录的触发词冲突）和覆盖性（用户可能的所有自然表达都要覆盖）。实际操作是：每次 Agent 走错了路由，就回来补一个触发词。运行半年后，触发词表从最初的 20 个增长到了数百个。

直读指引：跳过路由的快车道

对于高频访问的内容，逐级路由反而慢了。所以根 CLAUDE.md 还有一块「直读指引」——直接给出绝对路径，Agent 一步到位。

直读指引按领域分组，每组是一张「触发词 → 路径」的两列表格。这张表本质上是一个「缓存层」——把最热的路由直接平铺在 L1，省去中间跳转。

不这么做会怎样

没有多级路由的知识库，要么把全部索引堆在一个巨大的 CLAUDE.md 里（Agent 记不住），要么完全没有索引（Agent 只能盲搜）。前者的典型后果是 Agent 越来越经常「忘记」你写过的规则——因为 CLAUDE.md 太长，重要规则被淹没在大量索引信息里。后者的典型后果是 Agent 花 30 秒搜文件，搜到的还可能是错的。

🎯 实战提示词

为现有项目生成 CLAUDE.md 路由：

扫描我当前项目的目录结构，生成一套 CLAUDE.md 多级路由系统。要求：（1）根 CLAUDE.md 包含行为准则、目录导航（三列表：目录名/职责/触发词）、直读指引；（2）每个一级目录生成独立的 CLAUDE.md，只写本域内容索引和触发词；（3）触发词覆盖所有可能的自然语言表达。生成后统计总行数，确保根 CLAUDE.md 不超过 300 行。

审计现有路由是否有死链：

读取我的根 CLAUDE.md 和所有子目录 CLAUDE.md。逐条检查：每个触发词指向的路径是否真实存在、每个实际存在的一级目录是否在根 CLAUDE.md 的导航表里有对应条目、是否有多个触发词指向同一个目标（需要去重合并）。输出一份审计报告。

→ 深入阅读：CLAUDE.md 最佳实践 · MCP 最佳实践

三、目录结构设计原则

知识库的目录结构不是随心情建的。它遵循三个原则：职责唯一、边界清晰、正本归位。

职责唯一

每个顶层目录有且只有一个职责。以一个实际生产级知识库为例，常见的分区方式如下：

你不必照搬这八个目录——重要的是分区思想。你的知识库可能只需要四个顶层目录，也可能需要十个。关键是每个目录的职责不能重叠。

文件该放哪里，看归位规则表：

⚠️ 常见踩坑：新手最容易犯的错是「不知道放哪就新建一个目录」。三个月后你会有 20 个模糊目录，Agent 每次都要在其中纠结。正确做法是严守归位表——找不到位置说明你的顶层分类需要调整，而不是加目录。

同构原则

同一层级的目录应该遵循相同的内部结构。以品牌目录为例：品牌/ 下有多个品牌子目录，每个品牌内部都包含相同的子目录——身份（定位、表达风格、介绍）、受众（画像分析）、视觉资产（Logo、头像、封面）、竞品（对标分析）。

所有品牌目录结构完全一致。Agent 学会了一个品牌的路径模式，其他品牌也能直接套用。这就是同构的价值——减少 Agent 的认知负担，让路由逻辑可复用。

收件箱：运行态的唯一入口

收件箱是最容易失控的地方。控制它的规则很简单：

收件箱只处理运行态。什么是运行态？正在跑的任务（调度中台）、正在写的草稿（AI 草稿箱）、正在产出的中间数据（运行数据）、需要交接给下一个 Agent 的上下文（任务交接）、已经结束只需追溯的历史（存档）。

禁止新建中转桶。不许建 待处理/、临时/、待归位/ 这类目录——它们一定会变成垃圾堆。能判断归属的文件直接放到正确位置；不能判断的放收件箱对应区域，但必须在 30 天内清理。

不这么做会怎样

不遵守职责唯一的知识库，三个月后会出现「同一份规范在三个目录各有一份副本」的局面。Agent 读到了工具目录里的旧版规范，用旧规则写了代码，你花 20 分钟排查才发现它没读到规范目录里的新版。这类问题一旦出现就会反复出现，因为你永远记不清哪个副本是最新的。

🎯 实战提示词

审计现有项目的目录结构：

扫描我当前项目的目录结构，检查以下三项：（1）是否有多个目录在做同一件事（职责重叠）；（2）是否有文件放在了不合适的位置（正本归位违规）；（3）是否有空目录或只有一个文件的冗余目录。对每个问题给出具体的重构建议。

生成知识库目录骨架：

我要从零建一个 AI 编程知识库，涵盖以下内容：[列出你的内容类型]。帮我设计顶层目录结构，每个目录写清楚职责和边界。然后为每个顶层目录生成 CLAUDE.md 模板，包含子目录索引、使用边界和触发词。

→ 深入阅读：知识库上云教程

四、从零搭建一个 AI 知识库

下面是完整的建库流程。你按这个顺序走一遍，半天时间能搭出一个可用的知识库骨架。

第一步：建顶层目录

在你的工作根目录下创建顶层目录，按职责分区。然后在工具目录下建几个子目录：CLI 脚本存放处、凭据、最佳实践；在收件箱下建存档和运行数据两个子目录。

目录名用中文。AI Agent 对中文目录名的理解没有任何问题，而中文目录名对人来说可读性远好于英文。需要注意的是，如果你用 Claude Code 的通配符模式（glob）匹配文件，模式字符串（pattern）不支持中文——中文目录段要放在路径参数（path）里，不要放在模式里。

第二步：写根 CLAUDE.md

这是最重要的一步。根 CLAUDE.md 决定了 Agent 怎么理解你的知识库。

根 CLAUDE.md 的结构建议如下：

• 开头用一行引用块标明基础路径
• 行为准则板块列出 Agent 的操作规则，比如「工具优先：先查本地 CLI，禁止跳过直调 MCP」、「改前读规范：修改前先定位对应规范」、「向前演进：直接覆盖正确做法，不向后兼容」
• 知识库导航板块用三列表格（目录、职责、触发词）列出每个顶层目录的路由关系
• 直读指引板块用两列表格（触发词、路径）列出高频内容的快速跳转
• 变更记录放最后，保留最近 10 条

写根 CLAUDE.md 有几个铁律：

1. 行为准则放最前面——Agent 启动时先读行为规则，再读内容索引
2. 触发词表覆盖自然表达——用户可能说的话都要能匹配到
3. 直读指引只放高频内容——不是所有路径都要平铺，否则太长
4. 根 CLAUDE.md 不超过 300 行——超过了 Agent 的指令遵循度会显著下降

第三步：写子目录 CLAUDE.md

每个一级目录写一个 CLAUDE.md，格式统一。包含四个板块：

1. 标题 + 一句话定位——用引用块标明这个目录是干什么的
2. 子目录索引——用三列表格（子目录、定位、触发词）列出下辖的所有子目录
3. 使用边界——明确声明本目录做什么、不做什么
4. 变更记录——滚动窗口保留最近 10 条

关键点：每个 CLAUDE.md 只管自己这一层。不要在品牌目录的 CLAUDE.md 里写工具使用方法——那是工具目录的事。

第四步：建规范入口

规范目录是知识库的「宪法」——它不直接产出内容，但约束所有内容的质量。

初始阶段不需要太多规范。建议从这三个开始：

1. Markdown 编写规范——统一格式，Agent 生成的内容不会乱
2. 文件编写规范——文件命名、变更记录格式
3. CLAUDE.md 编写规范——路由文件本身的标准

第五步：配置凭据

API 密钥和令牌（Token）不能硬编码在文件里。在工具目录下建一个凭据目录，分为两区：「通用」存放可跨机同步的凭据，「敏感」存放仅本机保留的凭据。

Agent 通过凭据解析器（credential resolver）读取密钥，而不是直接从文件内容中提取。这样知识库可以安全地同步到其他设备，密钥不会被散播。

第六步：配置本地 CLI 并跑审计

知识库不是搭完就不管了。你需要一个命令行工具做日常维护。核心命令有四类：

• 检索——按关键词搜索全库文件
• 结构审计——检查每个目录是否有 CLAUDE.md、是否遵循同构原则
• 文档审计——检查 CLAUDE.md 索引是否与实际文件一致，有无死链
• 冗余审计——找出重复或过时的文件

第一次跑审计很可能发现一堆问题——目录没有 CLAUDE.md、文件放错位置、变更记录过期。修完它们，知识库就进入可用状态了。

🔍 深入一步：CLI 做确定性动作——检索、审计、归档、凭据管理。判断逻辑不放进 CLI。比如「这个文件应该归档到哪里」是 Agent 的判断，CLI 只负责执行归档命令把文件移到指定位置。这条边界很重要：CLI 是工具不是大脑。

🎯 实战提示词

一键生成知识库骨架：

帮我在 ~/knowledge-base/ 下从零搭建一个 AI 知识库。按以下步骤执行：（1）创建 8 个顶层目录：品牌、工作流、工具、业务、研究、规范、生活、收件箱；（2）在工具/ 下创建 app/、凭据/通用/、凭据/敏感/、最佳实践/ 四个子目录；（3）在收件箱/ 下创建 存档/、运行数据/ 两个子目录；（4）为根目录和每个一级目录各写一个 CLAUDE.md，根 CLAUDE.md 包含行为准则和触发词路由表，子目录 CLAUDE.md 包含索引和边界声明。完成后跑一次结构审计，确认所有目录都有 CLAUDE.md。

把现有散乱文件整理成知识库：

我在 ~/projects/notes/ 下有 200 多个散乱的 Markdown 文件。帮我做以下整理：（1）扫描所有文件，按内容主题自动分类到合适的目录；（2）为每个新目录写 CLAUDE.md；（3）生成根 CLAUDE.md 的触发词路由表；（4）列出无法自动分类的文件，等我手动决定。

→ 深入阅读：Claude Code 最佳实践 · 知识库上云教程

五、知识库运维与审计

搭完骨架只是开始。知识库是活的——每天有新文件产生、旧文件过期、路由需要更新。运维是持续动作。

日常维护循环

每次修改文件后的标准流程：

1. 先读根 CLAUDE.md 和目标目录最近的 CLAUDE.md
2. 按规范定位对应编写标准
3. 修改正文或工具
4. 同步上下游 CLAUDE.md——新增/删除文件后必须更新索引
5. 跑对应 CLI 自验
6. 用 rg 回扫旧口径——确保没有过期引用

第 4 步是最容易遗漏的。你新建了一个工作流但忘了在根 CLAUDE.md 的触发词表里加一条——结果 Agent 永远找不到它。

审计机制

三种审计覆盖三类问题：

审计发现的问题按优先级处理：结构问题（缺 CLAUDE.md）当天修、文档问题（索引不一致）三天内修、冗余问题（过时内容）攒一批统一归档。

归档分层

文件不是越多越好。活跃知识库里只保留「当前还在用」的东西：

归档不是删除。归档后在原位置留一个指针（CLAUDE.md 写明「已归档到 XX 位置」），Agent 需要时可以追溯。

⚠️ 常见踩坑：把大体量书籍（PDF、epub）直接扔在知识库活跃路径里。一本 50MB 的 PDF 对 Agent 没有任何用处——它读不了 PDF 原始格式。正确做法是：书籍转成 Markdown 后放研究目录对应话题，原始文件归档到 NAS。

变更记录

每个 CLAUDE.md 末尾都有一个变更记录板块。格式是两列表格（日期、变更内容），采用滚动窗口机制——只保留最近 10 条，每条不超过 20 个字。

这不是 git 日志的替代品。它的作用是让 Agent（和人）快速了解这个区域最近发生了什么——不用翻提交历史（commit history），扫一眼就知道。

不这么做会怎样

没有运维习惯的知识库，半年后的典型症状：根 CLAUDE.md 里有 30 条触发词指向已经不存在的目录，Agent 每次走到死链都会浪费一轮上下文去搜索替代路径。同时有 200 个过期文件占着位置，Agent 的搜索结果被噪音淹没。到了这个阶段，大部分人会选择「推翻重建」——但如果你从一开始就有审计习惯，每周花 10 分钟，根本不会走到这一步。

🎯 实战提示词

一键审计知识库健康度：

对我的知识库做一次全面审计。（1）结构审计：检查每个目录是否有 CLAUDE.md，目录结构是否遵循同构原则；（2）文档审计：逐条验证根 CLAUDE.md 中每个路由条目指向的路径是否存在，找出所有死链；（3）冗余审计：找出内容高度相似的文件对、空目录、超过 6 个月未修改的文件。输出一份带优先级的修复清单。

帮我清理过期内容：

扫描我的知识库，找出所有符合归档条件的文件：（1）超过 6 个月未修改且不在任何 CLAUDE.md 索引中引用；（2）文件名包含"旧""备份""临时"等关键词；（3）大于 10MB 的非 Markdown 文件。列出清单后，等我确认再执行归档。

→ 深入阅读：CLAUDE.md 最佳实践 · Agent 知识库与 AI 写作

六、规模化：从 10 文件到 1000+ 文件

知识库的治理方式随规模变化。10 个文件和 1000 个文件面对的问题完全不同。

10-50 文件：种子期

这个阶段不需要复杂治理。做好三件事：根 CLAUDE.md 写清楚、每个目录有 CLAUDE.md、文件命名一致。不要过度设计——很多人在只有 20 个文件的时候就搭了五层路由，这是浪费时间。

50-200 文件：成长期

开始出现「找不到文件」的问题。解法：

• 给高频内容加直读指引（直接平铺路径到根 CLAUDE.md）
• 建 CLI 做检索（关键词搜索全库）
• 开始写规范约束新增文件的格式

200-500 文件：治理期

需要引入正式的运维机制：

• 定期审计（结构 + 文档 + 冗余）
• 归档规则落地——不用的东西必须归档
• 触发词表膨胀——需要做去重和合并
• 变更记录强制——没有记录的改动等于没发生

500-1000+ 文件：稳态期

到了这个规模，单纯靠人维护 CLAUDE.md 已经不现实。需要：

• CLI 辅助同步——文件变动后自动检查关联索引是否更新
• 多级路由严格分层——L3 以下的路由不再出现在 L1
• 活跃文件数量控制——通过归档把活跃文件控制在合理范围内
• 分区授权——不同工作流只读自己需要的区域，不读全库

🔍 深入一步：1000 文件听起来很多，但实际上知识库的「热区」通常只有 200-300 个文件——Agent 日常访问的主要是工作流、工具配置和当前项目的业务文件。另外大量文件是研究素材、归档历史、低频规范，Agent 很少主动触达。控制热区文件的质量，比管好全部 1000 个文件更重要。

和 RAG 方案的深度对比

为了让对比公平，把两种方案放在同一个评估框架里：

混合方案：实际上两者不冲突。在「结构化导航」层用文件系统 + CLAUDE.md 路由，在「全文检索」层用本地 CLI 的关键词搜索。如果未来规模突破 2000 文件，可以在 CLI 层加一个轻量向量索引作为补充——但路由主干仍然是 CLAUDE.md。关键是路由和检索分离，两者互不依赖，哪个坏了另一个还能工作。

🎯 实战提示词

评估知识库当前规模和健康度：

统计我的知识库的以下指标：（1）文件总数和各目录文件数分布；（2）CLAUDE.md 文件总数 vs 一级目录总数（覆盖率）；（3）根 CLAUDE.md 的行数和触发词数量；（4）最近 30 天新增、修改、删除的文件数。根据这些数据判断我的知识库处于种子期/成长期/治理期/稳态期哪个阶段，给出对应的治理建议。

制定归档策略：

扫描我的知识库，按以下规则识别归档候选：超过 6 个月未修改的文件、不在任何 CLAUDE.md 索引中引用的文件、大于 50MB 的非文本文件。按「小型留收件箱/存档、大体量送 NAS」的规则生成归档计划，估算归档后活跃文件数。

→ 深入阅读：Claude Code 最佳实践 · MCP 最佳实践

设计哲学

回到最底层的设计选择。这些原则不是拍脑袋定的——每一条都来自踩坑。

文件即正本——不存在「数据库里有一份、文件系统里有一份」的双写问题。Agent 读什么、人读什么、同步什么、备份什么，都是同一个文件。双写问题一旦出现，你就会花无穷的时间在「哪个版本是对的」上面。

路由即文档——CLAUDE.md 既是 Agent 的导航系统，也是人的文档。你打开任何一个 CLAUDE.md，不需要启动 Agent 就能理解这个目录下有什么、怎么用。如果你的索引系统只有 AI 能读懂、人看不懂，那这个系统的每次故障都需要 AI 来排查——这是把自己锁进了对工具的依赖。

确定性胜过智能——CLI 做审计不用 AI 判断。归档命令不猜你想归到哪——你必须明确指定。路由靠关键词匹配不靠语义推断。在执行层面，确定性比智能更可靠。

人管结构，Agent 管内容——目录怎么建、CLAUDE.md 怎么写、触发词怎么定——这是人的决策。但在这个结构内部填充什么内容、生成什么产物、按什么工作流执行——这是 Agent 的工作。

归档是第一等公民——信息的默认归宿是「归档」而不是「永久保留」。只有正在用的东西才留在活跃区。这条原则让知识库不会无限膨胀。

实操清单

如果你现在就想开始，按这个清单做：

第一天：

• [ ] 建顶层目录（按你的实际需求决定几个）
• [ ] 写根 CLAUDE.md（行为准则 + 触发词路由表）
• [ ] 写每个一级目录的 CLAUDE.md

第一周：

• [ ] 把散落各处的文件归位到正确目录
• [ ] 写 2-3 条核心规范（Markdown、文件命名、CLAUDE.md 格式）
• [ ] 配置凭据目录
• [ ] 用 Claude Code 对话测试——它能不能找到你放的文件

第一个月：

• [ ] 搭建本地 CLI（至少做检索和归档两个命令）
• [ ] 建立周审计习惯
• [ ] 补全直读指引（把高频路径平铺到根 CLAUDE.md）
• [ ] 写第一条工作流并验证 Agent 能跑通

持续：

• [ ] 每次新增文件后同步 CLAUDE.md
• [ ] 每月清理一次归档
• [ ] 每季度回顾触发词表——去重、合并、补漏

我用这套方案跑了快一年。从最初几十个文件的草台班子，到现在上千个文件的生产级知识库，中间经历了数次大重构、无数次路由优化、反复推翻又重建的目录设计。

我的判断是：对于个人或小团队的 AI 编程工作场景，纯文件系统 + CLAUDE.md 路由是当前最实用的知识库方案。它不是最酷的方案——没有向量数据库那种「语义检索」的科技感。但它是最可控的方案——你能看清每一步路由逻辑，能用 cat 读每一个文件，能用 rg 搜全库。

当工具足够简单时，复杂性才不会反噬你。

获取完整建库模板

本文介绍的知识库方案——CLAUDE.md 多级路由模板、顶层目录结构、审计 CLI 工具、归档脚本——都有可直接复制的完整模板和工具代码，收录在翔宇的 AI 编程实操课中。

👉 查看 AI 编程实操课完整目录

延伸阅读

• Claude Code 最佳实践——CLAUDE.md、MCP、Hooks、Skills、子代理、上下文管理六大模块配置指南
• CLAUDE.md 最佳实践——Karpathy 四原则 + 分层设计 + 完整模板
• MCP 最佳实践——工具连接的配置、密钥管理和性能调优
• Agent 知识库与 AI 写作——知识库如何驱动 AI 写作工作流
• 知识库上云教程——多设备同步和云端备份方案

深入实操：对应课程模块

这篇讲的知识库架构设计，在我的 AI 编程实操课中有对应的完整实战模块——从建目录到写路由到搭 CLI 到跑审计，每一步都有录屏演示和源码。

• 国内版（FlowUS）：查看课程
• 国际版（Buy Me a Coffee）：查看课程

常见问题

知识库必须用 Claude Code 吗？

不必须。CLAUDE.md 路由的核心机制是「结构化 Markdown 导航」，任何能读文件的 AI Agent 都能用——Codex 用 AGENTS.md 是同一思路。只是 Claude Code 对 CLAUDE.md 的原生支持最好。

文件太多 Agent 会不会读不完？

不会。Agent 不是把整个知识库装进上下文窗口——它按路由层级逐步深入，每次只读当前需要的 1-3 个文件。上千个文件的知识库，Agent 处理一次请求平均读 4-6 个文件。

和 Obsidian / Notion 能共存吗？

Obsidian 可以直接打开同一个目录，但双向链接和 CLAUDE.md 路由是两套独立的导航系统，不要混在一起。Notion 不行（Notion 的数据不在本地文件系统）。多设备同步推荐用 Syncthing 或 git。

多人协作怎么办？

用 git。知识库的每个文件都是 Markdown 文本，天然适合 git 版本控制。多人各改各的区域，冲突时合并（merge）就行。如果不用 git，Syncthing 的实时同步 + 版本保留也能覆盖个人多设备场景。