**核心结论：**发布错版本不是粗心导致的意外，而是系统设计的必然结果。只要存在多个看起来一样的文件、而审批状态只存在于聊天记录里，事故就会重复发生。解法是三件事：版本不可变、审批锚定到版本、交付只能取已锜定的版本。
事故是怎么发生的
典型场景：设计师导出 final_v3.jpg，发给中国区；运营提了一个小修改，产生 final_v3_new.jpg；法务又要求加上免责声明，产生 final_v3_new_ok.jpg。三天后发布时，没人能确定哪一个含有声明。
这里有三个结构缺陷：
- **版本信息写在文件名里。**文件名不可靠，且任何人都能修改。
- **审批状态不在文件上。**它存在于邮件或群聊中，与文件脱钩。
- **交付渠道不验证源头。**任何本地文件都可以被上传。
为什么仅靠命名规范无法解决
命名规范依赖自律，而自律在截止时间前一小时会失效。它可以作为辅助手段，但不能作为主体机制。
三项基本原则
一、版本不可变
每次上传生成一个新版本号，旧版本永不被覆盖。“覆盖上传”是事故的温床：一旦发现问题，已无法回溯。
不可变也意味着每个版本都有独立链接。审核意见锚定在特定版本上，而不是“那个图”上。
二、审批锚定到版本
审批不是项目属性，而是版本属性。获批的是 v4，不是“这个素材”。当 v5 上传时，审批状态应自动回到待审，而不是继续沿用。
这一条看似严苛，但它阻止的正是最常见的事故类型：在审批后“只改了一个小地方”。
三、交付只取锜定版本
发布时只能从系统中拉取标记为已批准的版本，不允许上传本地文件。这是整套体系中唯一真正具有约束力的环节。
实践中的几个细节
- **区分源文件与交付文件。**源文件用于编辑，交付文件用于发布，两者分开管理但相互关联。
- **标注永不进入交付文件。**带批注的预览图与干净的交付图必须是不同文件，否则带批注的图上线只是时间问题。
- **外部链接指向版本而非文件。**发给客户的审阅链接应能看到当前版本与历史，而不是一个静态附件。
- **保留回溯能力。**一键回退到上一个已批准版本，是事故发生后的止损手段。
常见问题
小改动也要重新审批吗？
需要，但可以是轻量确认。关键不是流程长度，而是“获批的到底是哪个文件”必须有明确答案。
保留所有版本会不会消耗大量存储？
会占用存储，但可通过保留策略缓解：中间版本保留一定期限，已批准版本长期保留。相比一次事故的成本，存储开销可忽略。
代理商在外部工具中工作怎么办？
内部工具可以不同，但交付入口必须统一。只要交付进入同一体系，版本链就是完整的。
如何验证体系是否生效？
随机抽一个已上线素材，尝试在五分钟内回答：它对应哪个版本、谁批准的、何时批准的。答不上来就说明体系尚未生效。
结语
版本控制的目标不是增加流程，而是让“哪个是对的”这个问题永远有确定答案。版本不可变、审批锚定、交付锜定，这三条落地后，发错版本从一类常见事故变成一个结构上不再可能的事件。
