外包修图验收单模板：用图叮把禁改区、版本号和上线截图交接清楚

外包修图最容易卡住的地方，不是修图师不会修，而是验收的人手里只有一张修后图。运营说“Logo 好像变形了”，外包说“你没说 Logo 不能动”，负责人再去翻聊天记录，已经晚了。

这篇给一张更硬的验收单写法。它接在图叮处理之后，用来记录：原图是谁给的、图叮改了哪里、哪些区域不能碰、外包二修只负责哪一段、上线后用哪张截图确认。它不是把流程写复杂，而是把争议提前摊开。我的习惯是把它做成一张 CSV 或飞书表，字段少一点，但每个字段都能落到文件名和截图上。

如果你还在搭输入端，可以先看站内的 AI 修图需求单怎么写：先把输入说清楚，再谈出图效率。那篇解决“任务怎么发出去”。本文解决另一个问题：图叮已经产出初稿后，怎么让外包、运营、负责人用同一张表验收。

图注：验收表把原图、初修图和禁改区放在同一行

Step 1：先把原图和禁改区放进同一行

验收单第一行不要从“修后图链接”开始。先写原图。

我会放 6 个字段：

• SKU 或商品编码：例如 HX-204-white-01，不要只写“白色款”。
• 原图文件名：保留拍摄时的原始编号，方便回滚。
• 图叮初修文件名：例如 HX-204-white-01_tuding_v1.webp。
• 禁改区：Logo、型号标签、尺码线、接口、瑕疵、证书编号，能写具体就别写“细节”。
• 可修区：背景灰尘、台面划痕、轻微反光、边缘杂物。
• 责任人：谁判断禁改区，谁做最终验收。

这个顺序很像写一个小 schema。先定义不可变字段，再允许修图动作进来。对跨境团队尤其有用，因为 Amazon、Shopify 或独立站同一张图可能被投到不同 channel。你只把修后图丢给外包，外包无法知道哪一块是商业证据，哪一块只是拍摄瑕疵。

图叮在这里的价值是先把低风险区域处理掉。比如清背景、压反光、统一白底、轻微补边。然后验收单把“模型已经动过的区域”写清楚。这样外包二修不是重新开盲盒，而是在一个可控初稿上做局部确认。

这一行可以长这样：

字段	示例写法
SKU	HX-204-white-01
原图	IMG_8321.CR3 / IMG_8321.jpg
图叮初修	HX-204-white-01_tuding_v1.webp
禁改区	正面型号贴、底部防伪码、右侧接口孔位
可修区	白底脏点、左下角反光、边缘轻微毛边
验收人	运营 A / 类目负责人 B

不要把禁改区写成“重要信息”。这四个字没有执行力。写“正面型号贴”才有执行力。

Step 2：把图叮处理结果拆成可验收字段

第二步开始看图叮结果。这里不要写“已修好”。我建议拆成 6 列：背景、主体轮廓、文字标签、材质纹理、尺寸参照、导出规格。

背景列只判断背景是否干净、是否保留自然接触阴影。主体轮廓列看边缘有没有被削薄、孔位有没有变形。文字标签列只看可读性，不让任何人顺手“美化”字形。材质纹理列看皮革、金属、布料、透明塑料有没有被磨成同一种质感。尺寸参照列看手、尺、包装、配件是否还在。导出规格列看比例、像素、压缩和命名。

这一步很适合用图叮做第一轮 review。把原图和初修图放在同一屏，先让团队只看差异，不谈审美。你会发现很多争论会消失：背景脏不脏是一类问题，型号有没有漂移是另一类问题。前者可以继续修，后者必须回到原图或局部保护。

如果你们已经把修图任务搬到任务板，可以接着读 产品精修交接单怎么写：材质、阴影和比例别让修图师猜。交接单解决输入边界，验收单解决每张图的判断依据。两个东西不要混成一张大表，否则字段会越来越多，最后没人填。

