Matrix 首页推荐
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
国庆假期，工作室有幸参与了 《CCTV 央视 2025 品牌强国工程发布会》 开场片的制作。全程不能说是磕磕绊绊吧，简直是连滚带爬。这种项目的节奏非常快，制作周期一共只有 20 天时间，没得商量，而视频规格却高的离谱，时长 90 秒，出片分辨率：7036 x 1000 像素，30fps。
更凶残的是迭代速度，项目完成后我自己统计了一下，别的同事不知道，光我一个人负责的镜头，在进组的 12 天内，就修改迭代了 70 稿，整个项目的文件夹有 280G 的数据。
团队一共 10 个人，同时又分散在多个省市远程协作。排除技术难点，如此紧张的节奏，高效的流程把控和文件管理也是完成这类大型项目的必要条件。这篇文章不会大篇幅描述让人犯困无聊的专业知识，主要分享可以应对大部分场景下的远程数字化协作都有帮助的文件管理和命名规范，也是自己对这次经历踩过的各种坑进行一次复盘。
曾在 《2024 年，如何优雅使用 Windows PC》 中一笔带过我的工作目录模板，如下：
project name
- doc
- pj
- render然而，由于涉及团队协作，目录结构根据这次的项目做了相应调整：
project name #项目名称
- 01-in #上游同事提供的文件
- 02-doc #文档和参考资料
- 03-pj #工程文件
- tex #工程文件会调用到的素材
- 04-export #输出目录
- pre #用于审核的预览文件
- render #输出给下游同事的文件这样做有几个好处：
有利就有弊，这么做缺点也有：
无论做什么类型的数字化工作，清晰的目录结构和文件命名习惯都起着至关重要的作用。在我看来首当其冲的关键在于先让自己看得懂，准确地讲，是让未来的自己看得懂。
这样就算以后搜索的时候，即便已经忘记了很多细节，无需预览，只看目录结构和名字也更容易确认文件的大致用途。
说句题外话，相信我，一定要对过往的项目进行整理和复盘，无论商业还是原创，你的隐形财富就藏在里面。
一句话总结：在系统的整体命名规范下，以你的生产流程为准则。
接下来分别说明。
其实 微软在官方文档中 是对文件命名有详细说明的，我整理了一些需要注意的要点：
macOS 下其实大同小异。
具体到实际工作，我习惯的命名十分精简。以这次三维动画项目为例：
其中制作花苞的 c4d 工程文件名为「huabao-anim-1004.c4d」，整个名称分为：
命名词：huabao（花苞）
所属类别/状态：anim（表示是用来制作动画的工程）
创建时间/版本：1004（10月4日创建）另外一个「牡丹」的工程文件也是：
命名词：Mudan（因为它在模型结构上属于花苞的父级，因此大写）
所属类别/状态：solo（表示单体静态模型，里面没有制作动画）
创建时间/版本：0929（9月29日创建）是不是非常简单，这样无论是我还是同事，很容易就可以看出每个文件的作用和状态。不用检索，只要正常保持按名称排序可非常容易找到。
另外值得一提的是分隔符的使用，一般为短横线 - 和下划线 _，短横线在英文中作为连字符，但在文件名内可以非常好的用于划分信息类别，而我不使用下划线做分隔是因为在程序中，下划线通常被等同于空格。
罗马不是一天建成的。当你给自己制定好一个初步的命名规范之后，最好先在小规模的项目中试用一段时间。在推进过程里观察同事和自己是否能够很快适应并接受这种方式，就像游戏内测一样。
如果同事提出了困惑和建议，一定要询问清楚理解困难和感受不方便的地方。弄明白到底是命名规范不合理，还是团队之间的沟通问题。
之后再通过更大规模的合作和项目需求，进一步扩展和迭代更多的命名规范，这样团队的配合效率才会无形中提升。
规范的文件命名背后意味着高度的概括和归纳能力。这种能力不仅是职场专业人士的必备技能，也是作为设计师或工程师对其领域专业程度的一种体现。
给文件命名是一个思考的过程，人是爱偷懒的，大脑本身更偏爱低能耗的运作方式。人类焦虑和烦恼永远来自于「趋利避害」与「急于求成」，而我更愿意相信「慢就是快」。
如果你有更好的文件命名方式，欢迎留言讨论分享。
本文首发在 CGArtLab
关联阅读
> 关注 少数派小红书，感受精彩数字生活 🍃
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。