多数返工并不是因为设计做得不好，而是因为找不到正确文件：不知道哪个是最新版本、哪个是已评审通过、哪个是交付给开发的那份。命名和版本管理的目标只有一个：让任何人在30秒内定位到“正确文件”。
建议把目录分成4层：项目 / 模块 / 产物类型 / 版本。比如：
ProjectA / 01-Homepage / design / v01，或者 ProjectA / 02-Checkout / export / v01。
目录负责“范围”，命名负责“语义”。不要把所有信息都塞进文件名里。
推荐模板：
{项目}-{模块}-{页面/组件}-{状态}-{端}-{版本}-{日期}-{作者}
示例：
ProjectA-Checkout-PayPage-Review-M-VA.02-20260224-Li
说明：
1) 状态用有限集合：Draft / Review / Approved / Dev / Released。
2) 端用 M(移动)/D(桌面)/All。
3) 版本建议写成 VA.01、VA.02（避免 v1/v2 的歧义）。
常用两种策略：
A. 线性递增：每次改动就 +1，适合日常迭代。
B. 主次版本：VA.02.03（主版本=里程碑，次版本=小改），适合大项目。
无论哪种，关键是：评审通过、交付开发、上线回溯这些节点必须有“可标记的版本”。
把评审节点写进流程里：
1) Review：提交评审时复制一份并改状态为 Review。
2) Approved：评审通过后再复制一份改为 Approved，并在文件内写清交付说明（例如交互、动效、切图规则）。
3) Dev：交付开发时再复制一份改为 Dev，确保开发拿到的是冻结版本。
这样做的好处是：即便后续继续改稿，也不会污染交付版本。
每周或每个迭代结束做一次归档：
1) 把 Released/Dev 的版本移到 /archive。
2) 删除明显无意义的临时文件（例如“新建文件(3)”）。
3) 保留可追溯链条：Draft 最多留3个，Review/Approved/Dev 必留。
如果你只想立刻开始，建议先执行这三条：
1) 文件名必须包含：模块 + 状态 + 版本 + 日期。
2) 交付给开发的文件必须带 Dev 状态且不可覆盖。
3) 同一个模块的版本号必须连续递增，不允许“倒退”。
把规则写到团队协作手册里，并在评审时顺手检查一次，1-2周就能形成习惯。
