企业官网建设流程全解析

做全托管供货的老哥，最近是不是又被平台的图片质检搞到心态崩了？上一秒还在为出单量兴奋，下一秒就收到驳回通知，理由通常是“图片存在非目标语言信息”“图片包含水印或第三方标识”“图片做过不当遮挡处理”。我在跨境供货圈里泡了几年，这类驳回见得实在太多了。全托管模式下供货商不掌握前台运营，图片就是平台替你把关的第一道“入场券”，过不了质检，链接根本不会推到前台。今天把我自己折腾出来的一套AI批量清洗图片中文与水印的方法完整写出来，包含原理、可改用的脚本、复检步骤和真实效果对比，想给同样卡在图片审核这一关的朋友做个参考。文章里所有案例都脱敏处理，工具也只讲通用方案，不会有任何引导违规的操作。

1. 全托管供货的图片质检，到底在卡什么？

1.1 为什么图片会变成“入场券”

全托管模式和传统店铺运营最大的区别是：供货商只负责把货品和基础素材交上去，平台负责后续的定价、营销、物流和售后。听起来很省心，但代价是你失去了直接编辑商品信息的权限。平台拿到你的图片、标题、描述之后，会先进一个统一的素材审核池，用机器模型批量打分，再抽样转给人工复核。

图片审核被放在很靠前的位置，原因很简单：前台消费者看到的商品主图、详情图，全都来自你这批素材。平台需要确保这些图片能直接适配海外用户的浏览习惯和平台自身的合规标准。换句话说，你的图片质量不只影响点击率，还直接影响你能不能顺利进入销售环节。我见过不少供货商，产品本身没问题，价格也有竞争力，就因为图片反复驳回，错过了整个活动周期。

1.2 我见过的三类真实驳回理由

结合我自己操作过的批量供货项目，以及身边供应商反馈的情况，图片驳回理由表面五花八门，但归纳起来离不开下面三类。

注意最后一项，很多人以为“只要遮住中文就没事了”，结果用马赛克抹掉之后照样被驳。因为平台不仅有OCR，还有图片一致性检测。马赛克区域本身就是明显的“异常区块”，会被判定为刻意遮挡，同样过不了审。这个细节后面会重点展开。

2. 中文和水印为何是“重灾区”？背后原理拆解

2.1 中文为什么会触发平台警报

先说结论：平台质检对中文的敏感度，远高于对英文的敏感度。这背后的逻辑并不复杂。

全托管模式的销售站点主要在海外，目标消费者多数看不懂中文。如果商品主图上带有中文，比如“厂家直销”“超低价”“今日特惠”这类字样，消费者会产生两个反应：要么觉得这个商品不是本地化运营的，不信任；要么根本不知道图面上讲的是什么，影响购买判断。平台最怕的就是这种“用户看不懂”的素材。

更深一层，图片上的中文经常伴随营销话术和价格信息。平台对“引导性促销用语”是有明确限制的，因为全托管模式的价格和优惠策略由平台统一制定，供货商图片里如果出现“全网最低价”“联系客服有优惠”这类字样，会被视为绕过平台规则做站外引导，直接判违规。所以中文在图片里几乎是“一票否决”的。

我自己的经验是，只要主图里出现超过两个中文字符，机器审核阶段就被拦下来了，根本轮不到人工。标题页里那些中文商品描述，也最好不要直接截图进详情图。

2.2 水印不只是美观问题，还是版权与流量违规信号

水印比中文还麻烦。中文至少可以解释为“忘记翻译”，水印在平台眼中只有一个意思：素材来源不干净。

先说版权层面。很多供货商手上的图片是从其他渠道拿来的，上一个卖家可能留下了店铺水印、来源平台角标。平台一旦识别出这些标识，会认定图片有侵权风险。全托管模式里平台是销售主体，它对版权风险极度敏感，因为一旦被投诉，责任会落到平台身上。所以带水印的图，平台宁可错杀也不放过。

