1. 整体设计与思路拆解为什么需要一个“商品资料包体检助手”1.1 需求来源电商运营的“隐形加班”做电商的都知道一个商品从选品到上架中间要过多少道资料关标题、卖点、详情页文案、SKU规格、价格库存表、质检报告、品牌授权书……尤其是做多店铺、多平台的运营每天面对的不是一个商品而是一整个“资料包”。这些资料散落在表格、PDF、图片里格式五花八门信息口径还不统一。我这次要处理的场景就很典型一个新品牌准备上新品运营同事打包发给我6份资料商品信息表、SKU价格表、卖点文案、详情页文案初稿、质检报告扫描件、品牌授权书照片加1张主图让我帮忙“过一眼”有没有问题。说实话人工过一遍至少得花半小时而且容易漏价格表里某个SKU的库存写错了、详情页和标题里的参数对不上、质检报告的有效期快到了……这些细节光靠肉眼扫真的很难全抓出来。于是我想试试用 Qwen3.8-Max 搭一个“体检助手”把这些资料统一喂给大模型让它按照我预设的规则逐项检查最后输出一份结构化的“体检报告”。实测下来6份资料加1张图一次跑完查出27个问题覆盖了信息冲突、资质过期、价格异常、图片违规等多个类别。1.2 方案选型为什么选 Qwen3.8-Max 而不是自己写规则最开始我考虑过两种路线一种是纯规则脚本用正则匹配关键词、用pandas做表格校验另一种是直接用大模型做全量判断。纯规则脚本的问题很明显资料格式不固定每个品牌、每个运营给的表结构都不一样规则写得再全也有漏网之鱼。而且像“卖点文案是否和质检报告的检测项一致”这种跨文档的语义比对正则根本搞不定。大模型的优势在于语义理解能力和跨文档推理能力。而 Qwen3.8-Max 在这个场景里表现比较均衡上下文够长能一次吃下6份资料的文本内容加上商品图指令遵循能力强能严格按照我定义的结构化输出格式返回结果更重要的是它对中文电商语料的适配度很高像“SKU”“主图”“详情页”这些业务概念不需要额外解释就能理解。1.3 整体流程设计从“喂资料”到“出报告”四步走整个体检助手的处理流程我拆成了四步资料预处理把表格转成文本、PDF提取文字、图片做描述化处理统一成模型能读的格式。构建检查清单把电商商品资料常见的检查项固化成结构化指令让模型按清单逐项核查。模型推理与结构化输出调用 Qwen3.8-Max要求模型返回 JSON 格式的检查结果。结果解析与报告生成解析 JSON把问题按严重级别分类生成可读性强的报告。这个流程看着简单但每一步都有坑。下面我把核心细节拆开讲。2. 核心细节解析与实操要点检查项设计是“体检”的灵魂2.1 检查项分类一个电商商品资料包到底要查什么“体检”能不能查出真问题关键看检查项设计得全不全、细不细。我把商品资料包的检查项分成了七大类这也是后来能查出27个问题的基础框架。信息一致性标题、卖点、详情页、参数表之间的核心信息是否互相冲突。比如标题写“500ml”详情页写“450ml”这就是硬伤。资质合规性质检报告是否在有效期内、品牌授权书是否完整、送检单位和生产单位是否一致。价格与库存逻辑SKU价格是否为负数或明显异常、库存加总是否合理、促销价是否低于成本价如果资料里有。图片合规性主图是否存在极限词、是否包含违规水印或二维码、是否有多余的促销标签遮挡商品主体。参数完整性净含量、保质期、产地、执行标准等法定标注项是否齐全。文本规范性是否存在错别字、语病、歧义表达、标点符号乱用。平台规则适配标题是否超字数、是否有违禁词、类目属性是否匹配。这七类不是拍脑袋定的是我把过去两年遇到的商品上架驳回原因做了一次归类总结后的结果。做体检助手的第一步不是写代码而是建立这个检查清单。2.2 检查项的深度设计不能只查“有没有”还要查“对不对”检查项如果只停留在“有没有”那体检报告的水分就太大了。举个例子“资质合规性”如果只查“有没有质检报告”那等于没查。我把它拆成了几个更深的问题质检报告的签发日期是什么时候报告上注明的有效期是多久按当前日期推算是否过期报告上的产品名称、型号、生产单位是否与商品信息表里的一致检测依据的标准号比如 GB 标准是否适用于该商品类目类似地“价格与库存逻辑”也不是查“价格是否填了”而是查“价格是否在一个合理区间”“批发价和零售价是否倒挂”“SKU之间价格差异是否超出了正常范围”。这些深层检查项对模型的语义推理能力要求更高但 Qwen3.8-Max 的表现让我觉得这个方向是可行的——它能把“质检报告扫描件里提取出来的文字”和“商品信息表里的型号”做跨文档比对还能指出不匹配的具体位置。2.3 指令工程如何把检查清单变成模型能执行的“体检标准”检查清单是给人看的模型需要的是可执行的指令。我在设计 Prompt 时遵循了三个原则第一明确角色和任务。“你是一名资深的电商合规审核员请对以下商品资料包进行体检发现所有潜在问题。”这句话看着简单但它能激活模型在电商合规领域的知识背景。第二把检查项写成“要查什么怎么判输出什么”的结构。比如检查项3价格与库存逻辑。请逐一核对SKU列表中的价格和库存数据判断是否存在以下问题价格为负数、价格明显异常如低于1元或高于同品类正常价格10倍、库存加总错误、促销价高于原价。请列出每个问题的具体数据。第三强制结构化输出。我要求模型返回严格的 JSON 格式每个问题包含“问题编号”“严重级别”“所属类别”“涉及文件”“问题描述”“建议修正方案”六个字段。这个三步法很朴素但实测下来输出质量比“帮我看看这些资料有什么问题”高出一大截。3. 核心环节实现从资料预处理到27个问题的生成3.1 资料预处理表格、PDF、图片怎么“喂”给模型体检助手要处理多种格式的资料但大模型直接读表格和PDF的能力有限所以必须先做预处理。表格文件我用 pandas 读取后转成 markdown 格式的文本。为什么要转markdown因为表格的行列结构在markdown里能被模型清晰地感知到比单纯用print(df.to_string())效果好很多。尤其是SKU表这种二维结构markdown的管道符号能让模型更容易对齐“哪一行是哪个SKU、哪一列是什么属性”。PDF和图片的处理分两种情况如果是文字型PDF直接用 pdfplumber 提取文本如果是扫描件或图片比如质检报告照片、授权书照片我先调用多模态接口把图片转成详细的文字描述再把描述喂给主模型做判断。这里有个细节图片描述不能只写“这是一张质检报告图片”要尽量还原图片中的关键信息。我用的提示词是“请以文字形式完整提取这张图片中的所有信息包括表格内容、印章文字、手写备注、日期和编号等。不要遗漏任何细节。”实测下来质检报告里的印章日期、检测编号这些容易被忽略的信息在描述化处理后都能被主模型捕捉到。3.2 系统架构用“规则预检大模型深度检查”双引擎纯粹依赖大模型做所有检查有个隐患像“价格是否为负数”这种简单逻辑模型偶尔也会犯迷糊。所以我在架构上做了一个双引擎设计。第一层是规则预检用正则表达式和数值判断处理那些“确定性”问题。比如import re def rule_precheck(sku_data): issues [] for sku in sku_data: # 检查价格为负数 if sku[price] 0: issues.append({ keyword: 价格为负数, item: sku[sku_name], detail: f销售价格为 {sku[price]} 元不能为负数 }) # 检查促销价高于原价 if sku[promo_price] and sku[promo_price] sku[price]: issues.append({ keyword: 促销价高于原价, item: sku[sku_name], detail: f促销价 {sku[promo_price]} 元高于原价 {sku[price]} 元 }) return issues第二层是大模型深度检查负责那些需要语义理解的判断标题和详情页参数是否冲突、卖点文案是否有夸大宣传、平台违禁词是否出现等。最后把两层的输出合并去重按严重级别排序。这个设计的好处是规则层保证了基础逻辑不会漏模型层保证了语义问题能被发现两层互补查出来的问题更全面。3.3 Prompt模板直接可复用的“体检标准”指令下面是我实际使用的 Prompt 模板核心部分你可以直接抄走改造。你是一名资深的电商合规审核员你的任务是对一个商品的资料包进行全方位体检。 【检查范围】 1. 商品信息表包含标题、类目、品牌、产地、规格参数等 2. SKU价格库存表包含各规格的价格、库存、SKU编码 3. 卖点文案用于详情页首屏的卖点提炼 4. 详情页文案初稿包含商品详情介绍、参数表、售后说明等 5. 质检报告文字提取包含检测依据、检测项目、检测结果、签发日期等 6. 品牌授权书文字提取包含授权方、被授权方、授权期限等 7. 商品主图文字描述包含图中出现的促销文案、标签、水印信息等 【检查要求】 请逐项完成以下七类检查并输出所有发现的问题 一、信息一致性标题、卖点、详情页、参数表之间的核心信息是否互相冲突。 二、资质合规性质检报告是否在有效期内、授权书是否完整有效、报告中的产品信息是否与商品信息一致。 三、价格与库存逻辑价格是否为负数或明显异常、促销价是否高于原价、库存加总是否合理。 四、图片合规性主图是否存在极限词、是否包含违规水印或二维码、促销标签是否遮挡商品主体。 五、参数完整性净含量、保质期、产地、执行标准等法定标注项是否齐全。 六、文本规范性是否存在错别字、语病、歧义表达。 七、平台规则适配标题是否超长、是否有明确违禁词、类目属性是否匹配。 【输出格式】 严格按以下JSON格式输出不要输出任何其他内容 { summary: { total_issues: 0, critical_count: 0, major_count: 0, minor_count: 0 }, issues: [ { issue_id: 1, category: 信息一致性, severity: critical, files_involved: [商品信息表, 详情页文案初稿], description: 描述具体问题, suggestion: 建议修改方案 } ] }这个模板看起来长但每一段都是必要的。特别是“输出格式”部分它决定了模型返回的结果能不能被程序直接解析避免了人工去翻对话记录。3.4 实测回放27个问题是怎么被查出来的我用上面这套流程跑了一次真实的商品资料包。6份资料加1张主图总共处理时长大约3分钟包含预处理和模型调用时间最终查出了27个问题。这27个问题的分布大致是信息一致性7个、资质合规性4个、价格与库存逻辑5个、图片合规性3个、参数完整性4个、文本规范性3个、平台规则适配1个。其中有几个问题印象很深。第一质检报告的签发日期是去年报告上注明的有效期是“一年”按当前日期推算已经过期4天但人工审核很容易忽略。第二SKU表里促销价有一个数据填反了促销价比原价高被规则预检层抓出来了。第三详情页参数表里写的净含量是“450ml”而商品信息表和标题里都是“500ml”这个冲突被模型比对出来了。第四主图的右下角有一个小的“全网最低价”水印触发了极限词规则。这些问题如果靠人工逐份核对不仅慢而且容易疲劳出错。体检助手一次跑完直接输出带严重级别和修改建议的报告运营同事拿过去就能改。4. 常见问题与排查技巧实录实测中踩过的坑4.1 JSON输出不稳定模型偶尔会返回Markdown格式第一次跑流程的时候我发现 Qwen3.8-Max 偶尔会返回带 json标记的代码块而不是纯 JSON。直接用json.loads() 解析就会报错。解决办法是在解析前做一次清洗去掉代码块标记提取 JSON 部分。更稳妥的方案是在 Prompt 里加一句“不要使用代码块直接输出原始JSON”实测出错率大大降低。但还是建议在代码里做好容错import json import re def parse_model_response(response_text): # 去掉可能的代码块标记 cleaned re.sub(rjson\s*|\s*, , response_text.strip()) # 找到第一个 { 和最后一个 }截取中间部分 start cleaned.find({) end cleaned.rfind(}) if start -1 or end -1: raise ValueError(未找到有效的JSON内容) return json.loads(cleaned[start:end1])这个容错函数我后来一直留着不管换什么模型都能用。4.2 图片信息丢失主图上的文字经常被漏掉最初测试时主图上的促销文案、水印文字经常在图片描述化阶段被漏掉。后来我发现问题出在提示词上如果只是简单说“描述这张图片”模型会关注构图和主体而忽略角落里的文字。改进后的做法是分两步提取先让模型“描述图片的整体内容”再让模型“单独提取图片中的所有可见文字”然后合并结果。这样处理后主图上的“全网最低价”水印、角落里的“限时特惠”标签都能被捕捉到。4.3 跨文档比对会“张冠李戴”在处理多份资料时偶尔会出现模型把A文档的参数和B文档的参数搞混的情况。比如把 SKU 表里的一个规格误认为是另一个 SKU 的导致误报问题。这个问题的根源在于上下文太长模型注意力分散。我的解决办法是在喂给模型的文本中为每个文档增加清晰的边界标记比如【文档1商品信息表】 内容... 【文档2SKU价格库存表】 内容...同时在 Prompt 里特别强调“请严格区分不同文档中的信息如果某条信息只存在于单一文档请标注仅存在于该文档。”这个做法有效减少了误报。4.4 检查项遗漏模型会“选择性失明”大模型在长任务中会遗漏检查项比如跳过了“参数完整性”或“平台规则适配”某一项。我统计过如果不加限制模型大约会漏掉15%的检查项。解决方案是把检查项从“描述形式”改成“清单形式”并在 Prompt 里要求“请逐项检查每检查完一项就在该项后面标注已完成”。同时在问题最少数量上做提示“如果某项检查未发现问题也要在summary中留空数组但不要跳过该项。”也可以在后处理时增加一道“完整性校验”对比模型返回的问题分类和预设的七大类如果某一类完全没有问题人工复核一下是否真的没问题。4.5 常见问题速查表现象可能原因解决方案模型返回Markdown格式JSON指令不够明确在Prompt中强调“直接输出原始JSON不要使用代码块”图片上的文字信息丢失图片描述提示词太笼统分两步提取先整体描述再单独提取文字跨文档参数张冠李戴文档边界不清晰使用【文档N:名称】标记强调区分不同文档部分检查项被跳过检查项设计太长模型注意力分散用清单形式列出检查项要求逐项标注完成误报率高规则层的硬性判断和大模型的语义判断冲突加一层“人工复核或规则复核”兜底处理大表格时性能下降上下文过长对表格做字段裁剪只保留和检查项相关的列5. 从27个问题到“防患于未然”体检助手的扩展思路这次体检助手跑下来查出的27个问题里真正严重的其实只有两三个大多数是“改了就好”的小问题。但在电商场景里这些小问题往往就是差评、退货、抽检罚款的导火索。我在想这套体检逻辑还能往两个方向扩展。一个是往“售前校验”方向走把体检助手接入商品发布流程在资料上传阶段就自动跑一遍体检不合格直接打回修改。另一个是往“竞品资料分析”方向走用同样的框架去分析竞品的商品资料反推他们的卖点结构和合规情况。如果你也想搭一个类似的工具我的建议是不要一上来就追求大而全。先把你手头最常见的三类资料、十个检查项跑通再逐步扩展。我这次是先把“信息一致性、资质合规、价格库存逻辑”这三类做扎实其他的都是后续迭代加上去的。6. 最后再说几个实操心得整个项目做下来印象最深的一点是大模型的价值不在于“什么都知道”而在于“你问对问题时它能给出靠谱的答案”。检查项的设计质量直接决定了体检报告的含金量。另外不要迷信模型的一次性输出。我在实际使用中养成了一个习惯每轮体检完成后会抽几个问题去原文复核一遍。不是因为不信任模型而是因为“有问题”和“问题描述准确”之间还有一段距离。模型负责广撒网人负责精准收口。最后一个小技巧如果你要把这套流程固化下来建议把“检查项清单”和“Prompt模板”单独存成配置文件不要硬编码在代码里。这样当平台规则更新、类目调整时只需要改配置不用重写代码。我这轮跑完后已经把检查项升级到了第三版每次迭代改的都是配置文件代码几乎没动过。