前阵子运营那边塞给我一个活：一批新品的电商商品资料包要上架前审核，6份文档加1张商品图，人工一份份对，光缺项、错价、信息冲突就得来回折腾大半天，关键是漏检率还高。我本来想写一堆规则脚本硬碰，结果发现资料包里的问题五花八门——有图片和表格对不上的，有资质文件缺页的，还有详情页文案里参数写错单位的，纯规则根本覆盖不全。后来换成Qwen3.8-Max搭了个“商品资料体检助手”，把6份资料和1张商品图一次性丢进去做交叉体检，一轮下来直接列出27个问题，从信息缺项到跨文件冲突全给揪出来了。这篇就把整套思路、Prompt设计、数据结构化处理和排坑过程完整拆开讲，给同样被资料审核折磨的人一个能直接抄的参考方案。
1. 为什么用大模型做商品资料“体检”
1.1 电商资料审核的真实痛点
先还原一下工作场景。电商平台上架一个商品，尤其是标品、食品、美妆这类强管控类目，审核要看的资料通常不止一份：商品主图、详情页文案、质检报告、生产资质、品牌授权、价格库存表，有时候还要附上历史驳回记录。这些东西分散在不同格式的文件里，有PDF、Word、Excel，还有扫描件图片，人工审核的时候要来回切换、逐项比对，既慢又容易漏。
我统计过一组数据：纯人工审核一个资料包，平均耗时40到60分钟，漏检率大概在10%到15%之间。漏掉一个资质过期，等平台审核驳回，整个上架节奏就全乱了；漏掉一个价格不一致，客服当天就能收到比价投诉。传统的规则脚本只能做“文件在不在”“字段填没填”这种存在性检查，对“文案里写的成分表和质检报告上的成分表是不是一致”这种语义层面的交叉核对完全无能为力。这也是我一开始纠结要不要上大模型的原因——规则脚本做不了的事，恰恰是审核里最耗时也最容易出错的环节。
1.2 Qwen3.8-Max在这件事上的核心优势
选Qwen3.8-Max而不是其他模型，核心原因是三个：多模态理解、长上下文窗口、稳定的结构化输出。商品资料体检这件事，输入的是好几份不同格式的文档加一张商品图，输出的是一个看起来像“体检报告”的问题清单，这就要求模型既要能看懂图，又要能同时记住多份文档里的细节，还要按固定格式输出方便后续用程序处理。
我实测下来，Qwen3.8-Max在多模态输入上表现比较稳，尤其是对商品主图上的文字、吊牌上的参数这类密集文本，识别准确率比预期好。长上下文方面，六份资料加一张图的文本量大概在一万到两万token之间，模型都能完整吃进去，不需要拆成多段再做二次拼接，直接减少了一层信息损耗。最关键的还是结构化输出——我要的是给下游程序用的JSON格式结果，字段缺失、格式漂移都会增加解析成本，Qwen3.8-Max在输出稳定性上确实省了不少麻烦。
1.3 和纯规则脚本相比，差异在哪里
我不否认规则脚本的价值，它在大批量、强逻辑的场景下依然是最可靠的方案。但在这个项目里，规则脚本有两个硬伤：第一，只能做单文件内的格式校验，跨文件关联对比基本做不了；第二，遇到扫描件、图片里的信息，规则脚本只能靠OCR，而OCR出来的结果还要再写一堆正则去匹配，维护成本很高。
大模型的价值在于把这些离散的信息统一拉到一个语义空间里做对齐。原本要写几十条正则的活，现在一句“对比质检报告和详情页中的成分列表，列出不一致项”就能搞定。而且模型的泛化能力让它能处理规则脚本覆盖不到的边界情况，比如“生产日期格式不统一”“品牌商标大小写混用”这种人性化问题。我最后落地的时候其实是两条腿走路：大模型做语义体检，规则脚本做数值校验，两边互补，效果才拉满。后面第4节会具体讲这个混合架构。
2. 系统整体设计与资料包结构拆解
2.1 体检助手的整体工作流
整个体检助手不是只调一次大模型就完事，而是拆成“预处理-组装-推理-校验”四段流水线。预处理阶段把各种格式的文件统一转成模型能接受的输入：PDF转文本或图片、Word提取正文、Excel解析成表格、商品图压缩成合适尺寸。组装阶段按固定顺序把文本和图片拼成一条多模态请求。推理阶段让Qwen3.8-Max按预设的体检模板逐项排查。校验阶段再用规则脚本对模型输出的数字字段做二次核对，确保价格、日期、库存这种精确信息不出错。
这个流程我建议所有想复现的人直接照抄，不是因为有多高级，而是每段都有独立的容错点。比如预处理阶段如果某个PDF解析失败，可以单独告警而不用重跑整个链路；校验阶段如果发现模型把价格写错了，程序能自动纠正而不是盲信模型输出。整条流水线跑完一个资料包大概花三四分钟，其中模型推理占大头，人工只需要在最后扫一眼问题清单做复核。
2.2 六份资料和一张商品图的预处理
说得具体点，我这个项目里“6份资料和1张商品图”是指：商品主图（就是那张商品图）、详情页文案、质检报告、品牌授权书、价格库存表、历史驳回记录、产品参数表，一共七份材料。不同格式的处理方式差别很大，一个个说清楚。
商品主图我直接用多模态方式传给模型，但在传之前会做一次简单的图片质量检查——太模糊的图提前告知“清晰度不足”，避免模型乱猜。质检报告和品牌授权书通常是PDF，如果PDF本身带文本层就用pdfplumber直接抽文本，如果是扫描件就先用PaddleOCR转成文字再组装，这一步的准确率直接决定了后面模型判断的准度。详情页文案和产品参数表可能是Word也可能是PDF，统一用python-docx或pdfplumber提取。价格库存表是Excel，用pandas读成结构化表格后转成字符串。历史驳回记录一般就是纯文本，直接读就行。
这里有一个容易踩的坑：扫描件OCR出来的文本经常丢格式，比如“1000g”被识别成“1000 g”或者“1 ooo g”。所以预处理阶段我会在文本后面附带一行说明“以下文本来自OCR识别，可能包含字符错误，请结合上下文判断”，把这个不确定性直接告诉模型，比让它蒙着猜靠谱得多。
2.3 工具选型与运行环境
整个项目我用的都是Python生态的常见库，环境搭建成本很低。PDF文本提取用pdfplumber，扫描件OCR用PaddleOCR，Word文档用python-docx，Excel用pandas，图片压缩用Pillow，最后调Qwen3.8-Max的API走的是OpenAI兼容格式，用requests直接请求就行，不需要额外装SDK。
模型调用层面，参数上我固定设置temperature=0.1，目的是让输出尽量稳定，减少随机性。像“成分表哪里不一致”这种问题，我不需要模型发挥创意，只需要它准确列举。还有一个细节是max_tokens要设得足够大，否则长文档体检时输出到一半会被截断。我这个项目里设到8000，实测6份资料加1张图一轮体检下来，完整的JSON输出大概在3000到5000 token之间，8000的余量还是很充裕的。
3. 让Qwen3.8-Max看懂商品资料：Prompt与结构化输出
3.1 多模态输入组装
Prompt怎么组装是这项目里最影响效果的部分，没有之一。我踩过不少坑才调出一套稳定可用的组装格式，核心原则是“分区块描述 + 明确任务指令 + 强制JSON输出”。
文本部分，我会把每份资料按固定格式拼进去，格式大概是这样的：
文件一：商品主图（图片） 文件二：产品参数表（Word） - 品牌：XX - 型号：XXX-123 - 净含量：1000g - 保质期：18个月 文件三：质检报告（PDF） - 报告编号：QZ20240115 - 检测项目：...图片部分直接接在文本后面，用base64编码转成data URL传给多模态接口。关键点是图片不要只传一张压缩到很离谱的小图，尺寸控制在1024x1024左右比较合适——太小了吊牌上的字看不清，太大了浪费token还容易超时。我实测压缩到1080px长边，识别效果和速度比较平衡。
任务指令部分我写了固定模板，核心是“逐项体检、交叉对比、只报告问题不修改信息、输出严格JSON”。这里“只报告问题”很重要，不加这句话模型有时会直接把正确的信息也列一遍，导致输出膨胀还很占token。
3.2 体检模板与问题分类设计
体检不是让模型自由发挥，而是给它一个固定的问题分类体系，让它逐类排查。我把电商商品资料常见问题分成四大类：信息缺项、信息冲突、资质合规、格式与计算错误，这四类基本覆盖了日常审核里95%的驳回原因。
信息缺项包括“缺少品牌名”“缺少规格参数”“缺少生产日期”这类文档内缺失项。信息冲突是重头戏，指的是同一信息在不同文件中说法不一致——比如商品主图吊牌上写“净含量500ml”，产品参数表里却写“净含量500g”，这种跨文件矛盾靠人工看非常费眼，但对大模型来说就是一次简单的语义对比。资质合规指的是“质检报告过期”“授权书有效期与上架时间不匹配”这类。格式与计算错误则是“价格和数量相乘不等于总价”“日期格式不统一”这类相对机械的问题。
为了让模型输出更规范，我在Prompt里直接给出JSON Schema的示例，让它严格参照这个格式返回。Schema长这样：
{ "problems": [ { "category": "信息冲突", "severity": "高", "title": "净含量标注不一致", "detail": "商品主图标注为500ml，产品参数表标注为500g", "files": ["商品主图", "产品参数表"] } ] }3.3 两轮交叉体检：逐份查缺 + 跨文件比对
只让模型从头到尾读一遍，输出结果经常会有遗漏，尤其是信息冲突这种需要跨文件关联的问题。我后来改成两轮体检：第一轮是“逐份查缺”，让模型分别对每一份资料做完整性检查，找出文档内部的问题；第二轮是“跨文件比对”，把所有文件的内容放在一起，找出相互矛盾的地方。
两轮分开做有个好处：单文件内部的问题判断门槛低，模型更愿意输出，不会因为问题太多而漏掉，也算是降低信息遗漏率的一个办法；而跨文件比对消耗的上下文更长，需要模型做更复杂的推理，单独一轮更容易聚焦。实测下来，两轮体检比一轮多查出了大概30%的问题，尤其是细节上的冲突。第二轮Prompt里我还会刻意加一句“重点对比同名字段在不同文件中的描述差异”，这句话能有效引导模型关注跨文件一致性。
4. 27个问题是怎么被查出来的
4.1 问题清单全景
我拿一个典型的资料包跑了完整流程，最后模型输出的问题清单一共27项，按照四类问题分布如下：
| 问题类别 | 问题数量 | 典型例子 |
|---|---|---|
| 信息缺项 | 8 | 缺品牌中英文对照名称、缺存储条件说明、缺生产许可证编号 |
| 信息冲突 | 6 | 净含量单位不一致、主图颜色与参数表不符、保质期算法不一致 |
| 资质合规 | 5 | 质检报告有效期不足、授权书缺少官方盖章页、检测标准号引用过期 |
| 格式与计算错误 | 8 | 价格库存表第3行总价算错、Dates列混用中文/数字格式、SKU编码重复 |
说实话，这个数量我自己都有点意外，因为人工审核的时候我扫了一遍只觉得有七八个问题，很多冲突因为没有逐字对比根本没发现。模型一轮下来查出27个，其中“质检报告的检测标准和详情页里的引用标准不一致”这种问题，靠人眼几乎不可能发现。
4.2 跨文档冲突检测的实现细节
跨文档冲突是系统最核心的能力，也是写Prompt时最需要讲究的地方。我给模型的任务指令用了“先提取后对比”的思路：先从所有文件中提取一份“关键信息清单”，包含产品名、品牌、规格、价格、生产商、有效期、成分表等字段；然后再对这个清单做一致性检查，同一个字段在不同文件中出现多次就对比一次。
实际操作里，我会在Prompt里直接列出需要重点比对的字段，降低模型遗漏的概率。比如：净含量、保质期、储存条件、生产商、生产许可证编号、规格型号、成分列表，这些是电商审核最高频出现冲突的字段。模型会先输出提取结果，再输出冲突问题列表，这样每一步的结果都可追溯，而不是黑盒地给一个“有问题”的结论。
这里有个细节：我会要求模型在“detail”字段里引用具体出处，比如“商品主图吊牌区域标注XX，详情页第2段标注XX”。一方面方便人工复核时快速定位，另一方面也倒逼模型真正去看了对应的内容，而不是凭上下文联想瞎编。
4.3 Rule-base兜底：模型不管数字，规则管
不是说模型什么都能干，精确计算和法律格式校验我建议还是交给规则脚本。大模型在数字运算上不可靠，这已经是公开的秘密了，“价格×数量=总价”这种简单的算术，模型偶尔也会出错。所以我的系统里专门加了一层规则校验器，跑完模型之后再对数字字段做精确比对。
具体来说，规则脚本负责三件事：校验价格库存表里的算术逻辑、检查日期格式是否符合统一标准、验证SKU编码是否重复。这三类问题都是机械性判断，规则脚本能做到100%准确，没必要让模型花token去做还有可能做错。我在项目里用pandas加载价格库存表，直接用向量运算校验“单价×数量=总价”，一行代码都不需要模型。
这层校验如果发现问题，会以同样的JSON格式追加到问题清单里，和模型发现的问题合并输出。这样最终的报告既有模型处理语义问题的能力，又有规则脚本处理精确问题的可靠性，两边互补才敢对外说“一次查出27个问题”。
5. 上线实测：效果、坑与排查实录
5.1 测试数据与检出率
为了验证系统靠谱程度，我拿了10个商品资料包做压测，每个资料包都用人工审核和体检助手各跑一遍，再对比结果。量化来看，体检助手平均每个资料包检出23到31个问题，人工平均检出19个，多出的部分集中在跨文件冲突和资质细节上。人工复核了一遍模型查出的问题，准确率大概在90%左右，剩下10%是误报，主要集中在“OCR识别偏差导致的无效告警”和“模型过度解读导致的伪冲突”这两类。
时间方面，纯人工审核一个包要40到60分钟，体检助手一轮跑下来3分钟左右，加上人工复核总共不超过10分钟，效率提升了大概5倍。这个提升对日常运营来说很直观——原本一天只能审10个包，现在能审30个，还能顺手查漏补缺。
5.2 踩过的三个坑
第一个坑是扫描件OCR质量导致误报。质检报告是扫描件，PaddleOCR识别时把“8g”识别成了“0g”，模型对比成分表时认真指出了“成分表克重不一致”。这个不怪模型，问题出在OCR环节。后来我加了“OCR文本置信度提示”，在Prompt里说明某些字段来自OCR识别可能不准，让模型在对比时更谨慎，误报率明显下降。
第二个坑是PDF没文本层时直接被跳过了。有几个产品参数表是纯图片PDF，预处理时pdfplumber抽取出来是空的，模型完全没看到内容，自然也没查出那个文件里的问题。排查半天才发现是预处理环节没做“PDF是否有文本层”判断。后来我加了一步：如果PDF抽出来的文本长度小于某个阈值，就自动转成图片再走一遍多模态，双重保险。
第三个坑是模型输出偶尔会被系统截断。第一次测试时发现问题清单经常只有十几条，开始以为是模型没查全，后来看日志才发现是max_tokens设小了，输出到一半就被切断。把max_tokens从2000调到8000之后，这个问题就消失了。如果你复现时发现“查不全”，先检查这参数。
5.3 常见问题速查表
| 症状 | 原因 | 解决方案 |
|---|---|---|
| 模型漏查某个文件的问题 | 预处理时文件没被解析成功 | 检查文件解析日志，PDF无文本层需转图片 |
| 查出的问题数量偏少 | max_tokens设太小，输出被截断 | 调大到6000-8000 |
| 图片上的参数识别错误 | 图片压缩过度导致文字模糊 | 控制在1080px长边，不要过度压缩 |
| 跨文件冲突漏报 | 直接一轮体检做完全部检查 | 改成“逐份查缺 + 跨文件比对”两轮 |
| 价格计算类问题报错 | 让模型做了算术运算 | 交给规则脚本用pandas校验 |
| JSON输出偶尔格式错误 | 模型随机性导致 | 设置temperature=0.1，并在Prompt里给Schema示例 |
还有一个我觉得很值得分享的细节：每次跑完之后，我会把模型发现的问题和人工复核结果一起存进一个记录表，每周做一次统计，看哪个类别误报率高，哪个类别漏报多，然后针对性地调整Prompt。这不是一锤子买卖，是越用越准的。
6. 这套思路还能怎么扩展
商品资料体检只是大模型在电商内容治理里的一个切口，思路理顺了，周边应用其实很多。比如把体检助手接进上架审批流，资料包上传后自动跑体检，问题清单直接同步给运营或供应商去修改，改完再自动复检，完全不用人工介入；再比如把历史驳回记录里高频出现的问题喂给模型做Few-shot示例，让它更懂这个类目的审核偏好。
我个人的体会是，大模型应用能不能落地，往往不取决于模型本身多强，而取决于你把边界画得多清楚。什么让模型干，什么让规则干，什么让人工兜底，一开始就想清楚，系统才稳。Qwen3.8-Max在语义理解和多模态上的表现给了我很大惊喜，但这个项目最后效果好，靠的是“模型+规则+人工复核”三层结构，少一层都不行。
最后再分享一个小技巧：Prompt里的任务指令不要写成命令式，而是要写成“你在扮演一个电商审核专员”这种角色设定。实测下来，给模型一个明确的角色和职责边界，它的输出质量会比单纯下指令高一截，尤其在判断标准比较主观的“资质合规”类问题上，效果差距更明显。这个技巧免费送给大家，拿去用在其他文档处理场景也适用。
