用大模型给电商商品资料包做体检：Qwen实战与Prompt设计

上周帮一位做家居百货的卖家朋友处理店铺申诉，他的天猫店因为主图上印了“全网销量第一”被系统抽检下架。这个违规表述其实在商品资料包里躺了半个多月，前后经过运营、美工、店长三个人之手，愣是没人察觉。也就是在那一周，我用 Qwen3.8-Max 搭了一个商品资料包体检助手，把包含 6 份文档资料和 1 张商品主图的完整资料包一次性丢进去，不到十分钟就拿到一份 27 个问题的体检报告。其中至少有 5 个问题是人工审查几乎必然遗漏的——包括那个“全网第一”。

这篇文章不聊概念，直接把我搭建这套助手的过程、体检维度设计、Prompt 写法、实测踩坑全部摊开。做电商运营、商品管理、内容审核的朋友，或者正在研究大模型落地应用的同学，都可以照着这套思路改造出适合自己业务场景的版本。不需要复杂的算法基础，核心就是一个大模型 API 加一段可靠的数据解析脚本。

1. 电商资料包的“隐形体检需求”：为什么非做不可

1.1 一份商品资料包里到底藏了多少雷

先还原一下我处理的那套商品资料包。它是一个厨房收纳置物架产品，共包含 6 份资料和 1 张主图：

多平台运营的团队，这套资料还会衍生出天猫版、京东版、拼多多版、抖音版，每个平台对违禁词、宣传规范的要求不完全一致。这些文件分散在不同人手里，运营改一版标题，客服话术里还是旧价格；美工更新了主图，详情页文案里还在用旧卖点——这种不一致在团队协作中几乎每天都在发生。

1.2 人工体检的天然盲区

有人会说，这些东西让有经验的人过一遍不就行了？问题在于“有经验的人”看一份资料包需要多久。

我之前专门测算过，一个熟手把 6 份资料完整过一遍，至少需要 40 到 60 分钟。这还是在只做快速浏览的情况下。如果要做到真正的交叉一致性检查——比如把规格参数表里的“承重 30kg”和详情页里的“承重 60 斤”做单位换算核对，把客服话术里的价格和活动利益点里的到手价做比对——时间还要翻倍。而人眼的疲劳曲线决定了，连续排查到第 30 分钟之后，漏检率会直线上升。

更重要的是，人工检查存在一个几乎无法克服的问题：人是按文件去读的，不是按“字段关系”去读的。读详情页的时候，你不会时刻想着去对照规格参数表里的每一个数值；打字回复客服话术草稿的时候，也不会每写一句就去翻一遍活动利益点。跨文档校验这件事，天然违背人的阅读习惯，却恰恰是机器和大模型的强项。

1.3 为什么选 Qwen3.8-Max 而不是规则脚本

你可能想问：这些字段比对，用 Excel 函数或者写 Python 脚本不也能做吗？

能，但只能做最表层的那部分。规格参数表里的“304 不锈钢”和详情页里的“食品级不锈钢”，一个是材质标准，一个是安全等级，规则脚本判断不了它们是否指向同一信息。客服话术里写“七天无理由退换”，活动页里写“支持 15 天无理由”，这种语义级别的差异，传统的精确匹配完全无能为力。

我当时选 Qwen3.8-Max 的核心原因有三个。第一，它的长文本理解能力足够一次处理完整的多文件资料包，不需要把文档拆得七零八落再分别喂给模型，这样反而会丢失跨文档上下文。第二，它对中文电商语境的理解比较到位，平台禁用词、广告法相关表述、电商黑话它基本都能识别，不太需要额外维护一份庞大的词库。第三，它在结构化输出方面表现稳定，配合 JSON 输出模式，可以直接把检查结果变成可编程处理的报告数据。当然，我不是说规则脚本没用，实际上后面你会发现，规则脚本在大模型跑完之后还有非常重要的“兜底”角色——这个我们留到第三章细说。

2. 体检维度设计：让大模型查什么、怎么查、按什么标准查

2.1 五维检查框架：完整性、一致性、合规性、表达力、图片一致性

拿到一套资料包，先别急着写 Prompt。我踩过最大的坑之一，就是一上来就让大模型“检查一下有没有问题”——这种开放式的指令，得到的回答往往大而空，什么“建议加强品牌调性”“可以优化卖点表达”，一点实际价值都没有。

正确的做法是先把体检维度定义清楚。我在这个项目里把检查项拆成了五个维度：

完整性：必填字段是否缺失。比如规格参数表里有没有材质、尺寸、承重这些基础参数；详情页有没有售后说明；合规自查表是否完整。

