1. 为什么你的第二大脑越用越乱：从 Notion 数据库到纯文件夹 AI 知识库
如果你已经用过一段时间 Notion、Obsidian 或 Roam Research，大概率经历过同一个阶段：刚开始很兴奋，数据库、标签、双链、插件全都上，笔记数量一多，维护成本开始指数级上升。最后你不是在思考，而是在给工具打工。
我自己的转折点是把整套知识管理从「人负责组织」切换成「AI 负责组织」。核心结构简单到有点反直觉：三个普通文件夹，加一个 Schema 文件。人只负责往raw/里扔原料，AI 负责把原料编译成wiki/，提问产物落到outputs/。这套结构就是本文要讲的纯文件夹 AI 知识库，它解决的不是「怎么记」，而是「怎么让第二大脑随使用自动进化」。
它适合谁？适合已经有一堆散落笔记、文章剪藏、代码片段，但不想再花时间手动打标签、建双链、写摘要的工程师和知识工作者。你不需要数据库，不需要插件市场，只需要一个本地文件夹和能读取整个项目的 AI 编码工具（Claude Code、Cursor 等）。
先看整体目录树，这是后面所有配置的基础：
second-brain/ ├── CLAUDE.md # Schema 文件，AI 的行为规范 ├── raw/ # 原始素材，只进不改 │ ├── 2025-06-01-karpathy-thread.md │ └── claude-code-notes.md ├── wiki/ # AI 编译后的结构化知识 │ ├── INDEX.md │ └── ai-engineering.md └── outputs/ # 每次提问的产物 └── 2025-06-02-summary.md三个目录分工非常明确。raw/是只读原料区，你从浏览器、剪藏工具、随手记里把东西丢进来，格式不限，Markdown、纯文本、甚至一段粘贴的对话都行。wiki/是 AI 的产出区，所有结构化、带链接、带总结的内容都写在这里，你平时阅读和检索主要看这个目录。outputs/是会话产物区，每次你向 AI 提问、让它做健康检查、生成对比分析，结果都落在这里，形成可追溯的记录。
为什么这种「极简基础设施」反而让 AI 的组织能力被释放？因为复杂工具把组织工作留给了人，而纯文件夹把组织工作完全交给了 AI。AI 读取整个项目没有格式障碍，纯文本对模型最友好，没有数据库 schema 迁移、没有插件 API 限制、没有云同步冲突。你越简单，AI 越能发挥。
这里有个容易踩的坑：很多人一上来就把raw/整理得干干净净，按主题分好子目录。这恰恰违背了设计初衷。raw/的价值在于「零整理输入」，你扔得越随意，AI 编译时越能发现跨领域的隐藏关联。整理是 AI 的活，不是你的活。
理解了结构，下一步就是给 AI 写「宪法」，也就是 Schema 文件。没有它，AI 每次编译的规则都不一样，wiki 会越编越乱。下一节讲怎么配置。
2. TaoToken 前置准备：给 AI 知识库接上稳定的模型调用通道
纯文件夹方案要跑起来，前提是你的 AI 工具能稳定调用模型。Claude Code、Cursor 这类工具本身是客户端，真正干活的是背后的模型 API。如果你直接在各家平台之间来回切换，密钥管理、额度、模型 ID 对不上，编译到一半报错会很影响体验。我自己的做法是统一走一个兼容 Anthropic 接口的通道，把 Base URL、Key、Model ID 三件套固定下来。
TaoToken 在这里扮演的角色就是这层调用通道。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数，配置时直接用这个。
你需要准备的东西只有三样：一个 API Key、一个 Base URL、一个 Model ID。Key 在控制台的 API Keys 页面生成，地址是 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。生成后复制保存，后面配置里要用。
为什么强调「三件套」必须写全？因为 Claude Code、Cline、Codex 这类工具在配置时，如果只填了 Base URL 没填 Model ID，或者 Model ID 写错，最常见的报错就是401或model not found。很多人以为是 Key 失效，其实是 Model ID 对不上。把三件套一次性写对，能省掉大量排查时间。
如果你用的是 Claude Code，它的配置通常通过环境变量或 settings 文件完成。Base URL 指向https://taotoken.net/api，Key 填你生成的那串，Model ID 填你实际要用的模型标识。具体字段名以你所用工具的文档为准，但三件套的逻辑不变。
对于长期做编码和 Agent 任务的场景，可以考虑 Coding Plan，入口是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。它更适合需要持续调用、频繁编译知识库的用法，比按次调用更省心。
配置完成后，先别急着编译整个知识库。用一次最小请求验证通道是否通，比如让模型返回一句固定文本。确认通了，再进入下一节的完整配置。这一步能帮你把「通道问题」和「Schema 问题」分开排查，不然编译失败时你分不清是 API 没通还是规则写错了。
另外提醒一点：知识库项目里不要放任何敏感凭据。Key 放在工具的环境变量或全局配置里，不要写进CLAUDE.md或提交到 Git。纯文件夹方案的一个优势就是纯文本可控，但可控的前提是你自己别把密钥混进知识文件。
通道准备好之后，就可以写 Schema 文件了。这是整个系统最容易被忽略、却最关键的一步。
3. 可复制配置：CLAUDE.md Schema 文件与目录初始化
这一节给你可以直接复制的配置。先建目录，再写 Schema，最后配工具。三步做完，你的纯文件夹 AI 知识库骨架就立起来了。
第一步，初始化目录结构。在本地任意位置建一个项目文件夹，然后创建三个子目录：
mkdir -p second-brain/{raw,wiki,outputs} cd second-brain touch CLAUDE.md第二步，写 Schema 文件。CLAUDE.md放在项目根目录，它是 AI 的行为规范，不是普通提示词。下面这份模板可以直接复制，字段和注释都保留：
# CLAUDE.md - 本知识库的系统指令 ## 知识领域 - 核心主题：AI 工程实践、个人生产力系统、Claude Code 架构 - 禁止混入：纯娱乐内容、未经验证的推测 ## 组织规则 1. 先创建 INDEX.md 作为总入口，按主题分级 2. 每个主要主题生成独立 .md 文件 3. 所有文件使用 [[Wiki链接]] 格式相互引用 4. 每篇文章必须包含：原始来源引用 + AI 总结 + 关键洞察 5. 发现矛盾时，在对应文章末尾添加「争议记录」区块 ## 编译指令 - 读取 raw/ 下所有文件 - 提取实体、关系、主张 - 自动生成主题聚类和交叉链接 - 输出结果全部写入 wiki/ 目录 ## 输出规则 - 每次提问产物写入 outputs/，文件名带日期 - 不修改 raw/ 下任何原始文件这份 Schema 里，知识领域定义边界，防止 AI 把无关内容也编进 wiki。组织规则定义结构和链接格式，保证 wiki 内部一致。编译指令是核心，告诉 AI 从哪读、怎么处理、往哪写。输出规则保证原始素材不被污染，产物可追溯。
第三步，配置工具指向项目。以 Claude Code 为例，进入项目目录后启动，它会自动读取根目录的CLAUDE.md。如果你用的是其他支持项目级指令的工具，把同样的 Schema 放到它约定的文件名即可，比如AGENTS.md。关键是三件套要写全：Base URL 用https://taotoken.net/api，Key 用你在控制台生成的，Model ID 填你实际使用的模型标识。
如果你用 Cline 或带 MCP 的工具，配置片段通常长这样（字段名以工具实际为准）：
{ "mcpServers": { "knowledge-base": { "command": "your-mcp-command", "env": { "BASE_URL": "https://taotoken.net/api", "API_KEY": "你的Key", "MODEL_ID": "你的模型ID" } } } }注意这里 Base URL、Key、Model ID 三件套齐全。任何一项缺失，工具启动时就会报local proxy failed或401。我见过太多人只填了 Key，结果工具默认去连官方地址，自然连不上。
Schema 写好后，不要急着大改。先用它编译一次小样本，看 AI 是否按规则生成了INDEX.md和主题文件。如果生成的结构和你的预期不符，改 Schema，而不是手动去改 wiki。记住：wiki 是 AI 的产出，你改 Schema 才是改源头。
配置阶段还有一个细节：raw/里的文件名尽量带日期或来源，比如2025-06-01-karpathy-thread.md。这不是强制要求，但能让 AI 在生成来源引用时更准确。文件名本身就是一种轻量元数据。
到这里，目录、Schema、工具三件套都齐了。下一节验证一次完整请求，看知识库是否真的会自动归类。
4. 验证请求与成功结果：新增笔记后自动归类与索引更新
配置写完必须验证，否则你不知道 AI 到底有没有按 Schema 干活。这一节用一个具体动作走完整流程：往raw/扔一篇新笔记，让 AI 编译，检查wiki/是否自动归类并更新索引。
先准备一篇测试笔记，扔进raw/：
cat > raw/2025-06-03-agent-memory.md << 'EOF' # Agent 记忆机制笔记 来源：某技术分享 要点： - 短期记忆用上下文窗口 - 长期记忆用外部存储 + 检索 - 记忆压缩是关键难点 EOF然后在项目目录里启动 Claude Code，给它一个明确指令：
读取 raw/ 下所有文件，按 CLAUDE.md 规则编译，更新 wiki/INDEX.md。成功的情况下，你会看到wiki/目录发生变化。INDEX.md里新增了指向新主题文件的链接，同时生成了一个主题文件，比如wiki/agent-engineering.md，里面包含来源引用、AI 总结和关键洞察，并且用[[Wiki链接]]关联到已有的ai-engineering.md。
验证成功的三个信号：
第一，wiki/INDEX.md的条目数增加了，且新条目链接可点。第二，新生成的主题文件里有「原始来源引用」区块，指向raw/2025-06-03-agent-memory.md。第三，如果新笔记和已有主题有交叉，文件里会出现[[...]]链接，而不是孤立内容。
如果 AI 没有生成主题文件，只更新了 INDEX，通常是 Schema 里的「组织规则」不够明确。可以在规则里加一句「每个新主题必须生成独立文件，不允许只更新索引」。如果生成的文件没有来源引用，检查「每篇文章必须包含」那条是否被 AI 忽略，必要时把要求写得更具体。
再验证一次提问产物。让 AI 回答一个问题并把结果写入outputs/：
基于 wiki/ 内容，总结 Agent 记忆的三种方案，结果写入 outputs/2025-06-03-memory-summary.md。成功后outputs/下会出现带日期的文件，内容基于 wiki 而非 raw，说明 AI 是在结构化知识上做推理，而不是重新读原始素材。这正是第二大脑「随使用进化」的体现：每次提问都在已有结构上叠加，而不是从零开始。
验证通过后，你可以做一次健康检查，让 AI 找出 wiki 里的矛盾或缺口：
检查 wiki/ 下所有文件，找出相互矛盾的主张和缺失的主题，结果写入 outputs/。这一步会暴露 Schema 的不足。比如 AI 发现两个文件对同一概念定义不一致，就会在对应文件末尾加「争议记录」区块。你看到这个区块，就知道 Schema 的矛盾处理机制生效了。
整个验证流程走完，你的知识库就从「静态文件夹」变成了「可编译系统」。新增笔记不再需要你手动归类，AI 按 Schema 自动完成。下一节讲这套流程里最常见的报错和排查方法。
5. 本篇常见错排查：401、local proxy failed 与 reading choices 报错
纯文件夹方案跑起来后，报错基本集中在通道和 Schema 两类。这一节按真实报错逐个排查，帮你快速定位。
报错一：401 Unauthorized。最常见的原因是 Key 没填、填错，或者 Base URL 和 Key 不匹配。排查顺序：先确认 Key 是从控制台 API Keys 页面复制的完整字符串，没有多余空格；再确认 Base URL 是https://taotoken.net/api，没有拼错；最后确认 Model ID 是当前账号可用的。三件套任何一项不对，都可能返回 401。如果 Key 刚生成，稍等几秒再试，避免缓存延迟。
报错二：local proxy failed。这个报错通常出现在工具启动阶段，说明工具尝试连接本地代理或默认地址失败。根因往往是 Base URL 没配置，工具回退到了默认端点。解决方法是显式在工具配置里写全 Base URL、Key、Model ID。如果你用的是 Cline 或 MCP 类工具，检查配置文件里的env字段是否三项齐全。缺 Model ID 时，有些工具会报这个错而不是 401，容易误导。
报错三：reading 'choices' of undefined。这是典型的响应结构解析失败。工具期望拿到标准 chat completions 结构，但实际返回的不是。常见原因是 Model ID 写错，请求被路由到了不兼容的端点，或者 Base URL 指向了错误的路径。排查时先确认 Model ID 拼写，再确认 Base URL 没有多加或漏掉路径段。修正后重启工具。
报错四：OAuth 相关错误。如果你用的是 Claude Code 且走了 OAuth 流程，报错通常和登录态有关。检查是否已完成授权，以及配置里是否同时存在 OAuth 和 API Key 两套凭据导致冲突。建议二选一，用 API Key 方式时把 OAuth 相关配置清掉。
报错五：编译后 wiki 为空。这不是通道问题，是 Schema 问题。检查CLAUDE.md里的「编译指令」是否明确写了「读取 raw/ 下所有文件」和「输出结果全部写入 wiki/ 目录」。如果只写了「整理知识」这种模糊描述，AI 可能不知道从哪读、往哪写。把输入输出路径写死，问题基本解决。
报错六：raw/ 文件被修改。说明 Schema 里没有禁止修改原始素材。在CLAUDE.md里加一条「不修改 raw/ 下任何原始文件」，并放在显眼位置。原始素材只进不改，是这套系统的底线。
排查时有个通用方法：把「通道问题」和「Schema 问题」分开。先用一次最小请求验证通道，比如让模型返回固定文本。通道通了，再编译知识库。这样报错时你能立刻判断是哪一层的问题，不用在两者之间反复猜。
如果排查后确认是通道配置问题，去 API Keys 页面重新生成 Key 并核对三件套，地址是 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。接入细节可以参考接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。验证模型是否正常，可以用模型对话页面 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 发一条测试消息。
6. 让第二大脑持续进化：从一次性编译到日常闭环
配置和验证都通过后，真正决定这套系统价值的是日常使用方式。纯文件夹 AI 知识库不是搭完就结束，而是每次使用都在给 wiki 叠加结构。这一节讲怎么把它变成习惯。
日常动作只有两个：往raw/扔东西，向 AI 提问。扔东西不需要整理，看到有用的文章、代码片段、对话记录，直接存成 Markdown 丢进raw/。提问时让 AI 基于wiki/回答，产物落outputs/。你不需要手动维护任何链接，AI 按 Schema 处理。
每周做一次健康检查，让 AI 扫描 wiki 找矛盾和缺口。这一步是「自动进化」的关键。随着 raw 增多，wiki 会自然生长出新的主题聚类，AI 会在检查中发现之前没注意到的关联。你只需要看outputs/里的检查报告，决定要不要调整 Schema。
Schema 不是一次写死的。用一段时间后，你会发现某些规则太松或太紧。比如 AI 生成的总结太短，就在 Schema 里加「每篇总结不少于 200 字」。发现主题分得太碎，就加「相似主题合并到同一文件」。Schema 是你和 AI 之间的契约，随使用迭代。
对于长期、高频的编码和 Agent 任务，Coding Plan 更适合持续调用场景，入口是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。它让你不用每次担心额度，专注在知识库的持续编译上。
最后说一个我自己的经验：不要试图一次性把过去所有笔记都编译完。先扔十篇，跑通流程，确认 Schema 符合你的预期，再逐步增加。知识库的价值在于持续使用，不在于一次建多大。你每扔一篇、每问一次，第二大脑就进化一点，这才是纯文件夹方案真正的复利所在。