用大模型打造电商商品资料包智能体检助手：检查项设计与Prompt实践

上个月接手了一个电商项目的新品上架，供应商一次性丢过来 6 份资料和 1 张商品主图，说是“东西都在里面了”。等我把规格表、卖点文案、资质证书、SKU 列表全部打开，才发现光是核对“详情页参数”和“规格表参数”是不是一致，就花了我半个下午。更崩溃的是，最后上架前还是漏了一个问题：主图上的 Logo 位置正好压住了卖点标签，平台直接给打回了。

后来我痛定思痛，拿 Qwen3.8-Max 搭了一个电商商品资料包体检助手，把这一堆资料连图带文丢进去，一次就查出了 27 个问题，从标题超字数到 SKU 条码缺失全给列出来了。这篇文章就是把我整个搭建过程、检查项设计思路、还有实际跑批时踩过的坑，完整拆开讲一遍。如果你也在做电商运营、商品审核或者供应商管理，这个思路可以直接抄作业。

1. 为什么商品资料包需要“体检”

先别急着聊技术，我们得先把业务痛点聊透。电商商品资料包看着就是几个文件，但实际上它是后面所有环节的数据源头——店铺上架、详情页制作、客服话术、仓储入库、广告投放，全都要从这里面取数。

1.1 一份典型的电商资料包到底有什么

我这次处理的这套资料，其实非常典型，基本涵盖了一个标准商品的全部“身份信息”：

• 商品规格表：包含产品尺寸、重量、材质、颜色、上市时间、产地、保质期等硬参数
• 卖点文案：运营写的推广语、核心卖点提炼、目标人群描述
• 详情页文案：对应详情页各个模块的文字内容
• 资质文件：质检报告、授权书、生产许可等扫描件或截图
• SKU 列表：每个 SKU 的条码、价格、库存、规格组合
• 价格与促销策略：定价、活动价、优惠券规则、预估毛利
• 商品主图：通常是一张 800x800 或 1000x1000 的白底图或场景图

这里面的核心矛盾在于：这些资料不是一个人写的，也不是一个系统生成的。规格表可能是产品经理整理的，卖点文案是运营写的，SKU 列表是供应链给的，主图是设计做的。多源头协作的结果就是——信息交叉核对的工作量巨大。

1.2 人工核对到底难在哪

我拿这次的真实案例说。6 份资料加 1 张图，人工核对的话，你需要做的工作包括：

• 把规格表里的参数，逐个对照详情页文案，看有没有矛盾
• 检查 SKU 列表里的规格组合，是否覆盖了规格表里所有的可选属性
• 验证卖点文案里的每个“最强”、“第一”之类的词，有没有对应的证明材料
• 核对价格策略里的活动价，是否低于 SKU 列表里的成本价
• 看资质文件的有效期，是不是已经过期了

这些活儿听着不难，但问题在于“量”。一个 SKU 动辄几十个，一个商品有几十个参数，交叉比对的组合数一下子就能到几百上千。人眼盯久了，漏掉一两个太正常了。而电商平台现在的审核系统越来越严，一个主图文案违规、一个参数缺失，轻则驳回，重则影响整个店铺的流量权重。

1.3 大模型做这件事的天然优势

为什么我最终选了 Qwen3.8-Max 而不是传统的规则脚本？道理很简单：资料包里的信息是“非结构化”的，规则脚本只能针对固定格式做匹配，比如 Excel 里的列名比对。但“详情页文案说重量是 500g，规格表写的是 0.5kg”这种语义层面的等价性判断，规则脚本处理不了，大模型却可以。

Qwen3.8-Max 的优势在于长上下文处理能力——我这次一次性把 6 份文档的文本内容加 1 张图片的描述一起喂进去，模型没有出现前面信息被“遗忘”的情况，后面做交叉核对时还能准确引用前面的数据。再加它的结构化输出能力，让模型直接按 JSON 格式返回问题列表，后面接解析和自动化流程就非常顺。

2. 体检助手的设计思路与整体架构

聊完背景，进正题。这个“体检助手”本质上是一个跑批脚本，把商品资料包作为输入，输出一份问题清单。整体设计思路拆开看，就三件事：拆解、核对、报告。

2.1 数据拆解：让模型“看得到”每一份资料