一致性：多份资料之间的交叉信息是否统一。这个维度信息量最大，问题也最多。包括价格、规格、卖点、活动规则、材质表述等。

合规性：是否违反平台规则和广告法。极限词、绝对化用语、无法证明的数据宣称、侵权风险表述等。

表达力：文案层面的质量问题。错别字、标点全半角混乱、长句晦涩、卖点堆砌没有逻辑等。

图片一致性：主图上的文字信息与文档资料是否匹配。这是纯文本大模型需要借助 OCR 才能完成的部分。

2.2 跨文档一致性检查的“字段关系表”

五维框架里最容易设计、也最容易出问题的是“一致性”。你需要提前列出哪些字段之间存在对应关系，这些关系叫“字段关系表”。

举几个实际例子。价格这个字段，可能同时出现在客服话术、活动利益点、详情页文案三份文件中，三处必须一致。容量/净含量这个字段，可能同时出现在规格参数表、详情页文案、主图三处，而且可能存在单位换算（毫升和升、克和千克）。卖点关键词，会在标题、详情页、主图文案中重复出现，不能互相矛盾。材质表述，在参数表里是“201 不锈钢”，在详情页里写“不锈钢”，在产品图里写“高级不锈钢”，这三者之间的逻辑关系需要判断。

构建字段关系表的过程，实际上就是盘清你的资料包有哪些“关键信息节点”。我建议用 Excel 先把这些字段关系列出来，再把它写进 Prompt 里，让大模型严格按表执行。这样检查结果的可复用性会大幅提升——换一套资料包，只需要微调字段名称，检查逻辑完全不用重写。

2.3 商品图这条链路：OCR 先行，语义比对在后

主图的检查比较特殊。Qwen3.8-Max 是文本模型，不能直接“看”图片，所以需要先把图片上的文字提取出来。

我用的方案是 PaddleOCR 本地跑一遍，把主图上的中文、英文、数字全部抽成文本，再连同 OCR 坐标信息一起交给大模型做后续判断。主图上的文字通常不多，十几秒就能跑完。

这里有一个非常关键的细节：OCR 输出的文本一定要保留坐标信息。为什么？因为判断主图合规性时，排版位置很重要。比如“全场五折”和“满 99 减 50”如果放在主图的同一个位置，可能导致视觉冲突；再比如主图上如果有小字备注“活动最终解释权归本店所有”，这种字体过小、容易误导消费者的表述，平台往往是重点监管对象。有坐标信息，Prompt 里的检查规则才有落地的抓手。

3. 系统搭建实录：数据解析、Prompt 工程与代码兜底

3.1 整体架构与数据预处理

整个系统的代码不大，核心流程分四步：文件解析、OCR 提取、大模型体检、报告生成。我用 Python 搭的主流程，文件解析部分用了几个成熟库：Word 和 Markdown 直接读文本，Excel 用 openpyxl 读取并保留单元格结构，图片用 PaddleOCR 识别。核心代码骨架如下：

import json import openpyxl import docx from paddleocr import PaddleOCR import dashscope from dashscope import Generation def extract_text_from_docx(path): doc = docx.Document(path) return "\n".join([p.text for p in doc.paragraphs]) def extract_from_excel(path): wb = openpyxl.load_workbook(path, data_only=True) rows = [] for ws in wb.worksheets: for row in ws.iter_rows(values_only=True): rows.append(" | ".join([str(c) for c in row if c is not None])) return "\n".join(rows) def ocr_image(path): ocr = PaddleOCR(use_angle_cls=True, lang="ch", show_log=False) result = ocr.ocr(path, cls=True) items = [] for line in result: for box, text in line: items.append({ "text": text[0], "position": box }) return items def check_with_llm(context: dict): prompt = build_prompt(context) # 核心 Prompt 构造 resp = Generation.call( model="qwen3.8-max", messages=[{"role": "user", "content": prompt}], result_format="message" ) return json.loads(resp.output.choices[0].message.content)

提示：这里用了 dashscope SDK 调用 Qwen3.8-Max 模型接口，实际使用时替换为自己的 API Key 和模型可用名称即可。为了演示完整流程，我保留了最简调用方式，生产环境建议加上重试和超时处理。

3.2 Prompt 工程：三个决定成败的设计

Prompt 是这套系统的灵魂。我前后迭代了三个版本才稳定下来，最终版有三个关键设计。

设计一：给模型一个明确的“检查专家”角色，并定义输出约束。

一开始我的 Prompt 只写了检查要求，没有定义输出结构，结果每次返回的格式都不一样，有的用列表，有的用段落，后处理非常痛苦。后来改成角色设定 + 固定 JSON 输出结构，一次就稳定了。角色设定让模型以“平台资深审核员”的视角去做判断，输出约束强制它按 [{"file": "详情页", "issue": "...", "severity": "high", "suggestion": "..."}] 这样的结构逐条返回。

