做了差不多半年跨境电商多平台铺货天天跟商品标题打交道最烦的就是给几百个SKU写中文标题。后来我搭了一个批量图生文标生成工具接入阿里百炼、腾讯混元、火山引擎三家大模型服务专门处理Temu这类平台的中文商品标题生成。这里把整个思路、选型过程、代码结构和踩过的坑都整理一遍给同样被标题逼疯的运营和爱折腾工具的开发者做个参考。先说清楚这个工具解决什么问题你有一堆商品图可能来自工厂、供应商或者1688下载的素材包图片里有产品外观、包装、细节图。你需要根据这些图片批量生成符合Temu搜索逻辑和展示规范的中文标题。人工做这件事一个品平均要磨三四分钟200个SKU就是一个下午用工具跑按每个品调用一次大模型计算半小时内全部出初稿再花一两个小时人工审核修改整体效率能提三四倍。这个工具不是简单把英文标题机翻一下因为机翻根本不懂产品。图片里明明是“带挂钩的免打孔浴室置物架”机翻可能给你翻成“壁挂式存储架”丢了核心卖点更别提颜色、材质、尺寸这些细节看了图才知道。所以整个工具的核心逻辑是先让视觉大模型“看图说话”把商品属性抽出来再让语言模型根据这些属性和平台规则去组标题。这就是标题里说的“图生文”。这篇文章适合两种人一是Temu、速卖通、Shopee这类平台的运营想找工具思路提升铺货效率二是写脚本、做自动化工具的开发者想知道多模型接入、批量并发、标题优化这些环节怎么落地。1. 为什么商品标题非要“看图说话”而不是直接翻译Temu上架商品的逻辑和淘宝不太一样。淘宝靠店铺权重和销量驱动标题更多是给搜索引擎和买家看的Temu是半托管和全托管模式搜索流量分配更依赖标题关键词的完整度。一个中文标题写得准不准直接决定商品能不能被搜到、被推荐到相关类目。如果你手里只有一张图然后让大模型直接生成标题很多模型默认会走“翻译风”。比如一个英文标题叫“Wall Mounted Soap Dispenser with Brush”翻译过来是“壁挂式肥皂分配器带刷子”这已经算好的。但看图之后生成的是“厨房壁挂式洗洁精瓶 带刷头 免打孔 按压式”后者才符合国内消费者的搜索习惯——他们搜“洗洁精瓶”“带刷头”“免打孔”这些词。还有一个更现实的问题铺货场景下很多商品只有图片没有标题或者只有供应商给的极其笼统的英文名。不看图你连这个产品是塑料还是不锈钢、是方形还是圆形都不知道。中文标题如果连材质和形状都不写买家搜“不锈钢”“圆形”就找不到它。人工写标题的另一个瓶颈在于一致性。一个人写累了后面几十个标题明显变水动词重复、词序混乱。工具生成的话提示词里固定句式结构所有标题风格能统一。所以这个项目的核心主张是标题生成必须以视觉信息为起点以平台搜索规则为约束语言模型只负责最后一步的词汇组织。两段式流程缺一不可。2. 三家大模型接入对比阿里百炼、腾讯混元、火山引擎怎么选这个工具说要接入三家大模型很多人第一反应是“有必要吗”。一开始我也只接了其中一家后来发现两个问题一是单家服务在高峰期会限流批量任务一跑就断二是不同模型对图片细节的识别能力和中文组词习惯差距很大比如有的模型对颜色描述很准但材质容易瞎猜有的模型擅长把标题写得顺口但字数容易超。多接几家批量任务里可以按策略切换还能交叉校验。接入方式上三家都是“模型即服务”的形式给API Key传图片和提示词返回文字结果。我在工程上封装了一层统一接口无论调哪家对上层来说都是同一个函数参数和返回结构统一处理。有一点要注意三家平台的接口域名、鉴权方式、图片传输格式都有差异。有的支持直接传图片URL有的要求传Base64有的两者都支持。批量场景下我优先传Base64或者临时上传到自己的图床因为外部图片URL经常会过期传到一半报错很麻烦。我简单列一个选型对比表格这个是我实际测试下来的感受供参考维度阿里百炼腾讯混元火山引擎接入风格兼容OpenAI格式迁移成本低有独立的视觉理解接口对图片描述结构化较好豆包系列视觉模型生成中文标题自然度较高图片理解能力对商品主体识别稳定材质识别偶尔偏差对场景和空间关系理解强适合带环境图对细节特征颜色、数量描述保守不容易瞎编批量稳定性并发限制明确需控制QPS响应速度稳定偶发超时高峰期限流明显建议作为备用标题生成风格偏正式适合工具类、家居类偏简洁适合服装、配饰类偏口语化适合宠物、日用百货类选型逻辑其实很朴素。主力模型选择标准是并发稳、超时少、返回格式好解析。我目前把阿里百炼当主力腾讯混元做交叉验证火山引擎作为限流时的备胎。接口调用示意大概是这样的我用Python整理过一段最小可用的伪代码逻辑import base64 import json from concurrent.futures import ThreadPoolExecutor # 假设已经完成三家平台的client初始化 # clients {ali: ..., tencent: ..., volcano: ...} def image_to_title(image_path, providerali, prompt_template): # 读取图片 with open(image_path, rb) as f: image_b64 base64.b64encode(f.read()).decode() # 不同provider拼不同的请求体 if provider ali: resp clients[ali].chat.completions.create( modelqwen-vl-plus, messages[ {role: user, content: [ {image: image_b64}, {text: prompt_template} ]} ] ) return resp.choices[0].message.content elif provider tencent: # 腾讯混元的视觉接口走独立参数 ...真实代码里每家的字段名都不一样但封装完成之后上层逻辑完全不用关心调用的是哪家。提示词模板是整个工具的灵魂。我踩过坑一开始提示词写得太简单比如“给这张图生成一个中文商品标题”结果标题全是“高品质XXX”“厂家直销XXX”这种没有任何信息量的废话。后来我把模板改成了结构化约束效果完全不一样。下面是我目前在用的模板核心部分你是一个熟悉跨境电商平台规则的商品标题撰写专家。请根据用户提供的商品图片生成一个适合Temu平台的中文商品标题。 要求 1. 标题字数控制在28到32个汉字之间 2. 必须包含商品主体词、核心功能或材质、颜色或规格如果图片可见 3. 使用中文简体禁止出现英文单词除非是材质如PVC、不锈钢 4. 禁止使用“高品质”“厂家直销”“爆款”等无意义修饰词 5. 禁止虚构图片中没有出现的功能或材质 6. 输出格式仅输出标题文本不要加引号、序号或解释这个模板的意义在于把“看图”和“写标题”两步合在了一次调用里。你不需要先让模型提取属性再生成标题因为它自己会看图。但我们仍然要求它在标题里体现图片里能看到的属性这就等于把属性提取的步骤内化到结果里了。3. 批量处理管道的核心设计并发、缓存、重试、断点单张图调用大模型很简单难的是批量。2000张图一次性丢给接口马上就会被限流而且中途有任何一张图失败整个任务就得回滚重来。我在开发过程中把批量处理拆成五个环节输入整理、去重、并发调度、结果校验、进度持久化。输入整理这步看着简单实际坑最多。商品图可能来自压缩包、网盘目录、第三方图片链接文件名五花八门。我统一把它们归一化成“SKU编号图片序号”的命名格式然后全部复制到一个输入目录里。这样即使输出结果里没有文件名也能通过索引倒推是哪张图。去重这一步很多人会忽略。同一个SKU可能有五六张图角度不同但主体一样供应商给的素材里也经常有完全重复的图片换了名字。如果不去重等于同一件商品花五六次API调用费用。我用图片的MD5哈希做精确去重相同哈希直接跳过。如果图片有裁剪或缩放差异就再加一个感知哈希做近似去重。实测下来2000张素材图去重后往往只剩1200张不到省了将近一半费用。并发调度这块我用了线程池加固定并发数。并发数不是越大越好最优值取决于各家API的QPS限制。我从并发3开始测试逐步加到10观察响应时间和失败率最后把主力通道的并发数定在5到6之间。注意线程池里的每个任务都要做超时控制单个请求超过30秒就放弃并标记为失败避免一个慢请求卡住整个队列。我画一个简单示意把整个处理流程列出来输入目录扫描生成待处理任务清单计算图片哈希过滤重复项读取断点记录跳过已完成的SKU通过线程池并发调用大模型接口对返回结果做格式清洗去引号、去解释文字将标题写入结果文件并更新断点记录任务结束后生成失败清单供二次补跑失败重试和熔断机制是批量工具稳定运行的关键。单次调用失败可能是网络抖动重试一次就好但如果连续失败超过10次基本可以判定当前模型服务出问题了。这时我的策略是暂停当前通道的任务记录失败原因把后续任务自动切换到备用模型。等主通道恢复后再对失败的SKU进行补跑。这个过程里断点续跑帮了大忙。以前跑批量任务最怕停电、断网、代码崩溃一次中断几百张图全部白跑。后来我把处理进度同步写到一个JSON文件里每处理完一个SKU就更新一次。重新运行时先读取进度文件已经完成的直接跳过。这样即使跑到一半宕机重启后也只是从断点继续不会重复消耗API额度。结果校验这一步也值得细说。大模型返回的内容不一定干净有时候带解释有时候带引号有时候生成了一段“标题XXX”的话。我写了几条清洗规则去掉冒号前后的说明性文字去掉所有引号只保留第一个换行符之前的内容。如果清洗后字数超出35个字直接标记为“字数超限”交给人工处理。校验规则里还要拦截那些明显的违规内容比如标题里带“最好”“第一”“根治”这类词这些在平台上是禁用的。4. 中文商品标题的“优化”究竟在优化什么这个项目叫做“优化中文商品标”核心不止是生成一个标题而是让这个标题符合平台流量分配规则。我总结下来一个合格的Temu中文标题要满足四个要求核心词前置、属性词完整、字数卡线、无违禁词。先说字数。Temu前台展示标题默认截断长度有限后台字段虽然允许填得更多但真正在前台显示出来的部分才是有效的。依据我的实测和平台规则观察中文标题控制在30字左右是最稳的太长被截断、太短关键词不够。工具在提示词里已经要求字数在28到32字之间清洗后还会再校验一次。核心词前置这条很多新手容易忽略。平台搜索匹配时标题前半部分的权重明显高于后半部分。比如一个“免打孔浴室置物架”就不要写成“浴室用免打孔设计的多层收纳置物架”核心词被淹没在中间。工具的做法是在提示词里要求“商品主体词放在标题最前面”。属性词的完整度决定了长尾流量。一个买家可能在搜索框输入“不锈钢厨房置物架”——有材质词也可能输入“落地置物架多层”——有形状和层数词。看图生成标题的优势恰好在这里人的眼睛看一遍图很难把颜色、材质、形状、功能全部记全但视觉大模型可以。实际操作中我会额外让模型输出一行属性JSON方便后续排查。这个思路是从一个做独立站的朋友那边学来的他在类似场景里就是这么处理的。举一个具体的例子一张简单的商品图图里是一个白色塑料的免打孔肥皂盒带沥水孔挂在墙上如果只给它图片并问“描述这个产品”模型通常回答“一个白色塑料肥皂盒”但如果提示词里要求“提取颜色、材质、安装方式、功能细节”模型就会输出“白色”“塑料”“免打孔”“壁挂”“沥水”这几个关键词然后标题组合成“免打孔壁挂肥皂盒 卫生间白色塑料沥水置物架”。虽然字数偏多但信息密度很高“免打孔”“壁挂”“肥皂盒”“卫生间”“沥水架”都是可搜索关键词。这类标题在Temu上的搜索表现普遍比“白色肥皂盒”这种笼统标题好不少。标题优化还要注意类目差异。家居类目重材质和尺寸服装类目重款式和适用场景宠物类目重功能和规格。工具目前的提示词是按“通用模板类目补充”的方式设计的基础要求一致类目补充说明告诉模型重点看图片里的哪些信息。比如服装类目补充一句“重点识别领型、袖长、版型、面料不要输出尺寸数字”因为服装尺寸通常是另一套尺码体系不能靠看图猜。多语言残留是个容易被忽略的坑。大模型可能因为训练数据里中文电商标题样本不足偶尔把英文习惯带进来。比如生成“免打孔浴室置物架ABS环保材质”这种夹生标题ABS材质是合理的但“new design”这种英文垃圾词就不行。工具的结果清洗模块里内置了一个敏感词表把常见的英文残留、繁体中文自动转为简体把“Good quality”这类洋垃圾词直接过滤掉。另外平台对标题里的符号有严格限制。逗号、竖线、星号这些符号在Temu标题里要么不允许要么会被过滤掉。我的清洗逻辑是把所有英文符号统一替换成中文逗号然后把竖线、星号、括号全部删除。这个处理看似简单批量的时候能减少很多因格式问题被平台拒绝的情况。5. 真实运行中的问题与排查思路工具从开发到稳定运行中间经过了好几轮Debug。这一节挑几个最典型的坑说一下完整的排查链路。第一个坑是图片URL失效导致的大面积报错。第一版工具支持直接传网络图片链接因为很多素材是供应商发的在线链接。跑起来之后发现前100张图顺利通过第101张开始大量报“image download failed”。排查后确认是图片源站有防盗链机制前100张是CDN缓存之后触发了源站校验。解决办法是下载所有图片到本地再用Base64传给大模型。分布式下载加上重试这个问题就彻底解决了。凡是做这类工具的朋友建议第一步就是本地化不要省这个环节。第二个坑是模型识别偏差导致的标题错误。看图有一个天然的缺陷模型分不清“图片能看到的”和“实际商品包含的”。比如一张产品包装图上有英文字母模型可能把包装上的装饰文字当成商品名称的一部分。还有一个更常见的场景SKU主图里放的是多色排列图模型会把颜色写成“多色”或者写成一个具体颜色而实际上具体颜色是由SKU决定的与图片无关。我的解决办法是在提示词里加了一句“如果图片展示多个颜色或多个变体请在标题中写‘多色可选’如果只有一个主体则写具体颜色”。这句话直接把这类错误的概率降了一半以上。第三个坑是返回内容格式不稳定。有一次批量任务跑到最后发现标题全部带上了“标题”前缀排查后发现是火山引擎在某个版本上的模型对指令理解偏了它把输出格式要求理解成需要加前缀。我没有去改提示词因为改提示词会影响其他两家模型的输出。更好的办法是加一个后处理函数把“标题”“商品标题”这类前缀全部剥掉。这件事给我的教训是提示词模板要尽量在各家模型之间保持统一格式差异交给清洗层去处理不要每次单独调提示词。第四个坑是平台规则更新带来的连锁反应。有一段时间Temu调整了搜索展示规则标题超过一定字数会在前台被折叠。我的工具里已经做了字数校验但校验逻辑是硬编码的改一次要重新发版。后来我加了一个规则配置文件把字数上限、禁用词表、符号规则都放到配置里平台规则变了只改配置文件不用动代码。这里把踩坑效果汇总一下方便对照常见问题典型表现排查思路解决手段图片URL时效性批量跑到中途集体失败看错误码是403/404还是超时改为本地图片转Base64多SKU图颜色误判标题颜色与实际SKU不匹配比对图片排列方式与错误标题提示词里限定多色场景处理规则返回内容带前缀所有结果多了“标题”对比三家模型输出差异后处理清洗统一剥离平台规则更新标题在前台被截断检查平台公告与前台展示效果规则配置化不改代码单通道限流连续失败集中在同一模型查看API调用日志与报错码主备模型自动切换最后再分享一个个人实操中的体会这个工具跑起来之后最花时间的不是开发而是“让不同模型的输出风格统一”这件事。大模型不像传统程序同一个提示词在不同模型上给出的答案风格差异很大。我的方案是先用20张图做小样本测试分别跑三家模型人工看一遍结果选出最贴合平台风格的模型做主通道其余做备用。标题质量不够好的模型在提示词里加一句“语言风格参考主流电商平台中文标题简洁清晰”。还有一个比较小众但好用的技巧在批量任务正式开跑前把提示词里的“商品主体词”提取出来做一次自动校验。比如提示词里要求模型先输出商品主体词再输出完整标题那么我可以把每张图的SKU名称也带上对比模型识别的主体词和SKU名称是否一致。不一致的图片自动进入复核队列不参与批量生成。这一步等于给整条流水线加了一道质量闸门能拦住不少图片质量差、模型看不懂的情况。这个工具目前的稳定形态是本地命令行批量跑图生成结果以Excel或CSV形式输出运营同事只需要在表格里改改不满意的标题然后再回填到平台后台。工具本身不复杂但每一层都有可优化的细节尤其是那些不跑量就发现不了的问题。如果你也在做类似的批量生成工具建议先把单张图的质量跑稳再上并发和自动重试否则并发一开失败的排查难度会指数级上升。