AI 修图工作室 5 万张图素材库管理：文件命名、备份、检索 SOP

2026 年 4 月 9 日 22:17，杭州一家做电商精修的小工作室接到老客户消息：去年双 11 那 36 张小家电主图，品牌方想补 4K 版上明天的 banner。项目协调在 NAS、3 块移动硬盘、百度网盘里翻了 47 分钟，只找到压缩过的交付 JPG；老板才想起那块装 PSD 的硬盘上个月借给新人了。团队连夜重跑 19 张，半天利润被这次补图吃掉。

这篇文章不教你怎么修图，也不讲 NAS 怎么开机。它解决的是另一个问题——你已经能稳定出图、稳定接单，素材也悄悄从几千张涨到了 5 万张，桌面文件夹和移动硬盘开始扛不住的那一刻该怎么办。

5 万张图不是存储问题，是版本和责任问题

很多人以为素材库膨胀的瓶颈是硬盘容量。其实在 AI 修图工作室里，到 5 万张那一刻最先压垮你的不是 TB 数，是版本和责任。

5 万张大致是这样积起来的：2-8 人小团队，月交付 800-3000 张图，跑了 8-18 个月就够了。其中客户原图、AI 出稿、PSD/PSB 工作版、QC 返修中间版、多种规格的最终交付包，每一档都是一份。按产品精修的常见结构估算，原图 RAW/JPG 一般 2-4TB，工作版 PSD/PSB 4-8TB，交付 JPG/PNG/WebP 0.5-1.5TB，再加上缓存、重复文件、压缩包，10TB 这条线很快就摸到。

容量到 10TB 不算难事，硬盘越来越便宜。难的是这 5 万张里至少有 60% 不是孤儿——它属于某个客户、某个项目、某个 SKU，可能有 3 个版本、2 轮返修、4 种导出规格。一旦客户回头说”去年那批图我想补 4K”，你需要的不是把它找出来，是同时找出”原图、最终 PSD、当时签字的版本号”三件事。素材库管理的核心不是收纳，是让这三件事在 3 分钟内能被任何团队成员复现。

这件事在 AI 出图能力升级之后更紧迫。GPT Image 2 的 2K/4K 直出能力上线之后，老客户重新捞旧图升级规格的频率明显变高，图叮AI 接入 GPT Image 2 2K/4K 升级公告 里就提过这个趋势。原本”交付即归档”的项目，现在很可能在半年后被翻出来再跑一遍。素材库如果还是凭记忆找文件，就会被这种长尾需求一次次反复打脸。

接下来讲的 5 段——命名、目录、备份、检索、归档——是按”出事的顺序”排的：先解决文件名，然后解决目录，再讲备份与检索，最后才到归档。如果你团队还在初次跑通交付流程的阶段，先把 新手 AI 修图首次交付前的检查清单 走一遍更顺，再回头看素材库 SOP 才不会落地不下来。

先统一命名：客户、项目、SKU、版本 4 段式

文件名是素材库里最便宜也最有杠杆的工具。每改一次命名规则，下游的搜索、归档、备份脚本都会跟着省事。

我们建议的命名格式是 4 段式：

客户代号_项目代号_SKU_版本-规格.扩展名

落到具体例子：

MEIXIANG_202604-SpringLaunch_KT3001_orig01-RAW.CR3
MEIXIANG_202604-SpringLaunch_KT3001_v03-WIP.psd
MEIXIANG_202604-SpringLaunch_KT3001_v03-r02-WIP.psd
MEIXIANG_202604-SpringLaunch_KT3001_v03-final-4K.jpg
MEIXIANG_202604-SpringLaunch_KT3001_v03-final-2000x3000.jpg

四段各自的取值规则可以先记成 4 句话：

