用Obsidian久了，笔记一多，找文件就变成噩梦。
文件名记不住，文件夹越挖越深，点开七八个才找到想要的内容——这不是工具不好，是命名没做好。
最近整理了一套自用的文件命名规范，用了一段时间，确实比之前清爽太多。今天分享出来，照着做就行。
一、命名是导航，不是标签
好文件名和差文件名的区别在哪？
差文件名：读书笔记、待处理、新建文档2
好文件名：20250315-产品需求文档-小红书运营-V1.0-@蛋仔成长笔记-已完成
后者看起来信息量更大，但用起来有多爽，谁用谁知道：
- 查找快：不用点开文件夹扫一眼就知道是不是要找的文件
- 排序有用：按时间、按类型排序，一眼看到最新内容
- 批量操作方便：脚本处理、批量重命名都能实现
文件命名不是什么高阶技巧，就是怎么让找文件更快。
二、推荐格式
文档类型-主对象-子对象-所属业务-版本-更新时间-更新人-状态
示例：需求文档-进度计划系统-计划编制-智能建造-V1.0-20251201-@Cloud-未完成
拆开看
| 字段 | 含义 | 示例 |
|---|---|---|
| 文档类型 | 文件类别 | 需求文档、项目计划书、研究报告 |
| 主对象 | 核心内容 | 系统、主任务如：进度计划系统、施工日志、工作总结 |
| 子对象 | 细分内容 | 功能、子任务具体章节或专项 |
| 所属业务 | 归属项目/领域 | 如：智能建造、智慧城市、XXX项目 |
| 版本 | 当前版本 | V1.0、V0.3 |
| 更新时间 | 最后修改时间 | 20251201 |
| 更新人 | 修改者 | @Cloud、@蛋仔成长笔记 |
| 状态 | 当前进度 | 未完成、评审中、已完成 |
版本号规则：
- 0 = 草稿
- V0.1 = 草稿第一版
- 评审修改一次 +0.1
- 交付完成 +1 → V1.0、V1.1
这套格式覆盖了文件的核心信息，查找时一眼就能定位。
三、分隔符：用短横线，别用下划线
分隔符：用短横线，别用下划线
统一用 -，别混用 _。
理由：
- 日期格式一致：2025-03-15 本身就是短横线，拼在一起不违和
- Dataview处理方便：split(file.name, “-“) 直接拆字段
- URL友好：分享链接时，地址栏显示更清晰
下划线不是不能用，但只限于特定场景：
- 代码笔记：文件名本身是代码变量名，比如
data_structure-算法笔记 - 强调整体模块：
Data_Analysis-项目A，下划线表示这是一个整体
核心原则：全库统一。要么全 -，要么全 _，别混。
四、两条铁律：小写 + 日期前缀
1. 全部小写
防止 macOS 和 Windows 大小写敏感导致的路径问题。统一小写最稳妥。
2. 日期前缀
日常笔记用日期开头，如：20250315-工程数字化需求分析.md。
按时间排序，所有笔记自动排成一列。找最近的内容，看第一行就知道。
五、特殊符号标记
用【】表示以内容为主，无实效性的长期的笔记。
例如：MOC、指标、方案、规范、标准、报告
示例：【指标】集中式光伏电站智慧工程指标
用【】表示带有时间属性笔记。
例如：会议、任务。
示例：20250622【会议】关于战略、商业模式的讨论
六、现在开始
不用一次性改完所有旧文件，从新创建的文件开始用就行。
几个建议：
- 新文件套模板：每次新建文件时，按格式来，养成习惯
- 同类文件统一格式：同类型的文档用同样的结构，别各搞各的
- 关键信息不能少：可以简洁，但版本、时间、状态这些字段别省略
- 每月检查10分钟：定期看看命名是否跑偏，及时调整
规范本身不难，难在坚持。用久了就习惯了，你的Obsidian会明显比之前好找东西