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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数配置时直接用这个。你需要准备的东西只有三样一个 API Key、一个 Base URL、一个 Model ID。Key 在控制台的 API Keys 页面生成地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。生成后复制保存后面配置里要用。为什么强调「三件套」必须写全因为 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/apiKey 填你生成的那串Model ID 填你实际要用的模型标识。具体字段名以你所用工具的文档为准但三件套的逻辑不变。对于长期做编码和 Agent 任务的场景可以考虑 Coding Plan入口是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它更适合需要持续调用、频繁编译知识库的用法比按次调用更省心。配置完成后先别急着编译整个知识库。用一次最小请求验证通道是否通比如让模型返回一句固定文本。确认通了再进入下一节的完整配置。这一步能帮你把「通道问题」和「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/apiKey 用你在控制台生成的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_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入细节可以参考接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。验证模型是否正常可以用模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 发一条测试消息。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_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它让你不用每次担心额度专注在知识库的持续编译上。最后说一个我自己的经验不要试图一次性把过去所有笔记都编译完。先扔十篇跑通流程确认 Schema 符合你的预期再逐步增加。知识库的价值在于持续使用不在于一次建多大。你每扔一篇、每问一次第二大脑就进化一点这才是纯文件夹方案真正的复利所在。