• 客户代号：拼音或英文大写，6-12 字符（例如 MEIXIANG）。同一客户多个品牌时再加品牌后缀，如 MEIXIANG-KT。代号一旦定下来不要改，所有历史项目跟着改名是噩梦。
• 项目代号：YYYYMM-项目英文名 的格式，如 202604-SpringLaunch。前缀年份月份让按时间排序天然成立，后面那段英文名只是给人读的，不参与匹配。
• SKU：客户已有 SKU 优先（比如 KT3001），客户没有就用内部编号 SKU00037。这一段是检索时最容易命中的字段。
• 版本：原图用 orig01/orig02 标记客户提供的原始素材轮次，跟内部产出版本区分；v01/v02/v03 表示团队内部的大版本，r01/r02 表示客户返修轮次，final 表示已签字定稿。多规格用 -2000x3000 或 -4K 后缀，例如 v03-final-4K.jpg 表示”v03 大版本签字定稿的 4K 规格”。

四段之间一律用下划线 _ 分隔，段内细分用短横线 -。空格、中文括号、连续多个横杠都不要进文件名，跨平台路径处理会出怪事。还有一个反直觉的提醒：不要把修图师姓名塞进文件名。责任人记录放在任务系统、Notion / 飞书表的属性里，文件名只承担”这是什么”的职责，不承担”这是谁做的”。两件事放一起，到了归档阶段会绊住一大批自动化脚本。

如果你的团队还没把客户、项目、SKU、交付状态这几件事和任务系统打通，图叮 + Notion / 飞书 工作流集成模板 里有一套现成的 4 张数据库设计，可以让命名规则和任务卡之间天然对齐——客户代号、项目代号、SKU 三段在 Notion 里就是三个 relation 字段，文件名是它们拼出来的副产物，不需要修图师每次手敲。

目录只分 3 层：原图、工作版、交付版

文件名稳定之后，目录是第二个杠杆。我们见过最容易出事的几种目录结构：

• 按修图师姓名分（小张文件夹 / 老王文件夹），人一走文件就成孤岛；
• 按月份分（202404 / 202405），客户一回头要 SKU 谁也找不到；
• 按”临时 / 待修 / 完成”语义分，状态一变就要搬家，搬到一半就乱。

更稳妥的是只分 3 层：原图、工作版、交付版。每个项目固定下面这棵树：

MEIXIANG_202604-SpringLaunch/
  01_RAW/
    00_from-client/
    01_selected/
    99_rejected/
  02_WORK/
    01_ai-output/
    02_psd/
    03_qc-return/
    04_temp-cache/
  03_DELIVERY/
    01_preview/
    02_final/
    03_client-feedback/
    04_delivery-package/

口径只有三句话：

• 01_RAW 只放客户给的原始素材和筛选结果，不放任何修过的图。
• 02_WORK 放 AI 出稿、PSD/PSB、返修中间版、临时缓存——这是体积最大、最容易乱的一层。
• 03_DELIVERY 只放发给客户或准备发给客户的版本，每次交付按日期打包，例如 MEIXIANG_202604-SpringLaunch_delivery_20260427.zip。

子文件夹前面的两位数字（01_、02_、99_）只是为了在文件管理器里强制排序。99_rejected 故意放在最后一位，是为了”鸡肋图”被自然忽略，但又不至于被删掉。这个习惯从摄影行业借来，特别适合素材量大的工作室。

3 层目录的另一个好处是责任划分天然清晰。在 3 人 AI 修图工作室分工 SOP 里，项目协调对 01_RAW 和 03_DELIVERY 负责（接收和交付的两端是 ta 的事），修图师对 02_WORK 负责（生产环节），质检在 03_DELIVERY/01_preview 卡门。这种”谁动哪一层”的边界，比写在岗位说明书里更有效。

10TB 小工作室的 3-2-1 备份怎么落地

3-2-1 是 IT 圈早就达成的共识：3 份数据，2 种介质，1 份异地。但很多小工作室的实际状态是 1.5-1-0：一份在工作机、半份在某块移动硬盘、异地备份完全没有。这一节给一组截至 2026-04 公开渠道可查的方案，10TB 量级直接抄。

