更新时间：2026年10月09日

UI 设计文件命名先解决三个问题：去哪里找、眼前是哪种状态、哪一份可以交付。项目和文件写业务范围，页面按工作阶段组织，画板写对象与状态，图层写实际用途；版本变化放在记录中，不靠“最终版 2”表达。多人项目可结合Pixso 的在线设计协作共用一套命名表，减少各自另存文件造成的歧义。

先分清文件名、交付状态与版本

“采购系统最新最终版改 3”同时混入了产品、时间和评审结论，却没有回答负责采购订单的人应该打开哪一部分。文件名应该稳定表示内容范围；“待评审、开发中、已交付”属于工作状态；某次修改了什么，则属于版本说明。三者混用，名称只会越写越长。

下面以“采购协作”项目为例，团队有订单、供应商和报表三个模块。先按共同工作边界拆文件，而不是一位设计师一个文件。若订单与供应商要经常联动评审，可以先保留在同一文件；如果访问权限、交付节奏确实不同，再拆开。不要仅凭画板数量决定。

一份可以直接改用的命名结构

编号用于排序和沟通，不必编码出全部信息。PO-03 在状态变化时仍指向同一个订单详情页；“待审批”和“审批驳回”是它的不同画板。编号含义写进说明页，避免新人把 PO 理解成另一个业务对象。

上述阶段名是一种团队约定，不代表 Pixso 内置了这些审批状态。可以用文件页面、画布分区和说明文字表达；选一套团队能够持续维护的方式，比建立过细的目录更重要。

画板不能全部叫“详情页”，也不需要把需求说明全文放进名称。订单详情至少可区分“待审批”“审批驳回”“已完成”；若只是同一状态下按钮悬停，通常放进组件状态说明，不必再给整个页面增加一个含混版本。

同一张画板里的图层从“矩形 31、文本 20”改成“状态标签背景、订单编号、驳回原因”，检索和交付时才有意义。不要把图层命名成“蓝色按钮”，因为颜色变化不会改变它提交审批的作用。业务内容可用中文，平台约束的导出资源名再按约定使用 ASCII；不必为了整齐把所有业务名翻成难懂的缩写。

组件名与实例内容也要分开。一个“订单状态标签”组件可有不同状态，实例中显示“待审批”；不能把每个实例重新命名成互不相关的“黄色块”“红色块”。如果需要统一变量与设计令牌，另外参考设计 Token 命名规范，不要把文件目录规则直接套到变量体系。

在“30_开发交付”页面开头放一块说明区，列出本轮范围、负责人、确认日期和变更摘要。例如：“订单审批：新增驳回原因展示；移动端不在本轮范围。”正文对应画板可以变化，但交付入口不应被多个“最终版”取代。

探索稿留在探索区域，旧交付稿进入归档并写明被哪一轮替代。归档不等于删除：研发可能还需要回看当时的间距或交互决定。也不要用文件名上的“已交付”代替真实评审结论；只有团队确认过的内容才进入交付区。

版本说明记录三件事即可：改了哪个对象、为什么改、影响哪些关联状态。比如“PO-03：驳回理由由弹窗改为页内提示，避免重新打开才能看到；同步更新重新提交状态”。一眼就能判断是否需要重新阅读，而不是翻遍整份设计文件。

如果只有文件负责人理解新规则，这次整理就没有结束。请另一位成员找到“订单审批驳回”的交付画板，再指出它的上一个确认版本。找不到时应修正结构或名称，不要求对方记住你的整理顺序。

团队最初只需要约定分隔符、阶段、稳定编号和状态写法。不要把所有名称都限制成相同长度，也不要把作者、日期、设备、版本、审批人全部拼进每一层。文件层已有的信息，下层不必无条件重复。

把常用命名例子留在 Pixso 项目说明页，新模块直接沿用；出现歧义时补一个真实例子。导出给研发的素材另行核对格式与名称，可以接着查看UI 切图的尺寸、格式与命名。设计文件找得到、交付来源说得清、素材能对应上，命名才真正完成了协作任务。