第一步是把资料包里的文件变成模型能处理的内容。我用的方法是：

• Excel/CSV 文件：用 pandas 读取，转成 Markdown 表格格式
• Word/PDF：先抽取文本，再按段落结构转成纯文本
• 图片：先用多模态能力做一轮描述，把关键信息结构化
• 资质证书：同样转成文本描述，特别是有效期、证书编号这类关键字段

这里有个细节值得说：转成 Markdown 表格而不是纯文本或 JSON，是我试了几轮之后发现的更优方案。原因是 Markdown 表格的格式信息对模型理解“行列对应关系”帮助极大，尤其是在处理 SKU 列表这种规则性很强的数据时，模型对“某一行的某个单元格”的引用准确性明显更高。

2.2 核对逻辑：把“体检标准”前置

体检助手和普通问答最大的区别，是它有一套“检查标准”。我不会让模型自由发挥“你觉得哪里有问题”，而是把所有检查项预先定义好，让模型逐项执行。这就像体检套餐一样，先确定查哪些项目，再出报告。

我把检查项分成了几个层级：

• 完整性检查：必填项是否缺失、SKU 是否覆盖所有规格组合、资质文件是否齐全
• 一致性检查：跨文档的参数是否一致、价格和成本是否倒挂、条码和规格是否对得上
• 合规性检查：广告法违禁词、极限词、虚假宣传风险、资质有效期
• 图片检查：分辨率、主图背景、文字遮挡、Logo 位置、主体占比
• 逻辑检查：库存数量和可售状态是否矛盾、促销时间和活动时间是否冲突

这一套检查项定义下来，其实是把人工审核的经验沉淀成了可执行的规则。我建议你在搭自己的助手时，这一部分一定不要偷懒，检查项设计得越细，模型给出的报告质量就越高。

2.3 报告输出：让问题一眼可定位

最后一步是把模型返回的问题列表整理成报告。我这边直接让模型用 JSON 格式输出每条问题的字段包括：问题级别、所属模块、问题类型、涉及资料、具体描述、修改建议。拿到 JSON 之后，再用脚本转成表格，自动按严重程度排序，高优问题排在前面。

注意：这里有一个容易踩的坑。如果你让模型直接输出 Natural Language 形式的报告，后面想做自动化流转和处理就会非常痛苦。强烈建议一开始就定义好输出 Schema，哪怕是 Prompt 里多写几行说明，也值。

3. 核心实操：检查项设计与 Prompt 编写

这部分才是真正的干货。我把这次实际用的检查项定义、Prompt 结构、以及几个关键参数的选择过程，全部展开讲。

3.1 六份资料的检查维度拆解

先说“6 份资料”到底怎么拆检查维度。我按照资料类型设计了不同的检查侧重点，组合起来才是完整的 27 项体检。

规格表是数据的“基准事实”，所有跨文档一致性检查都以它为准。检查维度包括：必填字段完整性、参数值是否合理（比如重量不可能为负）、单位是否统一（kg 和 g 混用的问题）。

卖点文案是最容易出现合规风险的模块。重点查：极限词（“最”“第一”“顶级”“100%”）、虚假承诺（“永不褪色”“绝对不掉色”）、未经验证的数据宣称（“销量第一”却拿不出证明）。

详情页文案是和规格表做交叉核对的重点对象。这里要查的是：详情页列出的每个参数，是否和规格表一致；详情页里没有覆盖到的关键参数有哪些；有没有 SKU 组合在详情页里完全没展示。

SKU 列表是承上启下的数据枢纽。检查项目比较多：SKU 是否完整覆盖规格表里的所有属性组合、条码是否唯一、价格是否在合理区间、库存状态是否矛盾、规格命名是否统一（比如“红色”和“红”同时出现）。

价格与促销策略查的是：活动价是否低于成本价、促销开始时间是否早于结束时间、优惠券规则是否和活动时间冲突、预估毛利是否符合公司的最低线。

资质文件查的是：证书编号是否完整、有效期是否已过期或临近过期、授权范围是否覆盖当前商品类目、发证机构和商品类目是否匹配。

3.2 Prompt 的完整设计：角色、输入、输出三步走

Photo 这一节我直接把我实际用的 Prompt 结构拿出来，你可以根据自己的业务情况改动。