层级	配置建议	用途
本地工作盘	2-4TB NVMe SSD + 8-12TB 外置 HDD	SSD 只放当周项目；外置盘做当天镜像，每晚自动同步
NAS 主库	4 盘位 NAS，4×8TB 或 4×12TB 硬盘	跑 RAID 5 / Synology SHR-1，可用容量约 24TB / 36TB
云端冷备	阿里云 OSS / 腾讯云 COS / 阿里云盘 / 百度网盘择一	只传交付包、原图压缩包、关键 PSD，不传全部缓存

RAID 选择上有 3 个建议，是从踩过坑的同行那里抄来的：

• 本地工作盘不要做 RAID 0，速度高但坏一块整组丢；工作室素材盘优先 RAID 1 或单盘+自动同步。
• 4 盘 NAS 走 RAID 5 / SHR-1 比较均衡，能用 1 块盘的容量换容错。
• 6 盘以上再上 RAID 6；4 盘 RAID 6 可用空间太低，10TB 起步团队不划算。

具体型号上，截至 2026-04 主流 4 盘位 NAS 大致有 3 档可选：稳妥派 Synology DS425+，2.5GbE+1GbE 双口，对小白最友好；性价比派 QNAP TS-464，双 2.5GbE+M.2 缓存位，多工位并发拷图比较舒服；折腾派绿联 DXP4800 Plus，2.5GbE+10GbE，适合愿意自己配置权限和网络的人。三个具体配置都按官方说明书摆，自己按预算挑。

云端那一份冷备最容易被忽略。常见误区是”NAS 已经 RAID 了不用云备份”——RAID 防的是单盘故障，不防火灾、不防水浸、不防误删。云端只放交付包、原图压缩包和关键 PSD，不传全部缓存和废稿。阿里云 OSS 归档型存储 10TB 量级的年包公开报价大致在四位数人民币区间，取回和外网下载另算；阿里云盘和百度网盘对小工作室够用，缺点是团队权限粒度弱、自动化能力一般。客户隐私敏感的项目，云端只放加密压缩包，命名也别暴露客户品牌。

备份不只是花硬件钱，还要花时间。每天的镜像、每周的差异同步、每月的归档迁移，都会占用工时。这一段如果没有在工时核算里算进去，后面会变成”明明每月都在备份，但没人记得清谁做了”。AI 修图工时统计 3 套方案对比 里给过几种把运维时间算进项目成本的模板，团队规模到 3 人以上时建议直接抄一份。

检索工具怎么选：Bridge、Lightroom、Eagle 各自管什么

5 万张图最反直觉的一件事是：硬盘装得下、找不到。文件管理器里翻 30 个文件夹和 5 万个 SKU 是两回事。这时候就轮到检索工具登场——但市面上的检索工具不是分”好与坏”，是分”管什么”。

Adobe Bridge、Lightroom Classic、Eagle 三个我们都用过。它们其实是分工的，硬要二选一往往越用越卡。

工具	体量门槛	上手难度	价格（截至 2026-04 公开渠道）	适用场景
Adobe Bridge	1 万 - 20 万文件	低	官方免费下载	文件夹式素材库，PSD / JPG / AI 文件预览，批量重命名，元数据
Lightroom Classic	2 万 - 15 万照片	中	Adobe 摄影计划（含 Lightroom Classic + Photoshop）官方月费约 US$19.99	RAW 管理，拍摄批次筛选，调色预设，本地目录库
Eagle	5000 - 8 万参考图	低	一次性授权官方现价约 US$34.95，2 台设备激活	灵感图、参考图、风格板、标签检索

Bridge 是免费的，对 AI 修图工作室来说几乎是默认起点。它直接读文件夹，不强制导入，PSD/PSB 预览也快，批量重命名和 EXIF/IPTC 元数据写入都内置。生产素材主库放在 NAS 上，再用 Bridge 当窗口看，是大多数小团队跑得最久的组合。

Lightroom Classic 的优势在拍摄阶段。如果工作室里有摄影位（产品摆拍、模特拍摄），RAW 管理、拍摄批次筛选、调色预设走 Lightroom 比 Bridge 顺。但 Lightroom 是”目录库”模型，会建一个独立的 catalog 文件，多人协作时容易踩坑——同时打开同一个 catalog 会冲突。它适合 1 个摄影师独占使用，把成片导出之后再交回主库。

