VR全景素材命名与版本管理：上百个机位怎么不乱

一次完整的VR全景拍摄，少则十几个机位，多则上百个。项目交付半年后客户说「三楼那个有蓝沙发的角落要补一张」，如果当时的文件还叫 IMG_0421.JPG，找回来基本只能靠运气。

命名不是洁癖，是可检索性

比较稳的做法是四段式：项目号、空间、机位、版本。例如 QJ2410-BLDG-A-3F-DT-001_v3，读出来就是：2024年10月接的项目、A栋、三层、东侧通道、第1号点位、第三版。项目号解决「是哪一单」，空间解决「在哪」，机位解决「哪个角度」，版本解决「哪一次改的」。

四段之外不必再加修饰词。加日期、加摄影师名字、加「最终」两个字，看起来信息更多，实际会让排序和筛选失效。所谓「最终版」「最终版2」「真最终」，是行业里最常见的笑话，也是最常见的返工原因。

目录按处理阶段分，不按项目分

素材的生命周期有四段：原始拍摄、拼接成全景、修图与标注、导出交付。对应四个目录 raw、pano、retouch、export，一个项目一个根目录，阶段目录里再按空间分子目录。

这样分的好处是，任何一个环节出问题都能立刻定位：拼接有缝，去 pano 找源文件；标注写错字，去 retouch 改工程；客户端反馈首屏糊，去 export 核对导出规格。反过来，如果按「客户A、第一次、新文件夹」这样堆，三个月后就没人说得清哪份是能改的工程、哪份是只能看的成品。

版本只增不改

规则可以很简单：已经交付出去的版本不再改动，任何修改都生成新的版本号，同时在一份 changes.txt 里写一行记录，比如「v3：三层东侧补拍，替换机位 001，标注增加消防通道」。改动可追溯，客户拿到 v3 也能对比 v2 看差异。

版本号不要用日期代替。日期看起来天然有序，但同一天改两版就分不清先后；客户看到的永远是 20241015 这样的字符串，也无法判断哪个更新。

拍摄记录表比文件名更有用

文件名解决定位，记录表解决复现。每个机位记四项：编号、空间、拍摄时间、现场备注（光比情况、被遮挡的展位、临时堆放的货物）。补拍时照表走，机位高度、朝向、镜头焦段都能对上，新旧画面衔接才自然。

这套表不需要复杂工具，一张表格就够，关键是每次拍摄都填。填过三次之后，团队自己就会发现哪些信息是真的要留的。

备份要按最坏情况设计

全景项目的原始素材体积大，一个中型工厂拍下来几十到上百GB很常见。按 3-2-1 原则处理：三份副本、两种介质、一份异地。移动硬盘不要只留一块，存储卡也不要拍完就格式化——格式化之前，先确认当天的素材已经完整导入主存储并校验过。

实操上可以把「当天导卡、当天校验、当天备份」写进拍摄的收尾清单，和关灯、收三脚架放在一起。流程里有的动作才会被执行，靠记忆的环节迟早会漏。