我的经验是，每张图最多给 6 个验收字段。多了以后，运营会把表当报告写；少了以后，外包会把它当一句口头需求理解。6 列刚好能覆盖大多数商品图风险。

Step 3：给外包二修留一个最小可执行备注

外包二修备注要短。短到像 task comment，而不是像设计稿说明。

我会用这个格式：

动作 + 范围 + 停手线

举几个假设场景：

• “压低左上角反光，只处理背景，不碰瓶身高光。”
• “清掉底座灰尘，螺丝孔、刻度线和型号贴保持原样。”
• “右侧边缘补齐 2-3px，不能改变接口孔位。”
• “白底统一到主图标准，接触阴影保留，不做悬浮感。”

这里可以带一点极客做法：备注字段后面加一个 risk_level，只写 low / medium / high。low 是背景和灰尘，medium 是局部补边和轻微反光，high 是文字、结构、证据区。外包看到 high，就知道必须等运营确认，不要直接交最终图。

图叮做初修时，很多低风险动作已经能解决。外包的价值应该放在高风险判断：标签是否清楚但不改字，材质是否干净但不变质，尺寸参照是否突出但不抢主体。验收单把这个边界写出来，外包就不会被迫用审美去猜业务规则。

同类底层逻辑可以参考 产品精修规范化检查实战：电商平台要求与自检清单。那篇偏平台和自检框架，本文把框架落到外包交接字段。

Step 4：用上线截图做最后确认

只看导出的 WebP 不够。商品图上线后会被裁切、压缩、套模板，还会在移动端缩略图里变小。很多问题不是在修图软件里出现，而是在页面里出现。

图注：上线验收要同时看列表、详情页和移动端截图

所以验收单要有“上线截图”这一栏。我通常要求至少 4 张截图：主图列表缩略图、详情页首屏、移动端商品页、客服可能会引用的举证图。不是每个团队都要四张都存，但至少要知道哪张是最终确认依据。

这一步图叮也能帮你做前置判断。比如先把一组图统一成同一背景和比例，再拿去页面里看。如果同款 SKU 在列表页里一张偏灰、一张偏蓝，问题就不是外包有没有修干净，而是批量一致性没过。

上线截图字段建议这样写：

字段	填写要求
主图截图	列表页或商品页首图，能看出裁切是否安全
详情页截图	放在真实模块里，看文字和证据区是否可读
移动端截图	小屏下检查标签、接口、尺寸参照是否糊掉
客服举证截图	售后可能引用的图，不能把关键证据修没

如果团队已经有上线前复看动作，可以把 商品图上线前质检清单：12 个容易漏掉的小问题 当下一步阅读。本文的表只负责把“哪张截图算通过”固定下来。

Step 5：把版本号和回滚图留到同一个目录

最后一步是版本。别等出事再找原图。

我建议每个 SKU 保留 5 个文件：原图、图叮初修版、外包二修版、上线版、回滚说明。目录可以朴素一点：

/SKU/HX-204-white-01/
  original_IMG_8321.jpg
  tuding_v1.webp
  vendor_v2.webp
  live_2026-05-29.webp
  rollback_note.txt

rollback_note.txt 不用写长。只写三件事：回滚原因、回滚到哪一版、以后同类图的禁改提醒。比如“型号贴字形被改，回滚到 tuding_v1；下次型号贴进入 high risk”。

这个动作对 batch 很重要。一次处理 3 张图时，你可以靠记忆；一次处理 300 张图时，只能靠命名和目录。Ws.Han 式的处理习惯就是这样：能让机器读懂的字段，就不要藏在聊天记录里。哪怕你不用 Python 自动化，文件名和目录也应该像可执行脚本一样稳定。

到这里，验收单就能跑起来了。它不追求华丽，追求可复查。图叮负责把初修质量和局部处理效率提上来，验收单负责让团队知道哪些结果能继续流转、哪些必须停下来。下一步可以把这张表接进你们的任务板或批量命名规则里：一行一个 SKU，一列一个风险，少写形容词，多写能复核的证据。