至于平台上常见的“联系方式水印”，比如微信号、手机号、线下店铺地址，问题就更大了。这类水印触发的不是版权审核，而是“站外引流”风控。平台在全托管模式里最忌讳供货商私联消费者，图片上的联系方式等于直接告诉平台你有导流意图。我接触过的一个供应商，主图角落有个很不起眼的手机号水印，结果整批链接被限制上架，申诉也没有用。

此外，水印还意味着“复用痕迹”。平台系统会通过图像指纹比对，判断这张图是不是已经在其他渠道大量出现过。如果一张图有旧平台的角标，大概率已经在别处用过了，平台会认为图片重复，影响整体的素材多样性。

2.3 容易被忽略的“看不见的脏数据”

很多朋友以为规范化图片就是把看得见的字抹掉，直到被驳之后还在抱怨“图面上已经干净了”。实际上平台质检不只读图面上的像素，还会检查文件本身的属性信息。

以图片的EXIF信息为例，如果原始图片是从某个旧的电商渠道下载的，EXIF里可能残留着“软件来源”“原始相机型号”等信息，平台在机器审核阶段完全有可能读取并作为参考。还有文件名，如果你上传的图片叫“xx平台主图.jpg”或“中文批发logo.jpg”，等于在元数据层面再次暴露了来源。这类问题不用急着反驳“我图面已经改了”，平台确实有办法通过多维信息交叉判断。

再加上透明通道这个容易被忽略的坑：很多供货商交付的是PNG格式商品图，PNG有alpha通道，通道里可能还带着旧水印的透明图层痕迹。你用看图软件直接看，会觉得图面正常，但把alpha通道单独提出来，水印轮廓清清楚楚。这类图片被平台检测到，驳回理由照样是“包含水印”。

所以，AI批量清洗做的不只是“擦图”，而是把“图面上看得见的文字水印”和“图层里、文件属性里看不见的来源痕迹”一起清掉。这也是我在打磨整套流程时，最在意的部分。

3. AI批量清洗的完整技术方案：从关键词检测到图像修复

3.1 清洗任务的本质：OCR定位 + 图像修复

先拆解一下“AI清洗图片中文和水印”到底在做什么，理解了原理，后面调参才有方向。

整个流程本质上是两段式任务：第一步，让计算机找到“哪里有文字、哪里有水印区域”；第二步，把这些区域里的内容抹掉，并且让周围的背景自然地“长回来”。

找到文字区域依赖的是OCR技术，也就是光学字符识别。OCR模型会扫描图片，把每个文字的最小外接四边形框出来。你需要拿到的是这些框的坐标集合。找到水印区域则稍微麻烦一些，因为水印没有固定的文字结构，我的做法是用人工标注一轮模板，把固定位置的水印区域划出来，再用逻辑规则去匹配。

抹掉内容依赖的是图像修复技术，英文叫inpainting。原理可以理解成：计算机根据文字区域边缘的颜色、纹理、梯度方向，推测出“如果这里本来没有字，应该是什么样子”，然后用推断出的像素填充进去。早期的修复算法处理小面积文字很有效，但面对大面积水印、复杂背景时会露出破绽。

这套两段式流程完全可以用AI模型批量执行，比人工用PS一张张擦效率高得多。人工擦图10分钟一张，批量清洗脚本每秒就能处理好几张，而且整个流程可复现、可记录、可预检。

3.2 工具选型：开源OCR + 图像修复模型的组合

工具方面，我用了“开源OCR + 图像修复模型 + 前端处理”的组合，全部在本地跑，不需要上传原图到第三方。这对供货商来说很重要，毕竟商品原图涉及商业机密，本地处理安全可控。

OCR部分，优先选用对中文识别支持比较完善的开源方案，一般分为检测和识别两步。检测模型负责找出文字框，识别模型负责读内容。我建议只取检测模型，因为清洗场景不需要知道文字是什么，只需要知道文字在哪。具体选型上，轻量模型跑CPU也能有不错的速度，重型模型精度高但慢。以我的经验，用中等规模的检测模型已经足够。

