先说结论我用 Qwen3.8-Max 搭了个电商商品资料包体检助手把 6 份资料和 1 张商品主图一次性跑完查出了 27 个问题。这个结果让我自己都愣了一下。其实最开始我根本没打算写代码。那会儿帮朋友打理一个电商店铺商品资料包在人手里转了三轮运营整理、设计出图、客服上架结果商品刚上线一天就被平台下架。原因是标题里一个最字——广告法极限词直接违规。客服处理退款和解释忙了整整两天运营在群里甩了一句这锅我不背。谁都没错但问题就实实在在发生了。后来我把那批商品资料包翻出来仔细看了一遍发现标题极限词只是冰山一角属性表里写着材质棉详情文案里写着聚酯纤维主图分明是深灰色标题却写象牙白。这些矛盾靠人工一张一张对照真的很难发现尤其是当你同时面对 6 份资料、几十个字段的时候。所以我花了几天时间搭了这个体检助手把标题表、属性表、详情文案、卖点稿、资质说明、SKU 价格库存表和主图全部解析处理后交给 Qwen3.8-Max 做语义检查再配合一套硬规则引擎做确定性检查。第一次完整运行就查出了 27 个问题拆开看是硬规则命中 12 个、模型语义检测命中 15 个。这篇文章就是把整个搭建过程、检测逻辑、实测结果和踩坑记录完整写出来给同样被商品资料折磨过的运营、采购、客服以及对大模型落地应用感兴趣的朋友做个参考。1. 先搞清楚体检对象一份电商商品资料包到底装了什么1.1 六份资料一张图覆盖了一条完整的信息链在普通人眼里商品资料就是几张图加几句描述。但在实际上架流程里它是一个由多份文件组成的资料包每一份文件管一段信息任何一份出问题都会传导到前台展示或者订单履约。我这次用的是家居类目一个吸尘器商品的标准资料包一共 6 份文件加 1 张主图文件格式主要内容商品标题表xlsx标题、副标题、关键词、平台类目属性参数表xlsx品牌、材质、尺寸、重量、颜色、功率、保修期详情页文案docx页面描述、卖点段落、参数表引导文案卖点提炼稿txt运营整理的 10 条核心卖点用于内容分发资质文件说明pdf3C 认证、质检报告、品牌授权说明SKU 价格库存表xlsx规格、价格、库存、上下架状态商品主图jpg白底主图这 7 个组成部分分别对应了平台审核、前台展示、订单履约三个环节。标题表负责能不能被搜到属性表和 SKU 表负责用户看到的规格和价格对不对详情和卖点负责能不能转化资质文件负责能不能合法卖主图负责第一印象。任何一个环节出了问题轻则流量下滑重则被平台下架。1.2 人工审核为什么守不住这套流程说句实在话大部分店铺对资料包的审核不是没有而是看不过来。我总结下来主要是三个原因。第一跨文档对照非常反人类。属性表里材质写棉详情文案里写聚酯纤维这两行字可能在两个文件里相隔几千行人工很难一眼建立关联。第二极限词、违禁词往往藏在长段落里扫读非常容易漏尤其是那种写了三四行、又长又绕的卖点描述。第三图片和文字的匹配需要视觉判断一张主图和一个标题放在一起颜色对不对、数量对不对、配件齐不齐全靠人眼疲劳状态下基本靠运气。这些痛点决定了资料包体检这件事天然适合规则引擎 大模型的组合来干。规则引擎负责确定性检查大模型负责模糊、跨文档、跨模态的语义判断。两者各干各擅长的部分才能把问题查全。2. 模型选型为什么是 Qwen3.8-Max 而不是别的方案2.1 三个硬指标卡掉了大部分候选其实最早我考虑过两条路线一条是自己本地部署一个小参数模型另一条是直接调 API。本地部署当时就被否了因为资料包里既有 Excel 又有 PDF 还有图片如果把它们全部转成纯文本再喂给文本模型中间的格式损耗和信息损耗太大。我需要的是一个能同时处理文字和图片的模型而且对中文电商语境要有足够的理解能力。最终选 Qwen3.8-Max是因为它在我这里有三个硬指标都达标了。第一个硬指标是多模态。Qwen3.8-Max 可以直接吃图片 文字的组合输入主图检测不用再单独接一个图像分类模型一张图连同标题、属性一起发给它它就能判断图片里的颜色和标题描述是否一致。这省掉了两个模型之间来回对齐的麻烦整个流程的代码量小一截。第二个硬指标是结构化输出。体检助手最终要输出一份可以按类别筛选、按严重程度排序的问题清单而不是一段散文。所以我要求模型直接返回 JSON。Qwen3.8-Max 对 JSON 输出的遵循度在我实测过的几个中文模型里算稳的这个直接决定了后续写报告、做统计的体验。第三个硬指标是电商语境的中文理解。像全国联保原厂配件支持七天无理由这类表述单看都没问题但如果全国联保和详情页里的仅限线下门店同时出现就构成矛盾。小参数模型往往看不出这种语义冲突而 Qwen3.8-Max 对这类中文商业语义的把握明显好一截。说白了它能读懂话里有话。2.2 接入方式与成本控制接入成本比我想象的低。Qwen 系模型在阿里云百炼平台上有 OpenAI 兼容接口把 base_url 换一下就能直接用后端我用 Python 调几乎没有改变习惯的调用方式。如果你之前写过 OpenAI 接口的代码迁移到 Qwen3.8-Max 基本就是改两行配置的事。费用上一次完整的数据包体检输入大概是几万字。6 份文件读出来约 2.4 万 token加上图片的 token单次调用成本并不高。真正要控制成本的是反复试错阶段——刚开始写 Prompt 的时候我一天要跑几十次每次都是同样的文本来回传。后来我做了两个处理一是把硬规则能查的问题全部前置到规则引擎只把有疑点的内容交给模型二是把 Prompt 调试稳定以后再上批量避免在测试阶段浪费 token。这两条后面会细说。3. 体检助手整体设计规则引擎打底模型做语义判断3.1 先做一层标准化解析在把资料交给模型之前首先要让 6 份不同格式的文件能被程序读取。我用的库很常规xlsx 用 openpyxldocx 用 python-docxtxt 直接读pdf 用 pdfplumber 抽文本图片用 Pillow 读取并做基础检查。import openpyxl, docx, pdfplumber def load_package(paths): package {} for key, info in paths.items(): ext info[path].rsplit(., 1)[-1].lower() if ext xlsx: wb openpyxl.load_workbook(info[path], data_onlyTrue) package[key] wb_to_text(wb) elif ext docx: doc docx.Document(info[path]) package[key] \n.join(p.text for p in doc.paragraphs) elif ext txt: package[key] open(info[path], encodingutf-8).read() elif ext pdf: with pdfplumber.open(info[path]) as pdf: package[key] \n.join(p.extract_text() or for p in pdf.pages) return package这里有个细节容易被忽略读取时一定要保留字段名而不是只存值。比如属性表里材质棉这一行如果只把棉存下来后面模型就不知道它在描述什么。我让转出来的文本始终是字段值的格式这样喂给模型时它才能跨表格做比对不然模型连这是材质还是颜色都分不清。3.2 硬规则引擎先扫一遍模型不是万能的确定性问题的准确率我们没必要用 token 去换。我把所有非黑即白的问题都放进了规则引擎主要有六类标题长度。平台规定商品标题不能超过 60 个字符标题表里超过的一律报错。极限词/违禁词。维护一张词表覆盖最、第一、顶级、百分百、国家级、权威等常见广告法红线词在标题和详情文案里全量匹配。属性格式。比如重量字段必须是数字单位尺寸字段必须统一用厘米混入cm/inch的报异常。价格一致性。SKU 表里的最低价和文案里出现的起售价做数值比对。库存状态。SKU 里库存为 0 却标记上架的报异常。图片基础指标。主图宽度低于 800px、带水印、不是白底直接提示重新出图。这套规则跑完已经能稳定抓到一批低级但致命的问题。在实测中它命中了 12 个。这些规则最大的价值不是聪明而是稳定——同样的输入永远输出同样的结果这是模型做不到的。3.3 模型要回答的是规则引擎答不了的问题规则引擎只能处理看得到矛盾的问题处理不了需要理解的问题。Qwen3.8-Max 在这套系统里承担四个任务。第一跨文档一致性检查。把标题、属性、详情、卖点四份文本放在同一个上下文里让模型找出互相矛盾的地方。第二信息完整性检查。对照平台要求的必填信息清单看有没有该有的没有。第三图片与文案匹配检查。把主图的视觉信息与标题、详情传达的信息做一致性判断。第四品牌与合规表述审查。比如品牌名在标题里是大写、详情里却是小写这种不算错误但属于不专业模型能识别出来。这四个任务的共同点在于没有标准答案只有合理与否的判断这正好是模型擅长、规则引擎完全做不了的部分。图片这块我单独说一下。主图先用 Pillow 做了分辨率、水印、背景色基础检查再把图片编码成 base64和标题一起发给模型做视觉语义比对import base64 with open(main.jpg, rb) as f: img_b64 base64.b64encode(f.read()).decode() resp client.chat.completions.create( modelqwen3.8-max, messages[{ role: user, content: [ {type: text, text: 请分析这张商品主图提取主体颜色、产品数量、背景、配件情况并判断与标题文字信息是否一致只输出JSON。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_b64}}} ] }], response_format{type: json_object} )这样主图就从一张普通图片变成了可以和文字交叉验证的结构化信息。3.4 Prompt 设计把审核条款和输出格式写清楚模型判断的质量90% 取决于 Prompt 写得好不好。我用的不是一句话让模型看看有没有问题而是给了一套完整的审核标准 输出格式。sys_prompt 你是一名资深电商合规审核专家请对提供的商品资料包进行体检。 审核标准 1. 一致性标题、属性、详情、卖点之间的事实不得互相矛盾 2. 完整性必填信息品牌、材质、尺寸、重量、颜色、保修、售后说明不得缺失 3. 合规性不得出现广告法极限词、违规表示、虚假承诺 4. 匹配性图片内容与文字描述必须一致 5. 专业性品牌名、量词、单位、规格表述应当统一规范 只输出 JSON格式如下 {issues: [{type: 一致性|完整性|合规性|匹配性|专业性, severity: 高|中|低, source: 涉及文件/字段, desc: 问题描述, suggestion: 修改建议}]} 如果无问题输出 {issues: []}。 resp client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: sys_prompt}, {role: user, content: build_package_context(package_data)} ], response_format{type: json_object}, temperature0.1 ) issues json.loads(resp.choices[0].message.content)[issues]注意几个关键点temperature 要压到 0.1 左右让模型尽量少发挥所有资料以来源标签 内容的方式拼接让模型明确知道每段文字来自哪一份文件图片先做基础规则检查再传给模型分析避免模型把注意力浪费在分辨率不够这种规则就能解决的指标上。4. 一次完整实测6 份资料加 1 张主图27 个问题是怎么汇总出来的4.1 测试输入与运行过程我用一个真实家居类目吸尘器商品资料包跑的第一轮完整测试输入就是第 1 节表格里的 6 份文件加 1 张主图。运行链路分成三步。第一步规则引擎先跑输出确定性命中清单。第二步把解析后的文本组装成模型上下文调用 Qwen3.8-Max 做语义体检拿到模型输出。第三步把两个结果合并去重按严重程度分档生成一份 Markdown 报告。整个过程跑下来耗时约 40 秒其中模型推理占了大部分规则引擎是秒级的。虽然第一次跑完看到 27 个问题有点头大但冷静下来发现这 27 个问题里有 20 个是 5 分钟内能改完的低成本问题真正需要重新设计的是少数。4.2 27 个问题构成硬规则 12 个模型 15 个这次运行最终查出 27 个问题数量上比我预想的多不少。拆开看检测通道命中数占比典型问题硬规则引擎1244%标题超长 2 个极限词 3 个属性格式错误 2 个价格不一致 2 个SKU 库存异常 1 个主图尺寸不达标 1 个售后电话格式错误 1 个Qwen3.8-Max 语义检测1556%材质矛盾 2 个颜色图文不一致 1 个卖点与详情不一致 3 个必填信息缺失 4 个保修政策前后冲突 2 个品牌表述不规范 2 个赠品说明缺失 1 个我挑几个有代表性的说说。价格不一致是规则引擎抓的但根源其实在运营详情文案里写到手价 299 元起SKU 表里最低配的价格是 309 元中间差的 10 元是店铺券但文案没有标注券后两个字。平台展示价和页面到手价不一致被消费者举报属于最高危的问题类型。材质矛盾是模型抓的。属性表里写主材-铝合金详情页参数区却写机身 ABS 塑料。这种问题人工审核时很容易漏因为属性表和详情参数区是两张完全不同的表很少有人逐字段对照。模型在同一上下文里看到两个材质字段一眼就发现了冲突。最让我意外的是颜色图文不一致主图里吸尘器明显是深空灰标题里却写象牙白。后来查了一下原来标题是从上一个旧款复制过来的改图的时候忘了改字。这种情况如果不是模型做视觉和文本的交叉比对光靠人眼在 1 张图、6 份文件里找真的很难发现。4.3 报告怎么呈现很重要问题查出来只是第一步让人看得懂、能分派任务才是目的。我的报告按严重程度分级高优先级是会导致下架、投诉、退货的问题中优先级是影响转化率的问题低优先级是专业度提升项。每一行都带来源文件 字段 修改建议运营拿到报告不用再去翻原始文件直接照着改就行。报告最后还会给一个体检评分根据高、中、低问题数按 100 分制给出综合分。这个分数字一出来团队内部就有了一个可以横向对比的量化指标哪个商品资料包质量差、差在哪里一目了然。我在实测中发现这种评分机制比单纯列问题更能推动团队改进因为人都有对比心理。5. 踩坑记录幻觉、长文本、成本一个都没少5.1 模型幻觉和过度体检第一次跑完模型输出我差点以为这个助手立功太多因为模型报了一个品牌授权书缺少被授权方名称的问题。结果我去翻原件发现授权书里明明写得很清楚。这就是典型的模型幻觉——它在资料里没看到就默认缺失。解决办法是给模型加一条护栏指令只有在资料中存在明确信息可以佐证的情况下才能判定为缺失或矛盾如果资料里只是没提到要标记为建议补充而不是缺失。同时我在输出层加了一道过滤凡是 type 为完整性且 severity 为低的问题默认不进高优先级列表而是进入人工复核队列。这样既保留模型的发现能力又避免误报淹没真实问题。5.2 6 份文件全塞进上下文会超出模型处理范围最开始我图省事把 6 份文件解析出来的所有文本拼成一个大字符串直接传给模型。问题很快来了文本总长超过了模型单次处理的长文本上限后面的资质文件、SKU 表内容根本没被模型看到。而恰恰 SKU 表是价格检查的关键材料漏掉它等于最重要的矛盾点没查。后来我改成分块检测 关键区块整体送检的双层方案。所谓分块检测就是把详情文案按段落切开逐段送模型检查合规性和完整性问题所谓关键区块整体送检就是把标题、属性表、SKU 表、主图这张核心四件套放在同一个上下文中做交叉一致性检查。这样既控制了 token 长度又保住了跨文档比对的全局视野。这个结构调整之后模型的漏报率明显下降。5.3 成本和响应速度的实测数据我在测试阶段统计过一次完整跑一份资料包规则引擎前置以后模型实际摄入的输入 token 大概是 1.6 万到 2 万因为有一部分文本已经被规则引擎处理掉了输出 token 正常在 800 到 1500 之间。单次成本以官方价格算对于一个日上新几十个 SKU 的店铺每天全部体检一遍的成本完全可承受。耗时方面模型单次响应大约 30 秒配合规则引擎总共 40 秒一份。刚开始觉得慢后来想想这 40 秒换的是人工审 2 小时还可能漏性价比非常划算。如果要提速可以把 6 份文件的独立检查并行化只保留跨文档一致性检查在最后串行预计能压到 15 秒以内。6. 这套方案的扩展空间从体检到上架流水线6.1 接入上架审核流程目前我的用法是上线前跑一次出报告人改属于半自动。下一步完全可以做成强制节点商品的资料包在上架前必须通过体检助手报告里高优先级问题清零才能提交平台。这套逻辑用一个简单的状态机就能实现技术门槛很低但能把人工审核的漏网概率压到最低。6.2 把模型发现沉淀回规则库我的经验是规则引擎和大模型不是替代关系而是会不断互相反哺。模型查出的新类型问题比如卖点与详情语气不一致赠品说明缺失如果反复出现就可以固化成规则或者检查清单。我已经把这次 27 个问题里能规则化的 5 类问题加进了词表和校验逻辑下一轮体检的模型调用量又能少一截成本更低、速度更快。6.3 从发现问题到给出修改方案Qwen3.8-Max 的输出里每一行都带了 suggestion 字段其实已经具备半自动修复的潜力。比如品牌名大小写不统一可以直接让模型生成统一后的标准写法价格文案不一致可以让模型基于 SKU 表生成正确的到手价文案。这些建议经过人工一键确认就能落地效率比完全手改高很多。最后分享一点个人体会。这个项目的价值不只是查出了问题而是逼着我先把商品资料包的标准结构定义清楚了——字段命名、必填项、格式要求、文件命名规范。工具反而是这之后顺带出来的东西。如果你也想做类似的事情我建议先花时间梳理你自己的资料包规范再去调模型没有规范再强的模型也只会给你一份更长的问题清单。把问题变成规矩才是体检助手真正的意义。