先交代一下背景。我最近拿到一套准备上架的便携榨汁杯资料包供应商一次性丢过来 6 份文档加 1 张商品主图。按我以前的习惯这种资料得人工把标题、详情页、规格表、活动说明全部交叉比对一遍没有一两个小时下不来。那几天我实在不想做这种机械核对就试着用 Qwen3.8-Max 搭了一个电商商品资料包体检助手。结果第一轮跑完6 份资料和 1 张商品图被查出 27 个问题其中好几个属于人工核对时很容易滑过去、但上架后一定会被平台抓的硬伤。这篇文章把我做这个小工具的完整过程、模型选型思路、工作流设计、27 个问题的复盘以及调整过程中踩过的坑都写出来。如果你平时做商品运营、渠道铺货或者想用大模型做内容审核、资料一致性检查这篇内容可以直接参考。1. 商品资料包体检查的不是错别字而是“跨文档矛盾”1.1 “6 份资料 1 张图”里到底藏了哪几层一致性先说清楚这个体检任务到底是干什么的。一份商品资料包里通常不会只有一张表格而是多个来源并行产生的内容商品基础信息表、卖点文案、详情页文案、规格参数表、营销活动说明、客服 FAQ外加一张要直接投放到渠道的主图。这些文档往往不是同一个人写的。基础信息表可能是采购从 ERP 里导出的详情页是设计师根据卖点发挥的FAQ 是客服根据过往经验填的主图又是另一拨人按活动诉求做的。每个环节都有自己认为“正确”的口径但合在一起就会出现同一个参数在不同文件里不一样的情况。我在这个项目里把所有问题分成四层高风险合规问题极限词、绝对化用语、医疗功效暗示、资质缺失。这类问题平台一旦查到轻则下架重则扣分必须最先处理。跨文档数据一致性问题容量、尺寸、电池、防水等级、刀头数等硬参数在不同文件里互相打架。完整性与规范性问题该填的条码没有、该附的报告编号缺失、活动规则里有执行漏洞。图文一致性问题商品图上印的大字和正式资料里的参数对不上比如图片写 600ml规格表却是 450ml。如果只是做错别字检查或者只检查某一个文档本身是否通顺那就够不上叫“体检”。体检价值的大头就是把不同文档里描述同一个实体的信息拉齐比对。这也是为什么我用大模型而不是简单地用 Excel 公式硬核对照。1.2 为什么我决定放弃人工逐条核对一开始我也试过用人工方式处理这份资料。先打开商品基础信息表记住标称容量再去详情页里 grep“容量”两个字接着去规格表里核对最后还要把主图放大看角落里的标签。这种工作很考验人的耐心但最大的问题不是慢而是“漏”。人的注意力在处理跨文档一致性问题时有个天然短板短时记忆只能同时维护少量实体。我核对到第二份文档时前面标题里的“450ml”已经有点模糊了核对到第四份文档时我得反复回翻才能确认“600ml”到底是哪来的。而且像极限词、医疗暗示这类问题更多依赖一个人的合规知识储备不是每个做运营的人都记得住平台红线。另一个现实是这套资料包不是只做一次。换个型号、换个活动、换一批图片又要从头核一遍。人工核对能做一次但做不成一条持续运转的流水线。我花了两天把助手搭起来后续每次拿到新资料包丢进去跑一轮就能得到结构化的问题清单这个复利非常明显。2. 选型评估为什么在这个任务里押注 Qwen3.8-Max2.1 拆开任务的能力需求长文本、结构化输出、多模态识别借用一句项目里常说的大实话决定用哪个模型之前先决定你的任务需要哪些能力。商品资料包体检这个场景拆下来有三个硬需求。第一它需要同时处理 6 份不同格式的文档单份文档可能超过几千字。模型必须有一个足够长的上下文窗口最好还能在较长上下文中保持稳定的注意力。我测下来上下文窗口如果偏小把 6 份资料全部灌进去后后面的内容基本会被“稀释”最后返回的报告会漏掉后半段资料里的很多问题。第二它需要严格的 JSON 结构化输出。我要的不只是“这段文案有问题”这种自然语言提示而是能被后续流程自动处理的问题清单包括问题等级、所属资料、原文引用、修改建议。这要求模型能稳定遵循输出格式。第三它需要多模态能力。商品图上有大量手写标签、艺术字、价格角标这些并不是简单的 OCR 就能解决的因为有些标签字号小、颜色浅还叠加在复杂背景上。所以模型得能直接看图并把图上文字信息与文本资料做交叉比对。这三条叠在一起可选项其实没有那么多。我最后选了 Qwen3.8-Max是因为它在一个模型里同时覆盖了长文档、结构化输出和多模态理解不需要我再拼装两三个模型做串联。2.2 我的评估方法不是看榜单分数而是拿真实资料跑一遍坦白说比起看公开发布的榜单结果我更相信拿真实场景去跑一轮。做法很简单准备一份已经全部人工核对过的老资料标好标准答案比如“这里有一个极限词”“那里有一个容量冲突”然后让模型去查。第一轮我用两套方案做了对照。一套是本地部署的小尺寸模型大概是 7B 到 14B 的规模好处是数据和隐私都留在内网。但它有两个明显问题一是对 6 份长文本同时分析时经常“顾头不顾腚”只盯着开头的商品标题和卖点文案二是无法稳定输出 JSON经常在生成到一半时把字段名改了解析成功率只有六成左右。另一套是 Qwen3.8-Max通过官方 API 接入。它在 6 份文档同时输入的情况下仍然能把相互矛盾的数据点抓出来且输出基本能按我自己定义的 Schema 走。我还做了一个非常细的对比让两个方案分别从一段包含“商品标题写 450ml、规格参数表写总容量 500ml、可榨汁容量 400ml、详情页文案写黄金容量 450ml”的内容中找问题。小模型的回复是“450ml 和 500ml 有差异请确认”看起来没有错但没有进一步指出“三者口径不同标题无法区分总容量和有效容量”。Qwen3.8-Max 则能把“商品标题出现了 450ml 但又没有限定是总容量还是有效容量”这种语义层面的话直接说出来。这个差异在产线里很重要因为它决定生成的结果是“一个对人工仍有依赖的辅助草稿”还是“一条可以直接处理的问题工单”。2.3 接入方式与配置细节接入方式不复杂我用的是官方 API 兼容模式。项目里我习惯写一个小的封装类统一管理模型名称、API Key 和超时参数。具体代码不贴完整版了核心逻辑是这样的from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-qwen-endpoint.example.com/v1, ) resp client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: system_prompt}, {role: user, content: full_input_text}, ], response_format{type: json_object}, temperature0.2, )这里最关键的不是 API 形式而是三个参数temperature我固定设成 0.2任务本质是审查和排查不要让它发挥创意response_format必须加避免模型把内容生成到一半就断了messages里的 system prompt 要写好后面专门用一整章讲。需要提醒的是不同版本的 SDK 或者不同的私有化部署端点传入方式可能略有差异。如果照着写发现参数不识别先看你实际拿到的是哪个版本的兼容协议不要硬套网上的示例。3. 体检工具的工作流从文件读取到问题清单输出3.1 六份资料在“体检助理”里的角色划分与归一化拿到资料包后我先把 6 份文件统一转成 Markdown 文本。原因是商品资料包里的原始格式五花八门基础信息表是 Excel 导出的 CSV卖点文案是 Word 里的段落活动说明可能是 PPT 改的 PDF。直接把.docx或者.pdf丢给模型纯文本模型会吃不下多模态模型也只能读图片版 PDF效率很低。转成 Markdown 之后表格会保留成 Markdown 表格格式标题和列表结构也不会丢模型理解起来比纯文本要好很多。转换完后我给每一份资料加了一个标签前缀。比如资料1-商品基础信息表、资料2-卖点文案这样模型在输出问题时能明确说是哪份资料出了问题避免人工复核时还要去猜。归一化这一步经常被初学者跳过但它对质量的影响很大。比如 CSV 里的换行和逗号转义如果不处理就会被模型理解成 Markdown 的表格语法Word 里的自动编号如果不清除就会插入一堆层级混乱的列表。我第一版工具跳过清洗直接喂原文结果模型把好几个表格完全读错后来加了pandas读 CSV、python-docx读 Word 转 Markdown 的流程问题才缓解。3.2 商品图不“翻译”成文字直接让模型看图商品主图在这个体检任务里地位特殊。图片上的信息往往比正式文档里的信息更夸张因为它承担营销点击压力。比如详情页参数表写的是“32000 转/分”主图角落却印了个“32000RPM 高速破壁”人工核对时很容易漏掉这种角落小字。我一开始尝试用 OCR 先提取图上的文字再把文字丢给文本模型。这么做有一个缺陷OCR 会丢掉文字在图片上的位置关系、字号层级和标签所属对象比如图上“超大容量 600ml”的箭头指向杯体但如果 OCR 提取成普通文本模型看不出这是对杯形容量的宣称可能直接忽略。后来我改成直接把商品图片通过多模态能力传给 Qwen3.8-Max让它把图上每一个标签和对应的商品部位描述出来并强调“描述你看到的每一个营销文案、价格、容量、功率、材质相关文字不要漏掉角标”。实测下来直接看图比 OCR 再接文本的准确率高很多。模型不仅能识别出“600ml 超大杯”这个标签还能告诉我这个标签位于主图右上角视觉优先级最高意味着用户在商品主图上第一眼就会看到这句话。这种界面层面的判断是文本模型很难替代的。3.3 一条完整链路块级注入、事实表比对、结构化回传把文本和图片都准备好之后真正的体检逻辑分为三步。第一步让模型先不看具体问题而是从 6 份原始资料中提取一份“商品事实表”。我给它指定的范围是品牌、容量、尺寸、净重、电机转速、电池容量、防水等级、材质、充电参数、价格、活动时间、售后政策。这一步的作用是让模型先把矛盾点“记住”。第二步把图片信息和商品事实表放在一起让模型逐项核对。这时我会提供一个“体检维度清单”让模型按清单逐条扫描。每一份文本资料在输入时保留标签图片识别结果单独作为一个文本块也保留标签模型在提到问题时需要注明依据来自哪个标签。第三步强制输出 JSON 数组每条问题包含level、category、source、quote、issue、suggestion六个字段。我把这个 Schema 直接写进 system prompt并且加了一句“如果某个维度的信息在所有资料中都一致不要输出问题”。你可能好奇为什么要先做“事实表”而不是直接让模型从原文里找问题我试过直接扫结果模型会陷入“局部正确但全局混乱”的状态因为每份资料本身都可能互相矛盾模型一会儿被这份文档带偏一会儿被另一份文档带偏。先生成事实表相当于先给模型建立一个唯一的基准坐标系之后所有比对都基于这个坐标系误报率明显下降。4. 体检测试结果复盘27 个问题从哪个文件、哪一段被揪出来的4.1 高风险问题7 个基本都藏在营销语言里我把所有低于最高严重级别的规则先过滤掉最后第一级风险的问题有 7 个。这里挑几个典型说说。“卖点文案”里有一句“医用级 304 不锈钢刀头”这个表述踩中了医疗术语红线。“医用级”会让用户误以为刀头具备医疗器械标准且如果拿不出对应的证明材料平台基本会直接判为违规。修改建议是换成“食品接触级 304 不锈钢”既保留材质可信度又不越线。“商品详情页文案”里出现了“去菌率 99.99%”这种强功效宣称。榨汁杯本质上是个食品处理工具不是消毒设备在没有第三方杀菌检测报告的情况下这属于典型的功效夸大。这个问题的隐蔽之处在于写文案的人可能只是想突出清洁效果但在审核语境里它会被直接归类为虚假功效描述。“营销活动说明”里有“全网最低价”这样的极限词这个不用解释基本属于一眼能看出的问题但人工审核时如果只看活动文案本身其实也会忽略因为文案里还有一堆其他促销语句把它包住了。7 个高风险问题全列出来大概是这样的营销活动说明“全网最低价”极限表达平台审核必抓。卖点文案“医用级 304 不锈钢刀头”医疗术语风险。详情页“去菌率 99.99%”无检测报告支撑的功效断言。FAQ“无论什么情况一律退款”绝对化售后承诺与平台规则冲突。商品基础信息表“是否儿童适用”属性未填但详情和卖点文案里有“宝宝辅食”表述存在类目资质不符风险。详情页“最轻薄的榨汁杯”相对最高级表述难以佐证。主图文案“8 重安全防护”规格参数表没有列出对应结构和认证。4.2 数据一致性问题8 个这就是人工最头疼的部分第二类问题是我最想让模型帮忙检查的部分因为它们需要跨文档比对。容量问题是其中之一。商品基础信息表的标题写着“轻享便携榨汁杯 450ml”规格参数表却写“总容量 500ml、可榨汁容量 400ml”详情页文案里又说“450ml 黄金容量”。这三个数字单独看都问题不大放在一起就说不清了450ml 到底是总容量还是有效容量如果发货到渠道渠道编辑是按标题的 450ml 做展示但消费者收到实物后看杯身贴纸写 500ml就容易产生“货不对板”投诉。电池续航问题也一样。卖点文案写“一次充电可榨 15 杯”规格参数表写的是“2000mAh约 12 杯”FAQ 里却写“充满电可榨 10 杯”。三个来源三个数这种属于典型的“内容分头写、没人拉通”。严格来说这个问题的整改不是只改一个文件而是要统一测试口径是空载转还是带料榨、一次打 45 秒还是 60 秒都要明确。这一组 8 个问题我用表格做了一份摘要便于你对照感受问题主题涉及资料矛盾点容量口径基础信息表 / 详情页 / 规格参数表450ml、500ml、400ml 并存未区分总容量与有效容量续航杯数卖点文案 / 规格参数表 / FAQ15 杯、12 杯、10 杯三个说法机身高度详情页 / 规格参数表245mm 与 228mm 不一致刀头类型卖点文案 / 详情页“四叶狼牙刀头”与“六叶精钢刀头”同时出现充电时长卖点文案 / 规格参数表“1 小时充满”与“2.5 小时充满”不一致防水等级详情页 / 规格参数表IPX7 与 IPX5 并存活动时间营销活动说明 / 基础信息表活动说明写 4 月 30 日截止价格表有效期是 5 月 1 日到 5 月 5 日清洗方式FAQ / 规格参数表FAQ 允许杯体进洗碗机参数表标“仅支持手洗”这类问题如果靠人去逐行核对非常费眼而且核对完也不能保证没有漏网之鱼。模型的优势是它能稳定记住每一份资料里的数值再按同一实体做匹配。4.3 完整性与规范性问题7 个问题不出在文字而出在缺失第三类问题不是“写错了”而是“根本没写”。完整性检查是人工最容易忽略的因为人眼习惯看“有”的东西不会刻意去找“没有”的东西。模型则不同只要我在 Prompt 里设定了检查项它就会逐项核对。被查出来的一共有 7 个完整性问题。其中一个是规格参数表里多个 SKU 的商品条形码/货号字段为空这个信息一旦缺失渠道的仓库系统可能直接无法完成入库建档。另一个是详情页写了“通过食品接触材料检测”但资料包里完全没有附检测报告编号和有效期。没有编号的认证宣称等于没有认证。还有一个典型的执行层问题营销活动说明写“前 100 名送杯刷一套”但整个资料包里没有任何地方定义“前 100 名”的计算维度是按付款时间还是下单时间以哪个平台的支付时间为准如果消费者去咨询客服客服根本没有统一解释口径。还有两条值得一提包装清单字段没有出现在规格参数表里导致客服 FAQ 在核对“产品是否包含充电线和说明书”时没有官方依据整机保修期在详情页写的是 1 年但 FAQ 没有补充保修凭证要求、寄修邮费由谁承担等明细。完整性问题往往不像高风险问题那样会立刻触发处罚但它会在上架后变成客服压力和差评来源。4.4 图文不一致问题5 个主图才是最容易引出客诉的地方第四类问题来自商品主图。我提取出图上所有带文字信息的标签与文本资料逐项比对一共发现 5 处冲突。主图大标题写的是“600ml 超大杯”但所有文本资料里最高口径只有“总容量 500ml”基础信息表标题甚至写的 450ml。这个差异对消费者来说极其直接用户看图觉得容量很大收到货再看详情页参数发现不对第一反应就是“商家虚假宣传”。主图左下角还有一个“到手价 69 元”的红色角标但营销活动说明里写的是“限时到手价 79 元”商品基础信息表里的促销价则是 89 元。同一个商品出现三个价格不管最终以哪个为准都会让活动执行和客服解释出现混乱。电机转速的冲突也很有意思。文字资料里全部写“30000 转/分”主图标签却写成“31000 转/分”。写主图的设计师可能只是想强调“转速过万”随手写了一个整数带上去。可参数这种硬性指标一旦在图片和规格表间有差异一旦被用户截图投诉商家会很被动。防水等级同样存在主图和规格表不一致的问题主图标注 IPX7规格参数表写 IPX5。操作方式上主图画的是“双击启动”详情页使用说明却写的是“单击启动”。这类问题说明主图素材在制作时没有跟最终版商品规格做核对属于跨部门协作很常见的疏漏。5. 让大模型“找到问题不遗漏、不幻觉”的三层控制5.1 第一层给输出套 Schema不允许自由发挥如果你只是让大模型“请找出这份资料包的问题”它会给你一段长篇分析里面真假混杂完全没法程序化处理。所以我在搭建时做的第一层控制就是给输出强制套一个 JSON Schema。Schema 长这样{ issues: [ { level: high|medium|low, category: compliance|consistency|completeness|image_text_conflict, source: 资料编号/图片编号, quote: 原始语句或图片标签原文, issue: 问题描述, suggestion: 修改建议 } ] }把这一整段结构写进 system prompt 后我再补了一句“只输出上述 JSON不要输出解释”。实测下来不写这一段时模型经常会在返回结果里夹带“同时我建议……”这类文字导致解析器报错加了之后输出基本稳定。需要说明的是quote字段必须要求模型引用原文而不是概括。一开始我把这个字段省略结果模型经常用“资料里有一处关于容量的说法有问题”这种模糊表达人工复核时还得去猜是哪一句。要求回填原文后核查效率和可信度都提高了。5.2 第二层必须带原文引用不能引用就丢进“存疑区”即使有 Schema模型依然可能“脑补”出一些不存在的问题。我见过最典型的案例是规格参数表里明明没写功率模型却因为详情页写了“额定电压 5V”就自动推断“功率应该是 10W 但表格漏填了”。这种推断看似合理但商品资料审核讲究的是“以资料为准”模型不能替商家创造事实。为了压制这种幻觉我在 Prompt 里加了一条硬规则任何一条问题都必须给出在输入资料中能找到的原文引用如果某条结论基于推测或常识而不来自资料不要输出除非它属于明显的资质合规缺失。合规缺失的条目不要求引用原文因为缺失本来就没有原文但必须说明“缺什么信息、可能引发什么后果”。用这种方式我成功把误报率从第一版的 30% 以上压到了 5% 以内。具体怎么压的后面一章会细说。5.3 第三层用“两遍扫描”平衡召回率与精确率6 份资料全部塞进一个 Prompt 里好处是简单粗暴坏处是模型可能被大量无关内容干扰导致某几处小问题被漏掉。为了兼顾召回率我在流程里拆成了两遍扫描。第一遍是“全量粗扫”把所有资料连同商品图识别结果一次性丢进去按照完整 Schema 跑一遍。这一遍主要解决大面上的问题和跨文档矛盾。第二遍是“针对性精扫”把第一遍输出的问题按维度拆出来再对涉及的具体资料段落单独发一次请求让模型集中精力再核对一遍。比如第一遍发现了容量问题第二遍就把基础信息表标题、详情页容量段落、规格参数表容量行抽出来单独配一个专门 Prompt让模型只检查容量相关的所有表述。这样做的成本增加了一倍 API 调用量但收益很大。第一次粗扫常常会漏掉一些藏在长文档后半部分的细节问题第二遍精扫把范围缩小之后漏检少了很多。如果你对准确率要求极高甚至可以做第三遍反查拿第二遍的结果作为已知问题列表问模型“除了这些问题还有没有其他问题”这种自问式反查能再召回一小批遗漏。6. 我踩过的三个坑误报升高、上下文稀释和图片文字误读6.1 第一版一次查出 63 个问题原因在哪里第一次跑通流程后我非常兴奋地点开结果发现模型一口气列出了 63 个问题。数量比预期的 27 个多出一倍多我当时第一反应是这个模型还挺细心。但当我一条条人工复核时发现至少有 20 条是根本不成立的误报。其中一类非常典型。资料 4 的规格参数表里写着“容量500ml”资料 1 的标题写着“450ml”这确实冲突。但模型给它标了“高风险”理由是“可能导致消费者误解”。实际上商品标题里的 450ml 是营销口播口径规格表里的 500ml 是总容量只要详情页里有“总容量 500ml可榨汁容量 450ml”的解释这个设置完全正常甚至还是行业常见写法。问题不是两个数字不同而是前后没有统一说明口径。这类误报让我意识到在 Prompt 里单纯写“找出不一致”远远不够还必须训模型区分“真矛盾”和“口径未说明”。后来我在体检维度清单里增加了一个维度叫“口径清晰度”当两个数值不同时优先检查上下文里有没有说清楚两者的关系和定义域。如果没说清等级给 medium而不是一上来就扣高风险的帽子。6.2 全部资料硬塞进一个上下文里后半段检查质量明显下降第二版我试图把资料包完整地塞进一次对话里让模型一次完成所有检查。这在资料总量不大时效果不错但一旦 6 份文档的总和超过某个量级比如有大量表格和重复卖点描述时模型对后半段文档的关注度就会明显降低。具体表现是详情页前面几段的“问题”和基础信息表前几行都被查得比较细营销活动说明和 FAQ 这种排在后面的文档经常一条问题都没被提出来。这就是之前提到的“上下文稀释”问题。大模型在超长输入下注意力会被前部内容过度占用这是所有 Transformer 结构模型都躲不开的天然特性。我的解决办法是把“全量粗扫”拆成按维度并行扫描。比如合规维度单独跑一次请求只把标题、卖点文案、详情页文案和营销活动说明作为输入一致性维度再单独跑一次重点把基础信息表、规格参数表、详情页参数段作为输入。这样每次请求的上下文长度都控制在合理区间且内容的主题集中