图像修复部分，有两套选择。

第一套是轻量方案，直接调用现成的图像修复函数。比如基于快速行进算法的修复方法，适合小面积文字、背景较干净的商品图。优点是快、无依赖、CPU可跑；缺点是遇到大面积水印、纹理复杂背景时会出现“涂抹感”，平台能一眼识别。

第二套是深度学习修复方案，比如用最近几年常见的修复神经网络模型。这类模型经过大量“破坏-重建”样本训练，遇到大面积文字或水印时，会生成更自然的纹理、光影过渡。缺点是需要一块能跑的GPU，处理单张图耗时更高，但效果确实强。

我的实践做法是“两套分工”：面积小、背景干净的图走轻量方案；大面积水印、复杂背景走深度学习方案。批量脚本里先判断待修复区域占比，超过某个阈值就切换到修复模型，这样兼顾了速度和效果。

3.3 一份可直接改用的批量处理脚本

下面这个脚本思路完整，覆盖了“OCR定位文字→生成遮罩→图像修复→输出”的全流程。我把OCR调用部分封装成接口，大家根据自己的实际环境替换即可。脚本用Python写，依赖核心是图像处理库，以及一个可用的OCR检测模块。

import cv2 import numpy as np from pathlib import Path # 假设这是你的OCR检测函数 # 输入: 图片路径 # 输出: 文字框列表，每个框是 [x, y, w, h] from ocr_engine import detect_text_boxes def expand_box(box, scale_w=0.15, scale_h=0.35): """把文字框向外扩一点点，避免修复后残留文字边缘。 scale_h给大一些，因为中文笔画容易超出检测框下沿。""" x, y, w, h = box new_w = int(w * (1 + scale_w)) new_h = int(h * (1 + scale_h)) # 中心对齐扩展 x = max(0, x - int(w * scale_w / 2)) y = max(0, y - int(h * scale_h / 2)) return [x, y, new_w, new_h] def generate_mask(img_shape, boxes): """把所有文字框画成白色遮罩，其余区域为黑色""" mask = np.zeros((img_shape[0], img_shape[1]), dtype=np.uint8) for box in boxes: x, y, w, h = expand_box(box) # 防止越界 x, y = max(0, x), max(0, y) cv2.rectangle(mask, (x, y), (x + w, y + h), 255, -1) # 做一次膨胀，把文字边缘的浅色羽化区也算进去 kernel = np.ones((3, 3), dtype=np.uint8) mask = cv2.dilate(mask, kernel, iterations=1) return mask def inpaint_image(img, mask, use_heavy_model=False): """修复图片""" if use_heavy_model: # 调用深度学习修复模型，模型输入是原图和mask result = ai_inpaint_model(img, mask) return result # 轻量方案，使用经典修复算法 result = cv2.inpaint(img, mask, inpaintRadius=3, flags=cv2.INPAINT_TELEA) return result # ai_inpaint_model 需要替换成你实际选的深度学习修复模型调用 def ai_inpaint_model(img, mask): # 伪实现，实际使用时加载自己的模型 return cv2.inpaint(img, mask, inpaintRadius=3, flags=cv2.INPAINT_NS) def process_image(src_path, dst_path): img = cv2.imread(str(src_path)) if img is None: print(f"[跳过] 无法读取: {src_path}") return # 1. OCR定位文字框 boxes = detect_text_boxes(str(src_path)) # 2. 如果没有检测到文字，说明图面无可见文本，直接拷贝 if len(boxes) == 0: img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) cv2.imwrite(str(dst_path), img_rgb) print(f"[原样] {src_path.name}") return # 3. 生成遮罩 mask = generate_mask(img.shape, boxes) # 4. 计算遮罩面积占比，决定用轻量方案还是重型方案 mask_ratio = np.sum(mask > 0) / (img.shape[0] * img.shape[1]) use_heavy = mask_ratio > 0.12 # 超过12%面积被遮罩覆盖，切重型修复 # 5. 修复 result = inpaint_image(img, mask, use_heavy_model=use_heavy) # 6. 保存，注意转换回RGB result_rgb = cv2.cvtColor(result, cv2.COLOR_BGR2RGB) cv2.imwrite(str(dst_path), result_rgb) print(f"[完成] {src_path.name} ({'heavy' if use_heavy else 'light'}, mask_ratio={mask_ratio:.2%})") def batch_clean(input_dir, output_dir): input_path = Path(input_dir) output_path = Path(output_dir) output_path.mkdir(parents=True, exist_ok=True) # 支持的图片格式 exts = ["*.jpg", "*.jpeg", "*.png", "*.webp"] files = [] for ext in exts: files.extend(input_path.glob(ext)) print(f"共发现 {len(files)} 张图片") for f in files: process_image(f, output_path / f.name) if __name__ == "__main__": batch_clean("raw_images", "cleaned_images")