第一步是角色设定，让模型明白自己在做什么：

你是一名资深的电商商品审核专员，你拥有丰富的平台规则知识和商品数据管理经验。你的任务是对给定的商品资料包进行全面体检，识别其中可能存在的信息缺失、数据矛盾、合规风险等问题。

这里要强调“资深”和“丰富的经验”，实测下来这类角色描述对输出质量有正向影响。模型会模仿资深审核员的思考方式，而不是机械地做“找不同”。

第二步是输入数据处理。我是把每份资料标注好类型，然后按固定顺序拼接：

以下是需要体检的商品资料包： 【资料1：商品规格表】 {规格表内容} 【资料2：卖点文案】 {卖点文案内容} 【资料3：详情页文案】 {详情页文案内容} 【资料4：SKU列表】 {SKU列表内容} 【资料5：价格与促销策略】 {价格策略内容} 【资料6：资质证明文件】 {资质文件描述} 【资料7：商品主图描述】 {主图内容描述}

这个顺序不是随便排的。我把“基准事实”排在前面，把需要被核对的对象排在后面，模型在生成回答时，会优先参考前面已经“读入”的信息做判断，整体的一致性核对准确率会高一些。

第三步是输出格式定义。我给了一个完整的 JSON Schema 示例，并明确了“只输出 JSON，不要输出任何解释性文字”的要求。这样后面解析和自动化就方便得多。

3.3 商品主图的检查逻辑

主图检查是这次体检里比较特殊的一块，因为图片不是文本数据。我这边用 Qwen3.8-Max 的多模态能力，先把图片转成结构化描述，再做检查。具体检查项包括：

• 分辨率是否达到平台要求（通常 800x800 以上）
• 背景是否为平台要求的纯色或白底
• 主体是否完整，有没有被裁切
• 卖点标签是否遮挡了商品主体
• 是否有非授权品牌 Logo
• 图片上是否有水印、拼接痕迹或明显的牛皮癣要素

这里有一个经验可以分享：与其让模型直接基于图片做“合规判断”，不如先让模型“描述图片内容”，再进行规则判断。比如你先让模型说出“图片左上角有一个红色 Logo，覆盖了商品标签区域”，然后再用 Prompt 判断这个描述是否命中违规规则。分两步走，结果稳定得多，也方便定位具体问题。

3.4 27 个问题是怎么分类的

这次实际跑出来的 27 个问题，本身也体现了检查项的覆盖面。我按模块统计了一下：

可以看到，问题不是集中在一两个模块，而是均匀分布在各个资料里。这也从侧面说明，跨资料包的体检确实能发现很多平时人工核对容易忽略的角落。

4. 一次完整的体检跑批实录

理论聊完了，实际操作过程也得说。这一节我完整还原一次跑批的过程，包括输入准备、执行过程、问题输出和复核处理。

4.1 输入准备：从原始文件到模型输入

我的自动化流程大致是：

1. 把 6 份资料文件统一命名，放到指定目录
2. 用脚本判断文件类型，分别走不同的解析函数
3. Excel 用 pandas 读，转到 Markdown 表格
4. PDF 先用 PDF 解析库抽文本，再按页合并
5. 图片走多模态描述接口，生成描述文本
6. 所有内容按预设模板拼接，组装成最终 Prompt

这一步费时不多，核心工作量在写解析函数上，尤其是 PDF 的抽取效果，不同来源的 PDF 质量差异很大，有些扫描件抽不出文字，只能走 OCR 或者干脆用图片描述代替。

4.2 喂入资料：一次处理还是分批处理

有一个关键决策：6 份资料是打包一次喂给模型，还是分批处理。我的结论是：一致性检查必须一次性喂入，拆开做效果会大打折扣。

比如“详情页写 500g，规格表写 0.5kg”这类问题，如果你分两批让模型看，模型就失去了交叉比对的基础。Qwen3.8-Max 的长上下文能力在这里派上了用场，6 份资料的文本量大概在几千 token 的级别，一次处理没有问题。

但如果你实际情况中商品资料特别多，超出了模型单次处理的上限，我建议至少把“基准事实”和“待核对对象”捆绑在一起处理，不要拆得更细了。

4.3 输出结果的整理与优先级排序

