电商上架最怕的不是素材不够而是素材之间互相打架。标题写着一个卖点详情页吹着另一个功能SKU 表里少了一个颜色主图上的活动价和表格里的价格对不上——这些问题单个看都不大凑在一起就是差评、退货、平台处罚的导火索。我用 Qwen3.8-Max 搭了一个商品资料包体检助手把 6 份资料和 1 张商品图一次性丢进去第一轮跑完就查出 27 个问题。这篇文章不聊虚的直接讲清楚我为什么要做它、数据怎么整理、检查规则怎么定、代码怎么跑通以及过程中踩了哪些坑想用大模型做资料审核的同学可以直接抄作业。1. 上架前的资料体检为什么是电商运营最容易翻车的一环1.1 一次真实的资料翻车现场上个月我们有个新品要上架运营同学提前三天把资料包发到群里标题草稿、五点卖点、详情页文案、规格参数表、SKU 表、客服话术加上一张白底主图。看起来挺齐整结果审核的时候我发现规格参数表里写的是“保修期 1 年”详情页文案里却赫然写着“终身保修”。如果不是我多看了一眼这条详情页发出去售后那边接下来一整年都得为这句话擦屁股。这种问题不是个例。电商商品的资料包天然是碎片化的标题写在 TXT 里卖点存在 Word 里规格和 SKU 躺在 Excel 的不同 sheet 里客服话术又是另外一套文档。它们的共同特点是都由不同的人在不同时间维护没有人会专门做一次跨文档的交叉核对。人工核对当然可以做但一份资料包完整核对下来至少 30 到 40 分钟还得保持全程注意力在线稍微一走神最隐蔽的矛盾就从眼皮底下溜过去了。1.2 为什么我选 Qwen3.8-Max 而不是写死规则最开始我想过用正则表达式和关键词表硬写一套检查工具比如把广告法极限词拉一个表把必填字段列一个清单代码跑一遍就知道哪缺哪错。但试了之后发现这套方案能解决的只是最表层的问题。真正难查的是语义层面的矛盾规格表说材质是 60% 棉详情页说 100% 纯棉标题说支持 7 天无理由退货客服话术里却写着“定制商品不接受退换”主图上的商品是浅灰色SKU 表里却根本没有灰色这个选项。这些都需要理解上下文、对照不同语境的含义。Qwen3.8-Max 一次调用就能同时处理文本和图片具备很强的长上下文能力6 份资料整理完大概六七千 token一次全塞进去不成问题。更重要的是它的指令跟随能力和结构化输出表现稳定可以直接要求它按 JSON 格式返回问题清单。于是我就决定拿它搭一个“体检助手”目标是运营把资料包拖进来几分钟后拿到一份带严重程度分级、带修改建议的问题报告人只需要做最后复核而不是从零开始检查。2. 6 份资料是哪 6 份我先把素材整理成了模型吃得动的输入2.1 资料清单和每份资料的定位标题说的 6 份资料不是随便凑数的它们基本覆盖了一个商品从曝光到售后全链路会用到的文案数据。我拿手里的保温杯新品举例具体是这么六份资料原始格式主要内容商品标题草稿TXT主推标题 3 个、备用标题 2 个含关键词和卖点词五点卖点描述Word5 条核心卖点每条 10 到 30 字详情页文案Word模块化文案含参数承诺、使用场景、售后承诺规格参数表Excel材质、尺寸、容量、重量、保温时长、保修期SKU 表Excel颜色、容量规格、价格、库存、SKU 编码客服售后话术TXT售前咨询应答、售后问题处理模板这 6 份资料的字段并不完全重叠。规格参数表和 SKU 表看数据标题和卖点看文案详情页和话术看承诺口径。问题恰恰出在重叠的地方任何两个文档提到同一个信息价格、材质、保修期、颜色内容就必须一致而这个一致性的核对展开之后就是几十个对齐点。2.2 格式转换和文本重建比想象中更影响结果大模型读不了 xlsx 和 docx更读不了图片我得先把这些格式转成纯文本但转换方式直接决定模型能不能看懂表格的对应关系。Excel 文件我用 Python 的 pandas 读取转换时做了两个关键动作第一保留表头行把每一行转成“列名: 值”的格式第二保证空单元格也保留列名。举个例子SKU 表里有一行只有颜色没有尺码如果直接转成 CSV模型看到的就是一个空洞但如果转成下面的格式它就能明确知道是“尺码字段缺失”SKU编码: SKU-1001 颜色: 雾白 容量: 500ml 价格: 129 库存: 200 尺码: 空Word 文档的处理要轻一点只做纯文本提取但保留段落之间的顺序。详情页文案的每个模块都有小标题我会在小标题前后加换行让模型能看出文档的层次结构。所有资料塞给模型之前我在每份资料前面加一个醒目的分隔头和文件名比如 文档3详情页文案Word提取这样模型就不会把六份资料混成一锅粥答非所问。2.3 上下文长度怎么把 6 份资料全塞进去六份资料全部整理成文本之后我测了一下 token 消耗标题 300 多、五点卖点 800 多、详情页文案最长 2800 多、规格参数表 1200 多、SKU 表 1500 多、客服话术 900 多加起来 7500 token 左右再加上图片和系统提示词一次请求大概 1 万 token 上下。Qwen3.8-Max 的上下文窗口远够用所以我的方案是全部塞进一次请求不做拆分。但这里有个前提详情页文案如果特别长比如超过 5000 token我会先把每个模块压缩成两三句话的摘要再组合进消息而不是截断丢掉。截断会让模型看不到尾部信息漏报率会明显上升。因为要检查一致性摘要不能只留第一句我会把涉及参数、承诺、价格、材质、日期等关键词的句子原样保留其他修饰性内容才做压缩。3. 27 个问题是怎么被发现的检查清单和提示词设计3.1 检查维度我收敛成了四大类体检助手要检查什么决定它能不能查出真问题。我一开始也犯过贪多的毛病让模型“自由发挥找问题”结果它找出来的问题五花八门有的太宏观比如“营销策略需要调整”根本没法落地。后来我把检查收敛成四大类让模型按类别逐项过一致性类跨文档核对同一信息。规格表说 500ml详情页说 550ml这就是一致性问题。材质、容量、价格、保修期、颜色、发货时间、退换货政策全部拉出来四处对齐。合规类检查广告法相关风险。绝对化用语、虚假承诺、夸大宣传比如“最便宜”“100% 纯天然”“终身保修”这种。完整性类必填字段和必述项是否缺失。SKU 表有没有缺价格、缺库存、缺颜色详情页有没有漏掉材质说明、使用警示标题有没有漏掉核心品类关键词。匹配类图片与文字之间的对应关系。主图上出现的价格、规格、颜色是否和 SKU 表一致图片里标注的卖点有没有在五点描述里出现。3.2 提示词的核心结构直接决定输出质量提示词我迭代了三四版最后固定成五段式结构角色设定、任务说明、检查清单、输入数据、输出格式要求。这五个部分缺一不可尤其是角色设定。最初我把角色写成“你是一个文本检查助手”输出结果很干涩很多委婉的口语表达它不当回事。后来改成“你是一名拥有 10 年经验的电商平台商品合规审核专家擅长在跨文档信息中定位不一致之处审核风格严格、细致、不留情面”误报率没上升但真正的问题检出率明显提高。角色设定本质上在调节模型判断问题的“阈值”严格的人格设定会让它把潜在的矛盾也标出来。任务说明要告诉模型不能自由发挥。我明确要求只检查给定资料中存在的确定性问题不推测、不补全、不给出优化建议之外的内容。这句话非常关键否则模型会给自己加戏告诉你“详情页文案可以更生动”这完全不是我们要的。输出格式要求是 JSON 数组每个元素包含这样几个字段{ problem_id: 1, document: SKU表, category: 完整性, severity: P1, issue: 颜色浅灰在规格参数表的可选颜色列表中没有对应SKU, locations: SKU表第4行, suggestion: 补充浅灰色的SKU条目或在规格参数表中删除该颜色 }为了让模型稳定输出这种结构我在提示词里加了两个 few-shot 示例。经验是示例里的问题类型最好覆盖跨文档不一致和单文档违规两种模型会照着示例的详略程度来组织答案。3.3 为什么要用 JSON 格式而不是直接聊天很多人会问既然要让模型查问题直接让它“把问题说出来”不就行了不行。自由文本格式有几个麻烦一是问题描述容易掺杂主观评价机器没法直接归类二是后续没法做严重程度排序和自动生成报告三是模型经常把“没问题”的文档也强行凑几条无关紧要的观察干扰复盘。我要求它必须输出结构化 JSON并且每条问题必须带确切的出处文档名、行号或字段名没有问题的文档就让它输出空数组。这样我能直接在代码里统计 27 个问题按类别、按严重程度的分布也能直接拼成一张报告表格给运营看不用人肉再从一大段文字里摘信息。4. 从一条 API 到一份体检报告搭建检查流水线的完整代码4.1 这套流水线的模块划分整个体检助手我拆成了四个模块文件读取、文本组装、模型调用、报告生成。文件读取负责把六份文档和一个图片文件变成标准化的文本和 base64 数据文本组装负责把分隔标记、检查清单和工具人设定拼进 messages模型调用负责请求 Qwen3.8-Max 并处理返回的 JSON报告生成负责把问题清单转成一份带严重程度分级的 Markdown 报告。4.2 文件读取和文本组装的关键代码先看文件读取部分我用 pandas 读 Excel用 python-docx 读 Word图片转 base64import pandas as pd from docx import Document import base64 def excel_to_text(filepath): dfs pd.read_excel(filepath, sheet_nameNone) text_parts [] for sheet_name, df in dfs.items(): text_parts.append(f工作表: {sheet_name}) for col in df.columns: if col.startswith(Unnamed): for idx, row in df.iterrows(): for col2 in df.columns: if not str(row[col2]) nan: text_parts.append(f{col2}: {row[col2]}) text_parts.append(---) break else: for idx, row in df.iterrows(): for col in df.columns: val row[col] if pd.isna(val): val 空 text_parts.append(f{col}: {val}) text_parts.append(---) return \n.join(text_parts) def word_to_text(filepath): doc Document(filepath) lines [] for para in doc.paragraphs: text para.text.strip() if text: lines.append(text) return \n.join(lines) def image_to_base64(filepath): with open(filepath, rb) as f: return base64.b64encode(f.read()).decode(utf-8)这个代码里有几个细节要注意。第一sheet_nameNone能读出 Excel 所有工作表有的 Excel 文件把规格参数和 SKU 放在两张 sheet 里不能只读第一张。第二空单元格必须转成“空”否则模型会因为丢掉字段而漏掉完整性检查。第三Word 只取有内容的段落区分不了标题和正文没关系但空段落直接略过避免模型被大段空行干扰。4.3 组装提示词和调用模型的完整流程接下来是把上面准备好的文本拼进消息并调用模型。我用的 API 是 OpenAI 兼容格式Qwen3.8-Max 可以无缝切换所以代码写起来很顺手from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-model-endpoint ) system_prompt 你是一名拥有10年经验的电商平台商品合规审核专家擅长在跨文档信息中定位不一致之处。 你的审核风格严格、细致绝不放过任何可能引发投诉、处罚或售后纠纷的问题。 请按以下四大类检查所有资料 1. 一致性跨文档核对同一信息材质、容量、价格、保修期、颜色、发货时间、退换政策 2. 合规绝对化用语、虚假承诺、夸大宣传 3. 完整性必填字段缺失、必述项遗漏 4. 匹配主图内容与文档信息是否一致 要求 - 只输出确定存在的问题不要推测性评论。 - 如果某份文档没有问题不要强行输出。 - 严格按JSON数组输出每条问题包含 problem_id, document, category, severity(P0/P1/P2), issue, locations, suggestion - severity定义P0必须修改否则上架被拒或违规处罚P1建议修改可能引发投诉P2一般性问题。 user_prompt 文档1商品标题草稿 # 部分内容省略... user_prompt 商品主图 这是一张商品白底主图请结合其中的文字、价格、颜色等信息进行匹配类检查。 # 组装多模态消息 messages [ {role: system, content: system_prompt}, {role: user, content: [ {type: text, text: user_prompt}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_base64}}} ]} ] response client.chat.completions.create( modelqwen3.8-max, messagesmessages, temperature0.1, response_format{type: json_object} ) result_text response.choices[0].message.content温度设成 0.1 而不是 0是我试过几次之后的选择。温度设为 0 时模型偶尔会在重复性问题上打转0.1 既能保证输出稳定又不会太死板。response_format指定 json_object 能强制模型返回 JSON 而不是散文这一步节省了我大量解析的精力。4.4 报告生成让运营看得懂才是关键模型返回的 JSON 数组本身不算最终产物它还要转成一份运营同学能直接拿去改的报告。我把问题按 severity 分级排序再生成 Markdown 表格import json data json.loads(result_text) problem_list data[problems] if isinstance(data, dict) else data report_lines [# 商品资料体检报告, ] report_lines.append(| 问题编号 | 严重程度 | 所属文档 | 问题类型 | 问题描述 | 修改建议 |) report_lines.append(| --- | --- | --- | --- | --- | --- |) for p in sorted(problem_list, keylambda x: {P0: 0, P1: 1, P2: 2}[x[severity]]): report_lines.append( f| {p[problem_id]} | {p[severity]} | {p[document]} | {p[category]} | {p[issue]} | {p[suggestion]} | ) with open(report.md, w, encodingutf-8) as f: f.write(\n.join(report_lines)) print(f共发现 {len(problem_list)} 个问题)这一步看似简单却是我踩了坑才补上的。最初我直接把模型的 JSON 原文丢给运营被判读性极差。后来填充了表格运营拿到报告扫一眼严重程度列就知道先改哪里再扫一看出处列就知道去哪个文档改整个复核流程才真正跑顺。5. 实测跑出来的 27 个问题里哪些真的有用哪些让我想骂人5.1 27 个问题的整体分布第一次完整跑完这 6 份资料和 1 张主图模型输出了 27 个问题。分布情况大致是类型数量典型例子一致性11详情页和规格表保修期冲突、标题和详情页颜色不一致合规6标题含“最优惠”、详情页写“永不褪色”完整性7SKU 表缺一条尺码、标题未含品类核心词匹配3主图标注价格与 SKU 表价格不一致这个分布基本符合我的预期一致性问题和完整性问题最多因为它们最依赖跨文档对照这恰好是人工最容易漏、大模型最擅长的地方。5.2 真正拦住大问题的几个发现有几个问题让我觉得这套方案值回票价。第一详情页写了“终身保修”规格参数表里却是“保修期 1 年”这个如果不查出来售后成本会很难控制。第二主图上的“到手价 99”和 SKU 表里最低价 129 对不上这是客服要被问爆的隐患。第三SKU 表列出了“浅灰”色但规格参数表可选颜色字段里没有浅灰等于这个颜色在详情页完全不存在顾客根本不知道有这个选择。这些问题有一个共同点单独看任何一份文档都是“正常”的只有把文档放一起对照才暴露矛盾。这也说明我的判断是对的——这类检查靠关键字是抓不出来的必须依赖语义理解。5.3 误报和漏报模型不是万能的当然27 个问题里也有不少属于误报。最典型的是模型把“超强保温”里的“超强”识别成了绝对化用语实际上这就是普通营销词平台并不会处罚。还有一次背景复杂的商品图里有一个很小的标签文字模型 OCR 读错了字据此报了一个价格冲突等我放大图片一看价格根本没问题。漏报也有。最让我意外的是当六份资料里的两份同时使用了同一个错误数据比如标题和详情页都写了 550ml规格表是 500ml模型在发现文档之间不一致时会倾向于相信出现次数多的那个数据而不是根据规格表这种“事实性文档”去纠错。后来我在提示词里明确加了优先级的说明告诉它规格参数表和 SKU 表属于事实性数据优先级高于营销文案漏报率才降下来。5.4 时间账一次体检到底省了多久人工交叉核对一份资料包经验丰富的运营大概需要 35 到 45 分钟而且不一定能找出 27 个问题。用这套助手跑完一次大约 3 分钟出报告运营再花 10 分钟复核模型的每个发现、确认修改方案总共不到 15 分钟。更重要的是人工检查能不能找出 27 个问题取决于当天状态模型不会累也不会漏标准是恒定的。6. 想复刻这套助手的同学这几个坑希望你比我早一点知道6.1 结构化输出并不是 100% 稳定的我用了response_format约束输出但偶尔模型还是会返回格式破损的 JSON比如注释混进字段值、键名大小写不一致。为此我写了一个十几行的 JSON 修复函数如果json.loads失败就用正则把键名缺失的情况修掉还不行就重试一次。这个兜底逻辑虽然丑但极大提高了流水线的稳定性。6.2 token 成本和一次检查的真实开销我把一次请求的内容量测了一下输入 1 万 token 上下、输出 1500 token 上下按 API 定价算单次完整体检成本非常低比人工一分钟的工资还便宜。真正要关注的是批量场景如果一天跑 50 个商品成本就需要纳入考量了。对这种高频场景我建议把详情页摘要做得更狠一点把不必要的正文压缩掉能省下三四成 token。6.3 长文档截断是最隐蔽的误报源头我第一次跑的时候详情页文案超过 6000 字直接按窗口截断导致后半段的退换货承诺根本没被模型看到结果它报告“退换货政策缺失”属于典型截断导致的误报。后来改成摘要方案把每个模块压缩成保留关键信息的短文本这个问题就消失了。如果资料里出现超长文档宁可做摘要也别截断这是保底原则。6.4 “图片能看”不等于“图片看得准”多模态模型能读图但读取图片上的小字、叠印文字、反光区域的文字时可靠性远不如 OCR 工具。我的处理策略是图片只用来做高层的匹配类检查比如颜色、价格、主要卖点是否和文案一致如果主图上涉及精确数值或长串文字我会先用 OCR 提取一遍再交给模型而不是直接让模型读图。这个调整把匹配类检查的准确率提高了一截。6.5 提示词的角色设定和检查清单要一起调整我试过只改角色不改清单也试过只改清单不改角色效果都不理想。后来发现这两个是配合使用的角色设定影响模型找问题的“松紧程度”清单影响它往哪个方向找。想让助手严格一点只要把角色从“检查员”换成“拥有丰富经验的审核专家”就够了想减少误报就要在清单里剔除那些模棱两可的检查项。我现在的清单里没有任何一条是“文案是否有吸引力”这种主观项全部是可以明确判断对错的客观存在。这套体检助手从想法到跑通用了一个周末之后每次上新产品我都会先过一遍再交给人审。准确率当然达不到完美交付的程度但它把最耗人工、最枯燥的跨文档比对工作完全自动化了人的精力被释放到真正需要判断力的那些问题上。至少对我自己来说这已经足够改变我上架前的工作方式了。