1. 为什么 Obsidian 笔记一多就失控如果你用 Obsidian 超过三个月大概率经历过这个阶段刚开始疯狂记觉得终于找到了第二大脑记到两三百篇之后打开文件列表一片混乱想找一篇之前写过的内容只能靠搜索关键词碰运气。笔记是有了但找不到、用不上、也不想再翻。我自己的 Vault 就长期停在这个状态。表面看目录挺整齐实际上有三个致命问题有分类但没有进入路径有标签但没有检索维度有积累但没有复习机制。说白了它更像一个堆满文件的仓库而不是一套能运转的知识系统。真正让我下决心重构的是某次要写一篇关于网络自动化的文章我明明记得半年前记过相关笔记结果翻了二十分钟没找到最后重新写了一遍。那一刻我意识到问题不在笔记数量而在于我从来没有设计过「知识如何被放进去、如何被找到、如何被复习、如何长期维护」。这篇文章我会把整个重构过程拆开讲先讲清楚结构设计思路再给出可复制的 Codex 提示词骨架和 Obsidian 配置片段最后用整理前后的对比动作验证效果。适合已经有一定笔记量、但结构开始失控的 Obsidian 用户也适合想把知识库真正用起来、而不是只当收藏夹的人。2. 重构前先想清楚目录不是用来好看的我一开始最大的误区是把 Obsidian 当成「高级文件夹」用。每记一篇笔记先纠结放哪个目录、要不要新建文件夹、文件名要不要加编号。结果就是目录越建越多层级越来越深但找东西反而更慢。后来我换了一个判断标准目录不是为了看起来整齐而是为了降低未来复习、归类和扩展的成本。围绕这个标准我先问自己四个问题我以后会从哪里进入这批内容这些内容是按主题查还是按顺序学哪些是长期领域哪些只是一次性专题新文章进来时有没有稳定的归档规则这四个问题想清楚之后顶层结构其实就定下来了。我最终采用的 Vault 结构是00-总览 10-收件箱 20-领域 30-资源库 90-归档 99-模板每一层的职责必须明确否则又会退化成普通文件夹。我的定义是这样的目录职责放什么不放什么00-总览控制台知识地图、复习面板、最近更新、录入流程正式内容10-收件箱暂存区灵感、草稿、未整理片段已成型文章20-领域长期入口领域页指向资源库正文30-资源库沉淀主体专题、系列、MOC临时想法90-归档历史区过时、被替代内容活跃内容99-模板规则层文章、系列、知识地图、收件箱模板具体笔记这里有个关键点20-领域 只放入口页不直接放正文。正文全部进 30-资源库按领域再分层。这样领域页就变成了「长期认知主线」的入口而不是又一个文件夹。3. 用 Codex 重构知识库的提示词骨架结构想清楚之后真正耗意志力的是执行几百篇笔记要迁移、要补元数据、要统一标题、要维护索引页。这部分我交给 Codex 来做但前提是提示词要写清楚规则否则它只会给你一堆看起来合理、实际不可维护的建议。我用的提示词骨架分四段角色与目标、结构规则、命名与元数据规则、输出要求。下面是可以直接复制的版本你按自己的领域替换即可。你是一名知识库结构工程师帮我重构一个 Obsidian Vault。 【目标】 把散乱笔记收敛为可维护的知识系统重点解决进入路径、检索维度、复习机制、长期扩展。 【顶层结构】 00-总览 / 10-收件箱 / 20-领域 / 30-资源库 / 90-归档 / 99-模板 20-领域只放入口页正文全部进 30-资源库。 【资源库分层】 30-资源库/领域/ 00-MOC/ 10-专题/ 20-系列/ 内容量大时领域内可继续加模块层例如 10-基础设施 / 20-网络 / 30-运维 / 40-云计算 【领域、专题、系列判断】 领域 长期认知主线不是工具名、不是单一项目名。 专题 能单篇独立读懂的文章。 系列 必须按顺序看才更有价值的内容文件名带 01-、02- 顺序号。 【命名规则】 独立文章自然标题不强制编号。 系列文章01-标题.md、02-标题.md。 【frontmatter 字段】 title / domain / type / status / series / order / created / updated / next_review / tags 【标签规则】 只用四个前缀领域/、模块/、主题/、系统/ 标签只做补充检索维度不替代目录。 【输出要求】 1. 给出重构后的目录树。 2. 对每篇待迁移文章输出目标路径、type、domain、series、order。 3. 标出需要新建的领域页、MOC、系列页。 4. 不确定的项单独列出不要编造。这段提示词的核心是「规则前置」。你先把判断标准写死Codex 才不会自由发挥。我实测下来规则写得越具体它给出的迁移方案越稳定返工越少。4. 可复制的 Obsidian 配置片段结构定好之后需要让 Obsidian 本身配合这套规则。我最后只保留了一个社区插件 Dataview其余全部用原生功能Templates、Properties、Search、Bookmarks、Daily Notes。插件越少系统越稳。先看文章模板。放在 99-模板/文章模板.md--- title: domain: type: 专题 status: active series: order: created: {{date:YYYY-MM-DD}} updated: {{date:YYYY-MM-DD}} next_review: tags: - 领域/ - 主题/ --- 所属知识地图[[]] ## 正文系列文章模板只多两行把 type 改成「系列」并补上系列导航--- title: domain: type: 系列 status: active series: order: created: {{date:YYYY-MM-DD}} updated: {{date:YYYY-MM-DD}} next_review: tags: - 领域/ - 主题/ --- 所属知识地图[[]] 系列导航[[]] ## 正文然后是知识地图页用 Dataview 自动拉取不用手工维护列表。放在 30-资源库/领域/00-MOC/领域-知识地图.mdTABLE status AS 状态, updated AS 更新, next_review AS 复习 FROM 30-资源库/基础设施与运维 WHERE type 专题 OR type 系列 SORT updated DESC系列页则按 order 排序TABLE order AS 序号, status AS 状态, updated AS 更新 FROM 30-资源库/基础设施与运维/20-系列/NetBox实战 WHERE type 系列 SORT order ASC复习面板放在 00-总览用 next_review 过滤TABLE domain AS 领域, next_review AS 复习日 FROM 30-资源库 WHERE next_review date(today) SORT next_review ASC最近更新面板同理把条件换成按 updated 倒序即可。这样索引页永远不会因为文件移动而失效因为 Dataview 是按目录和字段实时查询的。5. 验证重构是否成功三个对比动作重构完不能只看目录好不好看要用具体动作验证。我给自己定了三个对比动作整理前后各做一次。第一个动作随机抽一篇旧笔记从打开 Obsidian 到定位它记录耗时。整理前我平均要 40 秒以上经常靠搜索碰运气整理后从知识地图进入领域页再进 MOC基本 10 秒内定位。第二个动作检查任意一篇正式文章看它是否满足三条最低链接规则。每篇至少回链知识地图系列文章必须回链系列页领域页和 MOC 职责分离。整理前大量文章是孤岛整理后可以逐条核对。第三个动作模拟新增一篇文章走一遍录入流程。从 10-收件箱 开始判断领域、判断专题还是系列、补 frontmatter、回链索引页。整理前这一步全靠记忆整理后变成固定动作新内容一进库就符合规则。这三个动作做完你就能判断知识库是不是真的从「仓库」变成了「系统」。如果新增文章还需要临时想规则说明结构还没收敛到位。6. 常见报错与排查重构过程中我踩过几个坑基本都是配置和字段问题列出来帮你少走弯路。Dataview 查询返回空结果。最常见原因是 FROM 路径写错或者 frontmatter 字段名大小写不一致。Dataview 对字段名敏感type和Type是两个字段。先在笔记里确认 frontmatter 实际字段名再对照查询语句。系列文章排序混乱。检查 order 字段是不是数字类型。如果写成order: 01YAML 可能解析成字符串排序就会出错。建议写成order: 1文件名再保留01-前缀两者分开管理。知识地图回链失效。Obsidian 的[[ ]]链接依赖文件名唯一。如果两个领域下有同名 MOC链接会指向错误页面。解决办法是 MOC 文件名带上领域前缀例如基础设施与运维-知识地图.md。标签系统再次失控。如果发现标签越加越多说明你在用标签替代目录。回到四前缀规则领域/、模块/、主题/、系统/其余一律不加。标签只做补充检索不承担分类职责。模板变量不生效。Templates 插件的{{date}}语法需要开启对应设置且模板文件必须放在配置的模板目录里。如果插入后是纯文本检查模板目录路径和日期格式设置。7. 把整理变成可持续的工作流重构不是一次性动作而是一套可以持续协作的流程。我现在让 Codex 参与长期维护主要做六类事设计结构、批量迁移文章、统一标题风格、统一 frontmatter、维护知识地图和系列页、持续优化目录策略。比如我后来把 NetBox 从独立领域降级为「基础设施与运维」下的一个系列又把该领域按模块继续拆成基础设施、网络、运维、云计算。这些调整如果手工做很容易半途而废交给 Codex 按规则执行成本低很多。如果你现在的 Obsidian 也开始变乱建议按这个顺序走先定顶层结构再建领域页和知识地图然后决定专题还是系列接着统一 frontmatter只装最必要的插件最后把整理新文章变成固定工作流。不要一上来就折腾插件也不要先补几百个双链先把结构、入口、元数据、工作流这四件事搭起来。需要把 Codex 接入到日常编码和知识管理流程里可以先用模型对话验证提示词效果再通过 API Keys 配置到自己的工具链。长期做编码和 Agent 协作的话Coding Plan 会更合适。具体接入方式参考接入文档按文档配置即可。模型对话https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel_chat Coding Planhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding_plan API Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi_keys 接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc好的知识库不是存了很多内容而是未来的你能稳定找到、理解、复习并继续扩展这些内容。结构、入口、元数据、工作流这四件事搭好之后笔记数量增长就不再是负担而是复利。 
长河君 · 2026/9/28 18:18:13 · 阅读 1.2k Obsidian 越用越乱？我用 Codex 重构了一整套知识系统
1. 为什么 Obsidian 笔记一多就失控如果你用 Obsidian 超过三个月大概率经历过这个阶段刚开始疯狂记觉得终于找到了第二大脑记到两三百篇之后打开文件列表一片混乱想找一篇之前写过的内容只能靠搜索关键词碰运气。笔记是有了但找不到、用不上、也不想再翻。我自己的 Vault 就长期停在这个状态。表面看目录挺整齐实际上有三个致命问题有分类但没有进入路径有标签但没有检索维度有积累但没有复习机制。说白了它更像一个堆满文件的仓库而不是一套能运转的知识系统。真正让我下决心重构的是某次要写一篇关于网络自动化的文章我明明记得半年前记过相关笔记结果翻了二十分钟没找到最后重新写了一遍。那一刻我意识到问题不在笔记数量而在于我从来没有设计过「知识如何被放进去、如何被找到、如何被复习、如何长期维护」。这篇文章我会把整个重构过程拆开讲先讲清楚结构设计思路再给出可复制的 Codex 提示词骨架和 Obsidian 配置片段最后用整理前后的对比动作验证效果。适合已经有一定笔记量、但结构开始失控的 Obsidian 用户也适合想把知识库真正用起来、而不是只当收藏夹的人。2. 重构前先想清楚目录不是用来好看的我一开始最大的误区是把 Obsidian 当成「高级文件夹」用。每记一篇笔记先纠结放哪个目录、要不要新建文件夹、文件名要不要加编号。结果就是目录越建越多层级越来越深但找东西反而更慢。后来我换了一个判断标准目录不是为了看起来整齐而是为了降低未来复习、归类和扩展的成本。围绕这个标准我先问自己四个问题我以后会从哪里进入这批内容这些内容是按主题查还是按顺序学哪些是长期领域哪些只是一次性专题新文章进来时有没有稳定的归档规则这四个问题想清楚之后顶层结构其实就定下来了。我最终采用的 Vault 结构是00-总览 10-收件箱 20-领域 30-资源库 90-归档 99-模板每一层的职责必须明确否则又会退化成普通文件夹。我的定义是这样的目录职责放什么不放什么00-总览控制台知识地图、复习面板、最近更新、录入流程正式内容10-收件箱暂存区灵感、草稿、未整理片段已成型文章20-领域长期入口领域页指向资源库正文30-资源库沉淀主体专题、系列、MOC临时想法90-归档历史区过时、被替代内容活跃内容99-模板规则层文章、系列、知识地图、收件箱模板具体笔记这里有个关键点20-领域 只放入口页不直接放正文。正文全部进 30-资源库按领域再分层。这样领域页就变成了「长期认知主线」的入口而不是又一个文件夹。3. 用 Codex 重构知识库的提示词骨架结构想清楚之后真正耗意志力的是执行几百篇笔记要迁移、要补元数据、要统一标题、要维护索引页。这部分我交给 Codex 来做但前提是提示词要写清楚规则否则它只会给你一堆看起来合理、实际不可维护的建议。我用的提示词骨架分四段角色与目标、结构规则、命名与元数据规则、输出要求。下面是可以直接复制的版本你按自己的领域替换即可。你是一名知识库结构工程师帮我重构一个 Obsidian Vault。 【目标】 把散乱笔记收敛为可维护的知识系统重点解决进入路径、检索维度、复习机制、长期扩展。 【顶层结构】 00-总览 / 10-收件箱 / 20-领域 / 30-资源库 / 90-归档 / 99-模板 20-领域只放入口页正文全部进 30-资源库。 【资源库分层】 30-资源库/领域/ 00-MOC/ 10-专题/ 20-系列/ 内容量大时领域内可继续加模块层例如 10-基础设施 / 20-网络 / 30-运维 / 40-云计算 【领域、专题、系列判断】 领域 长期认知主线不是工具名、不是单一项目名。 专题 能单篇独立读懂的文章。 系列 必须按顺序看才更有价值的内容文件名带 01-、02- 顺序号。 【命名规则】 独立文章自然标题不强制编号。 系列文章01-标题.md、02-标题.md。 【frontmatter 字段】 title / domain / type / status / series / order / created / updated / next_review / tags 【标签规则】 只用四个前缀领域/、模块/、主题/、系统/ 标签只做补充检索维度不替代目录。 【输出要求】 1. 给出重构后的目录树。 2. 对每篇待迁移文章输出目标路径、type、domain、series、order。 3. 标出需要新建的领域页、MOC、系列页。 4. 不确定的项单独列出不要编造。这段提示词的核心是「规则前置」。你先把判断标准写死Codex 才不会自由发挥。我实测下来规则写得越具体它给出的迁移方案越稳定返工越少。4. 可复制的 Obsidian 配置片段结构定好之后需要让 Obsidian 本身配合这套规则。我最后只保留了一个社区插件 Dataview其余全部用原生功能Templates、Properties、Search、Bookmarks、Daily Notes。插件越少系统越稳。先看文章模板。放在 99-模板/文章模板.md--- title: domain: type: 专题 status: active series: order: created: {{date:YYYY-MM-DD}} updated: {{date:YYYY-MM-DD}} next_review: tags: - 领域/ - 主题/ --- 所属知识地图[[]] ## 正文系列文章模板只多两行把 type 改成「系列」并补上系列导航--- title: domain: type: 系列 status: active series: order: created: {{date:YYYY-MM-DD}} updated: {{date:YYYY-MM-DD}} next_review: tags: - 领域/ - 主题/ --- 所属知识地图[[]] 系列导航[[]] ## 正文然后是知识地图页用 Dataview 自动拉取不用手工维护列表。放在 30-资源库/领域/00-MOC/领域-知识地图.mdTABLE status AS 状态, updated AS 更新, next_review AS 复习 FROM 30-资源库/基础设施与运维 WHERE type 专题 OR type 系列 SORT updated DESC系列页则按 order 排序TABLE order AS 序号, status AS 状态, updated AS 更新 FROM 30-资源库/基础设施与运维/20-系列/NetBox实战 WHERE type 系列 SORT order ASC复习面板放在 00-总览用 next_review 过滤TABLE domain AS 领域, next_review AS 复习日 FROM 30-资源库 WHERE next_review date(today) SORT next_review ASC最近更新面板同理把条件换成按 updated 倒序即可。这样索引页永远不会因为文件移动而失效因为 Dataview 是按目录和字段实时查询的。5. 验证重构是否成功三个对比动作重构完不能只看目录好不好看要用具体动作验证。我给自己定了三个对比动作整理前后各做一次。第一个动作随机抽一篇旧笔记从打开 Obsidian 到定位它记录耗时。整理前我平均要 40 秒以上经常靠搜索碰运气整理后从知识地图进入领域页再进 MOC基本 10 秒内定位。第二个动作检查任意一篇正式文章看它是否满足三条最低链接规则。每篇至少回链知识地图系列文章必须回链系列页领域页和 MOC 职责分离。整理前大量文章是孤岛整理后可以逐条核对。第三个动作模拟新增一篇文章走一遍录入流程。从 10-收件箱 开始判断领域、判断专题还是系列、补 frontmatter、回链索引页。整理前这一步全靠记忆整理后变成固定动作新内容一进库就符合规则。这三个动作做完你就能判断知识库是不是真的从「仓库」变成了「系统」。如果新增文章还需要临时想规则说明结构还没收敛到位。6. 常见报错与排查重构过程中我踩过几个坑基本都是配置和字段问题列出来帮你少走弯路。Dataview 查询返回空结果。最常见原因是 FROM 路径写错或者 frontmatter 字段名大小写不一致。Dataview 对字段名敏感type和Type是两个字段。先在笔记里确认 frontmatter 实际字段名再对照查询语句。系列文章排序混乱。检查 order 字段是不是数字类型。如果写成order: 01YAML 可能解析成字符串排序就会出错。建议写成order: 1文件名再保留01-前缀两者分开管理。知识地图回链失效。Obsidian 的[[ ]]链接依赖文件名唯一。如果两个领域下有同名 MOC链接会指向错误页面。解决办法是 MOC 文件名带上领域前缀例如基础设施与运维-知识地图.md。标签系统再次失控。如果发现标签越加越多说明你在用标签替代目录。回到四前缀规则领域/、模块/、主题/、系统/其余一律不加。标签只做补充检索不承担分类职责。模板变量不生效。Templates 插件的{{date}}语法需要开启对应设置且模板文件必须放在配置的模板目录里。如果插入后是纯文本检查模板目录路径和日期格式设置。7. 把整理变成可持续的工作流重构不是一次性动作而是一套可以持续协作的流程。我现在让 Codex 参与长期维护主要做六类事设计结构、批量迁移文章、统一标题风格、统一 frontmatter、维护知识地图和系列页、持续优化目录策略。比如我后来把 NetBox 从独立领域降级为「基础设施与运维」下的一个系列又把该领域按模块继续拆成基础设施、网络、运维、云计算。这些调整如果手工做很容易半途而废交给 Codex 按规则执行成本低很多。如果你现在的 Obsidian 也开始变乱建议按这个顺序走先定顶层结构再建领域页和知识地图然后决定专题还是系列接着统一 frontmatter只装最必要的插件最后把整理新文章变成固定工作流。不要一上来就折腾插件也不要先补几百个双链先把结构、入口、元数据、工作流这四件事搭起来。需要把 Codex 接入到日常编码和知识管理流程里可以先用模型对话验证提示词效果再通过 API Keys 配置到自己的工具链。长期做编码和 Agent 协作的话Coding Plan 会更合适。具体接入方式参考接入文档按文档配置即可。模型对话https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel_chat Coding Planhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding_plan API Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi_keys 接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc好的知识库不是存了很多内容而是未来的你能稳定找到、理解、复习并继续扩展这些内容。结构、入口、元数据、工作流这四件事搭好之后笔记数量增长就不再是负担而是复利。