如果把电商新品上架前的工作排成一张表大多数人最先崩溃的不是拍图也不是写文案而是拿着几份资料来回比对的那段时间。上上周我接了一个智能手环的新品资料包文件夹里躺着标题文案、规格参数表、检测报告、说明书、售后政策、详情页文案和一张主图按老办法我至少得花一下午逐项核对还不一定能查干净。这次我换了个思路让 Qwen3.8-Max 直接搭了一个商品资料包体检助手把这些材料一股脑喂进去跑完居然一次性列出了 27 个问题。这篇文章就把整个搭建过程和排查思路完整写出来包括我用到的方案架构、检查规则、Prompt 设计以及实际跑出来的问题明细和踩坑记录。如果你也经常被商品资料包搞得头大或者想用大模型做点能落地的内部工具这篇内容应该能给你一个可以直接复用的参考。1. 这个体检助手到底在解决什么问题1.1 电商商品资料包的真实检查场景先还原一下我面对的实际场景。一个新品要上架到主流电商平台资料包里通常不止一张主图和一段介绍文案而是像这样一组材料商品标题与卖点文案通常是运营写的规格参数表产品经理或工厂提供检测报告质检、认证类文件常见的有 CE、RoHS、3C 等产品使用说明书可能是工厂给的 PDF售后服务政策售后部门或平台规则整理详情页文案设计外包或美工产出商品主图1 到 N 张取决于平台要求这些材料来自不同的人、不同的时间段天然会存在各种不一致。运营写的标题说“石墨灰”参数表里写“深空灰”详情页又说“曜石黑”到最后消费者收到货发现颜色对不上第一波退货和差评就是这么来的。检测报告也有坑认证有效期到 2025 年 4 月结果 5 月才准备上架或者证书上的申请人主体和店铺主体根本不是一个公司平台审核直接驳回。这些事靠人工一条条翻确实能查但效率太低了而且很容易漏。我当时想得很清楚这类检查本质上就是“拿着规则清单在一堆半结构化文档里找矛盾和不合理之处”。这种活恰好是大模型比较擅长的——只要你把材料喂进去把检查规则说清楚再要求它按固定格式输出问题。不用搭复杂的系统一个 Python 脚本加一个 API 调用就够了。1.2 为什么选 Qwen3.8-Max 而不是传统规则引擎很多人第一反应是这种一致性检查用正则表达式和写死的规则不就行了吗我也试过传统规则的问题在于“规则太难穷尽”。你能写正则去匹配日期格式、电话号码但你很难用正则判断“详情页宣传的待机时长和说明书里的电池容量是不是自洽”。这需要理解语义而不只是匹配格式。我选择 Qwen3.8-Max 主要基于三点考虑。第一它的上下文窗口足够大能一次性塞进 6 份资料的文本内容不用做复杂的切片和检索对商品资料包这种“材料不多但每份都要看”的场景直接全量喂进去是最省事的方案能避免分块后信息割裂导致误判。第二它具备多模态能力商品主图可以直接传图让模型读出图中的文字和关键信息比如包装盒上的型号、配色、参数标签。第三它的指令遵循能力比较稳能按指定 JSON 结构输出检查结果对后续自动化处理非常友好。当然我也不是一步到位就用它。最早试过拿通用对话模型直接问“请检查这份资料有什么问题”结果它答得又散又空甚至有的问题是我没给过它的资料里“想象”出来的。后来我把检查规则结构化把输出格式固定成 JSON才慢慢稳定下来。这一点在后面的实操部分会详细展开。2. 整体方案设计与检查规则拆解2.1 把资料包整理成模型能读的“体检输入”整个助手的输入非常简单一个文件夹里面放着商品资料包的所有文件。脚本启动后做三件事遍历文件列表识别每个文件的类型文本类文件Word、PDF、TXT、Markdown直接提取文本图片文件压缩后转成 base64 编码准备传给多模态接口。文本提取这一步最容易翻车我建议按文件类型分开处理。Word 文件用 python-docx 读取段落PDF 文件优先用 pdfplumber因为它对表格的还原度比 PyPDF2 好很多。检测报告、参数表这类文档大量使用表格用 pdfplumber 提取后基本能保留行列结构转成 Markdown 表格格式。说明书这类图文混排的 PDF提取出来会有很多无关的页眉页脚需要先做一个简单的清洗去掉重复的页码和公司名。图片部分我一开始踩了个坑直接把原图传给模型结果接口报错因为文件太大。后来统一做了压缩和尺寸限制长边超过 1600 像素就等比缩放质量参数设为 85这样既能保住关键文字又能控制请求体大小。如果是主图上那种很小的角标文字压缩后可能看不清我会把图片切成上下两半分别传给模型识别效果会好很多。2.2 三类检查规则完整性、一致性、合规性规则设计是整个助手的灵魂。我把它整理成三大类每一类对应不同的问题形态。完整性检查负责找“缺了什么”比如售后政策里没有七天无理由条款、详情页没有保修说明、检测报告缺少封面页一致性检查负责找“信息对不上”比如标题里写的型号和参数表不一致、主图颜色和规格表 SKU 数量对不上、说明书电池容量和参数表不同合规性检查负责找“不能这么写/这么标”比如标题出现绝对化用语、详情页出现未授权的认证标识、检测报告有效期已过。在 Prompt 里我会把每个检查项明确列出来而不是只丢一句“请检查”。举个例子一致性检查里我会写“对比所有文档中出现的商品名称、型号、颜色、尺寸、电池容量、防水等级、保修时长只要有两个来源不一致就单独列一条问题。”这样模型就不会把精力分散到“这段话写得是否优美”这种无关判断上。2.3 方案取舍为什么不做向量数据库和 RAG资料包体检和很多知识库问答场景不一样它的特点是“材料少但每份都要精查”。6 份资料加起来可能也就一两万字完全在模型上下文窗口之内。这种情况下做 RAG检索增强生成反而画蛇添足——你还要切块、做 embedding、做召回而且召回不准会导致模型漏看关键信息。我的做法是把所有文本资料按统一格式拼接成一个长上下文先“全文通读”再“逐项检查”效果更可靠。但全量塞入对 Prompt 的排版要求会更高。如果只是把 6 份文档草草堆在一起模型很容易分不清哪段话来自哪个文件。我的解决办法是给每份资料加一个带编号的 XML 标签头格式类似document iddoc-02 name规格参数表……/document。这样模型在报告问题位置时可以直接引用doc-02我后续也方便定位到原始文件。3. 核心实操要点Prompt 设计与结构化输出3.1 文本材料的标注与拼接先说拼接格式。我把所有文档按顺序拼接成一个整体每个文档有明确的 ID 和名称。这样做的好处是模型输出的问题条目里可以直接带文档 ID我拿到结果后不用再靠猜去定位问题出处。document iddoc-01 name商品标题与卖点文案 提取到的文本内容 /document document iddoc-02 name规格参数表 提取到的文本内容 /document document iddoc-03 name检测报告 提取到的文本内容 /document ……以此类推图片则单独作为一个image块传入同时我会在文本里加一句简短说明“接下来是一张商品主图请结合这张图检查包装上的型号、配色、认证标识等视觉信息。”这样模型会明确知道图片和前面文本的关系而不是把图片当成一个孤立存在。3.2 Prompt 模板核心片段Prompt 是整个体检精度最重要的决定因素。我经过几轮迭代最终把 Prompt 固定成下面这个结构你可以直接抄走按照实际情况改你是一名资深电商商品合规审核员。下面是一组商品资料包包含文本资料和商品主图。 请根据以下检查要求对全部资料进行交叉核对输出一份问题清单。 【输出要求】 1. 只输出 JSON不要输出任何解释性文字。 2. 如果没有发现问题返回 {summary: 未发现问题, problems: []}。 3. 对每个问题必须给出严重程度高/中/低和修改建议。 4. 只有当资料中确实存在依据时才可以列出问题不确定的内容一律标注为待人工确认。 【检查范围】 1. 完整性检查各文档中应包含的关键信息是否缺失例如保修期、售后政策、认证编号、安全警告。 2. 一致性对比所有文档中出现的商品名称、型号、颜色、尺寸、电池容量、防水等级、保修时长等字段。 3. 合规性检查标题和详情页是否存在绝对化用语、虚假宣传、过期认证、未授权标识等风险。 【输出JSON格式】 { summary: 问题总数和整体判断, problems: [ { id: 1, category: 一致性, severity: 高, location: doc-02/规格参数表 与 doc-04/说明书, content: 具体的问题描述, suggestion: 修改建议 } ] }我把这份 Prompt 直接放在系统消息里用户消息则是拼接好的全部资料。实测下来只要把检查范围和输出格式都写死模型基本不会跑偏。最忌讳的是只给一句“帮我看看这些资料有什么问题”然后期待模型输出标准答案——它输出的内容会很主观、很发散你还要花大量时间整理完全失去了工具化的意义。3.3 结构化输出与容错解析调用部分我用的环境是阿里云百炼兼容 OpenAI 接口的方式只需要设置base_url和api_key代码很短。import json from openai import OpenAI client OpenAI( api_key你的API_KEY, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) def run_check(messages: list[dict]) - dict: resp client.chat.completions.create( modelqwen3.8-max, messagesmessages, temperature0.1, response_format{type: json_object} ) content resp.choices[0].message.content try: return json.loads(content) except json.JSONDecodeError: # 容错移除可能的 json 代码块标记 cleaned content.replace(json, ).replace(, ).strip() return json.loads(cleaned)temperature我设成 0.1目的是让输出尽量稳定减少随机性。response_format指定为 JSON 对象能很大程度避免模型输出大段废话。即便如此我还是在代码里做了两层容错第一层直接解析第二层把模型输出里可能出现的 Markdown 代码块标记去掉再解析。偶尔模型还会在 JSON 末尾多写几个字这种情况我会再保留一个“从第一个{截到最后一个}”的兜底逻辑。4. 一次完整体检6 份资料和 1 张图查出 27 个问题4.1 示例资料包构成这里我拿一个实际跑过的例子来讲解。某智能手环新品资料包共 6 份文本资料加 1 张商品主图编号文件来源doc-01商品标题与卖点文案运营doc-02规格参数表产品部doc-03检测报告第三方实验室doc-04产品使用说明书工厂doc-05售后服务政策售后部doc-06详情页文案外包设计img-01商品主图含包装盒摄影4.2 从原始文件到问题清单的三步流程整个跑批流程分三步。第一步脚本扫描文件夹把 doc-01、doc-02、doc-04、doc-06 这类 Word/Markdown 文件直接读取文本doc-03 检测报告是 PDF用 pdfplumber 提取保留表格结构doc-05 售后政策是 PDF同样提取文本。img-01 是 JPG压缩后转成 base64。第二步把所有文本按前面说的 XML 标签格式拼接到用户消息里图片作为独立消息块传入。消息结构大致是这样messages [ {role: system, content: SYSTEM_PROMPT}, { role: user, content: [ {type: text, text: all_text_content}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_base64}}} ] } ]第三步调用接口拿回 JSON把problems数组打印成 Markdown 表格。整个过程从脚本启动到输出结果大约 40 秒比人工核对快太多了。4.3 27 个问题的分布与明细那次跑出来的 27 个问题我当时整理成了一张表。按严重程度分高危 8 个、中危 11 个、低危 8 个。按问题类型分一致性 12 个、完整性 7 个、合规性 8 个。我挑一部分有代表性的列出来ID严重程度问题来源1高标题写“石墨灰”规格参数表与详情页均为“深空灰”主图手环本体颜色偏暖疑似第三色doc-01 / doc-02 / img-012高检测报告认证有效期至 2025-04-27当前已超期doc-033高检测报告申请人名称与店铺主体名称不一致doc-034高详情页出现“最薄智能手环”字样涉嫌绝对化用语doc-065高主图包装盒上印有 CE 标识但检测报告中未见 CE 认证文件img-01 / doc-036高售后政策中“支持 7 天无理由退货”但详情页写明“拆封后不支持退换”两者冲突doc-05 / doc-067中规格参数表中电池容量 300mAh说明书标注 280mAhdoc-02 / doc-048中主图展示了 4 种配色规格参数表仅列出 3 个 SKUimg-01 / doc-029中详情页缺少保修期说明售后政策中写的是整机 12 个月doc-06 / doc-0510中说明书缺少“充电时请勿佩戴”安全警告doc-0411中规格参数表中防水等级为 IP67说明书为 IP68doc-02 / doc-0412低规格参数表中重量单位为“g”实际数值明显偏大疑似“oz”误标doc-0213低详情页底部水印残留外包公司名称doc-0614低主图包装盒侧面文字拼写错误“Handband”应为“Handband”检查确认img-01这里最有价值的是第 5 条和第 6 条。品牌方看到主图包装盒上有 CE 标识一般人都不会多想但和检测报告交叉核对才发现这个产品根本没有 CE 认证文件。电商平台对认证信息的审核越来越严格这种问题如果上架后被抽查到轻则下架重则影响店铺信誉。第 6 条也一样详情页说“拆封后不支持退换”售后政策却说“七天无理由”消费者看到两个版本售后纠纷基本是跑不掉的。4.3.1 为什么模型能查出这些跨文件问题很多人会好奇模型是怎么做到跨文件比对的。核心在于我在拼接上下文中给每个文档加了 ID 标签模型在生成问题时可以明确引用来自哪个文档。这本质上和一个人同时打开 6 个文件来回切换比对是一样的只是模型能在几十秒内完成全量交叉核对而且不会因为看久了疲劳而漏掉细节。不过也要说明模型查出来的问题并不全是对的。第 14 条“Handband”拼写问题人类一看就知道是包装盒上印错了但模型会谨慎地标注“待人工确认”因为它不能百分百确定原文没有这个品牌词。这种“不确定就标记”的行为正是我在 Prompt 里反复强调的宁可少报也不要胡报。5. 常见问题与排查技巧实录5.1 模型“想象力”太强编造问题怎么处理最开始我这套 Prompt 没有加“不确定的内容标注为待人工确认”这句话模型就会发挥想象力把资料里根本没写的信息当作背景知识补充进来。比如它认为某款手环应该有 NFC 功能然后去查资料里为什么没写 NFC最后报了一个“疑似缺失 NFC 功能”的问题。实际上这个产品本来就是标准版不带 NFC根本不算缺陷。解决办法就是两条第一在 Prompt 里明确“只基于给定资料不要使用外部知识”第二要求模型对不确定的信息明确标注“待人工确认”。这样它就会把“疑似问题”和“确定问题”分开人工复核的时候心不累。5.2 图片里的文字识别不准多模态模型读图有一个共性弱点就是图片上太小太密的字容易读错。主图角落里印的型号、认证编号、小字免责声明经常会被漏读或误读。我的补救方案是“斜向处理”把图片按区域切块分别放大后再传给模型同时要求模型把识别到的文字原样输出不要纠正拼写。比如包装盒上写了“Bluettooth”你一旦让它“纠正”它就会自动改成“Bluetooth”反而丢失了原始错误信息。如果条件允许更推荐让设计部门把详情页和主图里的文案稿同步给一份文本版。图和文分开传让模型分别检查再合并比对这样既不会漏字又能在“图片文字”和“文本文案”之间做一致性检查。5.3 长上下文被截断虽然 Qwen3.8-Max 的上下文窗口很大但检测报告这类 PDF 如果图片很多提取出来的文本会非常长加上 6 份资料的文本偶尔还是会碰到超限。我的处理策略不是盲目切块而是按文档优先级调整。检测报告和规格参数表优先全量保留说明书可以只保留重点章节参数、安全警告、使用步骤。如果还超就先把主图放第二批单独检查因为图片会占用较多 token。这一步需要灵活处理。最忌讳的是把所有文档平均切成长度相等的 chunk然后让模型逐块检查再人工合并——你会发现很多跨 chunk 的一致性错误根本查不出来因为模型看前一半的时候不知道后一半写了什么。5.4 输出 JSON 不稳定即使指定了response_format偶尔模型还是会在 JSON 后面跟一句“以上是本次检查结果”之类的话或者把 JSON 包在 Markdown 代码块里。我的做法是在解析函数里按顺序尝试三种方式直接json.loads去掉json代码块标记后再解析截取第一个{到最后一个}的子串再解析。再加一层重试逻辑解析失败就重新调用一次接口并把上一次的原始输出附在对话里告诉模型“你上次的输出格式不对请重新生成合法的 JSON”。这三板斧下来我跑了二十多轮基本没有因为 JSON 格式问题卡壳过。写在最后的一点体会搭这个商品资料包体检助手我用了一个完整周末但真正跑通之后它带给我的价值是持续的。每次接到新品资料包只要把文件丢进脚本几分钟就能得到一份问题清单我只需要针对高危项逐条复核效率比过去提高了好几倍。尤其是主图包装盒文字、跨文档参数一致性、认证有效期这类人工最容易漏的点模型反而查得最准。我个人最大的体会是这类工具不是用来替代人的判断而是帮人把“批量核对”这种枯燥工作先做掉让人把精力集中在真正需要经验的决策上。后续我还打算把脚本改造成文件夹监听模式只要有人往指定目录丢资料包就自动触发检查并把结果推送到企业微信群里让上架审核从“等人工”变成“机器先跑一轮”。如果你也经常和电商资料包打交道建议直接照着这个思路搭一个不需要很复杂的工程能力一个脚本加一个 Prompt 就能产生实打实的效率提升。