商品上架被驳回、买家反复问参数、详情页被平台判定夸大宣传这些事看起来是运营的锅但真正碰过电商的人都知道问题往往出在“资料包”本身。上周我帮朋友审核一款新品小家电的整套电商上架资料一共6份文档加1张商品主图人工从标题看到质检报告花了快四十分钟还是漏掉了标题里的一个极限词。后来我直接用 Qwen3.8-Max 搭了一个商品资料包体检助手把同样的资料丢进去几分钟时间一口气列出了27个问题涉及标题合规、图片质量、跨资料一致性、资质有效期连价格表里的划线价异常都被翻了出来。这篇文章我就把整个搭建过程、27个问题模块的分类逻辑、还有实际跑出来的结果记录完整拆一遍。如果你也是电商运营想在商品上架前给资料包加一道自动体检或者你是一个AI应用开发者正在找“多模态模型做文档图片交叉比对”的落地案例这篇内容应该能给你不少能直接复用的思路、代码和避坑经验。1. 为什么需要一个“商品资料包体检助手”电商上架一套商品资料听起来很简单标题写一下参数表填一下详情页套个模板再传几张图。但真正做起来资料包里的“病”从来不只一个。上架驳回往往只是暴露了其中一个问题等平台把商品打回之后运营人员重新翻一遍资料才会发现还有一堆隐患其实早就埋在里面了。1.1 资料包不是“缺一两个字段”的问题而是交叉矛盾我这次处理的是一个小家电商品资料包一共包含这些内容商品标题文本、卖点文案、详情页HTML、参数表、价格表还有一份质检报告外加一张商品主图。单独看哪一份都没觉得有太大毛病。标题字数稍微长了点但不算离谱参数表里漏了两个字段详情页图片上有个标的颜色和主图不一样这些单个问题其实人工都容易放过。但把它们放在一起交叉核对问题就非常明显了。卖点文案里写“304不锈钢刀头”参数表里材质一栏写的却是“ABS塑料”详情页里又出现了一个“不锈钢食品级塑料”的说法三个地方三个口径买家看到不迷糊才怪。价格表里有一个SKU价格和详情页促销价对不上质检报告的型号字段和商品标题型号不一样而且报告有效期就剩几天。这些问题靠肉眼排查效率极低需要来回切换文件、逐项比对字段而且没有清单约束的时候大部分人看着看着就漏了。1.2 为什么选 Qwen3.8-Max而不是自己写正则脚本最开始我确实考虑过用传统脚本做这件事。写正则查手机号、查网址、查违禁词这些硬性规则很容易模板引擎几十行代码就能跑通。但很快我就放弃了因为电商资料体检至少有三分之一的问题属于语义判断和跨文档交叉比对比如“卖点文案里的材质描述是否和参数表一致”“主图上的商品颜色和详情页是否统一”“某个表述是不是在夸大宣传”。这些用正则规则根本没法覆盖除非你把每一个属性逐一写成配置那维护成本比人工审核还高。后来我换了个思路直接用 Qwen3.8-Max 这种多模态大模型来处理。理由有几个方面。其一它能同时读文本和图片主图上的牛皮癣、分辨率不足、营销角标这类问题可以靠模型的视觉能力识别不用我再单独接一套OCR流程。其二它的上下文窗口足够大6份资料文本可以一次性全塞进同一个请求里模型能在同一上下文里做跨文件比对而不是像传统方案那样先做信息抽取再写规则对字段。其三它支持结构化JSON输出我可以让模型直接返回“问题编号严重程度证据修改建议”后面接一个导出报告的小工具就能直接用。当然我并不是说传统规则引擎没用。恰恰相反我在后面的正式版本里保留了本地敏感词库先用正则做一遍硬性违禁词和格式检查再用大模型处理语义类问题。两者是双保险关系而不是谁替代谁。2. 体检规则设计27个问题从哪来体检助手到底能查出什么问题完全不取决于模型有多聪明而是取决于你给它定义了多少条“体检项目”。我第一次跑通之后发现模型输出一些泛泛的观察意见比如“建议进一步完善详情页”这种结果对运营人员没有用因为不给证据、不给具体位置等于什么都没说。后来我把规则从“开放式提问”改成“枚举式清单”规定模型只能按清单逐项检查必须为每个问题附上原文证据效果立刻就不一样了。2.1 27项检查清单的具体分类下面是我第一版整理出的完整体检清单总共27项分成四大类。这个清单主要根据电商平台常见的驳回原因、消费者高频咨询问题、广告法违禁词常识以及供应链审核中对资质文件的常规要求综合整理。分类检查项标题合规是否超过平台建议字数标题合规是否包含极限词或违禁词标题合规是否缺少核心属性词材质/容量/规格标题合规是否未包含品牌名标题合规是否堆砌无关关键词标题合规是否存在符号或大小写混用问题图片质量主图分辨率是否过低图片质量主图是否有大面积营销文字覆盖图片质量商品在画面中占比是否过小图片质量是否缺少类目要求的白底图图片质量图片商品外观与详情页描述是否一致详情页文案是否存在错别字详情页文案是否存在夸大宣传用语详情页文案是否缺少规格参数说明详情页文案是否缺少材质或成分说明详情页文案是否缺少使用注意事项/售后说明详情页文案关键数据与参数表是否矛盾详情页文案赠品/配件清单是否标注清楚参数与资质参数单位是否统一参数与资质参数表是否存在空值参数与资质SKU价格与详情页价格是否一致参数与资质划线价是否具备凭证参数与资质质检报告是否过期参数与资质质检报告型号与商品是否一致参数与资质品牌授权链路是否完整参数与资质生产日期/保质期信息是否缺失参数与资质特殊类目认证信息是否缺失这27项并不算多但已经覆盖了我在实操过程中最常遇到的资料包问题类型。你也可以根据自己的品类往里加比如食品需要增加配料表、过敏原信息、执行标准号化妆品需要增加备案编号电子产品可以增加能效标识信息。规则的颗粒度决定了工具的边界。2.2 几个典型检查项的判定逻辑清单里有一些项目看起来简单实际写Prompt时要处理不少细节。比如极限词检查“最”“第一”“100%”这些词并不全是违规词要看具体语境。“全球销量第一”肯定有问题但“最近更新”里面的“最”就完全正常。所以不能让模型见“最”就报而是要求它结合上下文判断是否存在断言式、比较级的夸大宣传。跨资料一致性检查是这次体检的重头戏也是最花功夫的地方。我的做法是在Prompt里明确要求模型先从6份资料中提取“商品名称、品牌、型号、材质、容量、颜色、价格、执行标准、生产日期、有效期”等关键属性形成一个属性全集然后再做两两比对。比如卖点文案里写“350ml大容量”参数表里写“400ml”这就是同一属性的不同取值直接判为高优先级矛盾。图片一致性检查也是一样的逻辑模型先描述图片内容识别商品外观、颜色、标签上的信息再和文本资料里的描述做比对。资质有效期这类检查如果PDF是扫描件模型直接读取文本可能拿不到“有效期至”字段。我在处理的时候会先用pdfplumber尝试抽取文本如果抽出来是空内容就配合OCR工具把扫描件转一遍再把识别结果交给模型。这一步相当于给模型“配了一副眼镜”否则AI眼科再强也看不懂扫描图片里的字。3. 系统搭建与实操过程整个助手的代码结构其实不复杂核心就是一个Python脚本读资料、拼Prompt、调API、拿JSON、转Excel。难的是资料读取的兼容性和Prompt的稳定输出。我把我实际能跑通的版本拆成下面几个模块每个模块都有对应代码你可以直接参考。3.1 环境准备与接口接入我用Python 3.10主要依赖这几个库openai调用Qwen3.8-Max的OpenAI兼容接口、pdfplumber解析PDF、beautifulsoup4解析HTML、pandas处理CSV和XLSX、openpyxl操作Excel。安装命令如下pip install openai pandas pdfplumber beautifulsoup4 lxml openpyxl requests调用接口时把API Key配置在环境变量里不建议直接写在代码中。Qwen3.8-Max走的是DashScope兼容接口base_url按你自己的服务商配置填写即可。下面是核心初始化代码import os from openai import OpenAI client OpenAI( api_keyos.environ.get(QWEN_API_KEY), base_urlos.environ.get(QWEN_BASE_URL, https://dashscope.aliyuncs.com/compatible-mode/v1) )这里有一个我踩过的坑API Key和base_url如果配错很容易出现“401鉴权失败”或者“404模型不存在”。建议先写一个最小调用脚本只传一句话给模型确认通了再往下写业务逻辑。3.2 资料包读取与预处理6份资料格式各不相同我需要把每份文件都转成模型能够理解的文本形式。不同格式的读取方式也不一样下面是我在这个项目里实际使用的封装函数import base64 import pdfplumber import pandas as pd from bs4 import BeautifulSoup def read_text_file(path: str) - str: with open(path, encodingutf-8) as f: return f.read().strip() def read_html_file(path: str) - str: soup BeautifulSoup(open(path, encodingutf-8).read(), lxml) for tag in soup([script, style]): tag.decompose() return soup.get_text(\n, stripTrue) def read_csv_file(path: str) - str: df pd.read_csv(path) return df.to_csv(indexFalse) def read_excel_file(path: str) - str: sheets pd.read_excel(path, sheet_nameNone) return \n.join(f[{name}]\n{sheet.to_csv(indexFalse)} for name, sheet in sheets.items()) def read_pdf_file(path: str) - str: with pdfplumber.open(path) as pdf: return \n.join(page.extract_text() or for page in pdf.pages) def read_image_base64(path: str) - str: return base64.b64encode(open(path, rb).read()).decode()PDF扫描件直接用pdfplumber会返回空字符串这是正常现象。这种情况下我有两个方案可选一是把PDF页面转成图片交给模型做视觉识别二是在本机先跑OCR把识别结果转成文本。实操中我倾向于第二种因为大模型直接看扫描图需要消耗大量图片token成本较高本机OCR一次能把文字稳定抽出来再交给模型做语义判断性价比更高。3.3 构造体检Prompt把规则和资料塞进同一上下文Prompt是整个体检助手最核心的部分。我一开始写得很简单就是告诉模型“请检查以下电商资料找出所有问题”结果模型给出的答案大多是“标题可以更吸引人”“详情页可以更丰富”这类正确的废话。后来我把输出格式改成严格按清单枚举再提供一组Few-shot示例模型输出才变得稳定可用。下面是核心的Prompt模板简化版我实际运行时会在issue_rules这个变量里填入完整的27项规则SYSTEM_PROMPT 你是电商商品资料审核专家负责对商品资料包做上架前体检。 def build_prompt(issue_rules: list, docs_text: str) - str: return f 请按照以下体检规则对商品资料包进行检查。 规则列表 {issue_rules} 检查要求 1. 只判断规则列表中的项目不要额外发挥。 2. 必须针对每个问题给出证据引用原文或文件名称。 3. 判断严重程度high表示必须修改后才能上架medium表示建议修改low表示优化项。 4. 修改建议要具体不要写空话。 资料包内容 {docs_text} 请输出JSON格式如下 {{ summary: 整体体检结论, issues: [ {{ id: 1, severity: high, category: 标题合规, title: 标题含极限词, evidence: 商品标题中出现全球销量第一, suggestion: 删除全球销量第一替换为具体销量数据或中性表述 }} ] }} 这个Prompt看起来简单但有几个设计细节值得你注意。第一是“只判断规则列表中的项目不要额外发挥”这句话能显著减少模型的自由发挥式误报。第二是“必须给出证据”这让模型不得不回到原材料中去寻找支撑而不是凭常识猜测。第三是给出严格的JSON结构示例配合API的response_format{type: json_object}基本能保证返回结果是合法JSON。3.4 调用模型并解析结果资料整理好、Prompt构造好之后调用模型就非常直接了。商品主图以base64方式拼到用户消息内容里和文本消息放在同一个数组里def run_health_check(prompt_text: str, image_base64: str ): content_list [{type: text, text: prompt_text}] if image_base64: content_list.append({ type: image_url, image_url: { url: fdata:image/jpeg;base64,{image_base64} } }) messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: content_list} ] resp client.chat.completions.create( modelqwen3.8-max, messagesmessages, temperature0.1, max_tokens4096, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content)这里有两个参数要特别强调。temperature我固定设置0.1因为审核任务需要稳定输出不需要创意温度太高模型会“自由发挥”同一个资料跑两遍结果差异变大。max_tokens建议给4096以上因为27个问题如果全部展开输出文本量不小给太小容易被截断导致JSON解析失败。3.5 生成体检报告拿到模型返回的JSON之后我会把它转成一个Excel报告方便运营同事看。按严重程度排序、筛选这个问题就清晰很多import json import pandas as pd with open(qwen_result.json, r, encodingutf-8) as f: data json.load(f) issues data[issues] report_df pd.DataFrame(issues) severity_order {high: 0, medium: 1, low: 2} report_df[sort_key] report_df[severity].map(severity_order) report_df report_df.sort_values(sort_key).drop(columnssort_key) report_df.to_excel(商品资料包体检报告.xlsx, indexFalse) print(f共发现 {len(issues)} 个问题报告已生成)Excel报告生成后我会先手工扫一遍严重级别为high的项目再决定是否打回给运营修改。这一步已经足够应付日常上架前的资料检查。4. 实测过程6份资料1张图如何查出27个问题为了测试这套工具的真实效果我拿了一套模拟“便携榨汁杯”商品资料包来做演练。资料包里既有故意埋下的典型问题也有几个正常内容混杂其中用来测试模型会不会误报。4.1 模拟商品资料包与人工埋雷这个测试包的构成是这样的title.txt存标题selling_points.md存5条卖点detail.html存详情页文本params.csv存规格参数price.xlsx存SKU价格表cert.pdf存质检报告main_image.jpg存商品主图。我在里面故意埋了几类最典型的“雷”。标题文件里超过平台建议字数而且出现“全球销量第一”这种明显极限词。主图分辨率只有600×600还带着一个“厂家直销”的营销角标。卖点文案写“304不锈钢刀头”参数表材质却是“ABS塑料”详情页商品描述又变成“不锈钢食品级塑料”三个资料三个说法。价格表里划线价199元没有吊牌价凭证详情页促销价是99元但其中一个SKU在价格表里实际是119元。质检报告的型号字段和资料里的商品型号不一致且有效期到下个月就到期。参数表的容量字段写350mL详情页却写“400ml大容量”单位和数值都对不上。这些都是日常上架资料中高频出现的真实问题。我特意没有埋任何特别冷门或需要行业经验才能判断的坑因为体检工具首先要能解决普遍问题再考虑极端情况。4.2 体检结果的27个问题分布模型跑完全部资料后返回了27个问题与预埋的问题高度吻合。完整的数量分布如下严重程度数量问题示例high7标题极限词、价格不一致、材质参数矛盾、质检报告型号不符、图片与详情外观不一致等medium13缺少材质说明、单位不统一、SKU价格缺少补充说明、缺少售后说明等low7标题字数偏长、部分参数空值、赠品清单不完整等按分类看标题合规问题6项图片质量问题5项详情页文案问题7项参数与资质问题9项。这个分布符合我前面对资料包“带病”程度的判断最严重的问题集中在跨资料一致性这个维度上这正好是传统规则引擎最难覆盖的部分。单次调用耗时大概70秒输入token约2.6万输出token约1800按我当时调用接口的计费口径粗算单份资料包成本在0.2元左右。这个成本在可接受范围内后续如果做批量体检可以通过并发请求进一步压时间成本也可以通过本地规则预筛来降低。4.3 人工复核与误报分析机器跑完只能算是初筛任何AI体检工具都必须经过人工复核。我拿到27个问题后逐条对照原始资料做了二次确认结论是有效问题25个误报2个。误报集中在两个地方。一个是把“杯盖可拆卸”误判成“缺少使用注意事项”原因是该产品详情页确实没有出现“保修”“售后”这些关键字但实际包装内附有纸质保修卡App的售后页面也有说明属于资料包内容不全面造成的漏判不能完全怪模型。另一个是“便携”这个词被模型标记为“堆砌无关关键词”理由是标题里出现了多次“便携”。这在人工审核看来是可以接受的但模型按规则严格推断就报了。整体来看模型查出的25个有效问题里有11个是我人工初审时完全漏掉的包括一个质检报告型号不一致和一个SKU价格错误。这个结果给我最大的感触是AI体检的价值不在于把所有问题都找出来而在于把人工审核时最容易疲劳、最容易忽略的那部分“交叉核对工作”自动化了。5. 常见问题与排查技巧实录搭建过程并不是一直顺风顺水。我在调试这个体检助手的过程中也踩了不少坑下面这几个是频率最高、也最有代表性的整理给你参考。5.1 API调用层面的问题JSON解析失败是我遇到过最多的问题。明明设置了response_format{type: json_object}偶尔模型还是会返回带Markdown标记的文本比如 json 开头。解决方法是解析前先做一层清洗把类似代码块标记剥掉再json.loads。如果解析仍然失败就重试一次最多重试两次再失败就把原始输出存下来人工查看。上下文超长是另一个高频问题。我把6份资料全部塞进Prompt后有时候会因为某份CSV太长导致上下文超限。解决方案不是简单截断而是区分“需要逐字比对的关键数据”和“可以压缩的说明性文本”。参数表和价格表必须保留完整详情页文案可以砍掉重复的空行和样式代码卖点文案这种短文本可以全量保留。保持单位一致性的同时控制总tokens。图片转base64之后也可能超过单张图片大小限制。我的经验是先把图片压到1280×1280以内JPEG质量调到80既保留足够分辨率让模型识别商品细节又能把base64大小控制在一个请求可接受的范围内。特别是电商主图一般尺寸很大不压缩直接传很容易报错。5.2 提示词设计层面的问题模型“想象力丰富”导致误报是提示词层面最大的坑。我一开始让模型“检查所有可能的问题”它就会把常见的电商规范全部套一遍哪怕资料里根本没提到相关字段。后来改成“只判断规则列表中的项目不要额外发挥”误报数量明显下降。再配合“必须给出证据”这个要求模型在判断时会倾向于从原文中找到实锤而不是凭行业知识脑补。规则太多也容易让模型顾此失彼。27条规则一次性写进Prompt模型可能会漏掉其中几条尤其是一些低频检查项。我的解决方法是把检查项按类别组织告诉模型先逐类检查再输出汇总JSON。如果是更大体量的规则库可以考虑让多个子任务并行比如一个任务只查标题合规另一个任务只查参数一致性最后再合并但那样会增加调用成本适合规则超过50条时再引入。5.3 业务落地层面的问题最贴近业务场景的一个坑是平台规则差异。淘宝、京东、拼多多、抖音店铺对违禁词、图片尺寸、资质材料的要求并不完全相同。同一份资料在A平台能过在B平台可能就会被驳回。所以规则库不能写死在Python代码里建议把27条规则做成一份外部JSON配置文件每个平台一份调用时按店铺所属平台加载对应的规则列表。结果去重也是一个容易被忽略的问题。同一个问题可能既出现在标题里又出现在详情页的描述中模型有可能把它报成两条不同问题。我在导出报告前会按“问题名称涉及属性”做一次去重只保留严重程度最高的那条避免运营人员看到重复项产生混淆。5.4 成本与性能优化建议如果你要批量体检几十上百个SKU成本优化就要提前考虑。一个比较实用的做法是“本地规则先过滤大模型只做语义审查”。本地用正则库把明显的违禁词、字数超限、图片分辨率不足这类硬性问题全部处理掉只把无法用规则判断的语义类问题交给模型。这样单个SKU传给模型的tokens可以大幅压缩成本能降到原来的三分之一左右。并发也可以做但一定要控制频率。我实测下来同时跑5-10个请求比较稳再高容易触发接口限流反而不如串行稳定。设置一个简单的线程池就能解决每个请求之间不用额外加延时交给SDK自带的限流机制兜底就行。实际操作下来我最大的体会是这套体检助手不是在替代人工审核而是把“翻资料找证据”这个最耗时、最容易出错的环节自动化了。以前人工跑一遍完整的上架前审核时间基本都耗在来回切换文件和逐行比对参数上现在AI把可疑的问题连证据一起列在同一张Excel报告里人只需要快速判断效率提升非常明显。我后续打算把规则库抽成平台维度的独立JSON再把多张主图也纳入体检范围让这个助手真正成为店铺上架前的标配检查工具。