上个月接手了一个电商项目的新品上架供应商一次性丢过来 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详情页文案】 {详情页文案内容} 【资料4SKU列表】 {SKU列表内容} 【资料5价格与促销策略】 {价格策略内容} 【资料6资质证明文件】 {资质文件描述} 【资料7商品主图描述】 {主图内容描述}这个顺序不是随便排的。我把“基准事实”排在前面把需要被核对的对象排在后面模型在生成回答时会优先参考前面已经“读入”的信息做判断整体的一致性核对准确率会高一些。第三步是输出格式定义。我给了一个完整的 JSON Schema 示例并明确了“只输出 JSON不要输出任何解释性文字”的要求。这样后面解析和自动化就方便得多。3.3 商品主图的检查逻辑主图检查是这次体检里比较特殊的一块因为图片不是文本数据。我这边用 Qwen3.8-Max 的多模态能力先把图片转成结构化描述再做检查。具体检查项包括分辨率是否达到平台要求通常 800x800 以上背景是否为平台要求的纯色或白底主体是否完整有没有被裁切卖点标签是否遮挡了商品主体是否有非授权品牌 Logo图片上是否有水印、拼接痕迹或明显的牛皮癣要素这里有一个经验可以分享与其让模型直接基于图片做“合规判断”不如先让模型“描述图片内容”再进行规则判断。比如你先让模型说出“图片左上角有一个红色 Logo覆盖了商品标签区域”然后再用 Prompt 判断这个描述是否命中违规规则。分两步走结果稳定得多也方便定位具体问题。3.4 27 个问题是怎么分类的这次实际跑出来的 27 个问题本身也体现了检查项的覆盖面。我按模块统计了一下问题模块问题数量典型问题举例SKU 列表8条码重复、规格命名不统一、库存与状态矛盾详情页与规格一致性6重量单位不一致、颜色名称对应不上卖点文案合规5出现“全网第一”、无依据的数据宣称主图问题4分辨率不足、Logo 遮挡主体、背景非纯色价格策略3活动价低于成本、促销时间超期资质文件1质检报告有效期临近过期可以看到问题不是集中在一两个模块而是均匀分布在各个资料里。这也从侧面说明跨资料包的体检确实能发现很多平时人工核对容易忽略的角落。4. 一次完整的体检跑批实录理论聊完了实际操作过程也得说。这一节我完整还原一次跑批的过程包括输入准备、执行过程、问题输出和复核处理。4.1 输入准备从原始文件到模型输入我的自动化流程大致是把 6 份资料文件统一命名放到指定目录用脚本判断文件类型分别走不同的解析函数Excel 用 pandas 读转到 Markdown 表格PDF 先用 PDF 解析库抽文本再按页合并图片走多模态描述接口生成描述文本所有内容按预设模板拼接组装成最终 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 条码重复、详情页参数矛盾——几乎都能在第一次体检时暴露出来。以前这些问题是等着平台审核打回或者客户投诉之后才发现的现在前置到了上架之前。回过头来看这个项目最核心的一点经验是不要指望大模型一步到位解决所有问题。我把检查项拆碎、把输出结构定死、把重要字段加了置信度标记、把敏感词检测拆给规则词典这些“笨功夫”才是整个工具稳定可用的真正原因。如果你也要做类似的事情我建议先把检查项设计这件事做到极致再考虑模型调用的工程细节。
用大模型打造电商商品资料包智能体检助手：检查项设计与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详情页文案】 {详情页文案内容} 【资料4SKU列表】 {SKU列表内容} 【资料5价格与促销策略】 {价格策略内容} 【资料6资质证明文件】 {资质文件描述} 【资料7商品主图描述】 {主图内容描述}这个顺序不是随便排的。我把“基准事实”排在前面把需要被核对的对象排在后面模型在生成回答时会优先参考前面已经“读入”的信息做判断整体的一致性核对准确率会高一些。第三步是输出格式定义。我给了一个完整的 JSON Schema 示例并明确了“只输出 JSON不要输出任何解释性文字”的要求。这样后面解析和自动化就方便得多。3.3 商品主图的检查逻辑主图检查是这次体检里比较特殊的一块因为图片不是文本数据。我这边用 Qwen3.8-Max 的多模态能力先把图片转成结构化描述再做检查。具体检查项包括分辨率是否达到平台要求通常 800x800 以上背景是否为平台要求的纯色或白底主体是否完整有没有被裁切卖点标签是否遮挡了商品主体是否有非授权品牌 Logo图片上是否有水印、拼接痕迹或明显的牛皮癣要素这里有一个经验可以分享与其让模型直接基于图片做“合规判断”不如先让模型“描述图片内容”再进行规则判断。比如你先让模型说出“图片左上角有一个红色 Logo覆盖了商品标签区域”然后再用 Prompt 判断这个描述是否命中违规规则。分两步走结果稳定得多也方便定位具体问题。3.4 27 个问题是怎么分类的这次实际跑出来的 27 个问题本身也体现了检查项的覆盖面。我按模块统计了一下问题模块问题数量典型问题举例SKU 列表8条码重复、规格命名不统一、库存与状态矛盾详情页与规格一致性6重量单位不一致、颜色名称对应不上卖点文案合规5出现“全网第一”、无依据的数据宣称主图问题4分辨率不足、Logo 遮挡主体、背景非纯色价格策略3活动价低于成本、促销时间超期资质文件1质检报告有效期临近过期可以看到问题不是集中在一两个模块而是均匀分布在各个资料里。这也从侧面说明跨资料包的体检确实能发现很多平时人工核对容易忽略的角落。4. 一次完整的体检跑批实录理论聊完了实际操作过程也得说。这一节我完整还原一次跑批的过程包括输入准备、执行过程、问题输出和复核处理。4.1 输入准备从原始文件到模型输入我的自动化流程大致是把 6 份资料文件统一命名放到指定目录用脚本判断文件类型分别走不同的解析函数Excel 用 pandas 读转到 Markdown 表格PDF 先用 PDF 解析库抽文本再按页合并图片走多模态描述接口生成描述文本所有内容按预设模板拼接组装成最终 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 条码重复、详情页参数矛盾——几乎都能在第一次体检时暴露出来。以前这些问题是等着平台审核打回或者客户投诉之后才发现的现在前置到了上架之前。回过头来看这个项目最核心的一点经验是不要指望大模型一步到位解决所有问题。我把检查项拆碎、把输出结构定死、把重要字段加了置信度标记、把敏感词检测拆给规则词典这些“笨功夫”才是整个工具稳定可用的真正原因。如果你也要做类似的事情我建议先把检查项设计这件事做到极致再考虑模型调用的工程细节。