设计二：把检查维度和字段关系表写进 Prompt，而不是让模型自由发挥。

第二章说的五个维度和字段关系表，这一步真正发挥作用。Prompt 里明确列出每个维度要检查什么，哪些字段之间需要做交叉比对，模型输出的结果就非常聚焦。比如我明确写了“请重点核对：规格参数表中的承重、容量、尺寸，与详情页文案及主图文字信息的一致性”，模型就会把精力集中在这类跨文档比对，而不是泛泛而谈“优化文案”。

设计三：引入“先推理再作答”的两阶段输出。

这是效果提升最大的一步。我在 Prompt 里要求模型先输出一个“检查过程摘要”，说明它发现了哪些可疑点、做过哪些交叉比对，再输出最终 JSON 报告。这个设计有点类似让模型先展示思考过程再给结论，实际跑下来，漏检率比直接输出答案要低不少。也不需要单独发两次请求，在同一个 Prompt 里让它先写推理再输出 JSON 就行。

3.3 数值归一化与规则兜底：大模型不擅长精确比对

大模型在语义判断上很强，但在精确数字比对上有明显短板。我的实测里，模型遇到“500ml”和“0.5L”这种单位换算能反应过来，但遇到“358×246×84mm”和“35.8cm×24.6cm×8.4cm”这种规格表达时，偶尔会给出错误判断，甚至出现把 358 和 35.8 直接当成两个不同数值的低级错误。

解决方案是在把文本喂给大模型之前，先用代码做一次数值归一化。我写了一个预处理函数，把所有常见的单位换算统一成标准单位，尺寸统一换算成 mm，容量统一换算成 ml，重量统一换算成 g。归一化后的文本再喂给模型，数字比对的准确率明显提升。

同理，规则脚本在大模型跑完之后还承担“硬性拦截”的角色。像“第一”“绝对”“最”这些极限词，我另外维护了一个小型敏感词库，用正则在大模型输出结果之外做一次全量扫描。这样做不是为了替代大模型，而是给合规性检查加一道保险——规则永远比模型更可靠，也更容易向平台审核人员解释。

4. 实测结果：27 个问题是怎么分布的，哪类最致命

4.1 问题清单总览

整套资料包跑完，Qwen3.8-Max 一共返回了 27 个问题。我按五个维度做了分类统计：

27 个问题里，严重级别为高的有 12 个。这个比例比我预想的高得多，也间接说明这套资料包在发布前的人工审核环节几乎是形同虚设的。

4.2 三个典型问题的深度复盘

问题一：标题“免打孔安装”与参数表“需钻孔安装”直接冲突。

这是整套报告里最触目惊心的一条。标题文案写的是“免打孔安装”，而规格参数表里明确标注“安装方式：需钻孔”。运营、美工、店长三个人分别看过材料，却没人把标题和参数表放在一起对照过。如果这套资料包直接上新，买家收到货发现需要钻孔，退货退款和差评几乎是必然的。

问题二：主图“承重 30kg”与参数表“承重 15kg”不一致。

主图为了突出卖点，把承重标到了 30kg，参数表里写的却是 15kg。这个差异我推测不是恶意夸大，而是运营在写主图文案时凭印象填的。但平台规则里，主图宣传参数和详情参数不一致，属于误导消费者，被举报或抽检到就是违规。这类问题典型的产生原因就是信息源多、更新不同步，人工极难发现，而大模型只要把主图文案和参数表放在一起做一次交叉比对，立刻现形。

问题三：客服话术的价格与活动利益点的到手价相差 10 元。

活动利益点写的是“前 100 名到手价 89 元”，客服话术里却还保留着“日常售价 99 元，活动到手价 99 元”的旧版本。买家咨询时按客服的说法下单，实际支付却是 89 元，用户不会觉得自己赚了，只会觉得店铺价格体系混乱。这类问题在电商里特别常见，因为客服话术的更新滞后于运营活动节奏，往往是一个月前的话术还在沿用到新活动里。

4.3 误报与漏报：大模型实测的边界在哪

27 个问题里，也有两条误报。一条是模型把“加厚不锈钢”里的“加厚”判断为疑似绝对化用语，实际上“加厚”是描述性词汇，只要不写“最厚”“超厚第一”这类表述，平台一般不会判定违规。另一条是模型认为详情页缺少“生产日期”信息——但这是一个收纳置物架，属于非食品类目，根本不需要标注生产日期。

误报不算严重，说明模型的判断在合理范围内，但提醒我两点：

