UI设计师切图命名规范：告别 icon_1.png 的尴尬

切图命名规范：终结设计与开发协作中的沟通黑洞

作为一名有七年工作经验的前端开发工程师，我见过太多因缺乏切图命名规范引发的协作困境——打开交付文件夹的那一刻，迎接我的常常是：

icon_1.png
icon_2.png
新的图层.png
新的图层 (1).png
新的图层 (2).png
... (共 287 个文件)

这不是个例。这是大多数设计与开发团队每天都在经历的现实。

切图命名规范，说小是个人习惯，说大是整个团队的协作基础设施。本文从 4 个真实痛点出发，整理出一套不需要死记英文单词、不依赖复杂工具、任何人都能快速上手的系统方案。如果你在寻找批量处理的工具，Renomee 可以在规范建立后帮你 5 分钟内完成 300 个文件的重命名——但工具之前，先把规范搞清楚更重要。

为什么切图命名总是出问题？

在讨论怎么命名之前，需要先弄清楚命名是为了什么。

命名的唯一目的是检索——让你（或者任何一个同事）在需要某个文件时，能快速准确地找到它，而不是在几百个缩略图里凭视觉记忆盲找。

理解了这一点，很多常见的命名误区就迎刃而解了。

误区一：截止日期前"先导出、后改名"

大多数切图命名失控，发生在项目最紧张的时刻。设计师需要在规定时间内完成交付，选择先把图全部导出，改名的事"等会儿再说"——而"等会儿"往往变成了"算了"。

几轮迭代下来，文件夹里混杂着旧版本和新版本、已确认的和待修改的，开发只能靠逐一预览来猜测该用哪张图。

误区二：强行英文，反而没人看懂

几乎所有切图命名规范文章都给出一长串英文词汇表：icon、btn、bg、nav……

但当项目里出现**"拼团"、"发红包"、"种草"、"砍价"**这类本土化功能时，应该怎么翻译？pintuan（拼音）？group-buying（英文）？两种写法同时出现在一个文件夹里，比纯中文命名更难识别。

切图命名的核心目标是让任何人凭名称就能快速定位文件，而不是展示英语水平。

误区三：所有切图堆进一个文件夹

背景图、插画、图标、动效帧全部混在一起。命名不得不"说明一切"：

首页_顶部_导航_搜索_图标_选中状态_24x24@2x.png

文件名越长，越难被记忆，查找效率反而更低。解决这个问题的根本不是改命名格式，而是先建文件夹结构。

误区四：觉得开发会自己改名，所以随意

确实，很多开发团队接收切图后会按自己的命名约定重新整理。但这不意味着设计师可以随意命名。

你的切图命名有一个最基本的职责：让开发在第一眼就能判断某张图是不是他需要的，而不需要放大缩略图逐一确认。此外，在项目迭代修改阶段，你自己也需要快速定位到对应资源——这时候规范命名的价值才会真正体现。

先建结构，再谈命名

分文件夹是切图管理最重要的前置步骤。有了合理的文件夹结构，每个文件夹内部的命名就可以大幅简化。

按类型划分的一级结构

一个典型的 APP 项目，切图资源大致分为以下几类：

切图/
├── 图标/          ← 功能性图标，通常数量最多
├── 插画/          ← 空状态插画、引导页图
├── 背景图/        ← banner 背景、页面底图
├── 动效帧/        ← loading 序列帧等
└── 其他/          ← 不好分类的资源

图标需要继续细分

图标是数量最多、类型最复杂的资源，需要进一步按使用场景拆分子文件夹：

图标/
├── 导航图标/      ← 底部 tab bar，有默认/选中两个状态
├── 功能图标/      ← 首页功能区 icon（通常只有一个状态）
├── 操作图标/      ← 通用操作按钮（编辑、删除、分享等）
└── 社交图标/      ← 平台分享图标等

@1x / @2x / @3x 不需要单独文件夹

很多文章建议为不同分辨率建立独立文件夹，但实际上这样做会增加查找成本。

