用扁平Markdown与CLAUDE.md搭建AI原生第二大脑的完整路径

打开Obsidian或Notion准备整理知识时，最常见的卡点不是内容本身，而是格式壁垒：专有链接、嵌套数据库、插件依赖，直接让AI agent读起来像隔着一层毛玻璃。真正需要的，往往只是一堆普通文本文件，再加一份告诉agent“去哪里找”的地图。

我起初也觉得“第二大脑”必须配上可视化图谱和双向链接，后来实际把知识交给Claude Code这类能直接读目录的agent后才发现：复杂App反而成了中间层，增加摩擦。扁平Markdown文件夹加上根目录的CLAUDE.md，才是让agent像本地同事一样工作的最低成本方案。

为什么扁平文件比笔记App更适合AI agent

笔记软件的本能是把信息锁进自己的格式和界面。Agent最擅长的，却是直接打开磁盘上的纯文本。就像把食材从密封保鲜盒里倒出来，直接摆在开放台面上——agent不用猜包装规则，人也能随时用任意编辑器改。

核心原则只有一条：一个主题对应一个文件。notes/里放事实与专题，people/里放联系人卡片，projects/里放项目进度。根目录再放MEMORY.md（长期核心信息）、LEARNINGS.md（经验教训）、decisions.md（决策日志）。没有嵌套数据库，没有专有链接，只有标准Markdown标题和列表。

语义文件夹如何构成可导航骨架

目录本身就是语义导航：

• notes/：学到的事实，按主题拆文件
• people/：一个人或公司一张卡片，含会议纪要与关键细节
• projects/：当前状态、卡点、下一步

根目录元数据文件补充长期记忆。这套结构覆盖绝大多数个人与小团队场景，扩展时只在某个主题大到值得独立子目录时再拆。

CLAUDE.md就是这套骨架的神经系统。它放在根目录，告诉agent文件夹含义、命名约定、读取协议。对Claude Code来说，这个文件会在每次会话启动时自动载入系统上下文，无需额外提示。

示例地图文件（重构后更精简、可直接落地）：

# 项目知识地图（CLAUDE.md）

## 目录结构
- notes/：主题事实，一文件一主题
- people/：联系人与会议纪要
- projects/：项目状态与下一步

## 命名规则
- 全部小写 + 连字符
- 文件名即主题（tax-policy.md，ivan-petrov.md）
- 禁止把无关内容塞进同一文件

## 读取协议
1. 先查本文件确定路径
2. 打开对应.md，引用原文作答
3. 找不到就明确说“知识库中无此信息”，禁止幻觉

## 常驻上下文
@MEMORY.md
@decisions.md

进阶用法是用@路径把核心文件提前挂进agent工作记忆，但只对真正需要持续关注的内容使用，避免上下文膨胀。

命名纪律如何决定系统成败

一文件一主题是成败关键。把“税收政策”和“公司组织架构”塞进同一个notes.md，就像把盐和糖混在一个罐子里——agent检索时必然出错。文件名直接用主题，统一小写连字符，消除歧义。

agent启动时先吞下CLAUDE.md，再根据问题定位文件、解析内容、合成答案并附上引用。信息缺失时它会老实报告，而不是编造。你只负责保持结构干净，检索交给agent。

常见陷阱与落地对照

最容易踩的坑：一开始就想把所有旧笔记搬进来；地图写得过长导致上下文浪费；命名不统一导致检索失败。正确做法是先建骨架，内容随用随补。

从地图到可复用系统的最小实践

不需要安装脚本，不需要额外软件。任意文本编辑器打开，建好三个文件夹和几个根文件，写好CLAUDE.md，就能立刻开始。如果用Claude Code，/init命令还能帮你生成初版地图，再人工精简即可。

这套架构的真正价值，不在于它看起来多“极简”，而在于它把知识从App的黑盒里解放出来，变成agent随时可导航的本地资产。复杂软件往往高估了可视化带来的效率，却低估了中间层给AI带来的摩擦。

当你已经有一份干净的CLAUDE.md和语义文件夹后，下一步最想优先填充的是notes/、people/还是projects/？或者你已经在用类似结构，实际遇到过哪些检索失败案例？欢迎直接分享。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。