模型返回的是 JSON 格式的问题列表，我这边再用脚本做后处理：

• 解析 JSON，转成 DataFrame
• 按问题级别排序，高优在最前面
• 按模块分组，方便分发给对应的负责人
• 对涉及具体行号的 SKU 问题，自动关联到原始 Excel 的行

这次跑出来的 27 个问题里，被我列为高优的有 9 个。什么叫高优？我的定义是：不解决会导致平台驳回、客诉风险、或者直接影响销售转化的问题。比如主图 Logo 遮挡、极限词违规、SKU 条码重复，这些都是必须在上架前处理的。

提示：体检报告出来了，别忘了给每条问题附上“修改建议”。我前期的 Prompt 里没有特别注意这一点，后来发现只有问题描述没有修改建议的话，业务团队拿到清单还是不知道怎么改。后面补上“修改建议”字段之后，整个流程顺畅了非常多。

4.4 人工复核：大模型不是终点

必须说一句公道话，大模型体检的结果不是 100% 准确，也不应该直接作为最终结论。我现在的流程是：模型出初检报告，人工做复核，复核通过后再分发处理。

复核的重点放在两类问题上：一是模型可能误报的地方，比如“重量不一致”其实是因为两个文档用了不同的精度；二是模型可能漏报的地方，比如某些行业特有的资质要求，光靠通用检查项是覆盖不到的。

这个机制的好处在于，人的精力被集中在“需要判断”的问题上，而不是从零开始逐行比对，审核效率提升是实打实的。

5. 实操中的常见问题与避坑指南

最后把这些天调试和实际使用中踩过的坑整理一下。这些问题我基本都踩过，有的调了很久才找到原因。

5.1 误报率高，怎么办

最开始跑第一版的时候，误报率大概在 30% 左右，也就是 10 个问题里大概有 3 个是“冤枉”的。后来排查下来，主要原因有两个。

第一个是检查项定义不够清晰。比如我让模型检查“详情页参数是否完整”，但没有定义“完整”的标准是什么，模型就很容易把“详情页没写产地”也报成问题，而实际上产地信息在规格表里已经有了，详情页并不是必须展示。

解决方法是把检查项做成 checklist 式的描述，明确哪些是必查项、哪些是建议项，同时对“问题”给出判断标准。比如“只有当详情页出现与规格表明确矛盾的数值时才判定为问题，缺失展示不作为问题上报”。

第二个原因是输入数据的格式不统一。同一份规格表，有时候是横向排列，有时候是纵向排列，模型理解起来容易出错。我的方案是在转 Markdown 表格之前，先做一层数据清洗，把列名标准化。

5.2 长上下文场景下信息被忽略

虽然 Qwen3.8-Max 的长上下文能力很强，但在处理超长文本时，偶尔还是会出现“前面的信息被忽略”的情况。我测试下来，尤其是当某个 SKU 列表特别长，夹在中间位置的某些行，模型在交叉核对时可能会跳过。

我的应对方法是：在 Prompt 中明确要求分批核对。比如“请先逐条检查规格表第 1 到 20 行与 SKU 列表的一致性，再检查第 21 到 40 行”。把任务显式拆解成子任务，模型的处理精度会明显提升，代价是多消耗一点 token，但换来的是结果稳定，值。

5.3 图片描述丢失关键信息

多模态转描述的方式，最大的风险是信息损耗。比如原始主图上有一个很小但很关键的文字——某个平台要求的资质标识，模型描述图片时可能会忽略这个细节，后面基于描述的检查自然就漏掉了。

这个问题目前没有一个完美的解法。我的经验是：对关键图片，同时让模型“描述”和“识别图中的全部文字信息”。在 Prompt 里加一句“请提取图片中出现的所有文字内容，包括角落、边缘位置的小字”，能很大程度上缓解信息丢失的问题。

5.4 结构化输出的“稳定性”问题

Qwen3.8-Max 支持结构化输出，但实测下来，偶尔还是会出现 JSON 格式不合法的情况，比如多了一个逗号、少了一个括号。脚本解析的时候直接报错，整个流程中断。

我的兜底方案是：在解析层加一个容错机制。先用正则在返回文本里截取出最外层 JSON 片段，再尝试用 JSON 解析器解析，如果失败就退回到正则提取关键字段。同时会在 Prompt 里再强调一次“严格只输出 JSON，不要包含任何注释或额外说明”。