脚本的逻辑不复杂，核心在三个地方：文字框扩展、遮罩膨胀、修复算法分流。我把文字框的纵向扩展系数设到0.35，是因为中文检测框经常只框住字身，忽略了下半部分的笔画阴影，不扩展的话修复后下边缘会露馅。遮罩膨胀做一次3×3迭代，目的是把文字周边的半透明羽化边缘一起覆盖掉，避免出现“边框感”。

在实际使用中，我建议先在几十张图上跑一遍，观察修复效果，再决定OCR检测阈值和扩展系数。不要直接拿全量图跑，因为不同类型商品图的背景复杂度差异很大。

3.4 参数与细节：为什么同一套清洗流程效果能差一大截

同一个脚本，有人跑出来效果很好，有人跑出来还是被驳回，问题通常不在AI模型，而在下面这几个容易被忽略的环节。

第一，遮罩覆盖不完整。只覆盖OCR检测到的文字框，但没覆盖文字的高光阴影、描边和背景渐变区域。比如白底图上印黑色中文，文字周围常有一圈淡淡的投影，如果只把黑字去掉，投影还在，图片看起来就像“被擦过”。解决办法就是我脚本里的膨胀处理，同时可以把修复半径适当调大，让修复算法多“跨出去”几个像素。

第二，处理完以后又压缩过度。清洗后的图片保存时如果用了过高的JPEG压缩比，会出现块状伪影，平台审核模型会把这类伪影当成“图片被编辑过的证据”。我的经验是保存时尽量用高质量参数，或者直接输出PNG格式。不要担心文件大小，全托管平台对图片大小通常有明确范围，超出略大点问题不大，伪影才是大问题。

第三，只处理了主图，没处理白底图边缘的透视畸变。有些供货商的原始图是从网页截图保存的，整张图带角度倾斜，文字区域也跟着倾斜。OCR检测出来的框如果是水平矩形，就会把大块背景区域一起覆盖掉，修复后产生明显的“补丁感”。这种情况我一般建议先做一次透视校正，让图片尽量正向，再做文字清洗。顺序不能反。

第四，忘了处理“遮挡痕迹”本身。平台驳回过一次之后，你手动把文字区域打了个模糊补丁，然后丢进脚本清洗。此时OCR虽然检测不到文字了，但模糊补丁区域还在，脚本不会主动识别它。所以我更推荐在批量清洗之前，先确认手上的图是不是已经被人工处理过，如果处理过，最好退回原始素材，或者在自动化流程里加一道“异常区域检测”。

4. 清洗后提交仍被驳回：我踩过的坑与完整排查链路

4.1 坑一：文字被拉伸后成了“像素噪点图”

我第一次跑通批量清洗时非常兴奋，几百张图秒级处理完，本地看图也觉得很干净。结果提交平台，还是被批量驳回，驳回理由集中在“图片存在不当处理痕迹”。排查了很久，最终定位到问题出在文字框区域修复后的“像素噪点”。

