上周帮一位做家居百货的卖家朋友处理店铺申诉他的天猫店因为主图上印了“全网销量第一”被系统抽检下架。这个违规表述其实在商品资料包里躺了半个多月前后经过运营、美工、店长三个人之手愣是没人察觉。也就是在那一周我用 Qwen3.8-Max 搭了一个商品资料包体检助手把包含 6 份文档资料和 1 张商品主图的完整资料包一次性丢进去不到十分钟就拿到一份 27 个问题的体检报告。其中至少有 5 个问题是人工审查几乎必然遗漏的——包括那个“全网第一”。这篇文章不聊概念直接把我搭建这套助手的过程、体检维度设计、Prompt 写法、实测踩坑全部摊开。做电商运营、商品管理、内容审核的朋友或者正在研究大模型落地应用的同学都可以照着这套思路改造出适合自己业务场景的版本。不需要复杂的算法基础核心就是一个大模型 API 加一段可靠的数据解析脚本。1. 电商资料包的“隐形体检需求”为什么非做不可1.1 一份商品资料包里到底藏了多少雷先还原一下我处理的那套商品资料包。它是一个厨房收纳置物架产品共包含 6 份资料和 1 张主图文件格式典型内容商品标题文案Word标题、副标题、卖点关键词详情页文案Markdown五张详情图对应文案、产品故事、场景描述规格参数表Excel材质、尺寸、承重、容量、颜色等结构化参数客服话术文本售前问答、售后话术、价格解释、物流说明活动利益点Word大促利益点、优惠券规则、赠品信息合规自查表Excel平台审核要求、禁用词清单、素材要求商品主图PNG电商平台首图含产品图、促销文案、标识多平台运营的团队这套资料还会衍生出天猫版、京东版、拼多多版、抖音版每个平台对违禁词、宣传规范的要求不完全一致。这些文件分散在不同人手里运营改一版标题客服话术里还是旧价格美工更新了主图详情页文案里还在用旧卖点——这种不一致在团队协作中几乎每天都在发生。1.2 人工体检的天然盲区有人会说这些东西让有经验的人过一遍不就行了问题在于“有经验的人”看一份资料包需要多久。我之前专门测算过一个熟手把 6 份资料完整过一遍至少需要 40 到 60 分钟。这还是在只做快速浏览的情况下。如果要做到真正的交叉一致性检查——比如把规格参数表里的“承重 30kg”和详情页里的“承重 60 斤”做单位换算核对把客服话术里的价格和活动利益点里的到手价做比对——时间还要翻倍。而人眼的疲劳曲线决定了连续排查到第 30 分钟之后漏检率会直线上升。更重要的是人工检查存在一个几乎无法克服的问题人是按文件去读的不是按“字段关系”去读的。读详情页的时候你不会时刻想着去对照规格参数表里的每一个数值打字回复客服话术草稿的时候也不会每写一句就去翻一遍活动利益点。跨文档校验这件事天然违背人的阅读习惯却恰恰是机器和大模型的强项。1.3 为什么选 Qwen3.8-Max 而不是规则脚本你可能想问这些字段比对用 Excel 函数或者写 Python 脚本不也能做吗能但只能做最表层的那部分。规格参数表里的“304 不锈钢”和详情页里的“食品级不锈钢”一个是材质标准一个是安全等级规则脚本判断不了它们是否指向同一信息。客服话术里写“七天无理由退换”活动页里写“支持 15 天无理由”这种语义级别的差异传统的精确匹配完全无能为力。我当时选 Qwen3.8-Max 的核心原因有三个。第一它的长文本理解能力足够一次处理完整的多文件资料包不需要把文档拆得七零八落再分别喂给模型这样反而会丢失跨文档上下文。第二它对中文电商语境的理解比较到位平台禁用词、广告法相关表述、电商黑话它基本都能识别不太需要额外维护一份庞大的词库。第三它在结构化输出方面表现稳定配合 JSON 输出模式可以直接把检查结果变成可编程处理的报告数据。当然我不是说规则脚本没用实际上后面你会发现规则脚本在大模型跑完之后还有非常重要的“兜底”角色——这个我们留到第三章细说。2. 体检维度设计让大模型查什么、怎么查、按什么标准查2.1 五维检查框架完整性、一致性、合规性、表达力、图片一致性拿到一套资料包先别急着写 Prompt。我踩过最大的坑之一就是一上来就让大模型“检查一下有没有问题”——这种开放式的指令得到的回答往往大而空什么“建议加强品牌调性”“可以优化卖点表达”一点实际价值都没有。正确的做法是先把体检维度定义清楚。我在这个项目里把检查项拆成了五个维度完整性必填字段是否缺失。比如规格参数表里有没有材质、尺寸、承重这些基础参数详情页有没有售后说明合规自查表是否完整。一致性多份资料之间的交叉信息是否统一。这个维度信息量最大问题也最多。包括价格、规格、卖点、活动规则、材质表述等。合规性是否违反平台规则和广告法。极限词、绝对化用语、无法证明的数据宣称、侵权风险表述等。表达力文案层面的质量问题。错别字、标点全半角混乱、长句晦涩、卖点堆砌没有逻辑等。图片一致性主图上的文字信息与文档资料是否匹配。这是纯文本大模型需要借助 OCR 才能完成的部分。2.2 跨文档一致性检查的“字段关系表”五维框架里最容易设计、也最容易出问题的是“一致性”。你需要提前列出哪些字段之间存在对应关系这些关系叫“字段关系表”。举几个实际例子。价格这个字段可能同时出现在客服话术、活动利益点、详情页文案三份文件中三处必须一致。容量/净含量这个字段可能同时出现在规格参数表、详情页文案、主图三处而且可能存在单位换算毫升和升、克和千克。卖点关键词会在标题、详情页、主图文案中重复出现不能互相矛盾。材质表述在参数表里是“201 不锈钢”在详情页里写“不锈钢”在产品图里写“高级不锈钢”这三者之间的逻辑关系需要判断。构建字段关系表的过程实际上就是盘清你的资料包有哪些“关键信息节点”。我建议用 Excel 先把这些字段关系列出来再把它写进 Prompt 里让大模型严格按表执行。这样检查结果的可复用性会大幅提升——换一套资料包只需要微调字段名称检查逻辑完全不用重写。2.3 商品图这条链路OCR 先行语义比对在后主图的检查比较特殊。Qwen3.8-Max 是文本模型不能直接“看”图片所以需要先把图片上的文字提取出来。我用的方案是 PaddleOCR 本地跑一遍把主图上的中文、英文、数字全部抽成文本再连同 OCR 坐标信息一起交给大模型做后续判断。主图上的文字通常不多十几秒就能跑完。这里有一个非常关键的细节OCR 输出的文本一定要保留坐标信息。为什么因为判断主图合规性时排版位置很重要。比如“全场五折”和“满 99 减 50”如果放在主图的同一个位置可能导致视觉冲突再比如主图上如果有小字备注“活动最终解释权归本店所有”这种字体过小、容易误导消费者的表述平台往往是重点监管对象。有坐标信息Prompt 里的检查规则才有落地的抓手。3. 系统搭建实录数据解析、Prompt 工程与代码兜底3.1 整体架构与数据预处理整个系统的代码不大核心流程分四步文件解析、OCR 提取、大模型体检、报告生成。我用 Python 搭的主流程文件解析部分用了几个成熟库Word 和 Markdown 直接读文本Excel 用 openpyxl 读取并保留单元格结构图片用 PaddleOCR 识别。核心代码骨架如下import json import openpyxl import docx from paddleocr import PaddleOCR import dashscope from dashscope import Generation def extract_text_from_docx(path): doc docx.Document(path) return \n.join([p.text for p in doc.paragraphs]) def extract_from_excel(path): wb openpyxl.load_workbook(path, data_onlyTrue) rows [] for ws in wb.worksheets: for row in ws.iter_rows(values_onlyTrue): rows.append( | .join([str(c) for c in row if c is not None])) return \n.join(rows) def ocr_image(path): ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(path, clsTrue) items [] for line in result: for box, text in line: items.append({ text: text[0], position: box }) return items def check_with_llm(context: dict): prompt build_prompt(context) # 核心 Prompt 构造 resp Generation.call( modelqwen3.8-max, messages[{role: user, content: prompt}], result_formatmessage ) return json.loads(resp.output.choices[0].message.content)提示这里用了 dashscope SDK 调用 Qwen3.8-Max 模型接口实际使用时替换为自己的 API Key 和模型可用名称即可。为了演示完整流程我保留了最简调用方式生产环境建议加上重试和超时处理。3.2 Prompt 工程三个决定成败的设计Prompt 是这套系统的灵魂。我前后迭代了三个版本才稳定下来最终版有三个关键设计。设计一给模型一个明确的“检查专家”角色并定义输出约束。一开始我的 Prompt 只写了检查要求没有定义输出结构结果每次返回的格式都不一样有的用列表有的用段落后处理非常痛苦。后来改成角色设定 固定 JSON 输出结构一次就稳定了。角色设定让模型以“平台资深审核员”的视角去做判断输出约束强制它按 [{file: 详情页, issue: ..., severity: high, suggestion: ...}] 这样的结构逐条返回。设计二把检查维度和字段关系表写进 Prompt而不是让模型自由发挥。第二章说的五个维度和字段关系表这一步真正发挥作用。Prompt 里明确列出每个维度要检查什么哪些字段之间需要做交叉比对模型输出的结果就非常聚焦。比如我明确写了“请重点核对规格参数表中的承重、容量、尺寸与详情页文案及主图文字信息的一致性”模型就会把精力集中在这类跨文档比对而不是泛泛而谈“优化文案”。设计三引入“先推理再作答”的两阶段输出。这是效果提升最大的一步。我在 Prompt 里要求模型先输出一个“检查过程摘要”说明它发现了哪些可疑点、做过哪些交叉比对再输出最终 JSON 报告。这个设计有点类似让模型先展示思考过程再给结论实际跑下来漏检率比直接输出答案要低不少。也不需要单独发两次请求在同一个 Prompt 里让它先写推理再输出 JSON 就行。3.3 数值归一化与规则兜底大模型不擅长精确比对大模型在语义判断上很强但在精确数字比对上有明显短板。我的实测里模型遇到“500ml”和“0.5L”这种单位换算能反应过来但遇到“358×246×84mm”和“35.8cm×24.6cm×8.4cm”这种规格表达时偶尔会给出错误判断甚至出现把 358 和 35.8 直接当成两个不同数值的低级错误。解决方案是在把文本喂给大模型之前先用代码做一次数值归一化。我写了一个预处理函数把所有常见的单位换算统一成标准单位尺寸统一换算成 mm容量统一换算成 ml重量统一换算成 g。归一化后的文本再喂给模型数字比对的准确率明显提升。同理规则脚本在大模型跑完之后还承担“硬性拦截”的角色。像“第一”“绝对”“最”这些极限词我另外维护了一个小型敏感词库用正则在大模型输出结果之外做一次全量扫描。这样做不是为了替代大模型而是给合规性检查加一道保险——规则永远比模型更可靠也更容易向平台审核人员解释。4. 实测结果27 个问题是怎么分布的哪类最致命4.1 问题清单总览整套资料包跑完Qwen3.8-Max 一共返回了 27 个问题。我按五个维度做了分类统计检查维度问题数严重级别典型问题举例一致性9高 6 / 中 3标题“免打孔”与参数表“需钻孔安装”冲突主图“承重 30kg”与参数表“承重 15kg”不一致客服话术价格与活动利益点到手价相差 10 元合规性6高 4 / 中 2主图含“全网销量第一”详情页“顶级工艺”未标注专利号却宣称“专利设计”完整性5中 4 / 低 1规格参数表缺少材质字段详情页无售后说明合规自查表质检报告编号为空图片一致性4高 2 / 中 2主图促销文案“满 99 减 20”在活动利益点中未出现主图容量标注与规格参数不一致表达力3低 3“不占空间”重复 4 次详情页第三段全角标点混乱客服话术“哦哦”等语气词过多27 个问题里严重级别为高的有 12 个。这个比例比我预想的高得多也间接说明这套资料包在发布前的人工审核环节几乎是形同虚设的。4.2 三个典型问题的深度复盘问题一标题“免打孔安装”与参数表“需钻孔安装”直接冲突。这是整套报告里最触目惊心的一条。标题文案写的是“免打孔安装”而规格参数表里明确标注“安装方式需钻孔”。运营、美工、店长三个人分别看过材料却没人把标题和参数表放在一起对照过。如果这套资料包直接上新买家收到货发现需要钻孔退货退款和差评几乎是必然的。问题二主图“承重 30kg”与参数表“承重 15kg”不一致。主图为了突出卖点把承重标到了 30kg参数表里写的却是 15kg。这个差异我推测不是恶意夸大而是运营在写主图文案时凭印象填的。但平台规则里主图宣传参数和详情参数不一致属于误导消费者被举报或抽检到就是违规。这类问题典型的产生原因就是信息源多、更新不同步人工极难发现而大模型只要把主图文案和参数表放在一起做一次交叉比对立刻现形。问题三客服话术的价格与活动利益点的到手价相差 10 元。活动利益点写的是“前 100 名到手价 89 元”客服话术里却还保留着“日常售价 99 元活动到手价 99 元”的旧版本。买家咨询时按客服的说法下单实际支付却是 89 元用户不会觉得自己赚了只会觉得店铺价格体系混乱。这类问题在电商里特别常见因为客服话术的更新滞后于运营活动节奏往往是一个月前的话术还在沿用到新活动里。4.3 误报与漏报大模型实测的边界在哪27 个问题里也有两条误报。一条是模型把“加厚不锈钢”里的“加厚”判断为疑似绝对化用语实际上“加厚”是描述性词汇只要不写“最厚”“超厚第一”这类表述平台一般不会判定违规。另一条是模型认为详情页缺少“生产日期”信息——但这是一个收纳置物架属于非食品类目根本不需要标注生产日期。误报不算严重说明模型的判断在合理范围内但提醒我两点第一合规检查规则需要结合具体类目食品、美妆、电器、家居的合规要求差异很大Prompt 里的检查清单得按类目定制不能一套规则打天下。第二大模型的判断结果适合做“候选清单”不适合直接当“最终结论”。我现在的流程是模型输出结果后由人工对高严重级别的问题做二次确认中低严重级别的问题直接走修改流程。这个分层审阅机制既保留了 AI 的效率也保留了人的最终判断权。5. 踩坑复盘系统从能跑到好用关键在三个细节5.1 OCR 识别误差图片文字质量的隐形陷阱PaddleOCR 中文识别准确率已经很高但在主图这种字体多变、有背景干扰的场景下仍然会出错。我第一次跑的时候“ml”被识别成“m1”“304 不锈钢”被识别成“3O4 不锈钢”。如果不做处理这些错误文本直接喂给大模型模型会在错误信息的基础上做判断结果自然不可靠。后来我加了两个处理。一是针对数字和单位做了 OCR 后处理结合商品类目常见的单位词库对疑似识别错误做自动纠正二是在 Prompt 里明确要求模型“注意 OCR 文本可能存在的识别误差如遇无法确认的字符请单独标注可疑程度”让它不至于在错误信息上得出过度自信的结论。5.2 模型输出偶尔“胡编”结构化校验必须有大模型偶尔会输出一些资料包里不存在的“问题”。比如它在一份资料里凭空生成了一个不存在的型号“BX-20”还说这个型号和标题中的“BX-10”不一致。我追踪了一下猜测是模型在上下文里看到了“型号”这个字段后自由发挥编造了一个。应对方案是在代码里加一道结构化校验模型返回的每条问题记录必须能从原文中找到对应的证据文本并记录证据所在的文件名和原始句子。如果程序在原文中检索不到对应证据这条问题直接降级为“疑似”不进入正式报告。这个机制在程序上不复杂但对报告的可信度提升非常大。5.3 Prompt 从第一版到终版的三个关键改动第一版 Prompt 太“放养”只给了角色和任务模型输出一堆正确的废话。第二版加入了五维框架和字段关系表输出开始聚焦但格式不稳定。第三版加了 JSON 结构约束和“先推理再输出”的两阶段要求这才达到我想象中的可用状态。除开发送前的 Prompt 设计生成后的报告整理同样重要。我把模型返回的 JSON 报告直接转成了带严重级别标签的 Excel 表格按“高-中-低”排序后发给业务同事。表格里每条问题都带“证据文件-证据原文-修改建议”业务同事不需要再翻原始资料包就能定位问题整个推动整改的流程顺畅了很多。注意如果要把这个流程做得更完整还可以在报告生成后加一层“整改闭环”——每条问题记录指派负责人和截止日期整改完成后再次用体检助手复检确认问题清零。这一步不涉及技术但能把体检的价值落到业务结果上。5.4 成本与耗时大家最关心的数字这套体检跑一套资料包耗时主要取决于文件数量。我的实测数据是6 份文档加 1 张主图OCR 约 10 秒大模型推理约 1 到 2 分钟全程不超过 3 分钟。费用方面OCR 本地跑不花钱Qwen3.8-Max 按 token 计费一份资料包入参加出参总共 1 万 token 左右成本可以忽略不计。对需要批量检查几十上百个 SKU 的团队来说这个成本和效率都相当有竞争力。6. 适用边界与进一步扩展思考这套方案目前最适合的是 SKU 数量多、资料包结构相对固定的电商团队。SKU 越多人工检查的边际成本越高AI 体检的收益越明显。相反如果团队只有两三个商品人工检查也就一两个小时的事搭建这套系统的投入产出比就不划算了。我在实际使用中还有一个体会这套系统的价值不止在于查出问题更在于把检查标准固化了下来。以前团队对“什么样的资料包算合格”没有统一认知每个人的标准都不一样。现在五维检查框架写进 Prompt 里等于把团队内部的品控标准变成了可执行、可复现的流程新来的运营照着报告改就行不需要再靠口口相传去理解老员工的经验。后续如果要扩展我建议优先考虑两个方向。一是把检查结果接入内部通知跑完自动推送到工作群时效性会更好二是沉淀每个商品的历史检查报告形成一个质量问题数据库用数据反向优化团队的工作流程——比如如果一段时间内一致性类问题频发说明协同流程里有环节需要调整这比单次检查的意义大得多。