生成一次不难，难的是同一批需求连着出十几版之后，还能说清楚每个文件从哪来、哪版在用、上次返工是因为什么。建议把批量出资产当成一条带账目的流水线：文件命名负责“身份”，版本后缀负责“顺序”，返工记录表负责“原因”。三样里面缺一样，第二个人接手或者隔一周再看，判断成本就会迅速变高。下面的规则都可以先用一个小批次跑一遍，再决定是否扩大到全部需求。

适用场景是同一类资产需要反复生成多个版本，而且存在换人接手、跨周回看的情况。操作上先固定资产标识字段，再固定版本后缀，然后用一张枚举式的返工记录表收集原因，按批次统计后把高频问题前置到输入准备阶段。验证方式是随手挑一个文件，只凭文件名加记录表就能回答：谁生成、属于哪个批次、基于哪版改的、为什么改。风险边界：字段一多协作者就不愿意填，命名和表格都应控制在最小可用集合；如果生成端或导出端不能写入自定义文件名和附加字段，需要先确认这一点，否则规则只能停留在人工改名层面，容易漏。

给每次生成分配可读的资产标识

资产标识的目标是让文件名本身携带来源信息，脱离文件夹也能判断归属。建议的字段组合是：项目或需求代号、资产类型、批次（日期加当日批次序号）、批内序号、版本后缀。字段之间用双下划线连接，避免空格、中文标点和大小写混写，减少跨系统传输时被改写。

# 示例命名（不含任何真实下载地址）
brand_A__img__20240612_b03__007__v1.png
brand_A__img__20240612_b03__007__v2-edit1.png
brand_A__copy__20240612_b03__015__v1.md

上面第一段是项目代号，第二段是资产类型，第三段是批次，第四段是批内序号，第五段是版本。目录可以按 assets/<项目>/<类型>/<批次>/ 分层，但文件名仍要写全字段，原因是一旦有人把文件挪到聊天工具或工单里，目录信息就丢了。生成时用变量拼接，避免手敲出错：

PROJ=brand_A; TYPE=img; BATCH=20240612_b03; SEQ=007; VER=v1
NAME="${PROJ}__${TYPE}__${BATCH}__${SEQ}__${VER}.png"
printf '%s\n' "$NAME"

验证方式很简单：进入资产目录执行一次文件名列举，看每个名字能否被不熟悉项目的人读出批次和顺序。字段不要无限加，提示词全文、模型参数这类长内容不适合塞进文件名，放到记录表里更合适。

用版本后缀区分重生成与手动修改

重生成和手动修改要分开表达，否则回退时分不清“哪一版是模型重新跑的”“哪一版是人在上面动过的”。建议规则是：模型重新生成一次，主版本号加一，写成 v1、v2；在某一版基础上人工修改，保留主版本号并追加修改序号，写成 v2-edit1、v2-edit2。任何情况下都不覆盖旧文件，新结果一律写新文件名，旧文件保留到批次归档。

回退时的查找方式是按前缀加版本排序取目标版本，而不是凭文件名里的时间戳猜测：

# 列出同一资产的全部版本，按版本号排序看尾部几项
ls assets/brand_A/img/20240612_b03/ | grep 'brand_A__img__20240612_b03__007__' | sort -V | tail -n 5

需要回到 v1 时，把使用方配置指向 v1 文件，同时在记录表里把状态列改成“在用”，把 v2 及之后的版本标成“已被替代”。只靠版本号大小判断哪个在用并不可靠，因为存在“试了 v3 又退回 v2”的情况，状态必须由记录表承担。验证方法是随机挑一个资产，按上述命令能完整列出历史版本，并且记录表里的在用版本与使用方配置一致。

记录每次返工的具体原因

返工原因如果只写“不太好”“再调一下”，下个月就没人能统计。建议把原因做成固定枚举，让填写人从列表里选，再补一句自由描述。常用分类可以先定这几项：提示词表达不清、参考素材缺失或不准、风格不符、构图与布局问题、文字或小字渲染错误、尺寸比例不符、内容重复、合规与审核要求、需求方临时调整方向、工具侧失败或输出被截断。

记录表建议用表格或 CSV 维护，字段保持精简但可查：

asset_id,version,rework_time,trigger,reason_type,note,input_snapshot,fix_action,status
brand_A__img__20240612_b03__007,v2,20240612_b03,提交人A,文字渲染错误,画面底部小字糊,assets/inputs/20240612_b03/007.md,缩短文案并放大字号,已替代

其中 input_snapshot 建议保存当时使用的提示词或需求描述副本路径，fix_action 写这一版实际改了什么，status 标记在用、已替代或废弃。验证方式是让协作者补录一条返工记录，看他是否能在不看说明的情况下选对原因分类；如果经常选错，说明枚举项之间边界不清，需要合并或改名。

定期回看返工记录找出高频问题

记录只有被统计才有价值。建议按批次结束或每周固定回看一次，统计维度可以先取四项：原因分类计数、资产类型分布、触发人分布、提示词版本分布。按原因分类计数最直接，假设 CSV 第 5 列是原因分类：

awk -F, 'NR>1{c[$5]++} END{for(k in c) print c[k], k}' rework_log.csv | sort -nr

统计结果要落到具体的输入检查动作上，而不是只留一个排名。常见对应关系是：文字渲染错误偏多，就在输入阶段固定文案清单，避免让模型生成画面中的小字；风格不符偏多，就把参考图和风格词整理成清单，要求提交时附上；尺寸比例不符偏多，就在输入模板里锁定宽高比并在提交前核对；参考素材缺失偏多，就在批次开始前做一次素材齐套检查。触发人维度只用于判断是否需要补充说明或培训，不宜用来评价个人。验证方式是下一个批次继续记录同类原因，观察条数变化，不做任何比例承诺。

把稳定流程写成给协作者的交接说明

流程跑顺之后，把它固化成一份短说明放在资产目录根部，比口头交接有效。说明里至少包含：命名规则与字段含义、版本后缀含义、记录表位置与必填字段、批次开始前的输入检查清单、回退步骤、明确禁止的动作（覆盖旧版本、随手改名、把文件挪出批次目录），以及谁负责确认在用版本。

# 资产批次说明（示例片段）
命名：项目__类型__批次__序号__版本.扩展名
版本：vN 为重生成；vN-editM 为人工修改；不覆盖旧文件
记录表：rework_log.csv，批次结束前补齐 reason_type 与 fix_action
回退：按前缀 grep 后 sort -V 定位目标版本，改使用方配置并更新 status 列
禁止：覆盖已有版本、改动他人文件名、把资产移出批次目录

交接说明要能被验证：让一个没参与过该批次的人按说明完成一次小批量的生成、命名和记录，遇到卡点就补进说明。说明篇幅控制在一屏内更实用，过长会被跳过；细节可以拆到单独的检查清单文件里，但入口仍指向同一份说明。