原因是修复算法在填充大面积文字时，产生了过度平滑的色块。正常情况下，商品图背景会有轻微噪点，比如拍摄环境的光线不均、墙壁纹理、布料织物质感。AI修复模型把这些纹理“脑补”得太均匀，反而形成了和周围不一致的“塑料感”。平台审核模型对图像的灰度方差、纹理一致性非常敏感，这块区域方差偏高，就被打上了“涂抹痕迹”标签。

解决办法有两个。一个是修复之后加一层轻量的高斯噪声，让修复区域的纹理起伏和周围背景匹配。另一个是优先选择保留纹理的修复模型，而不是过度平滑的经典算法。我最终采取的办法是混合策略：小面积文字用经典算法，大面积区域切换深度学习修复模型，修复后再加一个低强度的锐化操作，让边缘质感更接近拍摄的真实感。经过这轮调整，驳回率大幅度下降。

4.2 坑二：透明通道里的残留水印

有一阵子我处理了一批带透明背景的PNG产品图，图面干净得不能再干净了，但平台依然选择驳回。我一度怀疑平台的审核逻辑有问题，后来把PNG的alpha通道单独导出来看，整个人都不好了。

alpha通道里残留着一整排旧网店的水印轮廓。因为最初制作的素材是把带水印的原图叠加到透明背景上，水印虽然从视觉上被上层产品图遮住了，但alpha通道里依然保留了原始水印的透明度信息。平台在审核PNG时完全可能读取这个通道数据，于是判定图片“包含第三方标识”。

从那以后，我的清洗脚本增加了两条规则：一是把PNG统一转成JPG或重新生成透明通道，在转码时剔除旧通道上的残留痕迹；二是在处理带透明背景的产品图时，先用纯色背景替换掉透明通道，完成清洗后再决定是否需要抠图。不要迷信“转换格式就能清掉”，如果原始PSD或分层源文件里就有水印层，无论如何转码，残留信息都可能还在。

4.3 坑三：元数据与文件名这种“看不见的脏数据”

这个问题我在文章第2章的2.3节提过，但它值得单独再讲一次，因为这是最容易让人“死了都不知道怎么死的”的环节。

有一批图，我清洗完之后，用图像查看工具逐张看，全部干净，OCR复检也通过了，但提交后依然被驳回。后来我无意间看到某个文件名的前缀还带着旧渠道的名称缩写，再查看EXIF信息，里面赫然保留着“图像处理软件”的名字，指向一个旧的工具链版本。

平台在全托管审核链路中，读取文件元数据是完全合理的，因为它们需要确认上传素材的完整性和一致性。我的解决办法是，在批量清洗流程里增加一道“元数据清除”步骤，统一把EXIF信息剥离，文件名重新按“SKU+日期+序号”的规则生成。这一道工序加进去之后，再没有因为“文件属性”问题被驳回过。

4.4 本地复检：模拟平台审核的一整套自检流程

现在我的供货图片在上传之前，都会走一套本地复检，把“提交后被打回”的概率降到最低。整套复检流程分四步：

• 第一步：图面复检。用OCR模型对清洗后的图再跑一遍，确认没有任何可识别的中文或非目标语言文字，包括很小的角标字。
• 第二步：通道复检。检查PNG的alpha通道，确认没有隐藏水印轮廓；如果原图层次复杂，就另存一份JPG，用JPG作为最终提交格式。
• 第三步：元数据复检。用工具查看关键字段，确认不存在来源软件名、旧文件名、GPS信息等敏感元数据。
• 第四步：一致性复检。把主图、详情图的背景纹理调成同一套标准。因为经常出现“主图干净了，详情图还有中文”的情况，平台会做关联审核，一张驳回，整套素材全完。

