用Qwen3.8-Max搭建电商商品资料智能体检助手

上个月朋友找我帮忙审核一批准备上架的电商资料，六个文档加一张商品主图，按他们运营的说法，人工过一遍至少要半小时，还总担心漏掉细节。我实在不想对着Excel和Word来回切着看，干脆用Qwen3.8-Max搭了一个"商品资料包体检助手"，把资料一次性丢进去，几分钟跑完，一次查出27个问题，其中好几个是人工审核时特别容易忽略的。这篇文章就把这个项目的完整思路、数据建模、提示词设计、代码写法和踩坑经历都摊开讲，适合正在做电商运营、供应链管理、商品数据治理，或者打算用大模型做文档审核工具的朋友参考。

1. 为什么需要给商品资料做"体检"

1.1 电商上架前资料审核的真实痛点

电商的商品资料从来都不是一个文件，而是散落在各个协作环节里的。商品基础信息表可能由运营维护，详情页文案是文案写的，规格参数在研发或采购手里，资质证书在法务或品控那里，价格库存又是另一个系统导出的。每个人维护一份，没有人能保证它们完全同步。结果就是上架前必须有人把这几份资料逐项比对，发现问题再一个个找人确认修改。

人工审核最大的问题不是能力，而是稳定性和效率。人看前两份资料时注意力还在线，看到第五份时已经麻木了，很多不一致就顺手放过去了。更麻烦的是，每个审核人员的标准不一样，有的人会查极限词，有的人只看价格，有的人只关心规格参数是否齐全，最后商品上架后不是被平台驳回，就是被用户投诉描述不符。

我之前也试过用传统规则脚本做检查，比如写正则查手机号格式、用关键词列表匹配违禁词，但效果很有限。规则引擎只能查"长得不对"的问题，查不了"语义不对"的问题。比如标题写"无线吸尘器"，规格参数表里却出现"电源线长度5米"，这在规则引擎看来没有任何语法错误，但任何有常识的人都知道这是矛盾的。这类问题必须靠语义理解才能发现。

1.2 为什么选择大模型而非纯规则引擎

传统自动化审核的逻辑是穷举：把所有可能出错的地方变成规则，一条条匹配。问题是电商资料的错误形态太开放了，而且很多错误藏在上下文关系里。比如详情页文案里写"销量全网第一"，这不是格式错误，是合规风险。比如价格表里的划线价和实际售价倒挂，平台会判定为虚假促销。再比如商品参数表标注的容量是500ml，但详情页主图里印的却是600ml，这种图文不一致靠关键词规则几乎不可能捕获。

大模型的优势在于它能同时理解多份资料中的语义，并且能跨越文档做比对。它不需要你事先定义"什么算错误"，而是根据你的检查维度、行业常识和文档内容推断出哪些地方存在矛盾、缺失或风险。用Qwen3.8-Max来做的另一个原因是它对中文电商语料的理解比通用模型更细，能识别出"全网最低价""顶级品质"这类常见但违规的表达，也能理解规格表里"约/左右/±"这些词带来的不确定性。

1.3 整体方案选型：Qwen3.8-Max在流程中的定位

在设计这个体检助手时，我一开始考虑的是让模型一次性把所有文件和图片都读进去，直接输出问题列表。但实际跑下来发现不行：六份资料的文本量加起来非常大，再加上图片信息，很容易把上下文撑爆，而且模型在一个超长上下文里做精细比对，容易遗漏中间部分的内容，顾头不顾尾。

后来我把流程改成"三阶段"：第一阶段是资料结构化和信息抽取，第二阶段是基于抽取结果做多维交叉检查，第三阶段是把模型输出结果整理成可执行的问题工单。Qwen3.8-Max在三个阶段都有参与，但它不是简单地被调用一次，而是按需被调用多轮。第一阶段用一次调用来抽取所有资料的关键信息并汇总成统一JSON；第二阶段按检查维度分多次调用（如果一次能塞下，也可以一次调用），每个维度独立做交叉比对；第三阶段则主要靠本地代码把模型返回的JSON结构化成报表，不再需要模型参与。

