干了快五年电商运营我一直被一个事折磨上新前检查商品资料包。标题、详情页文案、属性参数、价格促销、SKU清单、资质证照再加上几张商品图每样都得过一遍。人工查费眼费神不查平台抽检一旦命中就是警告、降权、下架一条龙。前阵子我把这套检查流程交给了Qwen3.8-Max搭了一个商品资料包体检助手一次跑完6份资料加1张商品图直接查出27个问题。这篇文章就把从指标设计、提示词调优到实测复盘的完整过程写出来想搞自动化巡检的电商运营或产品经理可以直接抄作业。这个工具本质上做的事很朴素把一堆零散的商品资料包汇总起来按照预设的检查规则逐项核对把不一致、违规、缺失的地方标出来。适合谁用运营每周要上好几个新品的品控想建立审核SOP却懒得手动维护表格的开发想给电商后台加一个智能预检功能的都能在这套方案里找到自己需要的东西。1. 商品资料包为什么需要体检上架前的那堆隐形雷区1.1 一次让我印象深刻的翻车现场去年有一款保温杯上架我盯了半天详情页、价格、主图结果漏了一个致命问题详情页第三屏写着12小时长效保温属性参数表里写的是6-8小时。平台抽检抓到了这个不一致判定为虚假宣传链接被限流当时那批货的推广预算基本白烧了。这还不是最冤的。有次同事提交的SKU清单里规格写的是500ml*2只装但主图和标题都只提了单只装用户收到货之后炸了退货率直接拉满。这种问题靠人眼逐行比对早晚会漏。尤其在大促前运营一天要过几十个链接谁有精力把每个字都校一遍1.2 资料包体检的定义域到底应该检查哪些资料我这次设计的体检方案覆盖了电商项目中最常见也最容易出问题的7类输入对应标题里的6份资料和1张商品图。商品标题标题本身就是流量入口也是最容易被极限词、违禁词击中的地方。详情页文案详情页是转化核心也是信息不一致的重灾区尤其是材质、尺寸、售后承诺这些具体参数。属性参数表规格参数后台填写的结构化参数很多运营会复制粘贴上一款商品导致新旧信息混在一起。价格与促销方案包括划线价、销售价、满减、优惠券叠加这里算错轻则亏损重则被平台判定为价格违规。SKU清单规格组合、库存数、条码这块问题往往很隐蔽但一错就影响发货和库存管理。资质与证照质检报告、授权书、商标注册证这类文件最容易出现文件过期或者主体不一致的情况。商品图主图或详情页长图图片上的文字信息和文本资料信息经常打架比如图上标48小时内发货但详情页写7天内发货。1.3 为什么我用规则模型双引擎而不是只靠提示词一开始我也试过直接把所有资料丢给大模型问一句帮我看看有没有问题。结果模型输出了一堆含糊的可能建议很多还不是真问题全凭它在发挥。后来我想明白了商品资料包体检这件事真正靠谱的做法是规则引擎定边界大模型做判定。先由人工把平台规则和常见违规点固化成一套检查清单比如标题中不能出现绝对化用语详情页质保年限必须与售后说明一致然后让Qwen3.8-Max去执行具体的抽取、比对、判定动作。模型负责理解文字语义规则负责界定什么是对错这样既避免了纯规则引擎的僵硬也避免了纯大模型的天马行空。2. 体检指标怎么设计27个问题是从哪拆出来的2.1 从平台审核规则反推检查项设计检查项的思路倒不是坐在那凭空拍脑袋而是从两个地方找依据。一是平台明面上的高频违规点。极限词和绝对化用语这是老生常谈了第一顶级极致全网最低价这类词命中一条就是一个违规记录。虚假宣传和描述不符比如材质、产地、功能参数在标题、详情页、属性表里讲的不一样。价格违规像划线价无依据、促销价高于最近成交价、价格计算逻辑不对。SKU作弊用低价SKU引流实际上主推SKU根本不是那个价这是平台重点打击的对象。资质问题质检报告上的产品名和商品标题对不上或者报告已过有效期。二是从实际踩坑经历里提炼。那些年人工漏检出来的问题一条条记录下来反推成一个一个具体的检查项。2.2 27个问题的分类与编号规则我最后整理出一份包含27个检查项的体检清单为了让模型输出结构化结果每个检查项都给了编号、类型、检查内容、涉及资料。编号问题类型检查内容涉及资料T01-T05标题合规极限词、绝对化用语、字数、品牌词一致性、违禁词商品标题I01-I06信息一致性材质/尺寸/质保/发货时间/产地等信息在标题、详情页、属性表中是否一致商品标题、详情页、属性参数表、商品图P01-P05价格促销划线价无依据、折扣计算错误、促销文案与价格逻辑冲突价格与促销方案、详情页S01-S04SKU与库存SKU规格组合错误、库存负数、低价引流、条码缺失SKU清单、主图A01-A04资质证照证件过期、产品名称不一致、主体不一致、授权链不完整资质与证照文件M01-M03图片与文字图上文字与文本资料不一致、图片清晰度不够、品牌logo覆盖商品图、详情页这样设计的好处是模型输出问题编号后我能直接对到是哪一类问题方便后续修复和统计。读者如果在自己项目里做不需要完全照抄这个编号但建议保留类型编号的方式后面自动处理会方便得多。2.3 每条检查项的判定逻辑检查项定了还要给模型讲清楚怎么判定。这里特别关键因为模型不理解你觉得哪里有问题这种开放式问题它需要的是明确的判定规则。举个例子检查项I02质保年限一致性。判定逻辑是从商品标题中抽取质保年限从售后保障说明中抽取质保年限从属性参数表保修期字段中抽取质保年限三个值做比对不一致则判定为问题。如果有的资料里没提到质保那就标为信息缺失属于需要人工确认的弱问题。再比如检查项A01质检报告是否过期。判定逻辑是从质检报告文件中提取发证日期和有效期和当前日期比对如果文件里没有有效期就要结合报告类型常识判断证书是否在有效期内。这块大模型泛化能力比较强PDF、图片里的日期都能抽出来但输出格式需要约束好不然日期格式乱七八糟。3. 动手搭体检助手Qwen3.8-Max在我这套方案里的定位3.1 整体思路检验清单在前大模型在后很多朋友一听到用大模型搭工具第一反应是那是不是把所有材料扔给它它就能自己判断。我的经验是还行就是官网的入口不太好找层级挺深的。我最后是通过官方提供的开放接口接入的申请好API之后按文档参数调通就行。模型本身的优势是上下文长度够大能一次性吃下好几份资料而且对中文电商场景的表述方式理解得比较到位比如全网最低限量抢购踩屎感这种电商黑话它在判定的时候不会机械地当违禁词处理。3.3 结构化输出直接产出体检报告模型判定之后输出的结果不是一句我分析完了没问题而是一份结构化的JSON体检报告。每一处问题都包含问题编号、严重级别、命中的资料、具体描述和修改建议。严重级别分为三级High高风险涉及平台处罚或重大客诉、Medium中等风险涉及用户理解偏差、Low低风险仅是信息缺失或表达不规范。{ report_id: R20250616_001, total_issues: 27, by_severity: { High: 6, Medium: 14, Low: 7 }, issues: [ { issue_id: T02, severity: High, description: 标题包含绝对化用语「顶级」违反广告法要求, evidence: 标题原文XX品牌顶级不锈钢保温杯, suggestion: 删除「顶级」改为XX品牌不锈钢保温杯大容量便携款 }, { issue_id: I04, severity: High, description: 详情页写明48小时内发货商品图中标注7天内发货两者存在冲突, evidence: 详情页第四屏「发货时间48小时」主图左上角角标「7日内发货」, suggestion: 统一发货承诺建议以更短的48小时为准 } ] }有了这份JSON报告后续接自动化流程就很顺了。我还顺手写了个脚本把报告里的问题渲染成带颜色标签的HTML页面运营同学打开链接就能看不用碰原始数据。包括主图水印文案的去重、品牌英文名与中文名混用导致的疑似不一致这类低危提示模型也会用上下文去判断不硬报问题。这块让我最满意因为好用的体检助手不是话越多越牛而是知道哪些不必说。4. 实测复盘6份资料和1张商品图查出了哪些问题空谈没有意义我把一次真实的体检过程完整复盘一遍。这次用的是一批新上市的食品保温袋提交了6份资料加1张主图Qwen3.8-Max跑完之后输出了27个问题。下面按类型拆开看。4.1 标题与主图类4个问题标题类问题一共4个最典型的是T02标题里用了顶级两个字被判定为High级风险。另外T03是标题超过30个字符虽然平台提示了最长限制但运营没注意到模型把它标为Medium级因为长标题在部分类目下会被截断展示直接影响点击率。主图类问题里M01命中了。商品图里用了一行小字标加厚款赠送收纳袋但SKU清单和详情页里都没有提到赠品这属于典型的图上承诺和后台配置不一致用户下单后没收到赠品纠纷没跑。4.2 详情页与属性参数表的信息一致性9个问题信息一致性是这次体检中问题密度最高的类别27个问题里占了9个。最典型的是I04详情页承诺48小时内发货主图左上角却标注7日内发货顾客下单前看到两个完全不同的发货时间全凭运气理解差评预订。还有一处检验细节属性参数表里填料成分与详情页描述不一致。详情页写的是食品级PP材质不含双酚A属性参数表里材质字段却写着PPAS模型很敏锐地把它标了出来。我后来查证发现AS材质确实不符合食品级要求如果当时没发现质检环节很可能出问题平台对食品级材质的管控特别严格。4.3 价格、促销与资质类14个问题价格类问题有5个典型的比如P02划线价399元销售价199元折扣率算下来是5折但促销文案写的是限时4折抢购。这种文案和数字打架的情况顾客可能觉得折扣换算不对遇到较真的甚至会被投诉为虚假促销。这类问题人工核对特别容易漏因为要看文案、价格表、系统后台三处数据而模型可以在同一轮里把它们全部对比完。资质类问题4个A01是质检报告的有效期到上个月就截止了新品上架前需要更新报告。A03是质检报告上的产品名称写的是便携保温包和商品标题里的不锈钢保温袋不一致如果审核员严格一点这就是一个描述不符的瑕疵。还有个有意思的模型把主图左上角标了7日内发货详情页写48小时内发货判为High把SKU清单里规格名称为『大号/小号』属性参数表的规格字段是『XL/均码』判为Medium。前者影响用户预期后者主要影响后台筛选和运营管理。这种分级的能力是纯规则引擎很难做到的。4.4 人工复核之后的价值评估模型查出27个问题之后我又逐条做了人工复核。最终确认15个问题是确认的如果不修复上架后大概率引发客诉或平台警告7个问题属于需要运营决策的模糊项比如顶级这个词在部分类目的官方规则里可以有条件使用但不是所有运营都知道边界模型统一标出来更稳妥还有5个是真误报集中在一些需要结合行业常识判断的地方。这个比例完全可以接受。误报在大模型应用中很正常关键是用规则去压制误报率而不是指望模型100%准确。体检助手做的是把100个可能的问题缩到27个人工只需处理27条比从0开始翻几百屏资料轻松太多。5. 跑通之后稳定性调优和几个踩过的坑5.1 提示词里最容易被忽视的部分是输出格式和证据引用提示词工程在这套方案里很关键。我的经验是提示词至少包含三部分角色定义、检查清单与判定逻辑、输出格式要求。其中输出格式要求是稳定性的基石如果这里写不清楚模型就可能给你返回参差不齐的内容后续脚本解析起来会分裂。对应到代码里推荐使用结构化的提示词模板把检查项定义和判定逻辑单独组织成文本块避免每跑一轮都去改大段提示词。prompt f 你是一名电商商品资料包审核专家。请依据以下检查清单对提供的资料包逐项检查。 每一项检查请给出结论PASS通过、FAIL不通过、REVIEW需人工确认。 检查清单 {checklist_text} 判断规则 1. 若标题、详情页、属性参数表、商品图中的同一信息如材质、尺寸、发货时间、质保年限存在彼此矛盾的值判定FAIL并列出冲突信息。 2. 若文本信息中存在绝对化用语或平台明确禁止的表达判定FAIL。 3. 若某资料缺失且无法判断判定REVIEW不要自行推测。 4. 对于每一条FAIL和REVIEW必须引用原始文本作为证据。 请严格输出JSON格式 {{ total_issues: 0, issues: [ {{ issue_id: , severity: High/Medium/Low, description: , evidence: }} ] }} 资料包内容 --- 商品标题: {title} 详情页文本: {detail_text} 属性参数表: {attrs_text} 价格促销: {promotion_text} SKU清单: {sku_text} --- 第一个坑JSON格式不稳定。我一开始在输出格式里写了请返回JSON但模型偶尔会在JSON外面加注释、加markdown代码块标记甚至某个字段缺失导致解析失败。解决办法是在提示词里明确声明只返回JSON不要包含额外的解释和markdown标记并在代码里加入二次解析的逻辑一次解析失败就尝试剥离代码块标记再做一次。温度参数也建议调低我用的是0.2太高的温度会让输出跳跃。第二个坑资料包里的图片不是纯数字图片可能包含复杂的场景照、水印、促销标签。如果直接让模型看图它对水印小字的识别率并不稳定。我在实际方案中采用了OCR模块先将图片中的文字抽出来再和商品文本一起交给模型判定。这里有个细节OCR抽出的文本没有阅读顺序模型拿到一堆乱序文本后容易误判所以我会在OCR结果里加上坐标信息比如主图左上角7日内发货这样模型能结合位置语义。5.2 调优过程中的几个实测发现调优过程中有几个现象值得一提。第一个是负面示例比正面示例更有用在提示词里加入几条常见误判示例能显著降低误报率。比如属性参数表里写了『品牌: XX』但详情页首屏是品牌故事不要误判为信息不一致。第二个是REVIEW这个中间态价值很大。刚开始我只有PASS和FAIL两种结论结果模型在遇到缺失信息时要么硬判FAIL要么含糊带过。加了REVIEW之后模型更愿意承认不确定这样人工复核的关注点更聚焦了。跑了三轮之后High级问题的准确率稳定在85%以上Medium级75%左右其余靠人工兜底。第三个发现是上下文越长越要在提示词里强调依据原始文本不要做推断。大模型在上下文很长时容易自己脑补信息。我在判定规则里明确写了若原始资料中未出现该信息请标注为缺失不要推测这条规则对控制幻觉帮助很大。5.3 效率对比和可以预见的扩展方向人工检查一套资料包之前的耗时大概在30到45分钟眼睛不花是不可能的。我用这套体检助手跑完一套资料包解析加模型判定加报告生成总共不到3分钟。检查质量上人工逐行核对容易漏掉跨文档的矛盾模型则是每一次都穷尽全量资料做比对覆盖率高出一截。后续想扩展的方向第一个是自动生成整改后的商品文案。模型已经能指出标题包含绝对化用语『顶级』那下一步就可以让它基于原有标题自动改写一版合规的改完再跑一遍体检形成一个检查-修改-复检的闭环。第二个方向是沉淀各平台、各类目的检查规则库。不同平台对违禁词、价格展示的要求不完全一样可以根据规则库动态生成体检清单而不是写死在代码里或者堆在一次提示词里。这样规则更新时不用改代码只需调整规则配置。第三个方向是结合运营后台自动化。从商品发布系统自动拉取资料包跑完体检报告后回传状态有High级问题就拦截上架Medium级问题推送提醒Low级问题仅记录。这一步把原本靠人盯的上新流程变成半自动的质量闸门。写在最后的实际感受从设计检查清单到跑通第一份体检报告再到现在能比较稳定地每次输出二三十个问题最大的收获不是省了多少时间而是把过去五年在电商项目里碰过的坑沉淀成了一套可以反复使用的检查逻辑。以前招新人要花很长时间教育他上架前到底要看什么现在我直接给他开一个体检助手的权限让他先看报告再对着报告去查原始资料上手速度快得不是一星半点。如果你也想在自己项目里搞这么一套东西我建议别一上来就追求大而全。先把你最近三个月被平台警告、被用户差评的案例翻出来一条条整理成检查项哪怕只有10条先跑通再慢慢加。工具的精度永远取决于清单的质量清单本身是会进化的这比任何建模技巧都重要。