做电商的人十有八九都经历过这种慌张新品好不容易走到上架审批这一步平台一条消息弹回来——标题含违规词、详情页与规格参数对不上、主图不达标。返工重来还是小事被抽检处罚、被差评、被索赔才是真肉疼。为了不再靠肉眼和责任心硬扛我用 Qwen3.8-Max 搭了一个电商商品资料包体检助手把手上的 6 份文本资料和 1 张商品主图一次性喂进去它跑完直接给我一张 27 个问题的清单从极限词到价格倒挂从规格矛盾到证书型号不一致全是人工容易漏掉、但每条都可能真金白银的坑。下面我按设计思路、检查项定义、Prompt 实现、实测结果、踩坑调优的顺序把这个方案完整摊开讲。如果你在做电商运营、商品审核或者想用大模型做多文档交叉核验这里面的东西可以直接拿去用。1. 为什么给商品资料做体检一次漏检的代价有多大1.1 一个商品资料包里到底装了什么先对齐一个定义我说的商品资料包不是一个文件而是上架一个 SKU 前必须凑齐的一整套素材。在我这边的流程里一共有 6 份文本类资料加 1 张主图商品标题文案。几十个字但它同时是流量入口和平台抽检重点极限词、堆砌词、虚假宣传的雷基本都埋在标题里。详情页卖点文案。从几百到几千字不等描述材质、功能、使用场景、售后保障。这份文件最容易出问题因为运营和美工经常各写一版最后直接合并了事。规格参数表。供应商发来的表格通常是材质、尺寸、颜色、重量、产地这些硬参数还包括 SKU 选项比如颜色、尺码、套餐组合。价格与促销规则表。日常售价、划线价、活动价、满减、优惠券、会员折扣全在里面。资质与质检文件。质检报告、品牌授权书、3C 证书这一类很多还是 PDF 或扫描件。库存与物流配置。库存数量、发货时效、运费模板、偏远地区限制。外加 1 张商品主图。这次体检助手的全部输入就是这 61 份材料。1.2 人工检查的三个死穴我过去是纯人工核对这套资料的试了两个月就放弃了原因有三个。第一是疲劳漏检。6 份资料交叉比对眼睛来回扫看到第三遍就开始麻木。上次就因为在标题里漏看了一个最字新品刚上架三天就被平台下架还连累了整个店铺的权重。这种错不是态度问题是纯人工流程的结构性问题。第二是跨文档核对效率太低。标题里写加绒加厚详情页写单层摇粒绒这两个信息出现在两份不同文件里人工要自己记住标题说了什么、再去详情页里找对应描述来回翻文件一次上新光核对就要两三个小时。第三是图文对照几乎没人执行。规格表写云雾白主图拍的到底是偏白的还是偏灰的质检报告上的型号是 KX-208标题写的是 KX-280这种看图对字的活儿最容易被跳过去但恰恰是这类问题最容易引发消费者投诉和平台处罚。所以我才决定把这件事交给大模型它能读文档也能看图多模态只要把检查规则和输出格式定义清楚就能在一轮里同时完成单文档体检、跨文档交叉核对、图文一致性校验这三件事。2. 体检助手的设计蓝图让 Qwen3.8-Max 干三类活2.1 把检查拆成三种能力商品资料检查听起来是一件事做的时候其实是三种完全不同的能力。第一种是单文档规则体检。针对某一份资料按固定的规则去逐条排查。比如标题里有没有绝对化用语规格表里有没有单位写错、参数值明显离谱证书有没有过期。这类检查的特点是规则明确、判定独立不需要看其他文件。第二种是跨文档一致性核对。把两份甚至更多资料里描述同一个信息维度的内容拎出来对比。标题说纯棉规格表写聚酯纤维划线价 299、活动价 199结果满减算完之后反而低于成本价。这类检查的难点在于要先知道哪些字段应该互相对应然后再判断语义上是否一致。第三种是图像与文本交叉验证。主图分辨率够不够、文字有没有被裁切、商品颜色和文案描述是否一致、图中主体和标题卖点是否相符。这类检查对传统脚本最不友好因为图片里的信息要先看出来才能判断而大模型的多模态能力正好补上了这一环。2.2 为什么选大模型而不是死写规则我知道很多人第一反应是这些检查用正则表达式加 Python 脚本不就行了价格倒挂算一下、分辨率用 PIL 读一下、极限词做个词表匹配都能搞定。确实能搞定一部分。但问题是我面对的 6 份资料来自不同的人、不同的系统同样的信息在不同文件里的表达完全不一样规格表里写成分棉 100%详情页写纯棉材质标题写全棉透气。脚本想识别这是同一个语义得先做一堆同义词映射和别名维护维护成本比写检查逻辑还高。大模型的优势在于语义理解。它不需要我维护同义词表就能判断纯棉和100% 棉是同一个信息它能从两段完全不同的句式里抽出同一维度的信息做比对。而 Qwen3.8-Max 这类带视觉能力的大模型还能把图片里的文字、颜色、商品主体都读出来等于三种能力在一个模型里打通不用再接一个 OCR 再加一个图像分类模型。当然我的方案也不是全交给大模型。确定性的检查我仍然用脚本处理比如分辨率、价格计算、日期过期判断。大模型负责语义判断的部分两边各干各擅长的最后合并成一份报告。这个脚本搭骨架、大模型做判断的思路是整套方案稳定的关键。2.3 一整套管线的运行顺序整个体检助手按下面这条管线跑加载 6 份资料和主图把文本资料按类型分类图片单独走视觉通道。第一轮并行做单文档规则体检每份文档一个独立请求。第二轮做跨文档一致性核对把需要互相对应的字段组合两两配对分批请求。第三轮做图像与文本交叉验证喂主图加商品关键信息。三轮结果合并按检查项 引文去重然后按严重程度排序输出报告。这样设计有一个好处每一轮请求都是独立的任何一轮挂了或者结果不满意重新跑那一轮就行不需要从头再来。后面实测的时候这个特性帮我省了很多事。3. 27 类问题清单从业务事故反推出来的检查项3.1 问题库的三个来源检查项不是拍脑袋定的我整理这几类问题主要来自三个渠道。第一是平台规则和广告相关法规。绝对化用语、最字类、虚假宣传、医疗用语跨界使用这些都是平台明文列出的违规类型也是处罚最重的。我从平台规则中心和历史处罚通知里把所有出现过的高频违规点摘了出来。第二是真实的业务事故复盘。我翻了过去一年店铺里所有的差评、退换货、投诉记录凡是和资料描述不符相关的都列出来拆解成因。比如买家收到的颜色和图片不一样尺码表写错了导致退货产地标注冲突被职业打假人盯上这些事故背后全都能对应到一个具体的检查项。第三是行业常识和数据合理性。这个比较玄但很有用尺码是均码但 SKU 里有 S/M/L正常的商品不会这样一件 299 元的衣服活动价打完折低于成本价一定有价格逻辑错误一件 T 恤重量写 150kg明显是单位写错了。这些不需要查任何规则光靠常识就能识别但人工看的时候经常被忽略。3.2 四类 27 项检查清单全表我把所有检查项归成四大类正好 27 项类别检查项数量覆盖内容典型触发场景合规类8极限词、绝对化用语、虚假承诺、医疗用语、证书有效性、授权范围、警示语缺失、类目违禁词标题全网首发、详情页最佳材质、证书过期一致性类9标题-详情关键信息、规格-详情材质、价格逻辑、SKU 与规格、库存与发货、图文颜色、图文规格、型号、单位加绒加厚对单层摇粒绒、价格低于成本完整性类5必填字段缺失、售后说明缺失、保养说明缺失、SKU 图片缺失、包装清单缺失规格表没有产地、详情页没有售后政策图像类5分辨率不足、文字裁切、非白底、贴纸遮挡、颜色偏差主图 800×800、促销贴纸挡住商品我在项目里把它们维护成一个 JSON 配置而不是散落在 Prompt 里。每一类问题对应一份 rules 配置包括规则编号、规则名称、适用资料类型、判定标准、严重级别初始值。这样以后想加检查项或者改判定标准改配置就行不用动代码。3.3 每条检查项都要配体检标准只有问题名是不够的。我对大模型的要求是只输出问题不输出诗意所以每条检查项都必须写清楚判定标准否则模型容易自由发挥。比如极限词这条我的配置里写的是检出最、第一、顶级、极致、全网、国家级、最佳、100%等前缀或同义表达视为命中但如果上下文是同类产品中排名前多少且有数据支撑不算命中。再比如价格倒挂这条标准是活动价减去所有可用优惠后的到手价低于成本价 × 1.05或者高于划线价的 7 折都算异常。把判定标准写成这样大模型才有据可依。这一步很枯燥但直接决定了体检报告的质量。一开始我这步偷懒了规则写得很粗结果模型把颜色为灰白这种描述也当成颜色不一致报出来误报率一度超过三成。把每一条标准细化之后报告的可用性才上来。4. 核心实现三层 Prompt 设计与多文档交叉核对4.1 API 接入与最小运行环境我用的是 Qwen3.8-Max 的 OpenAI 兼容接口Python 侧只需要一个 openai 库就能调起来pip install openaifrom openai import OpenAI client OpenAI( api_key你的API-KEY, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, timeout180 ) MODEL qwen3.8-max需要说明的是我之前也试过用本地小模型跑这套流程效果不太行主要问题出在长文档指令跟随和图片细节理解上。Qwen3.8-Max 这类云端大模型在这两方面明显更稳尤其是图文交叉校验那一步小模型经常看图说话说不到点子上。所以最终方案就是云端 API 直连省掉部署成本。4.2 第一层单文档规则体检单文档体检是最基础的一层每一份资料发一个请求。Prompt 的核心是给角色、给规则、给内容、给格式约束。RULE_BASED_PROMPT 你是一名资深电商合规审核员负责对商品资料做单文档规则体检。 本次需要执行的检查项 {rules} 待检查资料 【资料类型】{doc_type} 【资料内容】 {content} 请逐条对照检查项排查问题。只输出 JSON 数组不要输出任何多余文字。 每个问题对象包含 - check_item: 命中的检查项编号 - severity: high / medium / low - quote: 原文中最能定位问题的片段不超过 50 字 - issue: 具体问题说明 - suggestion: 修改建议 如果没有问题输出 []。 有个细节rules 不是把全部 27 项都塞进去而是根据 doc_type 只传入适用的那几项。比如给标题文件体检只传极限词、违禁词、品牌信息缺失这类标题维度规则给规格参数表体检传单位错误、参数值离谱、字段缺失这些规则。这样既省 token又避免模型在无关规则上瞎报。4.3 第二层跨文档一致性核对这一层是整套方案的核心也是最容易翻车的地方。我的做法不是把 6 份文档一次性全塞给模型让它自由比对那样信息太多模型会顾此失彼。正确做法是先维护一张字段对应关系表明确哪些字段需要在哪些文档之间互相比对然后按字段 × 文档对拆成一组组小任务。CROSS_CHECK_PROMPT 你是电商商品信息一致性审核员。针对指定信息维度核对下面两份资料。 【资料A{doc_a_name}】 {content_a} 【资料B{doc_b_name}】 {content_b} 需要核对的维度{fields} 判定要求 1. 数值类信息先统一单位再比较数值是否超出合理偏差。 2. 描述类信息材质、颜色、卖点语义一致即视为一致不要求逐字相同。 3. 只有一方有值另一方缺失时归入完整性类别不要报为一致性冲突。 4. 无法确定是否一致时返回 confidence 字段0~1并把 confidence 低于 0.6 的问题标为 pending。 只输出 JSON 数组每个对象包含 - check_item, severity, quote_a, quote_b, issue, suggestion, confidence 如果没有问题输出 []。 最关键的就是第 4 条confidence 字段。这是我在第二轮调优时加的后面会专门讲。没有它之前模型经常在一段模棱两可的描述上强行下结论加了 confidence 之后拿不准的问题会流到待人工复核列表而不是直接污染最终报告。字段对应关系表长这样FIELD_MAP { 材质: [(规格参数表, 详情页卖点文案), (标题文案, 详情页卖点文案)], 颜色: [(规格参数表, 详情页卖点文案), (规格参数表, 主图)], 价格: [(价格与促销规则表, 详情页卖点文案)], 型号: [(标题文案, 资质与质检文件), (规格参数表, 资质与质检文件)], 产地: [(规格参数表, 详情页卖点文案)], 尺码: [(规格参数表, 库存与物流配置)], 库存与发货: [(库存与物流配置, 详情页卖点文案)], }4.4 第三层图像与文本交叉校验图像校验走的是多模态通道把主图和从文本资料里提取出来的关键信息一起发给模型。这一步要注意的是不要让模型做主观审美判断比如这张图好不好看只让它做能客观核对的事。IMAGE_CHECK_PROMPT 这是一张商品主图。结合下面的商品文本信息从可客观判断的维度进行校验。 商品关键信息 - 商品型号: {model_no} - 颜色: {color} - 核心卖点: {selling_point} 校验维度 1. 图片分辨率是否明显不足从清晰度、锯齿、马赛克程度判断。 2. 图片中是否有文字被截断、遮挡或压到画面边缘。 3. 商品主体是否被促销贴纸、边框、角标遮挡超过一定比例。 4. 图中商品主色调与文本颜色描述是否冲突色系层面不追求完全一致。 5. 图中商品是否体现标题中的核心卖点如加绒则图中应是毛绒内里或外层纹理。 只输出 JSON 数组每个对象包含 - check_item, severity, issue, suggestion 如果图片无法判断某项该项不要输出。 实测下来第 5 项卖点是否在图中有体现是最容易被模型过度解读的。比如标题写加绒主图如果只拍了外观没拍内里模型有时候会判未体现有时候会判无法判断。我的处理方式是在 Prompt 里明确图片中未体现不等于商品没有该卖点只有图中出现了与卖点明显矛盾的元素比如标题写加绒、图中是单层薄纱才算问题。这样调整之后误报大幅下降。4.5 结果合并、去重与报告生成三层检查跑完后把所有结果合并。去重是个关键动作因为同一个问题可能被不同层同时报出来。比如质检报告型号和标题型号不一致在单文档体检里不会被发现但跨文档一致性和图文校验可能同时报一次。我的去重逻辑是按检查项编号 引文前 30 字做 key重复的只保留严重级别更高、置信度更高的一条。然后按严重程度排序高危排最前输出 Markdown 报告def dedup_problems(problems): seen set() result [] for p in problems: key (p[check_item], p.get(quote, )[:30]) if key not in seen: seen.add(key) result.append(p) return result def sort_problems(problems): level {high: 0, medium: 1, low: 2} return sorted(problems, keylambda p: level.get(p[severity], 3))报告开头放一段总结共发现问题数、高危数、中危数、低危数、待人工复核数然后是分模块的问题明细。这份报告直接发给运营和美工他们照着一条条改就行。5. 实测复盘6 份资料 1 张主图查出的 27 个问题5.1 一次体检的运行全流程第一次完整跑通用的是一批真实待上新的女装商品资料标题文案、详情页、规格参数表、价格与促销规则表、资质文件、库存物流配置外加一张 800×800 的主图。整个流程跑了 9 分钟左右其中单文档体检 6 个请求并行跨文档核对拆了 7 组任务图文校验 1 个请求一共消耗不到 90 万 token按 Qwen3.8-Max 的接口定价折算一次全量体检的成本在几块钱级别。相比人工核对两三个小时的人力成本这个开销可以忽略不计。模型输出的原始 JSON 里一共报了 31 条问题去重后剩 29 条再过滤掉 confidence 低于阈值的 2 条待复核最终落在正式报告里的是 27 条。5.2 27 个问题的分布明细这 27 个问题按类别拆开是这样的问题类别数量高危中危低危合规类7421一致性类8332完整性类7016图像类5131合计278910合规类的 7 个问题里4 个高危全部和极限词、绝对化用语相关标题里的全网首发、详情页里的最佳材质100% 不刺激皮肤、授权书品牌与售卖品牌不一致。有一个很隐蔽的是医疗用语跨界详情页里写了抗菌消炎这个在服饰、美妆类目都是高风险词。一致性类的 8 个问题是最有价值的。其中标题写加绒加厚、详情页写单层摇粒绒直接是卖点矛盾属于会引发差评和退货的类型。划线价 299 元、活动价 199 元平台又有满 200 减 30 的券叠加后到手 169 元低于这条商品的成本线 180 元这种价格倒挂人工核对的时候最容易忽略因为三个数字来自三张不同的表。完整性类的 7 个问题全是低危和中危典型的是规格参数表没有产地字段、详情页没有售后政策、SKU 里黑色选项没配图、标题漏了品牌词。这类问题单个看不致命但叠加起来会让商品信息完整度评分很难看直接掉搜索权重。图像类的 5 个问题里最扎眼的是主图分辨率只有 800×800低于平台要求的 1000×1000另外主图边缘有一块促销贴纸正好挡住了商品下摆文字也有轻微裁切图片主体是米白色但文案写云雾白色系上存在偏差。这些问题靠脚本只能查出分辨率后面那几条必须靠多模态模型。5.3 三个最值钱的问题错过任何一个都是钱27 个问题里我挑三个最能说明价值的展开讲因为它们在人工核对时大概率会被漏掉。第一个是价格倒挂。人工核对三个价格通常只会看活动价是否低于日常价很少有人会把满减、优惠券、会员折扣全叠一遍再和成本线比。结果就是这个 SKU 一旦上架每卖一件就亏 11 元卖得越多亏得越多。模型在做跨文档价格核对时把几份表里的价格信息全抽出来按规则算了一遍直接报了高危并给出了建议售价。第二个是证书型号错位。质检报告上的型号是 KX-208但标题和规格表里全是 KX-280。这种字母数字顺序的错位人眼很难发现而且分布在不同文件里。但正是这种问题在平台抽检或消费者索要证书时会被无限放大。模型在核对型号字段时同时比对了标题、规格表、资质文件三处精准抓了出来。第三个是加绒加厚 vs 单层摇粒绒。这是一致性类问题里最典型的一个标题是运营写的突出保暖卖点详情页是美工从供应商素材里扒的写了真实材质单层摇粒绒。两个说法单看都没毛病放一起就是虚假宣传风险。这类语义层面的矛盾是正则脚本完全无能为力的。6. 从能跑到好用我踩过的坑和调优手段6.1 大模型幻觉导致的误报从三成降到接近零第一版跑完我自己人工复核了一遍报告发现 29 条里有 8 条是误报其中大部分集中在一致性核对环节。最典型的一个规格表写成分聚酯纤维 100%详情页写面料涤纶模型报了材质冲突。但实际上涤纶就是聚酯纤维的俗称语义完全一致。这让我意识到模型在自己不确定的时候不会说我不确定它会硬着头皮给结论。排查过程是这样的我先看误报问题的原文引用发现所有误报的 quote 都有一个共同特点——两边的用词在字面上完全不同。于是我回到跨文档核对的 Prompt加了三条约束第一语义一致算一致不能只看字面第二所有问题必须带 confidence 字段第三confidence 低于 0.6 的归入 pending不进正式报告。同时我用一个简单的语义相似度测试集去调 Prompt 措辞反复改了三四版最终把误报从 8 条压到了 2 条而且这 2 条都被 confidence 阈值挡在了待复核里。这个教训是大模型做交叉核对的产出必须自带置信度否则报告里掺着幻觉问题比没有报告还危险。6.2 长文档超出上下文窗口先抽事实、再做比对6 份资料里详情页文案最长一份就有四千多字再加上规格表和价格表直接全塞进上下文很快就顶到窗口上限。第一版我把所有资料一股脑塞进去结果模型开始丢信息后半段的内容明显没有被认真比对。我的解决方案是把核对拆成抽取和比对两步先用一个 Prompt 让模型把每份文档里的关键信息抽取成结构化的事实条目字段 值比如材质聚酯纤维、颜色云雾白、型号KX-280、到手价169 元然后再把多份文档的事实条目放在一起做比对。这样既压缩了文本量又让比对的对象从四千字散文变成几十条结构化断言准确率反而更高了。FACT_EXTRACT_PROMPT 把下面的商品资料抽取成结构化事实条目只保留与上架审核相关的信息。 每条事实输出为 JSON 对象{field: 字段名, value: 字段值, source: 原文引用} 【资料类型】{doc_type} 【资料内容】 {content} 这一步还有一个额外收获事实条目本身可以直接用于生成商品结构化信息喂给平台的属性填写算是检查之外的副产品。6.3 图片核验的边界要画清楚图像类检查我踩的坑最微妙。第一版我让模型检查主图质量结果模型开始自由发挥报了一堆构图不够精致背景杂乱模特姿势不自然之类的主观审美问题运营看到直接懵了。后来我把图片核验的边界收窄到能客观判断的范围内分辨率、文字裁切、遮挡比例、颜色偏差、卖点元素是否存在矛盾。审美类问题一律不纳入自动检查因为那是设计评审的事不是合规体检的事。边界画清楚之后图像类问题的可落地性高了很多。另外提醒一点图片相关的 Prompt 里最好显式告诉模型无法判断的项不要输出。多模态模型在信息不足时会脑补比如图片里根本看不到商品内里它也会硬说内里材质与描述不符。加这一句之后这种脑补问题基本消失。6.4 成本、限流与缓存最后说说不性感但很现实的问题成本和限流。单文档体检那 6 个请求可以并行发但我第一次并行把 6 个请求一次性打过去直接被限流报了一串 429。后来我改成33分批并行并发控制在 3重试两次就再没遇到限流。跨文档核对那 7 组任务同理分组跑每批最多 4 组。成本上有个省钱的技巧文档抽取的事实条目结果会被缓存下来。同一套资料如果只改了一张主图重新体检时只需要重跑图文校验那一轮其余结果直接读缓存。后面我把这个体检助手挂成定时任务每天早上自动跑一遍当天要上新的商品新增资料才触发新请求月成本压得很低。调到最后这套体检助手的定位已经很明确了它不是替代人工审核而是把人工审核从从头到尾扫一遍变成只需要看高置信度的问题清单。运营和美工收到报告后按高危、中危、低危的顺序逐条改半小时能处理完一次上新而这半小时在以前连核对材料都不够用。我个人实际用下来最深的一个体会是大模型做这种资料体检最有价值的点不在于它一次查出多少问题而在于它把不可见的风险变成了可见的清单。合规风险、价格风险、描述冲突风险过去全凭经验和运气现在至少有一个系统性的兜底。后面我还在琢磨两个扩展一是把平台规则更新自动同步进检查项配置二是把这套核对思路用到客服话术、直播口播稿的合规检查上逻辑是完全一样的。如果你也在做类似的事建议先把检查项标准和置信度机制设计好这两样决定了你最终拿到的是有用的体检报告还是一堆模型幻觉。