作者：Felix（Haro 协作整理）
最近我重新整理了一次自己的 Obsidian 知识库。与其说这是一次“目录调整”，不如说是一次知识管理边界的重新定义：哪些内容应该进入 Obsidian，哪些应该留在开发目录、Git、PLM 或其他资产系统里？
我以前也会把笔记、项目资料、临时想法放进 Obsidian，但结构并不完全稳定。尤其当事情涉及研发项目时，一个项目往往同时包含软件、硬件、固件、测试、交付物、PLM 流程和后续维护记录。如果没有一套清晰规则，知识库很容易变成另一个混乱的文件夹。
这次整理后，我给 Obsidian 定了一个更明确的角色：
Obsidian 是项目大脑和知识连接层，不是工程资产仓库。
一、先明确 Obsidian 的职责
我希望 Obsidian 负责的是“可读、可理解、可追溯”的内容，而不是把所有文件都复制进去。
适合放进 Obsidian 的内容包括：
- 项目说明
- 需求和方案
- 交付清单
- 测试结论
- 问题复盘
- 操作步骤
- 发布记录
- 会议纪要
- 关键决策
- 工程资产的路径、版本、commit、状态索引
不适合直接放进 Obsidian 的内容包括：
- 代码工程
- Keil / VSCode 工程
- KiCad / Altium 工程
- 固件产物
- Gerber
- CAD 文件
- 二进制文件
- zip 压缩包和大型附件
这些工程资产应该继续待在开发目录、Git、PLM、NAS 或正式发布目录里。Obsidian 只负责记录它们在哪里、是什么版本、当前状态如何、为什么这样做。
这个边界很重要。否则 Obsidian 很容易从“知识库”变成“大杂烩同步盘”。
二、整体结构：不是只为 Projects 服务
这次规划不是单独整理 Projects，而是重新确认整个知识库的分工。
目前我采用的是接近 PARA 的结构：
00_Inbox/
01_Projects/
02_Areas/
03_Resources/
04_Lab/
05_Archive/
98_Attachments/
99_Templates/每个区域有自己的职责：
00_Inbox：临时想法、待整理内容01_Projects：有明确目标、交付物、状态推进的项目02_Areas：长期维护的职责、系统、习惯和工作流03_Resources：跨项目可复用的知识资料04_Lab：实验、测量、调试、板卡、器件记录05_Archive：完成、失效或不再活跃的内容98_Attachments：附件集中存放99_Templates：模板和结构约定
这样做的核心不是“目录好看”，而是让每类信息有稳定归宿。
三、Projects：按项目本体组织，而不是按领域拆开
Projects 是这次调整里最明显的一块。
以前很容易自然地把项目拆成：
01_Projects/
Software/
Firmware/
Hardware/但真实项目经常不是这样。比如一个烧录器项目，可能同时包含硬件烧录板、MCU 固件、Keil 调试环境、BOM、Gerber、测试记录、交付清单和样机状态。它到底应该放在 Hardware、Firmware 还是 Software？
如果按领域拆，项目上下文就会被人为割裂。
所以现在 Projects 的一级目录只放真实项目：
01_Projects/
Project-Name/项目内部再按需要建立树状结构：
01_Projects/
Project-Name/
README.md
Deliverables/
Hardware/
Firmware/
Software/
PLM/
Lab/
Logs/这里的 Hardware、Firmware、Software 不是一级分类，而是某个项目内部的子上下文。这样，一个项目仍然是一个整体，但里面不同类型的内容也有清楚的位置。
四、Resources 和 Lab：区分“知识”和“记录”
除了 Projects，另外两个重要区域是 Resources 和 Lab。
03_Resources 放的是可复用知识。比如：
- 通用 KiCad 规则
- HPMicro 调试方法
- Linux 命令
- 编程语言经验
- 工具使用方法
这些内容不属于某一个项目，而是以后很多项目都可能复用。
04_Lab 放的是实验、测量和调试记录。比如：
- 某次板卡 bring-up
- 器件测试
- 仪器测量方法
- Debug log
- 可横向比较的实验数据
如果某条实验记录只和一个项目强绑定，可以放在项目内部的 Lab/。如果它可能复用或需要跨项目比较，就放到全局 04_Lab/，再从项目页建立链接。
原则是：
原始记录只放一处，其他地方用链接连接。
五、用一个真实项目验证结构
为了验证这套结构，我拿一个完整工程做了试整理：SPI Flash 加密烧录器。
这个项目包含：
- 硬件烧录板
- STM32/GD32 F103 固件
- Keil/J-Link 调试环境
- 加密方法说明
- Gerber 和 BOM
- 交付清单
- 样机和转接座交付记录
我没有把完整工程复制进 Obsidian，而是在 Obsidian 里建立项目入口：
01_Projects/SPI Flash 加密烧录器/
README.md
Deliverables/README.md
Firmware/README.md
Hardware/README.md
Lab/README.md
Logs/README.md工程本体仍然以本机开发路径为准。Obsidian 负责记录这个项目是什么、有哪些交付物、工程文件在哪里、目前有哪些已知问题、下一步该做什么。
这样整理后，查项目时不需要先判断它属于软件还是硬件。它就是一个完整项目，所有上下文从项目入口进入。
六、模板不是束缚，而是降低维护成本
这次我也整理了项目模板。
模板的目的不是要求每个项目都长得一样，更不是为了把目录填满。相反，模板只是提醒我：一个项目可能需要哪些信息。
如果某个项目没有硬件，就不需要建 Hardware/。如果没有 PLM 内容，也不需要建 PLM/。但是当项目真的变复杂时，结构已经有预留位置，不需要临时乱放。
好的模板应该降低维护成本，而不是制造新的负担。
七、这次规划后的收获
这次整理之后，我对 Obsidian 的使用边界更清楚了：
- Obsidian 管说明、决策、索引和上下文。
- 开发文件留在开发系统里。
- Projects 按项目目标组织，不按软件/硬件/固件拆开。
- Resources 沉淀跨项目知识。
- Lab 保存实验、测量和调试记录。
- 大文件和正式资产只做引用，不直接塞进知识库。
最终我希望形成的是一个长期可维护的知识系统，而不是一个短期看起来很整齐、过几个月又失控的目录结构。
小结
这次 Obsidian 整理给我的最大感受是：知识库真正重要的不是目录数量，而是边界清楚。
什么是项目？什么是知识？什么是实验记录？什么是工程资产？这些边界想清楚之后，Obsidian 才能稳定地发挥作用。
我现在比较满意的一条总结是：
项目按目标组织，知识按领域沉淀，资产按系统存放，Obsidian 负责连接它们。
这可能也是我后续继续维护个人知识库时最核心的一条规则。