做电商运营的同学应该都有过这种经历新品上架前运营、美工、合规、供应链几个角色来回传资料包平台审核驳回一两次才发现详情页里写了极限词或者参数表和质检报告对不上。以前我处理这些全靠肉眼硬翻一次大促前审完一份资料包差不多要一个下午还不敢保证没漏。后来我干脆用 Qwen3.8-Max 搭了一个电商商品资料包体检助手把 6 份资料和 1 张商品图丢进去跑一次直接列出 27 个问题。这玩意儿不是简单的关键词扫描而是把资料包当成一个整体来做交叉核对能发现很多人工容易忽略的细节问题。这篇就把整个搭建思路、核心实现和踩坑记录完整写出来帮同样被商品资料审核折磨的人少走点弯路。我默认来看这篇内容的人要么是电商运营、商品合规岗要么是想用大模型做内部提效工具的开发同学。整体内容不需要你有很强的算法基础但最好对 Python 和调用大模型 API 有基本概念。我会把整个方案拆开讲清楚从需求分析到提示词设计再到跨文件核对逻辑最后附上完整的实测记录和问题排查经验。1. 为什么需要一台“资料包体检助手”1.1 电商商品资料包到底在检查什么先定义一下这里说的“商品资料包”。它不是一张图或一份文档而是商品上架前需要准备的所有材料的总和。在我做的场景里一份标准资料包包含 6 类文档和 1 张主图具体是商品详情页文案、规格参数表、产品质检报告、品牌授权书或资质证书、SKU 清单含价格和库存、售后与物流说明以及一张白底商品主图。这 6 份资料加上 1 张图每一份都有自己的审核重点。详情页看的是有没有极限词、虚假宣传、材质功效描述是否有依据规格参数表看的是参数是否完整、单位是否规范、有没有明显数值错误质检报告看的是报告编号、检测机构、日期、结论是否匹配当前批次授权书看的是授权范围、有效期、品牌方盖章SKU 清单看的是价格层级、库存数量、规格命名是否和详情页、参数表对得上售后和物流说明看的是退换货政策、发货时效、保修条款是否写得清楚。真正麻烦的是这些材料之间还会互相打架。比如详情页写“全网最低价” SKU 清单里的价格却不是最低档参数表写“面料成分聚酯纤维 100%”质检报告的材质检测结论却是“棉 80% 聚酯纤维 20%”。这种矛盾不是单独看某一份文件能发现的必须把多份资料放在一起对照。而传统的关键词扫描工具只能检查单文件里的敏感词做不了跨文件的语义比对所以这类问题基本都是靠人眼反复看才能揪出来。1.2 人工检查的痛点和传统自动化方案的局限我最早处理资料包的方式相当原始把 6 份文档一一下载下来打开几个窗口来回切对着平台规则逐条核对。一份资料包如果认真查光详情页文案就有 2000 到 4000 字参数表少则 30 行多则上百行再加上质检报告和授权书的 PDF全部过一遍需要 3 到 4 个小时。如果遇到大促前集中上新品一天要看两三份眼睛基本是花的漏检概率越来越高。后来我想过用正则表达式和规则脚本做自动化比如直接扫描“第一”“最”“百分之百疗效”这类关键词。但这种方案有两个硬伤。第一规则写不全面。电商平台风控规则更新频繁今天合规的词明天可能就是违禁词用脚本维护关键词库非常痛苦。第二规则判断不了语义。比如“最低价”在详情页里可能是违规的绝对化用语但出现在“到手价计算方式”的解释里就没什么问题再比如“抗菌”这个词有检测报告支撑就是合规功效宣称没有支撑就是涉嫌虚假宣传。规则脚本只能告诉你“这个词出现了”没法告诉你“这个词在这里应不应该出现”。所以人工检查漏检率高纯规则脚本又太死板中间缺一个能理解语义、能跨文件比对、还能给判断依据的“审核员助手”。这也是我决定用大语言模型来做体检助手的直接原因。1.3 为什么选中 Qwen3.8-Max 而不是纯规则或者更小的模型选 Qwen3.8-Max 不是因为它参数规模大或名声响而是因为这个场景对模型有几点硬性要求。第一是长文本处理能力。6 份资料加起来通常有 8000 到 15000 字质检报告和授权书转成文本后虽然不长但 SKU 清单和详情页文案往往很占篇幅。你需要模型能在一次对话里吃下足够长的内容并且保持对前后文的关注。第二是中文电商语义理解能力。广告法违禁词、平台特殊规则、电商行业的常见表述这些都需要模型对中文语境有比较深的理解。第三是多模态能力因为还得看图需要模型能同时处理图片内容而不只是文本。第四是结构化和可操作性。我需要模型输出稳定、能解析的 JSON 结果方便后续自动化处理。Qwen3.8-Max 这几个维度都覆盖到了尤其是长文本和中文理解上的表现让我省了很多事。它的上下文窗口足够容纳整个资料包内容多模态也能支撑对商品主图的检测。相比之下如果用纯规则脚本根本做不到跨文件语义比对如果用一个参数量更小的模型虽然在速度和成本上有优势但面对“详情页写了 X但参数表写的是 Y这两者矛盾”这类需要多步推理和跨段关联的任务准确率会明显下降。我实际测试过几轮小模型的误报率偏高常常把“这是平台要求的售后话术”误判成“这是虚假承诺”得不偿失。1.4 方案的定位它不是一个自动审核系统而是人的放大镜在动手搭建之前我给自己定了一个很重要的原则这个助手不是用来替代审核员的它是用来帮审核员把精力集中在真正需要判断的问题上。所以我没把输出设计成“通过”或“不通过”这种是非判断而是输出“疑似问题 涉及文件 相关原文 可能违反的方向 建议核实的点”。最终的判断权还是在我手里。这样定位的原因很实际。一方面电商平台的规则细节在不同类目下差异很大一个模型不可能完全吃透所有类目的所有细则它给出的判断一定需要有经验的运营人员复核。另一方面模型偶尔会误报比如把正常的功能描述识别为功效宣称。如果输出结果是二元的“通过/不通过”那误报一次就会让人对整个系统失去信任但如果输出的是“这里存在风险请重点核实”那即使误报也只是多花几十秒看一眼而已。这个小细节决定了这个工具能不能真正在日常工作中用起来。2. 体检项怎么定义把平台规则翻译成可执行的检查点2.1 输入侧6 份资料和 1 张商品图怎么组织第一步要解决的是输入格式问题。我的资料包里有 Word 或 PDF 格式的文档也有图片不可能全塞给模型。我的做法是先用脚本把文档统一转成纯文本再按文件名前缀区分类型最后拼成一个有结构、带标记的长文本块。转换方法不复杂PDF 用 pymupdf 提取文本Word 用 python-docx 提取Excel 的 SKU 清单用 pandas 读出来然后转成 Markdown 表格。要注意的是质检报告和授权书这类文件通常是扫描件直接提取文本会得到一大段乱码或者空内容。这种 PDF 我的处理方式是用 OCR 服务转成文本转完后需要人工快速扫一眼确认关键信息提取没有明显错漏再进入下一步。拼装格式上我做了明确的分隔和段落标记比如 文件商品详情页文案 详情页文本内容 文件规格参数表 参数表内容 文件SKU 清单 | SKU 名称 | 价格 | 库存 | 规格 | | --- | --- | --- | --- | | 标准款 | 89 | 1200 | 均码 | ... 文件售后与物流说明 售后说明内容这样做的目的是让模型能清楚地区分“这段内容来自哪份文件”在做跨文件核对的时候才能准确指出矛盾对应的两个文件。如果不加这种标记模型在长文本中很容易混淆信息来源出现“把详情页的说法安到 SKU 清单头上”这种低级错误。2.2 体检项拆解从平台规则反推检查点体检项是整个助手的核心。我的做法不是直接写一大段规则让模型自由发挥而是把常见的审核点拆成 8 个大类每个类别下再列具体的检查点让模型“按图索骥”去逐项核对。这比让模型自己思考“我该检查什么”要可靠得多。具体的大类和检查点我是这样拆的检查大类具体检查点判断依据说明极限词与违禁词绝对化用语、虚假承诺、权威背书检查详情页文案中是否出现“最”“第一”“绝对”“国家级”等表述并判断语境功效宣称合规描述是否有报告支撑、是否超范围宣称比对详情页功效描述与质检报告检测项目判断是否存在无依据宣称价格与促销信息一致性详情页价格表述与 SKU 清单价格是否一致找出所有价格数字交叉核对是否矛盾参数与规格一致性参数表与质检报告、详情页参数是否一致检查面料、材质、规格、重量等核心参数在多个文件中的数值是否相同资质有效性授权书、质检报告的日期、编号、范围检查日期是否过期、编号是否完整、被授权方是否匹配图片合规白底纯度、水印、文字遮挡、清晰度检查主图中是否有促销文字、logo 叠加、非白底背景、模糊等问题SKU 信息完整度命名规范、价格缺失、库存异常检查 SKU 清单是否缺少必填字段、命名是否混乱、价格是否明显异常售后与物流规范性退换货政策、发货时效、保修条款检查售后说明是否覆盖平台要求的必填项每个检查点输出时都要求给出来源文件、原文摘录和风险说明。这样既能让模型聚焦也方便我复核时快速定位到具体内容。2.3 双层架构规则初筛 模型深检在正式调用 Qwen3.8-Max 做深度检查之前我先跑了一层规则初筛把那些确定性的、需要精确匹配的检查点先用脚本解决掉。这层规则做了三件事第一数字和日期比对比如提取价格字段做一致性比对、提取日期判断是否过期这些交给脚本做又快又准第二格式校验比如检查 SKU 清单是否有空列、电话号码格式是否规范、参数单位是否统一第三敏感词预扫描把常见的违禁词提前标记出来作为提示词输入的一部分提供给模型帮模型缩小排查范围。规则初筛的结果不是直接输出而是作为一个“预体检清单”拼接到提示词里告诉模型“这些是我已经通过脚本发现的可疑点请你结合上下文判断这些问题是否成立同时继续检查我没有覆盖到的问题”。这样做的好处很明显模型不需要花太多精力在简单的数字比对和格式检查上可以把上下文窗口的重点放在语义判断和跨文件矛盾上准确率和速度都有提升。3. 核心实现提示词设计、多模态识别与结构化输出3.1 提示词设计让模型像平台审核员一样思考提示词是整个助手能不能好用的关键。我调过很多轮从最早的一行“请检查以下商品资料包中的问题”到后来形成了一套完整的结构化提示词效果差距非常大。我的提示词包含 5 个部分角色设定、任务说明、输入材料、检查清单、输出要求。角色设定不是花哨的“你是一个经验丰富的审核专家”这种空话而是明确告诉模型“你正在处理一个准备上架的商品资料包你的任务是模拟平台审核规则中的合规检查环节输出疑似问题供人工复核”。任务说明里强调“关注需要综合判断的语义风险和跨文件矛盾不要重复我已经提供的预体检结果”。检查清单部分就是把上一节那 8 个大类直接列进去每一类底下附上平台规则里常见的表述逻辑。比如“价格与促销信息一致性”这一类下我会写重点核对详情页提到的划线价、促销价、到手价与 SKU 清单中的价格层级是否逻辑一致是否存在“详情页宣称全网最低但实际价格高于其他渠道”的情况。这样模型才知道你到底要它看什么。下面是我实际在用的提示词主体部分精简后贴出来你是电商平台商品合规审核助手。我会给你一份商品资料包包括详情页文案、规格参数表、质检报告、授权书、SKU清单、售后物流说明以及商品主图信息。 你的任务是模拟平台合规审核流程对这些资料进行交叉核对找出所有疑似问题。注意 1. 重点检查需要语义理解或跨文件关联才能发现的问题。 2. 我已经提供预体检清单请先判断预体检项是否成立再继续补充新问题。 3. 所有输出必须基于材料原文不要编造具体数字或日期。 4. 若某个字段缺失导致无法判断输出“缺失待核实”。 以下是检查清单 1. 极限词与违禁词绝对化用语、无依据的承诺、权威背书等。 2. 功效宣称合规描述是否有质检报告支撑是否存在超范围宣称。 3. 价格与促销信息一致性详情页价格表述与SKU清单是否矛盾。 4. 参数一致性参数表、详情页、质检报告的材质/规格/重量等是否一致。 5. 资质有效性授权书和质检报告的日期、编号、有效范围是否合规。 6. SKU信息完整度必填字段是否缺失命名和价格是否异常。 7. 售后与物流规范性退换货政策、发货时效、保修条款是否覆盖。 8. 其他你认为需要重点提醒的问题。 输出格式要求 { summary: 整体情况概述, issue_count: 数字, issues: [ { issue_id: 问题编号, title: 一句话概括问题, severity: high/medium/low, files_involved: [涉及文件1, 涉及文件2], evidence: 问题关联的原文引用不超过100字, type: 问题所属检查大类, suggestion: 建议核实的方向 } ] } 以下是输入材料这段提示词里最关键的其实是最后两句。第一句是“我已经提供预体检清单”这能避免模型重复报告规则脚本已经发现的问题节省上下文空间。第二句是“若某个字段缺失导致无法判断输出缺失待核实”这能防止模型为了完成任务而对不存在的内容编造结论这是一个我踩过坑之后才加上的要求。3.2 商品图检查多模态识别怎么用处理商品主图是体检助手另一个比较重要的能力。Qwen3.8-Max 是支持多模态输入的可以直接把图片传进去让它描述和分析图片中存在的问题。这比传统的 OpenCV 方案要灵活很多因为很多图片合规问题本质上不是像素问题而是内容问题。我让模型对商品图做了 4 类检查背景是否纯白或者符合类目要求图片中是否存在促销字样、角标、水印或平台禁止的引导信息比如“加微信”“进群领券”这类文字商品主体是否完整、边界是否清晰、是否存在拉伸变形整体清晰度和曝光是否正常有没有明显的马赛克或者噪点。实际使用中这部分的提示词我会单独调用一轮不跟长文本混在一起。因为文本检查已经比较耗费 token如果再把图片塞进同一个对话会让上下文非常长也容易干扰模型对文本的专注度。所以我的流程是先用文本提示词跑完 6 份文档输出 JSON 格式的文本问题列表再把商品图单独跑一次输出图片问题列表最后在汇总层合并。顺便提一句传给模型的图片分辨率很重要不能压得太低。一开始我为了省流量把图片压缩到 500 像素宽结果模型连包装上的文字都看不清误报率飙升。后来统一用原图或 1000 像素以上的图准确率才恢复正常。3.3 结果结构化让模型输出可解析的 JSON让大模型直接做检查不稀罕难的是让它的输出能被程序稳定处理。一开始我让模型自由发挥它输出的是带 Markdown 标题的文本报告虽然读起来像模像样但没法自动转换成表格也没法按严重级别筛选更没法二次处理。后来我在提示词里固定要求模型输出 JSON并且给出了具体的 JSON 结构。结构里必须有 summary、issue_count、issues 三个顶层字段issues 数组里每个对象包含 issue_id、title、severity、files_involved、evidence、type、suggestion 这些字段。我在提示词里明确要求 severity 只能是 high、medium、low 三个值之一files_involved 必须是数组每个文件名要跟输入时给的“文件xxx”标记一致。这里有一个很关键的小技巧请求参数里要把 response_format 设为 json_object 或 json_mode。如果用 Qwen 的 API可以在调用时声明使用 JSON 输出模式这样模型很少会输出多余的说明文字。即使这样我在代码里也保留了兜底逻辑如果 json.loads 解析失败就把模型输出的内容作为纯文本扔进一个临时目录并在日志里打一条警告不中断整个体检流程。原因是实际跑批的时候偶尔会遇到模型输出里混进了 markdown 代码块标记直接 json.loads 会报错但去掉包裹的 json 就能正常解析。这个清洗逻辑我已经固化成了工具函数。3.4 二次追问从“发现问题”到“给修改建议”第一次跑完后拿到的是问题列表但只是知道“哪里有问题”还不够。对运营来说更想要的是“应该怎么改”。我加了一个二次追问机制把第一轮输出的 JSON 问题列表作为上下文再次调用模型让它对每一条 high 和 medium 级别的问题给出具体的修改建议。这轮的提示词逻辑是以下是针对商品资料包发现的问题列表。请针对 severity 为 high 和 medium 的问题逐一给出修改建议。 要求 1. 每个建议必须具体指出哪个文件、哪个位置、改成什么样的表述。 2. 如果是价格或参数矛盾建议给出统一方向比如“以质检报告数据为准”。 3. 如果问题是“缺失待核实”建议补充具体材料来源。 4. 输出JSON数组字段为issue_id、修改建议。这一轮不需要把所有资料包内容重新塞进去因为问题清单里已经有原文摘录模型可以基于这些信息做出相对具体的建议。这样二次调用的 token 消耗很小但对实际使用的帮助非常大。运营拿到“详情页第二段出现‘全网最低价’需要删除或改为限时活动表述并和 SKU 清单中的实际价格同步”这种建议基本上可以直接照着执行省去了自己翻资料找位置的步骤。4. 实测记录一次体检查出 27 个问题的完整过程4.1 测试资料包长什么样为了验证这个助手是不是真的有用我拿一套真实的商品资料包做了测试。商品是一款家居收纳箱资料结构是详情页文案约 2800 字其中包含产品介绍、材质说明、使用场景和售后承诺规格参数表包含 42 行参数涉及尺寸、容量、材质、承重、颜色等质检报告是 PDF 扫描件检测结论是材质和承重合格品牌授权书有效期为未来一年内覆盖范围为线上渠道SKU 清单里有 8 个 SKU包含不同尺寸和颜色的组合附了价格和库存售后物流说明是比较模板化的内容商品图是一张白底收纳箱照片。这 6 份材料加 1 张图内容其实不算极端复杂但已经很能代表日常运营中会遇到的情况了。我在完全人工检查的情况下第一遍花了大概 1 小时 40 分钟发现了 9 个明显问题包括详情页有两个极限词、SKU 清单有一列库存为空、授权书里品牌名和详情页品牌名写法不一致等。我后来又用助手跑了一遍输出 27 个问题其中有 6 个是我第一遍人工检查完全没注意到的。4.2 27 个问题清单与分布助手输出的 27 个问题按严重级别分布是high 级别 8 个medium 级别 11 个low 级别 8 个。按检查大类分布是极限词与违禁词 4 个功效宣称 3 个价格与促销一致性 5 个参数一致性 6 个资质有效性 2 个SKU 信息完整度 3 个售后物流规范性 2 个图片合规 2 个。其中比较典型的问题有这么几条。参数一致性里有一条详情页写“单箱承重 150kg”规格参数表写“承重 120kg”质检报告检测结果显示“承重 100kg”三个文件三个数字这种情况靠人眼逐个文件翻确实很难发现。价格一致性里有一条详情页写“促销价 59 元起”但 SKU 清单里最便宜的一款是 69 元说明“59 元起”标注与实际价格不符。还有一条是在授权书里被授权方写的是公司简称而详情页落款和质检报告委托方写的是公司全称这种简称和全称不一致的问题规则脚本能识别出部分但不能判断它们是不是同一家公司模型则给出了“需核实是否为同一主体”的建议非常实用。4.3 最惊艳的部分跨文件矛盾的排查逻辑最能体现这个方案价值的是几个通过跨文件关联才能发现的问题。举一个具体的例子详情页在功效宣称部分写“本品采用抗菌面料能有效抑制细菌滋生”而质检报告里完全没有抗菌检测项目。如果只看详情页这句话可能被归类为“功效宣称是否有报告支撑”这是需要模型把详情页的描述和质检报告的检测项目做语义匹配才能判断出来的属于两个文件间的关联推理。规则脚本很难做到这一点因为“抗菌”和“细菌滋生”在关键词层面是有关联的但规则脚本无法判断质检报告是否真的对该指标做了检测。另一个例子是图片问题。商品主图本身是白底但右下角有一个很小的“热卖”贴纸这个贴纸在压缩后的图上很不起眼。我第一遍人工检查完全没注意到它但 Qwen3.8-Max 在图片检查时识别出来了并标记为“图片含促销角标部分平台类目可能限制使用”。这类图片问题靠传统的 OpenCV 方案很难判断因为它需要理解“热卖”这两个字是促销信息而不是商品包装上的图案。模型能结合电商审核的知识来做这个判断。跑完这轮测试之后我重新核对了每一条问题确认有 24 条是真实且值得修的另外 3 条属于误报或不需要修改。换句话说助手的查全率明显高于人工虽然存在少量误报但因为输出格式带了原文摘录和涉及文件复核成本很低平均一条问题花 20 秒左右就能确认。5. 常见问题与排查技巧实录5.1 模型漏检和误检怎么处理漏检是这类工具最让人头疼的问题因为用户不会因为你查出了 20 个问题就满足他们更在意的是你没查出的那 1 个是不是致命的。我用了一段时间后发现漏检主要有两个原因。第一是提示词里的检查项不够具体模型会觉得“这个方面不太重要”就跳过了。解决方法是把检查项写得非常细甚至带上一两个反面示例。第二是输入文本太长模型处理长文本时对中段内容的关注度会下降。解决方法是把资料包拆成两个批次检查比如详情页和 SKU 清单一批质检报告、授权书和售后说明一批最后合并结果。误检的原因则比较集中模型会把“功能描述”误判为“功效宣称”。比如详情页写“大容量设计满足家庭收纳需求”这本身只是一个容量描述但模型有时候会认为这是“功效宣称”。针对这类误报我在提示词里加了一句“注意区分客观功能描述和功效宣称仅当宣称超出商品本身性能或无法从材料中验证时才标记”。加上这句话之后误报率下降了不少。5.2 长文本和上下文管理一次处理完整的资料包文本量经常在 10000 个 token 左右加上提示词和输出一轮调用要消耗 12000 到 15000 个 token。虽然 Qwen3.8-Max 的上下文窗口够用但调用成本和响应速度都会随着 token 数上升。我发现有两个办法能明显降低消耗。第一个办法是预处理去噪。详情页文案里经常有大量重复的页面区块、导航文字、底部模板话术这些对审核没有帮助我会先用脚本清除这些噪音。第二个办法是分轮检查不要让模型在一轮调用里同时做所有事。我现在是先用规则初筛拿到预体检清单再让模型做全量检查最后再单独跑一轮二次追问。整个过程拆成了 3 轮调用相比一次超长调用总 token 消耗反而更低而且每一轮的输出质量都更高。尤其是二次追问那一轮不需要传完整资料包只需要传问题列表成本非常低。5.3 成本与速度的平衡说到成本我用 Qwen3.8-Max 的实际体验是单份资料包全流程跑下来总 token 消耗大概在 25000 到 35000 之间折合到单次调用成本可以接受。如果每天要处理 50 份以上的资料包那成本还是要考虑的。我的做法是加了一个简单的分级机制正常审核用标准模式跑全量检查如果是大促前临时上架只做快速模式跳过图片检查和二次追问只跑文本常规检查大概节省 40% 的 token。速度方面单份资料包全流程跑完大概 1 到 2 分钟。这个速度已经很理想了相当于你泡杯咖啡的时间机器就把之前一个下午的活干完了。如果遇到 API 响应变慢的情况我的排查经验是先看是不是输入文本里混进了大量重复内容把重复内容清理掉之后响应速度通常会恢复正常。5.4 结果不稳定和格式问题大模型每次输出的内容会有轻微差异但我在实际使用中更关注的是 JSON 格式稳定性和字段值稳定性。JSON 格式的问题通过 API 的 JSON 输出模式以及代码里的清洗兜底基本能解决。字段值不稳定主要体现在 severity 的取值偶尔会不一致比如有时输出 “high”有时输出 “High”。我的处理方法是做一步归一化统一转成小写并映射到三级标准在汇总统计时就不会乱。更实际的一个问题是不同批次的检查结果之间可能不一致。同样一份资料包今天跑和明天跑可能问题数量会有一两条出入。我一开始也纠结这个后来想明白了这些工具的核心价值是帮你发现需要关注的风险点而不是给你一个绝对精确的数字。所以我在终版报告里不会写死“27 个问题”而是标记“疑似问题 27 项已复核确认 24 项”。这样既保证了工具的实用性也给人工复核留出了合理的空间。我自己在实际使用这个助手时最深的感受是模型不是万能的它偶尔会误判、偶尔会漏检但它能在十几分钟内完成一次全量交叉审核已经帮我把效率拉高了不止一个量级。如果后续想把这件事做得更完善可以从两个方向扩展一是把二次建议直接接一个自动改稿的流程生成可编辑的商品文案让运营直接微调就能用二是引入历史批次对比比如记录每次审核的问题清单下次上架时自动检查上一轮的问题是否都解决形成闭环。这个工具本身不复杂真正值钱的是把审核经验变成可执行的检查逻辑这个过程。