这样做的好处是每一轮任务更聚焦，上下文更短，模型的稳定性和准确率都会明显提升。另一方面，一旦某个维度出现问题，我只需要重新检查对应的那一段，而不是重新读一遍所有资料，排查问题的成本也低很多。

2. 资料清单与数据建模：把7个输入变成统一结构

2.1 资料包里到底有什么

先说说这次体检的输入。这里说的"6份资料和1张商品图"分别对应真实的商品上架前常见的文件集合，我按实际使用频率整理成了一张清单：

实际业务里还可能更多，比如说明书、售后政策、物流说明，但核心配置就是这七类。很多错误不是某个文件内部的问题，而是文件与文件之间对同一事实的描述不一致。所以第一步要做的不是检查，而是把不同格式的资料拉平，放到同一个结构里。

2.2 数据建模：定义一个统一的"商品资料包模型"

我在设计时给所有输入定义了一个统一的JSON结构，相当于把六份资料和一个图片缩略信息都映射到一份"商品资料档案"里。给模型看的Prompt和最后的输出检查结果，都基于这个结构展开。

这个模型的结构大致如下，我简化了部分字段，方便说明思路：

{ "product_name": "便携榨汁杯", "basic_info": { "title": "无线便携榨汁杯 家用随行果汁机", "brand": "某品牌", "category": "厨房小电", "selling_points": ["无线便携", "一键操作", "易清洗"] }, "specs": { "model": "XZ-500", "capacity_ml": 500, "weight_g": 380, "power_w": 60, "material": "Tritan", "voltage_v": "5V/2A" }, "detail_copy": { "sections": [ {"heading": "核心卖点", "content": "600ml大容量，一次榨汁满足全天需求"}, {"heading": "续航", "content": "满电可榨15杯，出差旅行必备"} ] }, "price_stock": { "sku_list": [ {"sku": "XZ-500-白", "price": 129, "original_price": 199, "stock": 320}, {"sku": "XZ-500-绿", "price": 139, "original_price": 199, "stock": 0} ] }, "certificates": { "cert_numbers": ["质检报告编号: QZ-2024-0158"], "cert_status": "有效", "cert_issuer": "某检测机构" }, "activity": { "activity_name": "春季焕新", "discount_info": "前100名下单立减30元", "gift_info": "赠定制杯刷" }, "main_image_text": "容量500ml，杯身材质Tritan，功率60W" }

这个模型不需要每个字段都填满，凡是能从资料里抽取到的就填，抽不到的就保留空字符串或null。这样设计有三个好处：一是后续检查脚本可以直接按字段做一致性比对；二是模型在抽取时会更认真，因为它知道你后面要用这个做检查；三是检查结果可以追溯到具体是哪个环节丢了信息。

2.3 图片和PDF怎么进模型：OCR与多模态输入的取舍

商品图在资料包中很重要，但也是最难处理的。如果直接用多模态能力把整张图送进模型，模型固然能看图，但是它对图上的小字、标签、参数表细节的识别不一定可靠。实际项目中，我更推荐把图片分成两条路处理：商品主图这种以视觉表达为主的图，直接让模型看图，判断图片风格、构图与文案是否匹配；但图片上如果印了参数、容量、生产日期等关键信息，就必须先用OCR或表格识别工具把文字抽取出来，再作为文本输入补充进去。

我在这套体检助手里也是这么做的。商品主图先过一遍本地部署的OCR服务，抽取到"容量500ml""材质Tritan""功率60W"这样的文本片段，然后和图片本身一起传给后续检查模块。这样既保留了模型对图像内容的感知，又避免了"图片里有一行小字，模型根本没看到"这种翻车场景。

需要注意的是，OCR的识别结果一定要保留坐标或段落位置，不要只抽文本。有时候详情页图片上有"500ml"淡色水印，OCR识别出来后你可能误以为它是实际参数。宁可多保留一些上下文信息，也不要让后续模型被OCR噪音带偏。

3. 体检助手核心实现：提示词、代码与输出设计

3.1 检查维度设计：27个问题从哪里来

