用扁平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.mdivan-petrov.md - 禁止把无关内容塞进同一文件 ## 读取协议 1. 先查本文件确定路径 2. 打开对应.md引用原文作答 3. 找不到就明确说“知识库中无此信息”禁止幻觉 ## 常驻上下文 MEMORY.md decisions.md进阶用法是用路径把核心文件提前挂进agent工作记忆但只对真正需要持续关注的内容使用避免上下文膨胀。命名纪律如何决定系统成败一文件一主题是成败关键。把“税收政策”和“公司组织架构”塞进同一个notes.md就像把盐和糖混在一个罐子里——agent检索时必然出错。文件名直接用主题统一小写连字符消除歧义。agent启动时先吞下CLAUDE.md再根据问题定位文件、解析内容、合成答案并附上引用。信息缺失时它会老实报告而不是编造。你只负责保持结构干净检索交给agent。常见陷阱与落地对照维度复杂笔记App方案扁平Markdown CLAUDE.md方案数据可读性专有格式需插件或导出纯文本任意编辑器与agent直接读取维护成本插件更新、同步冲突、界面学习只需遵守命名与一主题一文件agent检索准确度中间层干扰易幻觉地图明确路径失败时诚实报告迁移与备份依赖软件生态整个文件夹复制即可跨机器零成本上手时间小时级配置与学习五分钟建好骨架边用边填最容易踩的坑一开始就想把所有旧笔记搬进来地图写得过长导致上下文浪费命名不统一导致检索失败。正确做法是先建骨架内容随用随补。从地图到可复用系统的最小实践不需要安装脚本不需要额外软件。任意文本编辑器打开建好三个文件夹和几个根文件写好CLAUDE.md就能立刻开始。如果用Claude Code/init命令还能帮你生成初版地图再人工精简即可。这套架构的真正价值不在于它看起来多“极简”而在于它把知识从App的黑盒里解放出来变成agent随时可导航的本地资产。复杂软件往往高估了可视化带来的效率却低估了中间层给AI带来的摩擦。当你已经有一份干净的CLAUDE.md和语义文件夹后下一步最想优先填充的是notes/、people/还是projects/或者你已经在用类似结构实际遇到过哪些检索失败案例欢迎直接分享。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。 用扁平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.mdivan-petrov.md - 禁止把无关内容塞进同一文件 ## 读取协议 1. 先查本文件确定路径 2. 打开对应.md引用原文作答 3. 找不到就明确说“知识库中无此信息”禁止幻觉 ## 常驻上下文 MEMORY.md decisions.md进阶用法是用路径把核心文件提前挂进agent工作记忆但只对真正需要持续关注的内容使用避免上下文膨胀。命名纪律如何决定系统成败一文件一主题是成败关键。把“税收政策”和“公司组织架构”塞进同一个notes.md就像把盐和糖混在一个罐子里——agent检索时必然出错。文件名直接用主题统一小写连字符消除歧义。agent启动时先吞下CLAUDE.md再根据问题定位文件、解析内容、合成答案并附上引用。信息缺失时它会老实报告而不是编造。你只负责保持结构干净检索交给agent。常见陷阱与落地对照维度复杂笔记App方案扁平Markdown CLAUDE.md方案数据可读性专有格式需插件或导出纯文本任意编辑器与agent直接读取维护成本插件更新、同步冲突、界面学习只需遵守命名与一主题一文件agent检索准确度中间层干扰易幻觉地图明确路径失败时诚实报告迁移与备份依赖软件生态整个文件夹复制即可跨机器零成本上手时间小时级配置与学习五分钟建好骨架边用边填最容易踩的坑一开始就想把所有旧笔记搬进来地图写得过长导致上下文浪费命名不统一导致检索失败。正确做法是先建骨架内容随用随补。从地图到可复用系统的最小实践不需要安装脚本不需要额外软件。任意文本编辑器打开建好三个文件夹和几个根文件写好CLAUDE.md就能立刻开始。如果用Claude Code/init命令还能帮你生成初版地图再人工精简即可。这套架构的真正价值不在于它看起来多“极简”而在于它把知识从App的黑盒里解放出来变成agent随时可导航的本地资产。复杂软件往往高估了可视化带来的效率却低估了中间层给AI带来的摩擦。当你已经有一份干净的CLAUDE.md和语义文件夹后下一步最想优先填充的是notes/、people/还是projects/或者你已经在用类似结构实际遇到过哪些检索失败案例欢迎直接分享。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。 
