上个月朋友找我帮忙审核一批准备上架的电商资料六个文档加一张商品主图按他们运营的说法人工过一遍至少要半小时还总担心漏掉细节。我实在不想对着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张商品图分别对应真实的商品上架前常见的文件集合我按实际使用频率整理成了一张清单序号资料名称常见格式主要内容1商品基础信息表Excel/CSV商品名称、标题、卖点、类目、品牌、产地2规格参数表Excel/Word型号、尺寸、重量、功率、容量、材质、执行标准3详情页文案Word/Markdown商品卖点描述、功能说明、使用场景、营销文案4价格与库存表Excel/CSV售价、划线价、成本价、库存数量、SKU编码5资质与证书文件PDF/图片质检报告、3C认证、授权书、检测标准编号6营销活动说明Excel/Word活动名称、优惠力度、赠品信息、活动时间7商品主图JPG/PNG商品外观图、包装图、宣传视觉实际业务里还可能更多比如说明书、售后政策、物流说明但核心配置就是这七类。很多错误不是某个文件内部的问题而是文件与文件之间对同一事实的描述不一致。所以第一步要做的不是检查而是把不同格式的资料拉平放到同一个结构里。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个问题不是瞎数的我在模型输出格式里强制要求了多维度的检查项。每个维度下预置了一些子项同时允许模型补充它认为重要的额外问题。我最终使用的检查维度如下维度检查内容典型问题示例完整性必填字段是否缺失、证书是否缺失缺少质检报告编号、缺少规格表中的材质一致性不同资料对同一信息的描述是否矛盾标题写500ml参数表写600ml合规性是否含极限词、违禁词全网销量第一、最强吸力、绝对化用语规范性单位、格式、数值范围是否规范电压写成5V/2A、容量单位不统一为ml图片一致性图片展示内容与参数/文案是否一致主图标颜色绿色实际图片是白色价格合理性划线价、售价、成本之间关系是否合理划线价与售价差值异常、成本高于售价活动冲突活动信息与价格、库存、赠品是否冲突活动写全店包邮实际商品为海外直邮我在提示词里把每个维度都展开成具体的检查指令同时要求模型输出问题时必须带上发现该问题所在的文件来源不能只给一个结论。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.1top_p调到0.9。温度低是因为审核任务要的是稳定、可复现的结果不需要创造性发挥。如果你发现模型漏检或者误报先不要急着改温度先检查是不是Prompt里把检查维度描述得不够具体。3.3 关键代码实现调用Qwen3.8-Max的完整流程下面这段代码是我这个项目里的核心流程简化掉了一些业务细节。整体思路是读入多份资料 - 用第一轮调用抽取并归纳资料 - 组装成统一JSON - 用第二轮调用得到问题列表 - 解析JSON并生成报表。import json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlyour_dashscope_base_url # 以官方SDK文档为准 ) def load_documents(file_paths: dict) - str: 加载多份资料并拼接成文本用于第一轮抽取。 sections [] for key, path in file_paths.items(): with open(path, r, encodingutf-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( modelqwen-max-v38, # 以官方模型版本为准 messages[ {role: system, content: 你是一个严谨的商品资料抽取器只输出JSON。}, {role: user, content: prompt} ], temperature0.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_asciiFalse)} 商品主图OCR文本 {image_ocr_text} 请按照系统指令中的7个检查维度检查问题输出JSON数组。 resp client.chat.completions.create( modelqwen-max-v38, # 以官方模型版本为准 messages[ {role: system, content: SYSTEM_CHECK_PROMPT}, {role: user, content: prompt} ], temperature0.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容量500mlTritan材质60W) print(json.dumps(issues, ensure_asciiFalse, indent2))实际项目中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个问题。我按维度做了统计检查维度问题数量典型例子一致性8详情页写600ml规格表写500ml标题写无线参数表却出现电源线长1.5米合规性6文案出现最强榨汁活动说明写全网最低价完整性5资质证书扫描件缺报告编号绿色SKU缺少库存对应图片规范性3充电参数写成5V/2A未标注单位容量单位在ml和L之间混用图片一致性3主图杯身颜色为白色标题写抹茶绿图上有600ml水印实际规格为500ml价格合理性2绿色SKU售价139元划线价199元折扣力度约7折但成本价120元毛利偏低活动冲突0本次活动信息与价格库存无冲突这个分布很有参考价值一致性类问题最多这也是人工审核最容易漏掉的部分。模型一次性把这些差异找出来省去了运营在多个文件之间反复切来切去的痛苦。4.3 几个典型问题的处理细节我挑三个当时印象最深的问题展开说。第一个是容量标识不一致。规格参数表里是500ml详情页正文第一段写的是600ml商品主图的OCR文本里又出现了600ml水印。人工只看单个文件根本发现不了问题因为每个文件内部读起来都挺通顺。模型把三个来源放在同一个上下文里对比后立刻给出容量信息存在三处冲突的结论。修复建议也很明确以规格参数表为准或确认实际容量后统一所有位置。第二个是合规风险。详情页文案里的最强榨汁和活动说明里的全网最低价都是绝对化用语。这类词如果靠关键词字典确实也能命中一部分但模型能看到上下文能更好判断最强是在描述性能还是在违规宣传减少误报。第三个是图片一致性。商品主图显示杯身是白色但标题和商品基础信息表里写的颜色是抹茶绿。这种错误发生的原因一般是运营套用了旧图或者颜色字段填错。模型返回问题时还把图片OCR里识别到的白色字段一并列出修复建议是重新拍摄或替换主图同时核对基础信息表颜色字段。5. 避坑指南与问题排查5.1 常见问题速查表我把自己在这套方案落地过程中遇到的典型问题整理成了一个速查表方便你直接对照排查现象可能原因处理办法模型返回的JSON解析失败未开启结构化输出或温度过高设置response_format为json_object降低temperature到0.2以下漏检某个文件里的问题上下文太长模型注意力分散拆分为多轮检查每个文件或每个维度单独调用一次把没问题说成有问题提示词范围太宽模型过度发挥增加仅基于资料中明确出现的信息判断不推测同一问题重复出现多次多个维度都触发同一异常在提示词中增加去重规则同一问题只输出一次问题定位不到具体文件提取阶段丢失了来源信息在抽取阶段要求模型输出每条信息的source_file字段处理速度太慢单次调用塞入过多内容评估token数文本超过2万时优先做分块再做结果合并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个问题里有好几个就是模型主动补出来的比如规格参数表里电压值标注方式不符合平台规范这种细颗粒问题。开放项既能兜底又能帮你发现之前没考虑到的审核盲区。 用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张商品图分别对应真实的商品上架前常见的文件集合我按实际使用频率整理成了一张清单序号资料名称常见格式主要内容1商品基础信息表Excel/CSV商品名称、标题、卖点、类目、品牌、产地2规格参数表Excel/Word型号、尺寸、重量、功率、容量、材质、执行标准3详情页文案Word/Markdown商品卖点描述、功能说明、使用场景、营销文案4价格与库存表Excel/CSV售价、划线价、成本价、库存数量、SKU编码5资质与证书文件PDF/图片质检报告、3C认证、授权书、检测标准编号6营销活动说明Excel/Word活动名称、优惠力度、赠品信息、活动时间7商品主图JPG/PNG商品外观图、包装图、宣传视觉实际业务里还可能更多比如说明书、售后政策、物流说明但核心配置就是这七类。很多错误不是某个文件内部的问题而是文件与文件之间对同一事实的描述不一致。所以第一步要做的不是检查而是把不同格式的资料拉平放到同一个结构里。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个问题不是瞎数的我在模型输出格式里强制要求了多维度的检查项。每个维度下预置了一些子项同时允许模型补充它认为重要的额外问题。我最终使用的检查维度如下维度检查内容典型问题示例完整性必填字段是否缺失、证书是否缺失缺少质检报告编号、缺少规格表中的材质一致性不同资料对同一信息的描述是否矛盾标题写500ml参数表写600ml合规性是否含极限词、违禁词全网销量第一、最强吸力、绝对化用语规范性单位、格式、数值范围是否规范电压写成5V/2A、容量单位不统一为ml图片一致性图片展示内容与参数/文案是否一致主图标颜色绿色实际图片是白色价格合理性划线价、售价、成本之间关系是否合理划线价与售价差值异常、成本高于售价活动冲突活动信息与价格、库存、赠品是否冲突活动写全店包邮实际商品为海外直邮我在提示词里把每个维度都展开成具体的检查指令同时要求模型输出问题时必须带上发现该问题所在的文件来源不能只给一个结论。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.1top_p调到0.9。温度低是因为审核任务要的是稳定、可复现的结果不需要创造性发挥。如果你发现模型漏检或者误报先不要急着改温度先检查是不是Prompt里把检查维度描述得不够具体。3.3 关键代码实现调用Qwen3.8-Max的完整流程下面这段代码是我这个项目里的核心流程简化掉了一些业务细节。整体思路是读入多份资料 - 用第一轮调用抽取并归纳资料 - 组装成统一JSON - 用第二轮调用得到问题列表 - 解析JSON并生成报表。import json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlyour_dashscope_base_url # 以官方SDK文档为准 ) def load_documents(file_paths: dict) - str: 加载多份资料并拼接成文本用于第一轮抽取。 sections [] for key, path in file_paths.items(): with open(path, r, encodingutf-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( modelqwen-max-v38, # 以官方模型版本为准 messages[ {role: system, content: 你是一个严谨的商品资料抽取器只输出JSON。}, {role: user, content: prompt} ], temperature0.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_asciiFalse)} 商品主图OCR文本 {image_ocr_text} 请按照系统指令中的7个检查维度检查问题输出JSON数组。 resp client.chat.completions.create( modelqwen-max-v38, # 以官方模型版本为准 messages[ {role: system, content: SYSTEM_CHECK_PROMPT}, {role: user, content: prompt} ], temperature0.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容量500mlTritan材质60W) print(json.dumps(issues, ensure_asciiFalse, indent2))实际项目中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个问题。我按维度做了统计检查维度问题数量典型例子一致性8详情页写600ml规格表写500ml标题写无线参数表却出现电源线长1.5米合规性6文案出现最强榨汁活动说明写全网最低价完整性5资质证书扫描件缺报告编号绿色SKU缺少库存对应图片规范性3充电参数写成5V/2A未标注单位容量单位在ml和L之间混用图片一致性3主图杯身颜色为白色标题写抹茶绿图上有600ml水印实际规格为500ml价格合理性2绿色SKU售价139元划线价199元折扣力度约7折但成本价120元毛利偏低活动冲突0本次活动信息与价格库存无冲突这个分布很有参考价值一致性类问题最多这也是人工审核最容易漏掉的部分。模型一次性把这些差异找出来省去了运营在多个文件之间反复切来切去的痛苦。4.3 几个典型问题的处理细节我挑三个当时印象最深的问题展开说。第一个是容量标识不一致。规格参数表里是500ml详情页正文第一段写的是600ml商品主图的OCR文本里又出现了600ml水印。人工只看单个文件根本发现不了问题因为每个文件内部读起来都挺通顺。模型把三个来源放在同一个上下文里对比后立刻给出容量信息存在三处冲突的结论。修复建议也很明确以规格参数表为准或确认实际容量后统一所有位置。第二个是合规风险。详情页文案里的最强榨汁和活动说明里的全网最低价都是绝对化用语。这类词如果靠关键词字典确实也能命中一部分但模型能看到上下文能更好判断最强是在描述性能还是在违规宣传减少误报。第三个是图片一致性。商品主图显示杯身是白色但标题和商品基础信息表里写的颜色是抹茶绿。这种错误发生的原因一般是运营套用了旧图或者颜色字段填错。模型返回问题时还把图片OCR里识别到的白色字段一并列出修复建议是重新拍摄或替换主图同时核对基础信息表颜色字段。5. 避坑指南与问题排查5.1 常见问题速查表我把自己在这套方案落地过程中遇到的典型问题整理成了一个速查表方便你直接对照排查现象可能原因处理办法模型返回的JSON解析失败未开启结构化输出或温度过高设置response_format为json_object降低temperature到0.2以下漏检某个文件里的问题上下文太长模型注意力分散拆分为多轮检查每个文件或每个维度单独调用一次把没问题说成有问题提示词范围太宽模型过度发挥增加仅基于资料中明确出现的信息判断不推测同一问题重复出现多次多个维度都触发同一异常在提示词中增加去重规则同一问题只输出一次问题定位不到具体文件提取阶段丢失了来源信息在抽取阶段要求模型输出每条信息的source_file字段处理速度太慢单次调用塞入过多内容评估token数文本超过2万时优先做分块再做结果合并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个问题里有好几个就是模型主动补出来的比如规格参数表里电压值标注方式不符合平台规范这种细颗粒问题。开放项既能兜底又能帮你发现之前没考虑到的审核盲区。