"一次查出27个问题"不是瞎数的，我在模型输出格式里强制要求了多维度的检查项。每个维度下预置了一些子项，同时允许模型补充它认为重要的额外问题。

我最终使用的检查维度如下：

我在提示词里把每个维度都展开成具体的检查指令，同时要求模型输出问题时必须带上发现该问题所在的文件来源，不能只给一个结论。

3.2 Prompt模板的写法和参数选择

给模型的system prompt，我采用的是"角色定义+任务说明+输出格式约束"三段式结构。我没有用"请你扮演一名资深电商审核专家"这种泛泛的角色扮演，而是直接告诉它要干什么，以及输出什么格式的数据，实测下来前者更容易产出稳定结构。

下面是我实际用的一个简化版Prompt：

你是一位电商商品资料审核助手。你会收到一份整理后的商品资料JSON和一张商品主图的OCR文本。请按照以下维度检查问题：完整性、一致性、合规性、规范性、图片一致性、价格合理性、活动冲突。 要求： 1. 对比不同资料之间的描述，重点检查数据不一致。 2. 合规性检查重点关注绝对化用语、极限词、虚假宣称。 3. 每个问题必须包括：问题编号、所属检查维度、涉及的文件、问题描述、具体位置引用、修复建议。 4. 只输出JSON数组，不要输出解释文字。 输出格式： [ { "issue_id": "ISSUE-001", "dimension": "一致性", "source": ["规格参数表", "详情页文案"], "description": "规格参数表标注容量为500ml，详情页文案描述为600ml。", "location": "规格参数表-容量字段；详情页文案-核心卖点段落", "suggestion": "确认实际容量，统一两处描述并修改对应参数。" } ]

这种明确到输出JSON数组的写法，配合response_format之类的结构化输出参数，能极大减少后续解析的负担。

参数设置上，我把temperature调到了0.1，top_p调到0.9。温度低是因为审核任务要的是稳定、可复现的结果，不需要创造性发挥。如果你发现模型漏检或者误报，先不要急着改温度，先检查是不是Prompt里把检查维度描述得不够具体。

3.3 关键代码实现：调用Qwen3.8-Max的完整流程

下面这段代码是我这个项目里的核心流程，简化掉了一些业务细节。整体思路是：读入多份资料 -> 用第一轮调用抽取并归纳资料 -> 组装成统一JSON -> 用第二轮调用得到问题列表 -> 解析JSON并生成报表。

