真正有价值的知识库，不是收藏夹，也不是让 AI 把每一次对话都倒进去。它应该能在下一次遇到相似问题时，帮你更快地做出更好的决定。
我把 Obsidian 当成长期事实与上下文的载体，把 Codex 当成整理、质疑、重构和交付的执行者。前者负责留下可追溯的判断，后者负责把零散输入变成可维护的资产。两者各司其职，系统才不会随着笔记增加而失控。
先定义边界：什么该进入知识库
知识库只保存未来仍会复用的内容：关键决策、可重复流程、排错结论、项目背景、可靠参考资料，以及经过自己审阅的代码片段。即时聊天、没有上下文的灵感、纯粹的网页摘录先进入收件箱，经过一次处理再决定去留。
这条边界很重要。Codex 很擅长归纳，但它不应该替你决定什么是事实。每一条进入长期库的内容，都应保留来源、适用条件和最后验证时间。
目录只需稳定，不必复杂
00 Inbox/ # 尚未处理的输入
10 Notes/ # 可复用的概念、方法与排错记录
20 Projects/ # 项目上下文、里程碑与交接
30 Decisions/ # 有取舍的决定与原因
40 Reference/ # 外部资料的摘录和链接
90 Archive/ # 已失效但仍需追溯的内容
不要为每个新想法创建一层目录。目录只负责粗粒度归位，真正的关联交给链接、标签和统一的元数据。一个笔记放错目录可以接受，无法被搜索和理解才是问题。
给每个笔记一份可检查的元数据
---
type: decision
status: verified
created: 2026-07-18
updated: 2026-07-18
project: xzan
source: terminal + official docs
review_after: 2026-10-18
---
status 可以只用四个值：draft、verified、superseded、archived。这比堆叠几十个标签更能说明一条信息能不能直接使用。对会过期的内容，加上 review_after，让它在未来主动暴露风险。
把 Codex 放在正确的四个位置
1. 收件箱整理器
把终端输出、会议笔记、网页摘录或模糊想法丢进 00 Inbox，再让 Codex 提炼。要求它区分事实、推断和待验证项，而不是生成看起来完整的散文。
阅读下面的原始记录，输出一份 Obsidian Markdown 笔记。
保留所有可验证的命令、版本和错误信息；
把不确定内容列为“待验证”，不要补造事实；
最后给出 3 个应该链接到的已有主题。
2. 决策记录的反方
做技术选择时，先用自己的话写出背景、候选方案和倾向。再让 Codex 扮演审稿人：找出隐含假设、遗漏的失败路径和维护成本。最终决定仍由人来写，因为决策需要承担后果，而不是追求语言上的圆满。
3. 项目交接的压缩器
项目笔记最容易变成流水账。每次阶段性完成后，交给 Codex 把变更压缩为四部分：当前状态、关键文件、未解决问题、下一步可执行命令。这样即使隔几个月再回来，也能在十分钟内恢复上下文。
4. 写作前的研究助手
写文章前，先让 Codex 根据已有笔记列出论点、证据缺口和可能重复的内容。它可以帮助搭结构，但引用、结论和经验必须回到原始资料核验。知识库的价值来自可追溯性，不是“看起来像答案”。
一个低摩擦的日常循环
- 捕获：任何输入先进 Inbox，不在当下分类。
- 提炼：每天用 10 分钟让 Codex 协助压缩、补标题、列待验证项。
- 连接：为新笔记至少补一条“来自哪里”和一条“下一次何时会用到”。
- 复用：写文章、排错或做决策前，先搜索自己的库，再开始新的对话。
- 清理：每月归档失效方案，把被新结论替代的笔记标为
superseded。
把知识库放进 Git，但别把秘密放进去
Obsidian Vault 很适合 Git：Markdown 的差异清晰，历史可追溯，也方便在多台设备之间同步。但 .env、访问令牌、私钥、生产数据库导出和真实客户资料不应进入仓库，更不应直接粘贴进 AI 对话。知识库记录“如何取得凭据”和“凭据的用途”即可，不记录凭据本身。
让知识产生复利
一套好的系统不会要求你每次都做完美归档。它只需要让下一次开始工作时，比上一次少一点重复搜索、少一点上下文丢失、多一点可验证的判断。Obsidian 负责让记忆留下来，Codex 负责让记忆变得可用。长期来看，真正积累下来的不是笔记数量，而是你做事时越来越短的启动距离。