iOS 开发在 Xcode 中一次性导入三种分辨率，分了文件夹反而需要多次目录跳转。Android 开发虽然项目目录有 hdpi / xhdpi / xxhdpi 等文件夹，但那是开发自行整理的工作，不需要设计师提前处理。

在文件名末尾用 @1x / @2x / @3x 后缀区分即可，文件平铺在同一个文件夹中。

三级命名公式

有了合理的文件夹结构后，每个文件夹内的切图命名只需三级：

模块_名称_状态

层级	说明	示例值
模块	切图所在功能区域	首页、设置、商城、个人
名称	切图内容的直接描述	搜索、购物车、点赞、收藏
状态	该切图的交互状态	默认、选中、禁用、已读

只有一种状态时，省略状态级，保持简洁。

实际命名示例

导航图标/
├── 首页_默认@2x.png
├── 首页_选中@2x.png
├── 发现_默认@2x.png
├── 发现_选中@2x.png
└── 我的_默认@2x.png

功能图标/
├── 搜索@2x.png
├── 购物车@2x.png
├── 扫码@2x.png
├── 收藏_默认@2x.png
└── 收藏_已收藏@2x.png

多层状态时用序号保证排序

当同一个功能入口有多个展示状态（如"详情页有评论"、"详情页无评论"、"评论详情页"），如果只用文字描述，文件会因为首字母顺序而打乱逻辑关系：

❌ 按首字母排序的结果：
详情页_评论详情@2x.png
详情页_无评论@2x.png
详情页_有评论@2x.png

加上序号就能控制排列顺序：

✅ 加序号后的排序：
详情页1_1完整样式@2x.png
详情页1_2无评论状态@2x.png
详情页2_1评论详情默认@2x.png
详情页2_2评论详情空白@2x.png

开发可以按顺序浏览，一眼就能理解文件之间的逻辑关系。

图层命名：PS 和 Sketch/Figma 的关键差异

切图命名的源头，是设计文件里的图层或画板名称。在设计阶段把图层命名做好，导出时自动生成规范文件名，可以彻底消除导出后的二次改名工作。

但不同工具对图层命名的依赖程度差异很大。

Photoshop：图层命名必须精细

PS 选择图层的主要方式是通过图层面板——不像 Sketch 或 Figma 可以在画布上直接点选任意可见元素。在一个包含几百个图层的合成文件中，如果命名全是"图层 1"、"图层 1 拷贝"，每次修改都需要消耗大量时间定位目标图层。

对于 PS 文件：每一个需要单独导出或可能需要修改的图层都要命名，用中文直接描述内容。这类文件命名多细都不过分。

Sketch / Figma / Adobe XD：重点命名，而非全量命名

在这些现代 UI 工具中，鼠标可以直接在画布上点选任意可见图层，对图层面板的依赖远低于 PS。

一个 UI 项目动辄几百个页面和元素，如果真要做到每一个图层都精细命名，需要消耗极大精力去维护，而实际带来的效率提升有限。

建议重点命名以下内容：

1. 最顶层的 Frame / 画板：按功能模块命名，这是导出文件的默认文件名
2. Symbol / Component 内的文本图层：Sketch 的 Symbol 和 Figma 的 Component 需要通过图层名来替换内容
3. 所有标记为"导出"的图形资源：这些图层的名称直接决定导出文件名，必须符合命名规范

对于普通的布局图层，保持合理命名即可，不需要追求形式上的全覆盖。

版本管理：比 Git 更适合设计师的方案

很多文章推荐设计师使用 Git 或 SVN 管理设计文件版本。但这类方案在实际团队中落地困难：需要所有成员熟悉工具操作，发生冲突时处理复杂，且设计文件体积通常较大，不适合版本控制系统管理二进制文件。

更实用的方案是版本回收文件夹法。

操作方法

每当设计文件需要较大改动前，在同级目录创建 _历史版本 文件夹，将当前文件复制进去并按以下格式重命名：

_历史版本/
├── 20260115_v1.0_初版方案.fig
├── 20260201_v1.2_首页改版前.fig
└── 20260218_v2.0_全面改版前.fig

