1. 项目背景为什么商品资料包需要“体检”1.1 资料包到底长什么样做电商运营和商品管理的朋友应该都有这种体验一个新品要上架手里会攒出一大堆资料。标题表、SKU规格表、卖点文案、质检报告、包装信息、竞品对比再加上一张或几张商品主图零零散散散落在邮箱附件、网盘目录、微信传输记录里。多数团队的现状是——这些文件有人建、有人传、没人核对。我这次拿到的这包资料就是一位做家居日用品运营的朋友发来的结构挺典型的资料1商品基础信息表包含标题、品牌、类目、卖点关键词。资料2SKU规格参数表包含每个SKU的价格、库存、条码、规格参数。资料3详情页营销文案也就是准备投放到商品详情页的那段宣传文字。资料4合规资质文件包括质检报告扫描件、品牌授权书。资料5包装信息表包含包装尺寸、生产日期、包装上的信息标注。资料6竞品对比表用来做卖点对标和定价参考的表格。附件1张商品主图就是准备做主图的那张JPG。这些资料单独看都“还行”但一旦放到一起问题就全暴露了。我数了一数这次一次性查出27个问题里面真正要命的不是错别字而是多份材料之间互相打架。1.2 人工审核的真实痛点以前这种资料包审核靠什么靠运营和编辑肉眼一张张看、一个个字段对。听起来不复杂但实际做过的人都知道有多折磨。一是跨文件比对非常容易漏。标题里写了“加厚加大”竞品对比表里对标的是“标准款”SKU表里又只有常规尺寸这三份文件如果不是同一个时间版本很少有人会逐字比对它们之间的措辞差异。二是合规问题靠人记不住。平台对“最”“第一”“国家级”这些词有多敏感老运营知道新人未必知道。更别说授权书有效期、品牌名称写法、条码格式这些细节一次审核要看几十项漏掉太正常了。三是审核结果没有沉淀。今天人工查出3个问题改了明天另一个平台要用同一套资料又得重新审一遍。没有标准化规则经验就永远只是个人经验变不成团队能力。所以我想的很清楚与其继续在“人工打补丁”这条路上熬不如把检查环节做成一件事——让模型当体检医生我只需要把资料包扔进去它把问题清单报出来。1.3 为什么选大模型而不是传统规则脚本有人可能会问这种一致性比对、合规词检测用Python写规则不就行了确实一部分可以比如“标题是否超过60个字符”“条码是否为13位”“授权书是否过期”这类强规则脚本处理又快又准。但另外一大部分规则脚本搞不定。举个例子。详情页文案写“采用加密压缩工艺强度提升50%”质检报告里实测数据写的是“抗压强度提升45%”。这种“文案宣称和检测报告数据不一致”的问题传统规则根本没法自动识别因为两个数字出现在完全不同的句式里字段名也不对应。但大模型能它读得懂语义知道“强度提升50%”和“抗压强度提升45%”在说同一件事。再比如竞品对比表里写的竞品名称和授权书里出现的商标名称不完全一致规则脚本只能做字符串匹配匹配不上就放弃了。而大模型可以根据上下文判断“这俩指的是同一个东西只是一个写了全称一个写了简称”。所以我的结论是规则脚本做硬校验大模型做软理解两者结合才是最稳的方案。Qwen3.8-Max在这个场景里的定位不是替代规则而是补上规则覆盖不到的那一层语义比对能力。2. 整体方案设计一个体检助手该有哪些模块2.1 从“查问题”倒推功能拆解既然目标是“一次查出27个问题”那就得先想清楚这些问题是从哪几个维度查出来的我把体检维度拆成四层第一层基础完整性检查。必填字段有没有缺失资料包里有没有空文件、占位文件资质附件是不是图片冒充PDF这些属于拿到资料包第一步就能做的事。第二层格式规范检查。标题长度、条码位数、日期格式、图片尺寸分辨率这些都有硬性标准适合用程序化的规则直接跑。第三层跨文件一致性检查。同一商品的标题、详情页文案、规格参数表、竞品对比表四个文件里的品牌名称、核心卖点、价格区间、参数数值是否一致。这一层是工作量最大的也是人工最容易漏的。第四层合规风险检查。营销文案有没有触犯广告法的高风险词授权资质有没有超出有效期主图上有没有出现未授权的LOGO或者二维码水印。这四层检查合起来就是体检助手的整体功能范围。项目一开始就按这个结构来设计模块后面每加一个体检项都能落到具体的层级里不会乱。2.2 技术选型为什么是 Qwen3.8-Max选型这件事我其实纠结过一阵。当时摆在面前的有几条路直接用现成的文档比对工具用传统NLP方案或者用大模型。最后选了 Qwen3.8-Max主要看重它的三点一是上下文长度够用。一个资料包里的6份文件转成文本之后多的时候能到几万字。Qwen3.8-Max的上下文窗口能撑得住完整输入不需要把一份文件拆成好几段再分别送进去这对保持全局一致性判断非常重要。上下文窗口不够的话模型很容易“只见树木不见森林”看到后面忘了前面。二是指令遵循能力强。体检助手这个场景本质上是让模型按照一套固定规则去审查材料输出结构化结果。我实测下来Qwen3.8-Max对Prompt里的输出格式约束响应得比较稳定让它输出JSON就输出JSON让它逐条列问题就逐条列不太会自由发挥。三是部署和调用成本可控。对于一个内部工具来说成本是不能不考虑的因素。Qwen3.8-Max这个档位的模型单次调用费用完全在可接受范围内即使后面把全店商品资料包都跑一遍预算也不会爆。当然如果你手头用的是其他同级别的模型整个方案思路也完全适用。这个项目的核心不在“非某个模型不可”而在于怎么把体检规则设计好、Prompt组织好。模型只是执行引擎。2.3 整体流程与数据流转整个体检流程我拆成六个环节文件接收上传6份资料和1张商品图到指定文件夹。格式解析Excel转成结构化表格数据PDF抽取文字和表格图片做OCR或者直接交给多模态模型读取。规则预检用Python脚本跑第一轮硬性检查——必填项、长度、格式、日期等这部分不消耗模型调用。模型深度比对把六份资料的文本内容组织成一份结构化的“检查工作台”连同检查规则一起交给 Qwen3.8-Max让它逐项核对。结果聚合把脚本发现的问题和模型发现的问题合并去重按严重程度分级。生成报告输出一份问题清单每条包含问题描述、涉及文件、修改建议。实际跑下来一轮完整体检耗时不到两分钟其中大头在模型推理规则预检基本是秒出结果。这个速度已经能覆盖大批量商品的日常巡检需求了。2.4 27个体检项怎么来的说实话“27个问题”不是一开始就规划好的数字。我先列了一份常见的检查点大概五六十项然后根据这次实际的数据做了收敛去掉了那些在当前资料包里不适用或者重复的项最后落到27项。这27项覆盖了我上面说的四个层级。我列个简表方便大家快速理解层级典型体检项举例完整性必传文件缺失、空文件占位授权书文件夹里只有一个空PDF格式规范标题超长、条码位数不对SKU条码只有11位一致性同字段跨文件冲突标题写“加大号”规格表里没有该尺寸合规风险违禁词、资质过期、图片违规文案含“质量最好”授权书已过期体检项不是固定的不同类目、不同平台的规则差异很大。所以我在设计的时候把每个体检项做成了可配置的加一条规则就是往配置文件里加一行不需要改代码。这也是这个项目能持续用下去的关键——工具要跟着业务规则走不能业务规则跟着工具走。3. 核心实现解析、抽取、比对、判责3.1 文件解析层Excel、PDF、图片怎么处理文件解析是整个流程的第一步也最容易被低估。我这次实际踩了几个坑先说结论Excel解析用pandas就够但要注意多Sheet的情况。SKU规格参数表经常有多个Sheet页一个Sheet放商品信息一个Sheet放价格库存还有一个Sheet放包装参数。直接用pd.read_excel()只能读到第一个Sheet必须先把Sheet名全部列出来定位到真正有数据的那个Sheet。我这次的资料包就是这样SKU数据藏在第三个Sheet里名字叫“明细”前面两个Sheet反而是空模板。PDF解析得分情况。质检报告这类文件如果是印刷体文字版PDF用pdfplumber抽取文字和表格效果不错如果是扫描件就必须走OCR。我这次碰到的质检报告是扫描件直接用文字抽取什么都拿不到后来加了一层OCR才把关键数据捞出来。OCR这块我用的是本地OCR方案识别中文印刷体效果足够关键是数据不出本机安全性也更好。商品主图处理分两条路。一条是纯规则——用PIL检查图片尺寸、分辨率、格式、是否有水印区域这些信息直接可读另一条需要模型参与——图上有没有出现违禁词、有没有不合规的营销语、LOGO是否清晰可辨这些需要把图片喂给多模态模型来识别。我是两条路都走规则查硬指标模型看内容。解析层所有产物统一处理成文本和结构化数据方便后面拼接Prompt。这里有一个经验解析出来的表格不要丢列名列名是模型理解表格含义的关键线索。如果只保留数据行不保留表头模型很容易猜错每个字段是什么意思。3.2 产品字段抽取先让模型“读懂”资料拿到文本之后第一件事不是直接让模型找问题而是先做一轮字段抽取。为什么要多此一举因为直接问“这份资料包有什么问题”模型给出的答案往往是零散、片面的可能只盯着某一份文件看遗漏其他材料。但如果先让它把商品的关键信息抽成一张统一的“商品事实表”再拿这张表去做交叉比对效果会好很多。我这边的做法是让模型从全部资料中抽取以下字段商品名称、品牌、类目核心卖点词及出处规格参数尺寸、重量、材质、容量等价格体系前台价、活动价、成本价资质信息证书编号、有效期、授权品牌包装信息包装尺寸、生产日期、条码输出格式是JSON。比如抽取结果的片段是{ brand_aliases: [某某生活, 某某家居], main_selling_points: [ {content: 抗菌率99.9%, source: 详情页文案}, {content: 容量提升50%, source: 标题} ], specs: { color: 白色, size: 加大号, material: 食品级PP } }这一步的实际价值是把分散在不同文件里的信息统一到一个结构里后续不管是做字段比对还是合规审查模型需要处理的数据量都小了很多输出质量也更稳定。3.3 交叉比对同一商品在不同文件里的口径是否一致交叉比对是查出“27个问题”里占比最高的部分也是最能体现大模型价值的部分。传统脚本做交叉比对核心是字段映射——你得告诉程序“标题里的尺寸”和“规格表里的型号”是同一个概念才比得起来。但资料包里不是所有对应关系都这么明确。比如详情页文案写“加厚加硬”规格参数表里写的材质厚度是“5mm”标题里写的是“升级款”——这三者之间有没有矛盾脚本判断不了但模型能。所以我把交叉比对的Prompt设计成“声明式”风格不要模型自由发挥去找问题而是给它一组明确的比对任务。每个任务说清楚比对哪两个数据源、判断标准是什么。举个例子请比对以下两组信息是否一致商品标题中的尺寸描述XXL加宽款SKU规格表中的尺寸字段常规款非加宽判断标准标题、规格表、详情页文案三者中对同一属性的描述应保持一致。如果存在冲突请指出冲突双方及具体表述。这样做的优点是模型不会跑偏每条输出都能对应到具体的检查任务排查和追溯都很方便。我这次查出来的问题里有大约14个属于这类跨文件不一致包括标题强调“加厚”质检报告里厚度数据和常规款一样。竞品对比表里写的自身产品容量和SKU表里的规格对不上。包装信息表上的品牌名称和授权书上的商标名称差了两个字。详情页文案写出“含赠品”SKU表里根本没有赠品对应条目。价格体系里详情页文案宣传的到手价和SKU表活动价不在一个区间。这类问题如果靠人工找需要把六份资料打印出来铺在桌上一一对应非常耗时。模型做这件事优势不在“聪明”而在“耐心”——它不会因为文件多就看漏。3.4 合规审查把平台规则翻译成Prompt合规审查这部分我一开始也想得太简单了以为写几句“检查有没有违禁词”就行。后来发现合规检查的本质是“把平台的规则库翻译成模型能执行的语言”这里面有不少门道。首先是违禁词识别。不能只给模型一个词表让它“查一下有没有”因为很多违禁表达不是唯一的固定词而是带有强烈主观评价色彩的句式。比如“质量最好”“性价比之王”“全网第一”词表匹配不了这类变体模型却能根据语义识别出来。所以我的Prompt里明确要求不仅要找出词表里的词还要找出“语义上属于绝对化承诺”的表述。其次是资质检查。授权书有效期这种硬规则其实直接用正则和日期比较就能做不一定要模型来。但“授权品牌是否与本次上架商品品牌一致”就需要模型判断了。我这次就查出一个问题授权书上的品牌是全称商品基础信息表里用的是简称从字符串角度完全匹配不上但语义上都指向同一个品牌。这种又属于模型的活。再者是图片合规。给模型传一张商品主图它可以识别出图上有没有出现明显的营销水印、二维码、未授权品牌LOGO。我这次检查商品图的时候模型给出提示“图片右下角疑似存在其他平台水印”后来人工确认确实是处理图片时残留的水印。如果不是专门查这张图大概率直接就被上传了。合规这块我的建议是能上规则就上规则规则解决不了的语义问题才交给模型。否则每次检查都让模型读一遍全部资料成本高不说还可能因为模型“太灵活”把合规的表述误判成违禁词。3.5 报告输出与问题分级所有问题查完之后最终要落到一份可执行的报告里。我这边输出的每一条问题都包含六个字段问题编号便于后续跟踪比如Q-01到Q-27。严重级别分为致命、严重、警告、建议四档。问题描述说清楚发生了什么冲突或缺失。涉及文件指出是哪份资料、哪个字段、哪一行。依据说明为什么这是问题引用的规则或标准是什么。修改建议给出具体的修复方向。分级标准也很直接致命问题影响上架或触犯法规必须解决严重问题会造成消费者误解或平台处罚警告问题属于规范性偏差建议类属于优化项。举一个具体的例子某条严重问题的记录是这样的Q-14 | 严重详情页文案宣称“容量提升50%”但SKU规格参数表中标注的容量为2L未找到可对比的“旧版容量”数据无法支撑50%的提升结论。涉及文件资料3详情页营销文案第2段、资料2SKU规格参数表第5行。建议补充旧版容量数据或修改文案表述。报告生成之后我会把它保存成Markdown文件方便在文档工具里直接查看和评论。如果后续要对接工单系统把输出格式改成JSON也不难。4. 实操实录用 Qwen3.8-Max 跑通一次完整体检4.1 环境准备和依赖先说环境。整个项目我用Python 3.10写的核心依赖如下pip install pandas openpyxl pdfplumber pillow这几个是基础解析库分别处理Excel、PDF和图片。如果你需要OCR支持还可以加一个OCR库不过我这里做的是先测试文字版PDF的可读性再决定是否启用OCR避免引入不必要的处理链路。模型调用方面因为Qwen3.8-Max我们是通过API方式接入的所以不需要本地部署模型几行代码就能把服务端的能力调到本地脚本里来比较适合快速做原型验证。如果你追求数据完全不出内网部署本地版本也是完全可以的只是体力活多一点。4.2 核心代码结构整个脚本我控制在三百行左右分成四个模块。这里分享核心的结构思路完整代码不建议直接抄因为每个人的资料结构不一样但框架可以复用。第一步读取和解析所有资料import pandas as pd import pdfplumber from PIL import Image def parse_excel(filepath): 读取Excel的全部Sheet返回字段名能保留的字典结构 sheets pd.read_excel(filepath, sheet_nameNone) parsed {} for sheet_name, df in sheets.items(): if df.empty: continue parsed[sheet_name] df.astype(str).to_dict(orientrecords) return parsed def parse_pdf_text(filepath): 抽取PDF中的文字和表格 pages_text [] with pdfplumber.open(filepath) as pdf: for page in pdf.pages: text page.extract_text() if text: pages_text.append(text) tables page.extract_tables() if tables: for table in tables: pages_text.append(表格数据) pages_text.append(\n.join([ | .join(row) for row in table])) return \n.join(pages_text)第二步把解析结果组织成Prompt输入。这里的关键是给每份资料编号、加标签让模型清楚地知道每段内容的来源def build_context(parsed_files): context_parts [] for file_id, info in parsed_files.items(): context_parts.append(f文件{file_id}{info[filename]}/文件{file_id}) context_parts.append(info[content]) return \n\n.join(context_parts)第三步调用模型。这里我把检查任务分成几类Prompt每一类对应一个检查维度每一类都会做一次模型调用。比如“字段抽取”一次、“交叉比对”一次、“合规审查”一次。def run_check(context, task_prompt, output_format): full_prompt f 你是一个电商商品资料包审查专家。 以下是需要检查的全部资料内容每份文件都有明确的文件编号标记。 {context} 请完成以下审查任务 {task_prompt} 输出要求{output_format} response call_qwen_model(full_prompt) return response第四步把模型返回的结果解析成结构化数据和规则脚本的检查结果合并生成最终报告。def merge_and_generate(rule_issues, model_issues): all_issues rule_issues model_issues # 按严重级别排序 level_order {致命: 0, 严重: 1, 警告: 2, 建议: 3} all_issues.sort(keylambda x: level_order.get(x[level], 99)) return format_report(all_issues)整个流程没有很复杂的逻辑真正花时间的是调试Prompt。我前前后后改了七八版才把输出的稳定性和准确率调到比较满意的程度。4.3 Prompt设计要点让模型当“审核员”而不是“作家”这次项目里最值得分享的是Prompt设计上的一些心得。不要把模型当API调就完事了要给它清晰的角色和工作流。我最初的Prompt只是列出资料内容然后问“有什么问题”结果模型给出的答案很泛像一篇总结报告没有可执行性。后来改成“你是电商商品资料包审查专家请按以下步骤逐项检查”效果立刻不一样了。检查任务要拆细一次只让模型做一类事。我一开始试图让模型一次性完成所有检查比如“请检查所有资料的完整性和一致性找出全部问题”。结果模型要么过度关注某一个方面要么就是平均用力但每个方面都查得不深。拆成“先做字段抽取再做交叉比对再做合规检查”三个独立任务后每一轮的精确度都明显提升。输出格式要给出明确的JSON结构并且附上一个小示例。模型对JSON并不陌生但不同模型对JSON的边界理解不一样。给一个few-shot示例能大幅减少输出格式不稳定的问题。检查标准要写在Prompt里而不是让模型自己发挥。比如“请检查品牌名称是否一致”这个描述太模糊。要改成“请对比资料1中的品牌字段、资料4授权书中的授权品牌、资料5包装信息表中的品牌名称三者指向同一商业主体时允许全称/简称差异但不得指向不同主体”。规则越明确误报越少。4.4 一次实测的结果长什么样跑完全部流程之后输出的报告开头是这样的共发现问题27项其中致命问题2项严重问题9项警告问题11项建议事项5项。27个问题的分布情况基础完整性查出3项。包括资质文件夹中有一个空PDF、竞品对比表中有一列数据为空、包装信息表缺少生产日期。格式规范查出5项。包括SKU条码不足13位、商品主图分辨率低于平台要求、标题超长、重量单位不统一、日期格式混用。跨文件一致性查出14项。这是问题重灾区主要集中在标题/详情页文案与规格参数表、竞品对比表之间的数据冲突。合规风险查出5项。包括“质量最好”这类绝对化用语、授权书有效期不足三个月、商品主图右下角残留水印、详情页文案出现竞品未脱敏名称、赠品信息在SKU中无对应设置。这27项里最让我印象深刻的是那条致命问题——竞品对比表里引用了竞品品牌的完整名称和型号参数。如果这张表被当作详情页素材直接使用不仅涉及侵权风险还会让店铺因为“贬低同行”被平台处罚。但这份表本身只是内部参考资料并不是最终对外素材所以实际危害没有那么直接但作为体检项必须标出来提醒运营在对外输出前再次确认。5. 常见问题与排查技巧实录5.1 模型误报太多怎么办这是第一个会遇到的问题。模型查出100个问题人工复核后一半是误报这种情况我见过不止一次。排查方向有两个先看Prompt里的判断标准是否足够明确。很多误报其实是因为判断标准有歧义。比如你让模型检查“价格是否合理”它没有明确标准只能凭感觉自然容易把正常价格当成异常。改成“价格是否超出同类目商品平均价格的合理范围具体范围为同行的0.5-2倍之间超出此范围请标出”误报率立刻降下来。再看是不是任务拆得不够细。如果让模型同时检查十个维度它很可能为了“完成率”而把可疑但不异常的内容也列出来。拆细任务之后每个检查项的职责清晰模型反而会收敛不那么发散。5.2 长文本截断导致漏检资料包内容多的时候模型容易受上下文长度限制如果Prompt里塞了太多内容可能会导致后面的文件内容被截断模型自然查不到问题。这个在项目里遇到过。解决思路是分级处理。不要把所有文件一股脑全塞进一个Prompt。先让模型对每份文件单独做关键信息抽取抽取结果通常比原文短很多再把抽取结果汇总在一起做交叉比对。这样既保留了对全局的视野又不会触达上下文上限。实测下来这个“抽取-汇总-比对”的三段式结构比直接灌长文本的效果稳定得多。5.3 模型输出格式不稳定十个问题里有一个输出格式不对整个解析流程就会断。这是大模型的通病但可以通过两件事来缓解一是在Prompt里明确输出JSON的结构和示例二是在代码里做容错拿到模型输出后用正则提取JSON片段即使用json.loads失败也不至于脚本崩溃而是把原文记录下来等人工确认。我这边每次调用都会保留模型原始回复的日志一旦解析失败可以快速定位是哪一轮出了问题。5.4 成本和性能怎么平衡大模型调用的费用是持续成本批量跑商品资料包的时候不能不计成本。我这边有一些实测经验规则前置能省下大量无效调用。像“必填项缺失”“条码格式错误”这类问题脚本就能查出结果完全不用让模型参与。我这次27个问题里有8个是脚本直接查出来的如果全让模型查费用至少贵30%。能一次查完的不分多次。如果上下文长度允许尽量把同一类检查任务合并成一次调用减少重复发送资料内容的开销。我的做法是字段抽取一次调用交叉比对一次调用合规审查一次调用三次调用覆盖全部27个检查项单次体检模型调用成本完全可以接受。缓存重复内容。同一个商品不同批次上传的资料包解析结果经常是重复的。我在解析层加了一个简单的哈希缓存内容没变的文件直接复用上次的解析结果不需要重新解析更不需要重新调模型。6. 把这套方案用在更多场景这个体检助手目前是命令行工具形态我后续把它做成了一件可以持续迭代的事而不是跑完一次就丢。一个自然的扩展方向是接入商品管理后台每次新商品资料上传时自动触发体检结果直接推送审核群。这样就不需要运营手动提交文件、手动运行脚本了整个上架前检查环节变成了自动化流程的一部分。再往后还可以加”体检项配置“的可视化界面让运营自己调整哪些检查项开启、哪些关闭不需要改代码。另一个方向是把这个思路复制到其他数据类型上。例如活动页面搭建前需要准备的图片、文案、价格表本质也是一种“资料包体检”直播带货前的主播口播稿和产品参数表之间也存在大量的信息一致性核对需求。处理过一次商品资料包之后就会发现“多份资料一份商品真相”的矛盾是这个行业里普遍存在的,大模型能做的其实是把“找不同”这件事从人的负担变成机器的职责。做这个项目最大的感受是Qwen3.8-Max这类模型真正改变效率的地方不是它能写出多么华丽的文案而是它能把以前需要人工逐字核对的工作变成一次能快速跑完的自动化流程。模型当然会误判规则脚本也会有漏洞但一台准确率90%的体检仪器加上一个复核的医生怎么都比只用肉眼一个一个文件翻要强。这套方案落地之后我第一时间把它用在了后续所有新品的资料包审查上光是节省出来的对比时间就足够值回开发投入了。