Eagle 不一样，它是”灵感库”路线。拖 Pinterest、电商图、竞品截图进去，按标签和颜色检索，找参考图特别快。它不适合当主交付库——5 万张工作版和交付版扔进 Eagle，多人同步、权限、跨设备打开都会变形。Eagle 的合理位置是放在每个修图师的本地，专门管参考图和风格板。

简单说：生产素材主库走 Bridge + 目录规范，摄影原片走 Lightroom Classic，灵感参考图走 Eagle。三个工具不是替代关系。

交付完成后多久该压缩、什么时候可以删原图

最容易被忽略的一块是归档。很多小工作室没有归档策略，只有”硬盘满了就买新硬盘”。但 5 万张里大约有一半其实不需要随时在线——一旦交付确认、过了售后期，它就该进冷库。

可以按下面这个时间线落：

时间点	推荐动作
交付后 0-7 天	不压缩、不移动，等客户第一轮反馈和可能的小返修
交付后 8-30 天	03_DELIVERY 打包成 ZIP，02_WORK 保留可编辑文件
交付后 31-90 天	临时缓存、AI 中间废稿、99_rejected 内容可清理
交付后 90-180 天	原图 + 最终 PSD + 交付包整体压缩进归档区
180 天后	低价值项目仅保留原图压缩包、最终交付包、关键 PSD

压缩格式分两档：

• 普通交付包：.zip，压缩等级 6，客户和团队打开都方便；
• 长期归档：.7z，LZMA2，压缩等级 5-7，分卷 4GB 或 10GB，便于上传云端；
• 隐私客户：.7z + AES-256，密码放 1Password、飞书妙记或 Notion 的权限库，不要写在压缩包旁边的 readme 里。

删除原图这一步最敏感。我们见过工作室因为提前删原图被客户索赔的案例，也见过把所有原图永久保留导致 NAS 半年塞爆的。建议把”什么时候可以删”写成 4 个并存的条件，全部满足才动手：

• 合同或报价单里的原图保留期已经到期；
• 客户已签字确认终稿，并且超过售后返修窗口（通常 30-90 天，看合同）；
• NAS 和云端各有一份归档压缩包，校验通过；
• 删除前导出一份 archive-manifest.csv，记录客户代号、项目代号、SKU 数、文件数、压缩包名、归档日期、操作人。

那份 manifest 是关键。它不大，几兆，但在客户半年后回头补图时，它告诉你”那批图归档在哪个云端 bucket、压缩包密码在哪个保险箱、当时谁动的手”。比起翻硬盘、翻聊天记录，找一份 CSV 是 1 分钟的事。

系统比记忆更可靠

回到开头那个杭州工作室的故事。他们后来花了 3 个周末把素材库重做了一遍：客户代号统一规范，3 层目录铺到所有项目，4 盘位 NAS 上线，云端只备交付包，Bridge 当主检索窗口。

第二次老客户回头补图，是 2026 年 4 月底。这一次项目协调在 Bridge 里搜 MEIXIANG + KT3001 + final-4K，3 分钟之内把原图、最终 PSD、交付 ZIP 三件事都摆到了修图师的屏幕上。客户没有听到那句”我们找一下”，老板没有再问”硬盘借给谁了”。会议结束的时候没人专门讲这件事，仿佛它一直就这样。

素材库整理到最后，不是为了文件夹排得好看，是为了下一次客户催图时，团队不用靠记忆救火。5 万张图本身不会让你赚钱也不会让你亏钱，决定差距的是它有没有一套别人也能照着做的 SOP——你休假那一周新人能找到图，半年后客户回头你还能找到原图，团队从 3 人变 5 人时这套规则不用推倒重写。命名、目录、备份、检索、归档这 5 段，每一段的意义都不在它自己，而在于把”这件事下次别人怎么做”这个问题提前回答好。