这套复检流程听着繁琐，但把它固化到脚本里后，也就是批量处理时几分钟的事。相比被驳回后重新同步一套素材，性价比高出太多。

5. 一批图的实测效果与几条关于“供货通过率”的真正心得

5.1 实测数据：同一批图，清理前后通过率对比

拿我自己操作过的一批模拟测试数据来举例。某次整理500张家居类商品图，原始素材全部来自一个旧的批发渠道，图面上带着大小不一的中文营销文字和旧渠道水印。

清理前，我抽样提交了80张，平台通过率只有一半左右。驳回理由和前面表格总结的三类完全吻合。清理后，同一批素材全部走完AI清洗和本地复检流程，再提交500张，通过率提升到90%以上。剩下的个别驳回，主要是原图本身分辨率不足，以及某几张背景纹理复杂导致修复痕迹仍然可见。这个结果让我很明确地意识到：通过率不是靠“撞运气”，而是靠“清洗+复检”的系统化流程。

在另一批小家电图上，我发现直接套用默认参数效果并不理想，因为小家电表面常常带有品牌标签、参数铭牌，OCR到的一大堆英文数字需要保留，不能一股脑全擦掉。所以我现在会根据品类维护不同的关键词黑名单和区域保护名单，比如“品牌logo区域不处理”“参数铭牌区域不处理”，避免误伤商品本身的合规信息。

5.2 比“擦图工具”更重要的源头素材管理

批量清洗流程跑熟之后，很多人会产生依赖，觉得拿到什么图都能靠AI修缮成“干净素材”。但我要泼一盆冷水：清洗只是补救手段，源头素材管理才是决定通过率上限的关键。

我做了两件事之后，供货通过率才真正稳定下来。第一，向供应商索取“无水印、无文字”的原始大图。很多供应商手里其实有干净素材，只是对接的销售默认发了渠道图，你要主动开口要。只要源头是干净的，整个清洗流程只需要应对偶尔的拍摄环境杂物，通过率自然高。第二，建立自己的素材归档规范。新到的干净素材按“SKU-拍摄日期-素材类型”命名，统一存进一个本地图库，同时保留一份无文字版本、一份可编辑图层版本。这样即使后续需要做活动素材，也能快速从成套的底稿里取用，而不是满世界找旧图来擦。

源头管理做好之后，清洗脚本承担的角色就变成了“最后一道安全检查”，而不是“唯一的救命稻草”。这两种心态，带来的供货稳定性完全不同。

5.3 最后聊AI批量清洗的边界

必须说明，AI批量清洗不是万能的。这个方案应对的是“图片上有文字、有固定水印”这类结构化问题。如果素材本身是模糊翻拍的、严重畸变的、或者把文字做进了复杂的商品纹理里，清洗效果就会断崖式下跌。

复杂纹理上叠加大面积中文，比如编织品表面印着品牌活动口号，这类图我建议直接放弃清洗，重新拍摄或更换素材。强行修复会造成不可逆的光影断裂，平台反而更容易判定为“合成图”。另外，涉及他人商标logo的区域，无论技术上行不行，都不建议用清洗来绕过。平台有更严苛的logo库比对，硬擦logo既过不了审，也可能引发版权纠纷，源头换素材才是正确做法。

我的使用边界总结就一句话：清洗用在小面积文字、固定位置水印、干净背景上是高效且合规的；超出这个范围，趁早回到素材获取环节重新解决问题。

这套流程从搭建到稳定运行，我前后调了大概三周。中间踩过坑、被驳回、又回头查源头，最终沉淀为一条固定的供货管线。现在每次拿到新素材，第一件事不是急着清洗，而是先登记来源、检查原始干净度，再决定要不要走批量清洗。做过全托管供货的朋友应该能理解，通过率不是一个绝对值，而是一套流程互相咬合的结果。AI清洗在其中解决了很大一部分重复劳动，但我更希望所有供货商都能意识到，真正的长期优势，还是建立在一套靠谱的素材供应链管理之上。