5.5 敏感词检测不能全交给模型

最后说一个比较本质的问题：大模型做合规检查确实很灵活，但敏感词、广告法违禁词这类检查，本质上更适合用规则词典来做。

因为违禁词是高度确定的，比如“最”“第一”“国家级”这些词，用闭包词表做精确匹配，速度又快、准确率又高，完全不需要大模型。但如果只用词典，又做不到“语义层面”的判断，比如“微信扫一扫可以领取优惠”这种整体表达是否违规，词典就无能为力了。

所以我的最终方案是规则和模型结合：先跑一遍敏感词词典，把确定命中的问题直接标记，再让模型做语义层面的合规判断，两者结果合并，去重后输出。这样的准确率和效率是最均衡的。

5.6 成本控制：一次体检到底花多少钱

有朋友问我成本问题。实际算下来，一次包含 6 份资料和 1 张图的体检，如果不做多次重试，大概消耗的 token 在 1 万到 1.5 万之间。按 Qwen3.8-Max 的调用价格来算，单次成本在几毛钱到一两块钱之间，这相比人工核对动辄半小时以上的时间成本，性价比相当高。

如果你打算高频使用，建议在 Prompt 层面做好缓存和复用——同一份规格表的解析结果可以直接缓存，下次体检不用重复解析。另外，不是每次都需要调用多模态能力，只有商品主图有更新时才需要重新跑图片描述，这个可以单独做流程控制。

6. 体检商品的同时，我顺手做的一件事

因为资料包里信息多且杂，我在搭体检助手的过程中，顺手把“信息提取”也做了。效果是：同一个 Prompt 流程里，模型在返回问题清单的同时，还能自动生成一份结构化的商品信息主数据，直接导入到后面的商品管理后台。

这算是体检流程的“副产品”，但对实际工作的帮助极大。以前一个新品上架，光是录入商品基本信息就要花十几分钟，现在直接从资料包里自动抽取，人工只需要核验一遍，基本五分钟内可以搞定。

具体做法是在输出 Schema 里，除了issues数组，再加一个product_info对象，把商品名称、类目、品牌、规格参数、SKU 明细、价格策略等字段全部结构化输出。然后脚本自动映射到后台的字段名称，生成可直接导入的模板文件。

这里要注意的是，自动抽取的商品信息一定要有人工确认环节，尤其是类目、品牌这些关键字段，一旦填错后面改起来非常麻烦。我在流程里设置了“高置信度字段自动导入、低置信度字段人工确认”的规则，用模型输出的置信度字段来控制分流。

7. 我把整套流程封装成了一个小工具

写到这里，其实整套东西已经不只是“一个 Prompt”了。我把解析、组装、调用、后处理、报告生成这几段脚本串起来，封装成了一个命令行小工具，放在公司内部的工具库里，运营、审核、供应链的同事都可以直接调用。

目前的版本支持的功能包括：

• 单个商品资料包体检
• 批量商品资料包跑批
• 按模块或问题级别筛选输出
• 自动生成 Excel 版体检报告
• 严重问题自动发送通知

工具本身不复杂，技术栈就是 Python 加一个 API 调用，核心价值全在检查项的设计和 Prompt 的调优上。这也印证了我一直以来的一个观点：大模型时代，真正的门槛不在模型本身，而在于你对业务的理解能不能转化成一套有效的“检查逻辑”。

这个小工具上线跑了差不多两周，效果比我预期的要好。最明显的变化是，新品资料包的人工核对时间从原来的一到两小时，压缩到了十分钟以内，而且各种隐蔽的小问题——比如 SKU 条码重复、详情页参数矛盾——几乎都能在第一次体检时暴露出来。以前这些问题是等着平台审核打回或者客户投诉之后才发现的，现在前置到了上架之前。

回过头来看，这个项目最核心的一点经验是：不要指望大模型一步到位解决所有问题。我把检查项拆碎、把输出结构定死、把重要字段加了置信度标记、把敏感词检测拆给规则词典，这些“笨功夫”才是整个工具稳定可用的真正原因。如果你也要做类似的事情，我建议先把检查项设计这件事做到极致，再考虑模型调用的工程细节。