先交代一下背景。我手上大约有十几个SKU要做平台入驻和活动报名每个SKU要提交的物料包括商品标题、详情页文案、价格表、库存表、规格参数表、资质扫描件外加一张主图。以前这套流程靠人工核对一个商品看下来少说二十分钟眼睛还得顶着屏幕反复比对描述和参数有没有打架、价格和划线价合不合理、资质有没有过期。做多了之后我实在不想再干这种重复劳动就把 Qwen3.8-Max 拉过来搭了个商品资料体检助手拿 6 份资料和 1 张商品图喂进去一次就给我列出了 27 个问题从标题到图片、从价格到资质全给扫了一遍。这篇就记录一下我完整的搭建过程、提示词设计和踩过的坑给同样被商品资料审核折磨的人一个参考。1. 这个助手到底解决了什么问题1.1 电商上架前资料审核的真实痛点商品资料审核这件事听起来不起眼实际做起来非常繁琐。以我手头这个 SKU 为例资料包里有商品基本信息表、详情页文案、价格促销表、库存清单、资质文件列表和规格参数表再加一张主图。这 7 样东西分散在不同文件里信息却高度交叉价格表里的促销价要和主图上的水印价一致详情页文案里的参数要和规格表对得上资质文件的有效期要在活动时间段内库存数又不能出现负数或者零。任何一个环节出错轻则驳回修改重则错过平台活动报名窗口。人工审核最大的问题在于人的注意力是波动的。前 10 分钟可能还能精神集中到第五六个商品的时候标题里缺了类目词、规格参数里漏了净含量这种问题很容易就滑过去了。我统计过自己一次完整的审核如果资料本身比较规整最少需要 15 分钟如果哪份表里的数据对不上来回翻文件、查平台规则半小时打底。而且这种工作极度依赖审核人员的经验同一个问题两个人看可能一个觉得严重一个觉得无所谓。1.2 为什么用大模型而不是传统规则引擎一开始我确实考虑过写规则脚本。标题长度超了多少字、库存是不是负数、价格是不是低于成本这些规则型检查用 Python 循环就能做。但真正把 6 份资料摊开之后我发现大量需要判断的问题不是 数字超没超阈值 这种硬校验而是语义层面的不一致。比如详情页文案里写着 采用航空铝材质规格参数表也写着 材质航空铝看起来一致但平台类目规范里这个价位的商品应该是 铝合金这就是一个需要理解上下文才能发现的类目描述偏差。这类语义判断正是大模型的强项。Qwen3.8-Max 这类模型能同时接收长文本、表格和图片可以把多份资料整体放进一个上下文里做交叉比对。相比之下传统规则引擎虽然稳定但每新增一种检查逻辑都要写一堆条件和正则规则之间还容易出现冲突。大模型只需要把检查清单描述清楚它自己就能根据上下文推理出哪些信息对不上。这也是我选定这个方向的最主要原因。2. 方案架构与技术选型2.1 整体流程设计整个体检助手在运行层面的逻辑其实不复杂拆开就是四步读文件、组装输入、调用模型、解析结果。第一步把 6 份资料从 Excel、Word、PDF 里提取成纯文本图片单独走多模态通道第二步按照预设的提示词模板把不同资料用清晰的标记分隔开塞进同一个上下文第三步调用 Qwen3.8-Max 的接口让它按指定 JSON 结构返回问题清单第四步把返回结果解析成一眼能看懂的表格按问题严重程度排序。这四步里最关键的其实是第二步的提示词组装。模型能力再强如果输入是一锅粥输出也不会好到哪里去。我在设计提示词时参考了平时给同事提需求的方式先交代身份和目标再说明每份资料是什么然后给出明确的检查规则最后规定输出格式。把这一整套流程跑通之后整个检查耗时从人工的十几分钟压缩到了大约 40 秒其中绝大部分时间是 API 响应和文件解析。2.2 为什么选 Qwen3.8-Max选型的时候我对比过几个方案最终还是定了 Qwen3.8-Max主要看中三点长文本处理能力、多模态输入支持和结构化输出的稳定性。先说长文本。6 份资料全部转成文本之后仅详情页文案就有将近 8000 字规格参数表转成键值对之后也有 300 多行。这种量级如果模型上下文窗口不够资料会被截断后面的检查就成了无米之炊。Qwen3.8-Max 的长上下文能力足够把这些内容完整装下而且对中间位置的内容也有不错的记忆不会出现只检查开头和结尾、忽略中间内容的情况。再说多模态。商品主图和详情页里的大图是纯文本无法覆盖的信息。有没有水印、分辨率够不够、主图背景是不是纯白这些判断必须靠视觉能力。Qwen3.8-Max 支持图像输入我在实测里发现它对图片中的文字信息比如价格水印、参数说明识别得相当准确这为图文交叉比对提供了基础。最后是输出稳定性。我要的是机器能直接解析的 JSON模型如果喜欢在回答里夹杂解释性文字后处理会非常痛苦。Qwen3.8-Max 在 JSON 输出模式下的表现比较稳定字段缺失和格式错乱的情况比预期少很多。2.3 六份资料和一张图片怎么喂给模型我一开始踩过坑把六份资料直接全文字拼接用换行分隔就丢给模型。结果模型分不清哪些内容属于同一份资料在判断 价格表里的促销价与主图水印是否一致 这种跨资料比对时经常张冠李戴。后来我改成在每一份资料前面加一个明确的标记头并且规定统一的格式。举个例子资料 1商品基本信息 商品IDSKU2088 商品标题XX品牌 不粘锅炒锅 家用电磁炉通用 30cm 少油烟 所属类目厨具 锅具 炒锅 品牌XX ... 资料 2详情页文案 【卖点区块】 ...标记头的作用是帮模型建立 资料边界感。我实测下来加上这种结构化的头之后模型在指认 问题来自哪份资料 时准确性提高了不少。图片方面我在调用时把主图以 base64 编码传给模型同时在图下面标注这张图是 商品主图让它知道这张图是和其他资料配套的不是无关图片。3. 核心实现提示词、规则与代码3.1 27 类问题清单是怎么设计出来的标题里说的 27 个问题不是模型自己灵光一现编出来的而是我把过去一年遇到的各类商品驳回原因做了分类汇总沉淀成了一份检查清单。清单分成六个大组每组下面几条具体规则最后加起来正好 27 条。第一组是标题与类目。这类检查包括标题是否超过平台限长、是否包含违禁词比如最第一这类极限词、是否重复堆砌关键词、是否缺少核心类目词、类目与商品实际属性是否匹配。标题问题是最容易在模型身上见效的因为语言模型对词汇和语义的理解天然有优势。第二组是价格与促销。包括划线价是否低于销售价、促销价是否高于近 30 天最低成交价、价格单位是否有异常比如元写成了角、满减逻辑计算是否正确、限时优惠时间区间是否在活动期内。价格类问题需要模型做简单的算术和逻辑判断实测下来 Qwen3.8-Max 对这类问题的处理很稳定没有出现算错的情况。第三组是库存与履约。包括库存数量是否为 0 或负数、是否存在超卖风险比如活动预估销量大于现有库存、预售发货时间是否超过平台要求、偏远地区是否不包邮但未标注。库存类问题大多来自表格模型在读取结构化数据时能直接抓取数字并给出判断。第四组是详情页与文案。包括描述是否与规格参数表中的材质/尺寸/型号冲突、是否缺少必要的售后信息、是否存在夸大宣传或绝对化用语、文案中出现的品牌词是否与授权主体一致。这组问题是语义判断的重头戏也是最体现大模型价值的地方。第五组是图片与视觉。包括主图是否为白底图、分辨率是否低于 800×800、图上是否有牛皮癣水印或促销贴纸、图片中商品颜色是否与标题中的颜色一致、图片是否包含品牌 logo 且与备案一致。这里用到模型的多模态能力我实测发现它对 图片上有没有非官方贴纸 的判断相当灵敏可能是因为这类贴纸在训练样本中足够多。第六组是资质与合规。包括质检报告是否在有效期内、授权书是否覆盖当前品牌和类目、资质文件上的公司主体是否和店铺主体一致、特殊类目比如食品、化妆品是否缺少强制资质。这组问题的检查高度依赖 OCR 和日期判断Qwen3.8-Max 在识别资质文件里的关键日期和主体名称上表现不错但偶尔也会把日期的月日搞反所以我专门在提示词里强调了一遍 日期以原文件为准。3.2 提示词结构系统提示、资料输入与输出格式提示词的写法直接影响检查效果。我调整了五六版之后沉淀出了一套结构分享出来供参考。整个提示词分成三块系统提示system、用户内容user、输出格式约束。系统提示是模型行为的总开关我写的内容大致是你是一名资深电商商品合规审核专家拥有多年电商平台商品管理经验。 你负责对提交的商品资料包进行全量体检输出问题清单。 你要以严格的合规视角检查发现问题不要遗漏同时不要凭空捏造问题。 所有判断必须基于用户提供的资料内容资料之外的推测要标注疑似。用户内容部分则按顺序放资料每份资料前加标记头图片放在文字之后。为了让模型不丢规则我还会在用户内容末尾加一句请按以下 27 条检查规则逐条核对......。第一次测试时我没加这句结果模型只检查了它认为重要的维度大概只查出了 14 个问题漏掉了大量细节规则。加上完整规则清单之后问题召回率明显提升。输出格式我用 JSON 强制约束{ summary: { total_issues: 27, level_high: 8, level_mid: 12, level_low: 7 }, issues: [ { id: 1, category: 标题与类目, issue_type: 标题超长, source: 商品基本信息表, description: 标题共 62 个字符超出平台 50 字符限制, suggestion: 删减重复关键词控制在 50 字符以内, level: high } ] }在代码里我用 response_format 参数强制模型返回 JSON这样后面解析起来非常方便。有一点要注意模型偶尔会在 JSON 里多出一个逗号或者少一个引号导致 json.loads 直接报错。我后来加了一个兜底函数如果解析失败就尝试用正则提取大括号之间的内容再解析实测可以把解析成功率从大概 93% 提升到 99% 以上。3.3 Python 调用代码与参数选择接口调用本身不复杂用的 OpenAI 兼容模式几行就能跑通。完整示例放在下面你可以直接参考import base64 import json from openai import OpenAI client OpenAI( api_keyyour-dashscope-api-key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) def image_to_base64(image_path): with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def build_user_content(material_texts, image_path): content for idx, text in enumerate(material_texts, start1): content f资料 {idx}\n{text}\n\n if image_path: img_b64 image_to_base64(image_path) content 商品主图\n这张图是商品主图请与以上资料交叉核验。\n content fimg srcdata:image/jpeg;base64,{img_b64} / return content def run_inspection(material_texts, image_pathNone): system_prompt 你是一名资深电商商品合规审核专家... user_content build_user_content(material_texts, image_path) response client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature0.1, max_tokens2000, response_format{type: json_object} ) return response.choices[0].message.content参数选择上有几个经验。temperature 我固定 0.1原因很简单体检这种事要的是稳定和一致不是创意。如果 temperature 太高同一个商品跑两次可能查出不同的问题这对后续改进体验是灾难。max_tokens 给到 2000 基本够用如果问题数量超过 27 条输出可能被截断我后面还想了一个办法在提示词里要求模型如果问题超过 30 条优先报告最严重的 30 条这样既能控制长度也不会丢最关键的信息。4. 实操记录从原始文件到体检报告4.1 资料预处理与文件读取实战中最费时间的不是写代码调模型而是处理格式各异的原始文件。我手上拿到的 6 份资料分布在不同类型的文件里商品信息表是 Excel详情页是 Word价格表是 CSV库存表是 Excel资质文件是 PDF 扫描件规格参数表是 Markdown。这套组合虽然常见但每种都要单独写读取逻辑。Excel 和 CSV 的处理相对简单用 pandas 读进来之后我会先做一次规整把所有列名统一成中文字段名、把空行和重复表头去掉、将数值列转成不带科学计数法的字符串。规格参数表这类两列形式的表格我会直接转成 参数名参数值 的多行文本这样模型处理起来比原始宽表更顺手。Word 文档我用的 python-docx 按段落读取同时保留标题层级信息用 Markdown 的标题符号标出来。这一手对后面的文案检查很有用因为详情页往往分成卖点、规格、售后几大块标题层级能帮助模型理解文本结构。PDF 资质文件我用 pdfplumber 提取文字如果提取出来是空的说明是扫描件我会先 OCR 再送进模型。这里提醒一下扫描件的 OCR 质量直接会影响到资质有效期的判断如果 OCR 出来的日期格式不对后端的解析逻辑会直接当缺失处理。图片方面我拿到的是商家给的主图 JPG。预处理主要做两件事检查图片能不能正常打开以及确认尺寸是否过小。如果图片本身小于 300×300直接标记为一类问题没必要再送进模型里浪费 token。图片编码之后单独作为一条多模态消息传入不混在文字里。下面是预处理完成后组装好的输入片段示例资料 1商品基本信息 商品IDSKU2088 商品标题XX品牌 不粘锅炒锅 家用电磁炉通用 30cm 少油烟 所属类目厨具 锅具 炒锅 品牌XX 上市时间2023-06 ... 资料 3价格与促销信息 销售价159.00 划线价199.00 活动价139.00 活动开始2025-03-08 00:00 活动结束2025-03-10 23:59 满减规则满200减30 ... 资料 4库存信息 仓库A135 仓库B60 可售天数12.5 补货周期7天 ...4.2 完整跑一遍流程的现场记录我拿这个 SKU 实测时的心情其实挺忐忑的因为之前用 14 条规则自定义测试只召回了一部分问题不知道上 27 条完整规则效果会怎么样。整个流程跑下来从读文件到模型响应总共花了 43 秒返回的内容我用 json 格式化之后一看发现模型真的把 27 类问题里的问题全部列出来了而且 27 是一个汇总值不是每一个都命中——命中的问题它都会给出具体的 问题定位 修改建议。我特意挑几个过去人工容易漏的问题验证了一下。第一个是价格与库存联动的问题库存表里写着仓库 A 有 135 件、仓库 B 有 60 件看起来没问题但模型指出活动价设定后预估日均销量为 50 件当前库存只够用 3.9 天而平台要求活动期间必须有 7 天以上库存保障。这个问题我们人工审核时从来不会去算很容易在活动进行到一半时断货。第二个验证点是图文是否一致。主图上印了一个 30cm 的尺寸标签而商品标题里也写了 30cm但规格参数表里的锅口直径写的却是 28cm。这种跨资料的信息冲突光看文字或者光看图根本发现不了必须放到同一个上下文里做交叉比对。模型不止发现了不一致还指出标题里的 30cm 是含手柄的总长度规格表里的 28cm 是锅口直径两者并不矛盾但它依然建议在详情页里面补充说明避免用户投诉。这个判断水平说实话超出了我的预期。4.3 输出报告怎么读模型返回的 JSON 经过简单处理后我会把它转成一张 Markdown 表格按问题严重程度排序方便直接同步给运营和供应商。表格长这样级别问题分类问题描述修改建议高资质与合规质检报告有效期至2025-02-28已过期联系供应商更新报告高价格与促销活动价139元低于近30天最低成交价149元调整为149元以上高库存与履约活动期间库存预计3.9天耗尽低于7天保障要求补货或缩短活动周期中标题与类目标题缺少核心类目词炒锅标题中加入炒锅中详情页与文案文案写航空铝与规格表铝合金不一致统一物料表述中图片与视觉主图存在价格促销贴纸上传白底无贴纸主图低规格参数净含量字段缺失补填规格信息拿到这份报告之后我只需要把问题分发给对应负责人资质问题找供应商图片问题找美工文案问题找运营。整个流转过程比从前一遍遍列问题、拍照截图、在群里 人 要高效得多。5. 踩坑记录与改进心得5.1 缩着跑和放开跑之间怎么调这个体检助手我前后调整了三四轮最头疼的不是代码而是检查尺度的把控。一开始提示词写的偏宽松写的是请检查商品资料中的明显问题结果模型只查出 5 个问题很多细节都没覆盖到。后来我把 27 条规则全部写进提示词又强调逐条核对问题数一下子飙升到 31 个里面混进了一些误报。误报最典型的例子是规格参数表里写 锅盖玻璃详情页文案里写 强化玻璃锅盖模型报了一条 表述不一致但实际上玻璃和强化玻璃是一个意思不算错误。这类误报虽然不致命但会浪费人工复核的时间。我的解决办法是在提示词中加入判定标准段落把容易误报的规则按在黑名单之外并给出一个容错说明比如若两种表述指向同一材质且不构成消费者误解则不视为问题。经过这轮微调误报率显著下降最终稳定在可接受范围内。总结下来提示词的边界设定是一个反复试错的过程你需要在漏报和误报之间找到一个适合自己场景的平衡点。5.2 多模态图片识别的边界图片检查是这个项目里最有意思的部分也是最容易让结果翻车的部分。我测过的场景里Qwen3.8-Max 对大面积水印、彩色促销标签、非白底背景的判断都非常准基本没有失手过。但遇到一种情况它会 犯迷糊图片内容比较复杂比如主图是场景图背景里有绿植和木桌模型会犹豫该不该把它判断为 非白底图。它给出的描述是背景不是纯白但商品主体完整可能属于场景图而非白底图这个判断就让人很头疼。我的处理方式是提示词里明确写清规则如果主图是场景图直接判为非白底主图并给出风险提示。除非平台明确允许场景图否则一律视为问题。 这样规则前置模型的输出就稳定多了。另外我还让模型在判断图片问题时除了给出问题描述还额外输出图片上能识别出的文字信息比如价格标签上的数字。这样一旦出现图文不一致我们能直接看到模型引用了图片中的哪个文本方便快速复核。5.3 成本和速度的平衡每一次体检的 token 消耗不算小我粗略估算过一个 SKU 的资料包加上图片输入大概要消耗 8000 到 10000 token主要是详情页文案占了大部分。如果每天要审 50 个商品费用确实是一个需要掂量的数字。我后来做了两件事来控制成本。第一把详情页文案做了精简再送入模型。详情页里有大段的场景渲染文字和图片 alt 文本这些内容对问题检查没有直接帮助我会先用规则把纯描述性段落去掉只保留包含具体参数和承诺性表述的段落。第二针对价格和库存这类纯结构化检查我会先用脚本做一轮快速过滤只有脚本发现异常或有异常嫌疑的数据才走模型做深度判断。这两招组合下来单次体检的 token 消耗比最初降了约 30%。速度方面如果只是检查纯文本资料响应基本在 10 秒以内一旦加进图片耗时会上浮到 20 到 40 秒。这主要是因为图片编码本身占了不少体积。后来我把图片压缩到 800×800 再编码识别准确率没有明显下降但响应速度快了 20% 左右。5.4 长期维护的一点心得商品资料体检这种事规则不是一劳永逸的。平台的活动规则、违禁词库、资质要求每隔几个月就会更新一次。我的做法是把检查规则单独抽成一个 JSON 文件模型提示词里引用这个文件的内容这样规则更新只需要改 JSON不需要动代码逻辑。另外每次发现误报或漏报我都会把案例记到一个小型的经验库里回填到提示词的判定标准中让模型的检查能力慢慢变强。还有一点要提醒模型输出不能直接当最终结论用。我在流程里保留了一个人工复核环节专门设了一个低风险问题列表这类问题系统不会自动通知而是每周汇总一次由运营快速勾选确认。这样既没有完全依赖模型也没有让模型输出变成无人问津的空架子。说实话这套工具到目前为止已经帮我处理了 30 多个 SKU 的资料审核每次跑完拿到结构化的报告再也不用自己埋头对表格了。我也越来越觉得这种 文档 图片 规则 大模型 的组合在电商后端这类资料密集、规则繁杂的场景里能发挥的价值远比想象中大。如果你也在被商品资料审核折磨不妨从这个思路入手先把最耗时的跨资料一致性检查交给大模型剩下的手动工作会轻松不少。
用大模型给电商商品资料做自动体检：从提示词设计到落地实践
先交代一下背景。我手上大约有十几个SKU要做平台入驻和活动报名每个SKU要提交的物料包括商品标题、详情页文案、价格表、库存表、规格参数表、资质扫描件外加一张主图。以前这套流程靠人工核对一个商品看下来少说二十分钟眼睛还得顶着屏幕反复比对描述和参数有没有打架、价格和划线价合不合理、资质有没有过期。做多了之后我实在不想再干这种重复劳动就把 Qwen3.8-Max 拉过来搭了个商品资料体检助手拿 6 份资料和 1 张商品图喂进去一次就给我列出了 27 个问题从标题到图片、从价格到资质全给扫了一遍。这篇就记录一下我完整的搭建过程、提示词设计和踩过的坑给同样被商品资料审核折磨的人一个参考。1. 这个助手到底解决了什么问题1.1 电商上架前资料审核的真实痛点商品资料审核这件事听起来不起眼实际做起来非常繁琐。以我手头这个 SKU 为例资料包里有商品基本信息表、详情页文案、价格促销表、库存清单、资质文件列表和规格参数表再加一张主图。这 7 样东西分散在不同文件里信息却高度交叉价格表里的促销价要和主图上的水印价一致详情页文案里的参数要和规格表对得上资质文件的有效期要在活动时间段内库存数又不能出现负数或者零。任何一个环节出错轻则驳回修改重则错过平台活动报名窗口。人工审核最大的问题在于人的注意力是波动的。前 10 分钟可能还能精神集中到第五六个商品的时候标题里缺了类目词、规格参数里漏了净含量这种问题很容易就滑过去了。我统计过自己一次完整的审核如果资料本身比较规整最少需要 15 分钟如果哪份表里的数据对不上来回翻文件、查平台规则半小时打底。而且这种工作极度依赖审核人员的经验同一个问题两个人看可能一个觉得严重一个觉得无所谓。1.2 为什么用大模型而不是传统规则引擎一开始我确实考虑过写规则脚本。标题长度超了多少字、库存是不是负数、价格是不是低于成本这些规则型检查用 Python 循环就能做。但真正把 6 份资料摊开之后我发现大量需要判断的问题不是 数字超没超阈值 这种硬校验而是语义层面的不一致。比如详情页文案里写着 采用航空铝材质规格参数表也写着 材质航空铝看起来一致但平台类目规范里这个价位的商品应该是 铝合金这就是一个需要理解上下文才能发现的类目描述偏差。这类语义判断正是大模型的强项。Qwen3.8-Max 这类模型能同时接收长文本、表格和图片可以把多份资料整体放进一个上下文里做交叉比对。相比之下传统规则引擎虽然稳定但每新增一种检查逻辑都要写一堆条件和正则规则之间还容易出现冲突。大模型只需要把检查清单描述清楚它自己就能根据上下文推理出哪些信息对不上。这也是我选定这个方向的最主要原因。2. 方案架构与技术选型2.1 整体流程设计整个体检助手在运行层面的逻辑其实不复杂拆开就是四步读文件、组装输入、调用模型、解析结果。第一步把 6 份资料从 Excel、Word、PDF 里提取成纯文本图片单独走多模态通道第二步按照预设的提示词模板把不同资料用清晰的标记分隔开塞进同一个上下文第三步调用 Qwen3.8-Max 的接口让它按指定 JSON 结构返回问题清单第四步把返回结果解析成一眼能看懂的表格按问题严重程度排序。这四步里最关键的其实是第二步的提示词组装。模型能力再强如果输入是一锅粥输出也不会好到哪里去。我在设计提示词时参考了平时给同事提需求的方式先交代身份和目标再说明每份资料是什么然后给出明确的检查规则最后规定输出格式。把这一整套流程跑通之后整个检查耗时从人工的十几分钟压缩到了大约 40 秒其中绝大部分时间是 API 响应和文件解析。2.2 为什么选 Qwen3.8-Max选型的时候我对比过几个方案最终还是定了 Qwen3.8-Max主要看中三点长文本处理能力、多模态输入支持和结构化输出的稳定性。先说长文本。6 份资料全部转成文本之后仅详情页文案就有将近 8000 字规格参数表转成键值对之后也有 300 多行。这种量级如果模型上下文窗口不够资料会被截断后面的检查就成了无米之炊。Qwen3.8-Max 的长上下文能力足够把这些内容完整装下而且对中间位置的内容也有不错的记忆不会出现只检查开头和结尾、忽略中间内容的情况。再说多模态。商品主图和详情页里的大图是纯文本无法覆盖的信息。有没有水印、分辨率够不够、主图背景是不是纯白这些判断必须靠视觉能力。Qwen3.8-Max 支持图像输入我在实测里发现它对图片中的文字信息比如价格水印、参数说明识别得相当准确这为图文交叉比对提供了基础。最后是输出稳定性。我要的是机器能直接解析的 JSON模型如果喜欢在回答里夹杂解释性文字后处理会非常痛苦。Qwen3.8-Max 在 JSON 输出模式下的表现比较稳定字段缺失和格式错乱的情况比预期少很多。2.3 六份资料和一张图片怎么喂给模型我一开始踩过坑把六份资料直接全文字拼接用换行分隔就丢给模型。结果模型分不清哪些内容属于同一份资料在判断 价格表里的促销价与主图水印是否一致 这种跨资料比对时经常张冠李戴。后来我改成在每一份资料前面加一个明确的标记头并且规定统一的格式。举个例子资料 1商品基本信息 商品IDSKU2088 商品标题XX品牌 不粘锅炒锅 家用电磁炉通用 30cm 少油烟 所属类目厨具 锅具 炒锅 品牌XX ... 资料 2详情页文案 【卖点区块】 ...标记头的作用是帮模型建立 资料边界感。我实测下来加上这种结构化的头之后模型在指认 问题来自哪份资料 时准确性提高了不少。图片方面我在调用时把主图以 base64 编码传给模型同时在图下面标注这张图是 商品主图让它知道这张图是和其他资料配套的不是无关图片。3. 核心实现提示词、规则与代码3.1 27 类问题清单是怎么设计出来的标题里说的 27 个问题不是模型自己灵光一现编出来的而是我把过去一年遇到的各类商品驳回原因做了分类汇总沉淀成了一份检查清单。清单分成六个大组每组下面几条具体规则最后加起来正好 27 条。第一组是标题与类目。这类检查包括标题是否超过平台限长、是否包含违禁词比如最第一这类极限词、是否重复堆砌关键词、是否缺少核心类目词、类目与商品实际属性是否匹配。标题问题是最容易在模型身上见效的因为语言模型对词汇和语义的理解天然有优势。第二组是价格与促销。包括划线价是否低于销售价、促销价是否高于近 30 天最低成交价、价格单位是否有异常比如元写成了角、满减逻辑计算是否正确、限时优惠时间区间是否在活动期内。价格类问题需要模型做简单的算术和逻辑判断实测下来 Qwen3.8-Max 对这类问题的处理很稳定没有出现算错的情况。第三组是库存与履约。包括库存数量是否为 0 或负数、是否存在超卖风险比如活动预估销量大于现有库存、预售发货时间是否超过平台要求、偏远地区是否不包邮但未标注。库存类问题大多来自表格模型在读取结构化数据时能直接抓取数字并给出判断。第四组是详情页与文案。包括描述是否与规格参数表中的材质/尺寸/型号冲突、是否缺少必要的售后信息、是否存在夸大宣传或绝对化用语、文案中出现的品牌词是否与授权主体一致。这组问题是语义判断的重头戏也是最体现大模型价值的地方。第五组是图片与视觉。包括主图是否为白底图、分辨率是否低于 800×800、图上是否有牛皮癣水印或促销贴纸、图片中商品颜色是否与标题中的颜色一致、图片是否包含品牌 logo 且与备案一致。这里用到模型的多模态能力我实测发现它对 图片上有没有非官方贴纸 的判断相当灵敏可能是因为这类贴纸在训练样本中足够多。第六组是资质与合规。包括质检报告是否在有效期内、授权书是否覆盖当前品牌和类目、资质文件上的公司主体是否和店铺主体一致、特殊类目比如食品、化妆品是否缺少强制资质。这组问题的检查高度依赖 OCR 和日期判断Qwen3.8-Max 在识别资质文件里的关键日期和主体名称上表现不错但偶尔也会把日期的月日搞反所以我专门在提示词里强调了一遍 日期以原文件为准。3.2 提示词结构系统提示、资料输入与输出格式提示词的写法直接影响检查效果。我调整了五六版之后沉淀出了一套结构分享出来供参考。整个提示词分成三块系统提示system、用户内容user、输出格式约束。系统提示是模型行为的总开关我写的内容大致是你是一名资深电商商品合规审核专家拥有多年电商平台商品管理经验。 你负责对提交的商品资料包进行全量体检输出问题清单。 你要以严格的合规视角检查发现问题不要遗漏同时不要凭空捏造问题。 所有判断必须基于用户提供的资料内容资料之外的推测要标注疑似。用户内容部分则按顺序放资料每份资料前加标记头图片放在文字之后。为了让模型不丢规则我还会在用户内容末尾加一句请按以下 27 条检查规则逐条核对......。第一次测试时我没加这句结果模型只检查了它认为重要的维度大概只查出了 14 个问题漏掉了大量细节规则。加上完整规则清单之后问题召回率明显提升。输出格式我用 JSON 强制约束{ summary: { total_issues: 27, level_high: 8, level_mid: 12, level_low: 7 }, issues: [ { id: 1, category: 标题与类目, issue_type: 标题超长, source: 商品基本信息表, description: 标题共 62 个字符超出平台 50 字符限制, suggestion: 删减重复关键词控制在 50 字符以内, level: high } ] }在代码里我用 response_format 参数强制模型返回 JSON这样后面解析起来非常方便。有一点要注意模型偶尔会在 JSON 里多出一个逗号或者少一个引号导致 json.loads 直接报错。我后来加了一个兜底函数如果解析失败就尝试用正则提取大括号之间的内容再解析实测可以把解析成功率从大概 93% 提升到 99% 以上。3.3 Python 调用代码与参数选择接口调用本身不复杂用的 OpenAI 兼容模式几行就能跑通。完整示例放在下面你可以直接参考import base64 import json from openai import OpenAI client OpenAI( api_keyyour-dashscope-api-key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) def image_to_base64(image_path): with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def build_user_content(material_texts, image_path): content for idx, text in enumerate(material_texts, start1): content f资料 {idx}\n{text}\n\n if image_path: img_b64 image_to_base64(image_path) content 商品主图\n这张图是商品主图请与以上资料交叉核验。\n content fimg srcdata:image/jpeg;base64,{img_b64} / return content def run_inspection(material_texts, image_pathNone): system_prompt 你是一名资深电商商品合规审核专家... user_content build_user_content(material_texts, image_path) response client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature0.1, max_tokens2000, response_format{type: json_object} ) return response.choices[0].message.content参数选择上有几个经验。temperature 我固定 0.1原因很简单体检这种事要的是稳定和一致不是创意。如果 temperature 太高同一个商品跑两次可能查出不同的问题这对后续改进体验是灾难。max_tokens 给到 2000 基本够用如果问题数量超过 27 条输出可能被截断我后面还想了一个办法在提示词里要求模型如果问题超过 30 条优先报告最严重的 30 条这样既能控制长度也不会丢最关键的信息。4. 实操记录从原始文件到体检报告4.1 资料预处理与文件读取实战中最费时间的不是写代码调模型而是处理格式各异的原始文件。我手上拿到的 6 份资料分布在不同类型的文件里商品信息表是 Excel详情页是 Word价格表是 CSV库存表是 Excel资质文件是 PDF 扫描件规格参数表是 Markdown。这套组合虽然常见但每种都要单独写读取逻辑。Excel 和 CSV 的处理相对简单用 pandas 读进来之后我会先做一次规整把所有列名统一成中文字段名、把空行和重复表头去掉、将数值列转成不带科学计数法的字符串。规格参数表这类两列形式的表格我会直接转成 参数名参数值 的多行文本这样模型处理起来比原始宽表更顺手。Word 文档我用的 python-docx 按段落读取同时保留标题层级信息用 Markdown 的标题符号标出来。这一手对后面的文案检查很有用因为详情页往往分成卖点、规格、售后几大块标题层级能帮助模型理解文本结构。PDF 资质文件我用 pdfplumber 提取文字如果提取出来是空的说明是扫描件我会先 OCR 再送进模型。这里提醒一下扫描件的 OCR 质量直接会影响到资质有效期的判断如果 OCR 出来的日期格式不对后端的解析逻辑会直接当缺失处理。图片方面我拿到的是商家给的主图 JPG。预处理主要做两件事检查图片能不能正常打开以及确认尺寸是否过小。如果图片本身小于 300×300直接标记为一类问题没必要再送进模型里浪费 token。图片编码之后单独作为一条多模态消息传入不混在文字里。下面是预处理完成后组装好的输入片段示例资料 1商品基本信息 商品IDSKU2088 商品标题XX品牌 不粘锅炒锅 家用电磁炉通用 30cm 少油烟 所属类目厨具 锅具 炒锅 品牌XX 上市时间2023-06 ... 资料 3价格与促销信息 销售价159.00 划线价199.00 活动价139.00 活动开始2025-03-08 00:00 活动结束2025-03-10 23:59 满减规则满200减30 ... 资料 4库存信息 仓库A135 仓库B60 可售天数12.5 补货周期7天 ...4.2 完整跑一遍流程的现场记录我拿这个 SKU 实测时的心情其实挺忐忑的因为之前用 14 条规则自定义测试只召回了一部分问题不知道上 27 条完整规则效果会怎么样。整个流程跑下来从读文件到模型响应总共花了 43 秒返回的内容我用 json 格式化之后一看发现模型真的把 27 类问题里的问题全部列出来了而且 27 是一个汇总值不是每一个都命中——命中的问题它都会给出具体的 问题定位 修改建议。我特意挑几个过去人工容易漏的问题验证了一下。第一个是价格与库存联动的问题库存表里写着仓库 A 有 135 件、仓库 B 有 60 件看起来没问题但模型指出活动价设定后预估日均销量为 50 件当前库存只够用 3.9 天而平台要求活动期间必须有 7 天以上库存保障。这个问题我们人工审核时从来不会去算很容易在活动进行到一半时断货。第二个验证点是图文是否一致。主图上印了一个 30cm 的尺寸标签而商品标题里也写了 30cm但规格参数表里的锅口直径写的却是 28cm。这种跨资料的信息冲突光看文字或者光看图根本发现不了必须放到同一个上下文里做交叉比对。模型不止发现了不一致还指出标题里的 30cm 是含手柄的总长度规格表里的 28cm 是锅口直径两者并不矛盾但它依然建议在详情页里面补充说明避免用户投诉。这个判断水平说实话超出了我的预期。4.3 输出报告怎么读模型返回的 JSON 经过简单处理后我会把它转成一张 Markdown 表格按问题严重程度排序方便直接同步给运营和供应商。表格长这样级别问题分类问题描述修改建议高资质与合规质检报告有效期至2025-02-28已过期联系供应商更新报告高价格与促销活动价139元低于近30天最低成交价149元调整为149元以上高库存与履约活动期间库存预计3.9天耗尽低于7天保障要求补货或缩短活动周期中标题与类目标题缺少核心类目词炒锅标题中加入炒锅中详情页与文案文案写航空铝与规格表铝合金不一致统一物料表述中图片与视觉主图存在价格促销贴纸上传白底无贴纸主图低规格参数净含量字段缺失补填规格信息拿到这份报告之后我只需要把问题分发给对应负责人资质问题找供应商图片问题找美工文案问题找运营。整个流转过程比从前一遍遍列问题、拍照截图、在群里 人 要高效得多。5. 踩坑记录与改进心得5.1 缩着跑和放开跑之间怎么调这个体检助手我前后调整了三四轮最头疼的不是代码而是检查尺度的把控。一开始提示词写的偏宽松写的是请检查商品资料中的明显问题结果模型只查出 5 个问题很多细节都没覆盖到。后来我把 27 条规则全部写进提示词又强调逐条核对问题数一下子飙升到 31 个里面混进了一些误报。误报最典型的例子是规格参数表里写 锅盖玻璃详情页文案里写 强化玻璃锅盖模型报了一条 表述不一致但实际上玻璃和强化玻璃是一个意思不算错误。这类误报虽然不致命但会浪费人工复核的时间。我的解决办法是在提示词中加入判定标准段落把容易误报的规则按在黑名单之外并给出一个容错说明比如若两种表述指向同一材质且不构成消费者误解则不视为问题。经过这轮微调误报率显著下降最终稳定在可接受范围内。总结下来提示词的边界设定是一个反复试错的过程你需要在漏报和误报之间找到一个适合自己场景的平衡点。5.2 多模态图片识别的边界图片检查是这个项目里最有意思的部分也是最容易让结果翻车的部分。我测过的场景里Qwen3.8-Max 对大面积水印、彩色促销标签、非白底背景的判断都非常准基本没有失手过。但遇到一种情况它会 犯迷糊图片内容比较复杂比如主图是场景图背景里有绿植和木桌模型会犹豫该不该把它判断为 非白底图。它给出的描述是背景不是纯白但商品主体完整可能属于场景图而非白底图这个判断就让人很头疼。我的处理方式是提示词里明确写清规则如果主图是场景图直接判为非白底主图并给出风险提示。除非平台明确允许场景图否则一律视为问题。 这样规则前置模型的输出就稳定多了。另外我还让模型在判断图片问题时除了给出问题描述还额外输出图片上能识别出的文字信息比如价格标签上的数字。这样一旦出现图文不一致我们能直接看到模型引用了图片中的哪个文本方便快速复核。5.3 成本和速度的平衡每一次体检的 token 消耗不算小我粗略估算过一个 SKU 的资料包加上图片输入大概要消耗 8000 到 10000 token主要是详情页文案占了大部分。如果每天要审 50 个商品费用确实是一个需要掂量的数字。我后来做了两件事来控制成本。第一把详情页文案做了精简再送入模型。详情页里有大段的场景渲染文字和图片 alt 文本这些内容对问题检查没有直接帮助我会先用规则把纯描述性段落去掉只保留包含具体参数和承诺性表述的段落。第二针对价格和库存这类纯结构化检查我会先用脚本做一轮快速过滤只有脚本发现异常或有异常嫌疑的数据才走模型做深度判断。这两招组合下来单次体检的 token 消耗比最初降了约 30%。速度方面如果只是检查纯文本资料响应基本在 10 秒以内一旦加进图片耗时会上浮到 20 到 40 秒。这主要是因为图片编码本身占了不少体积。后来我把图片压缩到 800×800 再编码识别准确率没有明显下降但响应速度快了 20% 左右。5.4 长期维护的一点心得商品资料体检这种事规则不是一劳永逸的。平台的活动规则、违禁词库、资质要求每隔几个月就会更新一次。我的做法是把检查规则单独抽成一个 JSON 文件模型提示词里引用这个文件的内容这样规则更新只需要改 JSON不需要动代码逻辑。另外每次发现误报或漏报我都会把案例记到一个小型的经验库里回填到提示词的判定标准中让模型的检查能力慢慢变强。还有一点要提醒模型输出不能直接当最终结论用。我在流程里保留了一个人工复核环节专门设了一个低风险问题列表这类问题系统不会自动通知而是每周汇总一次由运营快速勾选确认。这样既没有完全依赖模型也没有让模型输出变成无人问津的空架子。说实话这套工具到目前为止已经帮我处理了 30 多个 SKU 的资料审核每次跑完拿到结构化的报告再也不用自己埋头对表格了。我也越来越觉得这种 文档 图片 规则 大模型 的组合在电商后端这类资料密集、规则繁杂的场景里能发挥的价值远比想象中大。如果你也在被商品资料审核折磨不妨从这个思路入手先把最耗时的跨资料一致性检查交给大模型剩下的手动工作会轻松不少。
)