第一，合规检查规则需要结合具体类目，食品、美妆、电器、家居的合规要求差异很大，Prompt 里的检查清单得按类目定制，不能一套规则打天下。

第二，大模型的判断结果适合做“候选清单”，不适合直接当“最终结论”。我现在的流程是模型输出结果后，由人工对高严重级别的问题做二次确认，中低严重级别的问题直接走修改流程。这个分层审阅机制，既保留了 AI 的效率，也保留了人的最终判断权。

5. 踩坑复盘：系统从能跑到好用，关键在三个细节

5.1 OCR 识别误差：图片文字质量的隐形陷阱

PaddleOCR 中文识别准确率已经很高，但在主图这种字体多变、有背景干扰的场景下，仍然会出错。我第一次跑的时候，“ml”被识别成“m1”，“304 不锈钢”被识别成“3O4 不锈钢”。如果不做处理，这些错误文本直接喂给大模型，模型会在错误信息的基础上做判断，结果自然不可靠。

后来我加了两个处理。一是针对数字和单位做了 OCR 后处理，结合商品类目常见的单位词库，对疑似识别错误做自动纠正；二是在 Prompt 里明确要求模型“注意 OCR 文本可能存在的识别误差，如遇无法确认的字符请单独标注可疑程度”，让它不至于在错误信息上得出过度自信的结论。

5.2 模型输出偶尔“胡编”：结构化校验必须有

大模型偶尔会输出一些资料包里不存在的“问题”。比如它在一份资料里凭空生成了一个不存在的型号“BX-20”，还说这个型号和标题中的“BX-10”不一致。我追踪了一下，猜测是模型在上下文里看到了“型号”这个字段后自由发挥编造了一个。

应对方案是在代码里加一道结构化校验：模型返回的每条问题记录，必须能从原文中找到对应的证据文本，并记录证据所在的文件名和原始句子。如果程序在原文中检索不到对应证据，这条问题直接降级为“疑似”，不进入正式报告。这个机制在程序上不复杂，但对报告的可信度提升非常大。

5.3 Prompt 从第一版到终版的三个关键改动

第一版 Prompt 太“放养”，只给了角色和任务，模型输出一堆正确的废话。第二版加入了五维框架和字段关系表，输出开始聚焦，但格式不稳定。第三版加了 JSON 结构约束和“先推理再输出”的两阶段要求，这才达到我想象中的可用状态。

除开发送前的 Prompt 设计，生成后的报告整理同样重要。我把模型返回的 JSON 报告直接转成了带严重级别标签的 Excel 表格，按“高-中-低”排序后发给业务同事。表格里每条问题都带“证据文件-证据原文-修改建议”，业务同事不需要再翻原始资料包就能定位问题，整个推动整改的流程顺畅了很多。

注意：如果要把这个流程做得更完整，还可以在报告生成后加一层“整改闭环”——每条问题记录指派负责人和截止日期，整改完成后再次用体检助手复检，确认问题清零。这一步不涉及技术，但能把体检的价值落到业务结果上。

5.4 成本与耗时：大家最关心的数字

这套体检跑一套资料包，耗时主要取决于文件数量。我的实测数据是：6 份文档加 1 张主图，OCR 约 10 秒，大模型推理约 1 到 2 分钟，全程不超过 3 分钟。费用方面，OCR 本地跑不花钱，Qwen3.8-Max 按 token 计费，一份资料包入参加出参总共 1 万 token 左右，成本可以忽略不计。对需要批量检查几十上百个 SKU 的团队来说，这个成本和效率都相当有竞争力。

6. 适用边界与进一步扩展思考

这套方案目前最适合的是 SKU 数量多、资料包结构相对固定的电商团队。SKU 越多，人工检查的边际成本越高，AI 体检的收益越明显。相反，如果团队只有两三个商品，人工检查也就一两个小时的事，搭建这套系统的投入产出比就不划算了。

我在实际使用中还有一个体会：这套系统的价值不止在于查出问题，更在于把检查标准固化了下来。以前团队对“什么样的资料包算合格”没有统一认知，每个人的标准都不一样。现在五维检查框架写进 Prompt 里，等于把团队内部的品控标准变成了可执行、可复现的流程，新来的运营照着报告改就行，不需要再靠口口相传去理解老员工的经验。

后续如果要扩展，我建议优先考虑两个方向。一是把检查结果接入内部通知，跑完自动推送到工作群，时效性会更好；二是沉淀每个商品的历史检查报告，形成一个质量问题数据库，用数据反向优化团队的工作流程——比如如果一段时间内一致性类问题频发，说明协同流程里有环节需要调整，这比单次检查的意义大得多。