import json from openai import OpenAI client = OpenAI( api_key="your_api_key", base_url="your_dashscope_base_url" # 以官方SDK文档为准 ) def load_documents(file_paths: dict) -> str: """加载多份资料并拼接成文本，用于第一轮抽取。""" sections = [] for key, path in file_paths.items(): with open(path, "r", encoding="utf-8") as f: content = f.read() sections.append(f"### {key}\n{content}") return "\n\n".join(sections) def extract_product_json(documents_text: str) -> dict: """第一轮：从多份资料中抽取统一商品资料模型。""" prompt = f""" 请从以下多份商品资料中抽取关键信息，输出为JSON。 必须覆盖：product_name、basic_info、specs、detail_copy、price_stock、certificates、activity。 无法确定的字段留空字符串。 {documents_text} """ resp = client.chat.completions.create( model="qwen-max-v38", # 以官方模型版本为准 messages=[ {"role": "system", "content": "你是一个严谨的商品资料抽取器，只输出JSON。"}, {"role": "user", "content": prompt} ], temperature=0.1, response_format={"type": "json_object"} ) return json.loads(resp.choices[0].message.content) def check_product_issues(product_json: dict, image_ocr_text: str) -> list: """第二轮：基于统一JSON模型做多维度体检。""" prompt = f""" 商品资料JSON： {json.dumps(product_json, ensure_ascii=False)} 商品主图OCR文本： {image_ocr_text} 请按照系统指令中的7个检查维度检查问题，输出JSON数组。 """ resp = client.chat.completions.create( model="qwen-max-v38", # 以官方模型版本为准 messages=[ {"role": "system", "content": SYSTEM_CHECK_PROMPT}, {"role": "user", "content": prompt} ], temperature=0.1, response_format={"type": "json_object"} ) data = json.loads(resp.choices[0].message.content) return data.get("issues", data) if isinstance(data, dict) else data # 使用示例 documents = { "商品基础信息表": "files/basic_info.xlsx", "规格参数表": "files/specs.xlsx", "详情页文案": "files/detail.docx", "价格与库存表": "files/price_stock.xlsx", "资质与证书文件": "files/cert.pdf", "营销活动说明": "files/activity.xlsx" } docs_text = load_documents(documents) product_json = extract_product_json(docs_text) issues = check_product_issues(product_json, image_ocr_text="容量500ml，Tritan材质，60W") print(json.dumps(issues, ensure_ascii=False, indent=2))

实际项目中，load_documents这一步不是简单读文本就能解决的。Excel要用openpyxl或pandas读成文本，PDF要用专门的库抽取文本，图片上的表格信息可能要先用PP-Structure这类工具做版面识别。我当时是把每个文件都先转成"markdown风格的文本块"，每个表格转成管道的文本表，这样模型理解起来负担最小。

3.4 输出层设计：把模型结果变成可直接执行的工单

模型返回的是一堆JSON，但这还不算完。真正要交付给运营、客服、供应链同事的是一个可执行的问题清单。我在本地写了一个后处理脚本，做几件事：第一，把模型返回的JSONissues数组转成Excel表格，列包括问题编号、维度、涉及文件、问题描述、位置引用、修复建议；第二，按风险等级给问题排序，把"价格倒挂""极限词风险""证书缺失"这类严重问题排到最前面；第三，为每个问题生成一个简短的"修复动作"描述，方便对接人直接复制进工单系统。

这里有个很实用的技巧：输出Excel时，尽量把"涉及文件"和"具体位置"做成独立的列。因为电商团队大多用飞书或钉钉协作，这些字段可以直接作为表格筛选条件，谁负责哪个文件，就筛出谁的问题。模型给出问题列表后，人工复核的成本会低很多。

4. 实操实录：一次真实的"体检"结果分析

4.1 输入资料概览

为了说清楚这套东西的实际效果，我把当时其中一个测试项目匿名化后拿出来讲。这是一个便携式榨汁杯商品，资料包里有商品基础信息表、规格参数表、详情页文案、价格与库存表、资质证书PDF、营销活动说明，以及一张商品主图。产品定位是"无线便携"，目标人群是有通勤和出差场景的年轻人。

资料不算复杂，但我特意没有预先做任何清洗，完全模拟运营把一堆文件丢过来的真实场景。文件里既有表格，又有长段文案，PDF证书里还夹杂着扫描件的水印。整个文本量折算下来大概1.8万个token左右。

4.2 27个问题分类和分布

模型跑完一轮检查之后，返回了27个问题。我按维度做了统计：

这个分布很有参考价值：一致性类问题最多，这也是人工审核最容易漏掉的部分。模型一次性把这些差异找出来，省去了运营在多个文件之间反复切来切去的痛苦。

4.3 几个典型问题的处理细节

我挑三个当时印象最深的问题展开说。

第一个是容量标识不一致。规格参数表里是500ml，详情页正文第一段写的是600ml，商品主图的OCR文本里又出现了"600ml"水印。人工只看单个文件根本发现不了问题，因为每个文件内部读起来都挺通顺。模型把三个来源放在同一个上下文里对比后，立刻给出"容量信息存在三处冲突"的结论。修复建议也很明确：以规格参数表为准或确认实际容量后统一所有位置。

第二个是合规风险。详情页文案里的"最强榨汁"和活动说明里的"全网最低价"都是绝对化用语。这类词如果靠关键词字典，确实也能命中一部分，但模型能看到上下文，能更好判断"最强"是在描述性能还是在违规宣传，减少误报。

第三个是图片一致性。商品主图显示杯身是白色，但标题和商品基础信息表里写的颜色是"抹茶绿"。这种错误发生的原因一般是运营套用了旧图或者颜色字段填错。模型返回问题时，还把图片OCR里识别到的"白色"字段一并列出，修复建议是重新拍摄或替换主图，同时核对基础信息表颜色字段。

5. 避坑指南与问题排查

5.1 常见问题速查表

我把自己在这套方案落地过程中遇到的典型问题整理成了一个速查表，方便你直接对照排查：

5.2 三个容易踩的坑

第一个坑是过度相信模型的"全知视角"。一开始我试图让模型直接读取原始Excel和PDF文件内容，觉得大模型既然什么都会，应该能自己处理这些格式。结果发现不行，表格结构稍复杂一点，模型就会读串行。老老实实先用代码把各种文件转成Markdown文本，再喂给模型，稳定性和准确率都提升了一个级别。

第二个坑是忽略了输出字段约束。最初版本的Prompt只要求"输出所有问题"，结果模型有时候输出的是自然语言段落，有时候又是结构化的列表，下游解析代码要兼容好几种格式，写得很痛苦。后来系统里强制约定输出JSON数组，每个问题必须包含issue_id/dimension/source/description/location/suggestion，这些字段缺一不可，解析逻辑才稳定下来。

第三个坑是成本失控。一开始我图省事，全文一次性丢给模型，每次调用消耗大量token。后来发现，第一阶段抽取和第二轮检查分开跑，总token反而少了很多，因为抽取阶段可以把重复的表格内容精简掉，检查阶段只面对一个干净的结构化JSON，检查效率和效果都会提高。

5.3 成本与响应时间控制建议

用大模型做批处理审核，心里一定要有成本账。我当时统计了一下，一个标准资料包（6份文档+1张图），如果全部用文本方式处理，总token大概在2万到3万之间。用Qwen3.8-Max跑一轮的成本并不高，但如果每天要处理几百个SKU，积少成多也是一笔不小的开支。

控制成本的办法有几个。一是先做规则预筛选，比如用正则把必填字段缺失、价格倒挂这种规则性很强的问题先筛掉，剩下的语义类问题再交给大模型。二是合理利用模型上下文能力，一个模型实例在同一轮里尽量让它处理多个SKU，减少重复的Prompt开销和网络请求开销。三是对结果做缓存，同一个商品资料如果没变过，就直接读历史检查结果，不用重新跑一遍。四是设置好超时和重试机制，避免因为个别调用超时导致整个批次失败，重新跑一遍反而更费钱。

在实际使用中，我建议把"抽取商品资料模型"和"问题检查"做成两个独立的API调用，不要合并成一个超级Prompt。两者的目的不同，合并了反而会影响模型的专注度，增加token消耗，还对排错不友好。

6. 这个助手还能怎么扩展

项目跑通之后，我又顺手做了两个小扩展。一个是在输出Excel之外，生成了一个Markdown格式的"上架修改清单"，运营可以直接把它贴到飞书文档里，问题、负责人、修改状态一目了然。另一个是把检查结果接了个简单的回调，如果某个SKU连续两次检查都出现合规类问题，会自动把对应商品标记为"高危，需复审"，方便品控团队优先处理。

目前这套体检助手已经不只是我自己在用，我把它包装成了一个简单的内部工具，输入是商品资料压缩包，输出是一个问题报告。整个流程走下来，最大的感受是：大模型解决的不是"能不能发现矛盾"的问题，而是把"发现矛盾"这件本来要人工花大量时间做的事情，变成了一个可以随时调用、可重复、可追溯的标准流程。

如果你也想搭一个类似的工具，我的建议是从最痛的一两个场景切入，先别急着做成全流程自动化。比如只看价格与库存的一致性，或者只看详情页的合规性，跑通之后再逐步加维度。资料类型越收敛，模型的表现越可控，后续维护成本也越低。

最后再分享一个小技巧：在Prompt里给模型留一个"其他问题"的开放检查项，让它在完成预设维度检查之外，自主判断还有哪些值得关注的问题。我这次查出的27个问题里，有好几个就是模型主动补出来的，比如"规格参数表里电压值标注方式不符合平台规范"这种细颗粒问题。开放项既能兜底，又能帮你发现之前没考虑到的审核盲区。