命名格式：日期_版本号_变更说明

主目录始终只保留最新版本的工作文件，保持唯一性和简洁。

这个方案的优势

• 零学习成本：所有人都会复制文件和重命名，无需额外培训
• 历史版本一目了然：按日期排序，找"两周前的方案"直接看文件名
• 不干扰主文件操作：主目录干净，只有当前在用的文件
• 文件体积可控：Figma / Sketch 文件通常几十 MB，存几十个历史版本也完全可接受

多人协作时的唯一性原则

当一个项目有多位设计师协作时，务必保持设计源文件的唯一性：所有人基于同一份主文件工作，存放在团队共享的云盘中（坚果云、飞书云盘均可），不允许各自存副本后独立修改。

一旦每个人电脑上都存有不同版本的源文件，并且各自添加了新内容，合并时将面临极大困难——这是比命名混乱更严重的协作灾难。

用 Renomee 批量处理切图命名

按上述规范手动命名，对于小型项目完全可行。但当一次需要处理 200+ 个图标时，手动操作的时间成本就无法接受了。

场景一：接手命名混乱的切图包

问题：前任设计师离职，切图文件夹里 300+ 个文件命名毫无规律，需要在 2 小时内整理好交给开发。

Renomee 处理流程：

1. 在 Renomee 中创建命名规则模板，定义 {模块}_{名称}_{状态}@{倍率}x 的格式
2. 使用批量查找替换，统一处理命名前缀和后缀
3. 对需要逐一确认的文件，在预览模式下核对后批量应用
4. 全部完成，导出整理好的文件夹

耗时对比：手动操作约 2+ 小时 → Renomee 约 10 分钟

场景二：版本迭代后的批量版本号更新

问题：项目从 v1.0 迭代到 v2.0，所有切图文件名中的版本标记需要同步更新，部分模块名称也做了调整。

Renomee 处理流程：

1. 批量查找替换：_v1.0 → _v2.0
2. 针对模块名变更（如"消息中心"改为"通知中心"），精准替换指定词
3. 预览确认，一键应用，无遗漏

关于如何在设计文件全流程中建立完整的命名体系，可以参考设计师必看：设计文件命名的黄金法则。

切图命名常见问题

命名到底用中文还是英文？

切图交付物用中文就好。

设计团队的主要沟通语言是中文，"搜索图标"比 search_icon 更直接，不会产生拼写歧义，也不会因为不同人的英语水平差异而形成不一致的命名。

唯一的例外是：如果开发团队明确给出了英文命名要求，那就按开发提供的规范执行。但这是例外，不是默认选项。

开发说他们会自己改名，还需要我做规范吗？

需要。

你的切图命名的价值，不只是给开发看。在项目修改阶段，当 PM 说"把第三稿首页的搜索图标换一下"，你能否在 30 秒内定位到对应文件并找出它的所有状态版本，才是命名规范真正发挥效用的时刻。

如何从根源上避免二次改名？

在 Sketch、Figma 中，Frame / 画板的名称就是导出文件的默认文件名。在设计阶段就按命名规范给 Frame 命名，导出时自动生成规范文件名，无需任何额外步骤。

这是减少切图改名工作量最根本的方法，成本在设计阶段就被分摊了。

总结

一套好用的切图命名规范，核心不在于格式有多复杂，而在于让任何人打开文件夹时，凭名称就能判断每个文件是什么。

本文的核心方案：

• 先建文件夹结构：按类型划分，减少每个命名需要承载的信息量
• 三级命名公式：模块_名称_状态，说人话，不强求英文
• 序号控制排序：有多个相关状态时，前置序号确保逻辑顺序
• 图层命名看工具：PS 必须精细，Sketch/Figma 重点命名导出资源
• 版本管理用文件夹：日期_版本号_说明 比 Git 更适合设计师
• 源文件保持唯一性：多人协作时避免各自存副本独立修改

规范建立后，批量重命名的机械工作交给 Renomee 处理——把节省下来的时间，留给真正需要创意的设计工作。

---

立即下载 Renomee | 设计文件命名完整指南