文件命名规范:团队完整指南

国家网信办（CAC）发布的数据分类分级指南要求企业对文件存储建立可追溯的命名体系——文件名混乱直接影响数据主体权利响应效率，也是监管检查的常见问题点。能够经受实际考验的文件命名规范采用以下格式：YYYY-MM-DD_项目代码_文档类型_描述符_vNN.扩展名。始终使用 ISO 8601 日期（排序正确）、简短的项目代码（3-10个字符）、文档类型的受控词汇表、连字符命名的描述符、两位版本号（v02 而非 v2），以及在无关紧要处使用小写字母。示例：2026-06-12_ACME-RB_contract_master-services-agreement_v02.pdf。格式本身不如一致性重要——选定一个，写下来，在入职时和每周清理时执行。

为什么日期放在最前面

ISO 8601 日期（YYYY-MM-DD）放在文件名开头解决了排序问题。2026-06-12_report.pdf 在任何文件系统、任何云盘、任何工具中都紧靠 2026-06-13_report.pdf。日期移到末尾，排序就丢失了；移到中间，排序就变成随机的。

专门使用 ISO 8601，而非美国格式（MM/DD/YYYY）、英国格式（DD/MM/YYYY）或无标点格式（YYYYMMDD）。ISO 是唯一满足以下条件的格式：

• 作为文本排序时结果正确
• 跨地区无歧义解析（06/05/2026 是6月5日还是5月6日？）
• 与所有主要科技公司日志使用的国际标准一致

对时间敏感的文件，可添加时间：2026-06-12T1430Z_meeting-notes.md 使用UTC时间，适用于多时区团队，让"这份文件何时产生"的信息在交接时一目了然。

可扩展的项目代码

文件名第二位置的简短项目代码，使文件无需依赖文件夹结构即可按项目搜索。有效规则：

• 3-10个字符，全大写，允许连字符
• 前3-4个字符标识客户或内部单位
• 可选后缀标识项目类型或阶段

示例：ACME-RB（Acme品牌重塑）、INTL-ONBRD（内部入职）、FINOPS-Q2（财务运营Q2）、ACME-SUP-001（Acme支持项目#1）。

在 Notion、Confluence 或共享电子表格中维护项目代码注册表。创建新项目时，注册一个代码，只需30秒，却能防止三个月后有人叫它 ACMErebrand、你叫它 Acme-RB，导致两个文件同时存在的混乱。

文档类型的受控词汇表

文档类型字段需要固定列表。没有固定列表，你最终会得到 report、Report、REPORT、rpt、reprt、summary、summary-report、final-report 这些词——全都表示同一件事。

初始词汇表：

• brief — 初始项目简报、创意简报
• spec — 技术或设计规格说明
• contract — 法律协议、SOW、NDA
• invoice — 账单文件
• proposal — 提案和投标
• report — 定期或临时报告
• presentation — 演示文稿、提案、全员会议
• design — 设计资产和交付物
• video — 原始或成品视频内容
• audio — 播客、配音、源音频
• dataset — CSV、Excel、JSON数据文件
• note — 会议记录、工作备忘录
• template — 可复用的起始模板

保持列表简短。如果有人想添加 whitepaper，问一下它是否真的与 report 不同。在列表层面的纪律能带来复利效益。

真正有效的版本编号

v1, v2, v3 用起来顺手，直到到了 v10——它会排在 v2 前面。从一开始就使用两位版本号：v01, v02, v03, ..., v10, v11。

对于可能超过99个版本的长期项目，从一开始就用三位数字：v001。

区分主版本和草稿：

• v01 表示第一个提交版本
• v01.1、v01.2 表示主版本内的小草稿
• 主版本在值得重新审阅的实质性变更时递增

不要对业务文档使用语义版本控制（v1.2.3），它适合软件和API，不适合合同或演示文稿。

"final"陷阱：文件名中永远不要出现"final"这个词。它必然导致 final、final-final、final-final-REAL、final-use-this-one 的出现。用 v02 表达你所说的"最终版"，相信版本编号即可。

连字符命名的描述符

描述符字段是唯一自由形式的部分。保持：

• 小写
• 连字符命名（单词之间用连字符分隔）
• 简短：2-5个词
• 具体到可以快速扫读：q2-revenue-forecast 优于 forecast

master-services-agreement 是好的。MasterServicesAgreement.pdf 不好，因为不区分大小写的搜索会得到不一致的结果，屏幕阅读器也会读得很奇怪。master services agreement（含空格）不好，因为文件名中的空格会破坏命令行管道和URL编码。

不需要"警察"的执行机制

在一个200人的组织中，不可能手动检查每个文件的命名。但你可以：

• 入职培训：第一周用15分钟讲解命名规范和示例
• 模板：在 /Knowledge/Templates/ 中放置预命名的模板文件，让人们从正确的形式开始
• 评审时顺手纠正：评审工作时，内联重命名命名错误的文件，并附上简短说明
• 每周清理：由轮换负责人花10分钟修正偏差
• 自动化重命名脚本：对于高频文件夹，Python + watchdog + os.rename 是半天的项目

对于正式记录存储库——合同、发票、已签署文件——SharePoint 文档库可要求在保存前填写元数据字段；Google Drive 在 Workspace Business Plus 的特定文件夹也可设置标签要求。

格式特定的文件扩展名

扩展名比人们想象的更重要：

• .pdf 用于不应被编辑的最终文件
• .docx 和 .xlsx 用于可编辑的 Office 文件；避免 .doc 和 .xls（已过时且存在安全问题）
• .pptx 用于演示文稿；.key 仅在纯 Mac 环境中使用
• .md 用于技术笔记和内部 Wiki——可排序、可在 Git 中差异比较、永久可读
• .csv 用于数据交换；.xlsx 用于带格式的最终分析
• .mp4 用于 H.264 或 H.265 编码视频；除非真的需要用于剪辑的 ProRes，否则避免 .mov
• .psd、.ai、.indd 用于 Adobe 源文件；.fig 用于 Figma 源文件

有疑问时，选择10年后无需专业软件也能读取的格式。PDF 和 Markdown 几乎总是能赢得这个赌注。

迁移而不破坏历史记录

在现有混乱中采用新规范时，不要重命名历史文件。这会破坏现有链接、书签和引用。应该：

1. 从特定日期起，所有新文件采用新规范
2. 仅重命名正在进行工作中触及的文件
3. 让存档自然地在2-3年内更新换代

对一个包含10,000个文件的云盘进行全面追溯重命名，是一个通常不值得付出代价的40小时项目。向前的纪律胜过向后的清理。

HexaTransfer 在发送文件时保留原始文件名，让接收者看到的文件名和你发送时完全一致，不会在传输途中被重命名或截断。立即前往 https://hexatransfer.com 免费使用，无需注册，最大支持 10 GB。