用Qwen3.8-Max搭建电商商品资料体检助手，自动揪出27个上架问题

上周运营那边扔过来一批商品资料包说上架审核又被打回来了让我帮忙看看问题出在哪。我打开文件夹一看6份文档加1张商品主图零散塞在同一个目录里命名还是“最终版2.0(1)(2)”这种鬼样子。最开始我打算人工翻一遍结果翻了不到三份眼睛就花了——标题里藏着疑似极限词、属性表写的是300g详情页却印着500g还有一张主图的白底明显发灰。这种问题靠人眼一个个比对效率实在太低。于是我就用 Qwen3.8-Max 搭了一个电商商品资料包体检助手把这6份资料和1张商品图全部喂进去一次性输出了27个问题每个问题都标了严重等级和修改建议。整个过程从写脚本到拿到体检报告不到半天时间后面每次来新商品都能直接复用。今天把整个思路、代码和踩坑过程完整拆出来做电商运营、做商品上架管理、或者在小团队里兼着做内容合规的同学都可以直接参考。1. 项目背景与整体方案选型1.1 一个真实的电商商品资料管理痛点先说说这事儿的背景。电商商品上架特别是平台店铺运营每个商品涉及到的资料远不止一张图一段文案。以我这次接手的为例一个普通商品至少要准备这些商品主图、详情页长图、商品标题文案、五点卖点描述、属性参数表、价格与库存表。这还只是基础档如果涉及特殊品类还要加资质文件、检测报告。资料一多问题就来了。不同资料之间信息不一致是最常见也最坑的情况。属性表写的是500g详情页印的是300g标题写的是“多色可选”但SKU表里只有一个颜色主图展示的是黑色款五点描述里却在讲白色款怎么好看。这些问题在人工审核时非常容易漏掉因为检查的人往往只看单份资料不会把6份资料逐字逐句做交叉比对。另外还有合规类问题。平台对商品标题和详情页的用词有明确限制极限词、医疗功效词、夸大宣传词都是雷区。这类词藏在长文案里人工很难一一排查干净特别是每次上新品都要重复检查效率非常低。一套能自动扫描、自动比对、自动出报告的“体检助手”在这种场景下就特别有价值。1.2 为什么选择 Qwen3.8-Max 而不是本地小模型或纯规则可能有同学会说这种检查任务写个正则不就能搞定吗极限词用词表匹配参数不一致用程序比对为什么非要上个多模态大模型我的判断是这样的纯规则方案可以解决一部分问题但解决不了“理解类”的问题。举个例子主图底色到底是不是纯白这不是正则能判断的详情页里那句话到底算不算医疗功效宣称也需要语义理解标题里的“最低价”是不是极限词依赖上下文。这些任务本质上需要模型同时理解图像和文本并且做跨文档的语义对齐。Qwen3.8-Max 最吸引我的点有两个。第一是多模态能力它可以直接读图主图的背景、主体位置、清晰度、水印遮挡这些都能识别不需要我单独再搭一套OCR或者图像分类服务。第二是长上下文和指令遵循能力6份资料加1张图的文本信息全部拼进去仍然可以稳定输出结构化的JSON结果。这两点加在一起让它特别适合做这种“跨文件体检”型任务。本地小模型我也试过但效果不行。7B、14B级别的开源模型在处理这种多文档综合比对时经常出现漏报而且对图像细节的感知明显不如大参数模型。与其花时间调小模型不如直接跑 API把精力放在体检规则的设计上——那才是这个项目的真正核心。1.3 体检助手的工作流设计整个体检助手不是“一股脑把资料丢给大模型让它自由发挥”而是设计成两条线并行先用规则引擎做机械性初筛再用大模型做语义层面的深度审查。这样设计的原因很实际。规则引擎跑得快、成本低、结果稳定适合处理那些有明确标准的检查项比如标题里是否有极限词、属性表里的参数是否在平台允许范围内、SKU价格是否符合区间逻辑等。而大模型负责的是那些需要“看图说话”和“跨文档理解”的部分比如主图的视觉质量问题、详情页文案与属性表的一致性、卖点描述是否存在虚假宣传倾向。两条线的结果最后合并进同一份报告。这样做的好处一是降低了大模型幻觉带来的风险二是把成本控制住了——规则引擎那部分不花钱只有真正需要语义判断的内容才走大模型。整个流程可以抽象成四步文件解析、结构化抽取、规则初筛、LLM深度审查、汇总报告。下面我一个个环节拆开讲。2. 体检项设计6份资料和1张图到底查什么2.1 一份电商商品资料包含哪些文件先说清楚这次处理的是哪6份资料。因为不同类目的资料会有差异我以这次实际处理的商品为例这个商品是一个小型家用电器资料结构是很多标品都适用的大家可以对照替换。第一份是商品主图通常是一张白底图800x800或1000x1000像素展示产品主体。这张图不光是视觉门面平台审核对背景色、占屏比例、是否有促销贴片都有要求。第二份是详情页长图一般5到10屏包含功能展示、参数说明、使用场景、售后保障等内容。第三份是商品标题文案也就是用户搜索时看到的那个标题一般要求45到60个字符以内核心关键词前置。第四份是五点卖点描述就是商详页里那种“产品特点”列表每条一两句话。第五份是属性参数表通常以表格形式存在列明品牌、型号、材质、净重、功率、保修期等结构化字段。第六份是价格与库存表往往是Excel格式包含各个SKU的规格、价格、库存数量、SKU编码等信息。这六份资料之间的信息是高度相关的属性参数表里写了净重详情页大概率也会提到标题里的卖点也应该从属性表里来。一旦这些信息对不上轻则审核驳回重则被平台判定为描述不符影响店铺信誉。我们的体检任务核心目标之一就是把这些“对不上”抓出来。2.2 五个体检维度一致性、合规性、格式、文案、逻辑在写提示词和规则之前我先定义了五个体检维度。这五个维度基本覆盖了商品资料审核的主要风险面。第一个维度是信息一致性。这个维度专门做跨资料比对检查主图看到的商品外观、标题描述的商品特性、属性表登记的技术参数、详情页展示的规格参数、SKU表里的价格库存这些信息之间是否存在矛盾。一致性问题是商品审核驳回里最常见的类型也是纯人工检查最容易遗漏的地方。第二个维度是合规性。重点扫极限词、医疗功效词、虚假宣传词、未授权资质宣称这几类内容。平台对这类词是零容忍的一旦被抓到可能直接限流甚至下架。这个维度我会用词表加语义双重判断。第三个维度是格式与形象。针对图片类资料检查主图背景是否为纯白底、图片是否清晰、水印是否遮挡主体、详情页文字是否过小、长图尺寸是否超限等。这些涉及视觉模型的判断是规则引擎无法替代的部分。第四个维度是文案质量。检查标题是否堆砌关键词、五点和详情页文案是否有重复啰嗦、参数单位是否缺失、是否有错别字或繁体字混用等。这类问题不影响合规但影响商品转化率和专业感。第五个维度是逻辑与配置。针对SKU表检查SKU数量是否超过平台限制、价格梯度是否异常比如最大差价超过合理范围、库存分配是否合理、是否存在规格与价格错位等情况。这部分需要结合SKU数据和平台规则做判断。2.3 设计27个检查项并给问题分级体检维度定好后我开始拆具体的检查项。最终拆成了27个可执行的问题检查项每个都归属到对应维度并设置了严重等级。等级我定义为P0、P1、P2三级。P0是必须修改的问题比如极限词、属性与详情页严重冲突、资质缺失这类问题不解决商品无法上架P1是强烈建议修改的问题比如价格梯度异常、主图背景不纯净、参数单位缺失这类问题不解决可能影响审核通过率或转化率P2是优化建议比如文案重复啰嗦、关键词布局不合理这类问题不影响上架但值得调整。严重等级的设置很重要不然27个问题混在一起运营同学根本不知道先处理哪个。有了分级拿到报告后按P0到P2的顺序逐项处理就行省去了大量排序讨论的时间。下面这张表是27个检查项的完整清单按维度分好了组维度检查项等级信息一致性标题核心卖点与属性参数表不一致P0信息一致性详情页参数与属性参数表存在冲突P0信息一致性主图展示款式与商品标题描述不符P0信息一致性五点描述中提到的功能在属性表中无对应参数P1信息一致性SKU规格名称与属性参数表不一致P1信息一致性价格区间与实际SKU价格不匹配P1合规性标题包含极限词如“最”“第一”P0合规性详情页含医疗功效宣称词P0合规性卖点文案存在虚假宣传表述P0合规性商品资质宣称无对应文件支撑P1合规性详情页存在引导评价违规内容P1合规性宣传语含夸大性能表述P2合规性标题含非必要促销词堆砌P2格式与形象主图背景非纯白底P1格式与形象主图存在水印遮挡主体P1格式与形象主图清晰度不足有锯齿感P2格式与形象详情页长图尺寸超平台限制P1格式与形象详情页字体过小阅读困难P2格式与形象主图促销标签遮挡商品主体P1文案质量标题关键词堆砌且可读性差P2文案质量五点描述存在重复内容P2文案质量属性参数缺失计量单位P1文案质量文案含错别字或繁体字P2逻辑与配置SKU数量超过平台限制P1逻辑与配置同一商品SKU间价差异常P1逻辑与配置库存为0的SKU未及时下架P1逻辑与配置规格命名混乱导致SKU识别困难P2这27个检查项不是拍脑袋定的而是结合了平台审核规则、日常运营踩坑记录以及这次实际遇到的一批问题。大家在落地时可以根据自己的类目删减或新增。类目不同合规重点差异会非常大比如食品类和电器类关注的点就完全不同。3. 实战从零手写商品资料包体检助手3.1 环境准备与依赖安装体检助手我用 Python 来写这是AI原生应用里最顺手、生态最全的语言。核心依赖库只有几个python-docx 用来解析Word文档openpyxl 用来读Excel表格Pillow 用来做图片的基础处理还有 OpenAI 兼容客户端用来调用 Qwen3.8-Max 的接口。安装依赖直接 pip 一把梭pip install python-docx openpyxl pillow openai这里有一个细节要提醒大家。如果你接的 API 是兼容 OpenAI 协议的话直接用 openai 这个 SDK 就行只需把 base_url 指向对应服务的地址把 api_key 配置好。不需要再额外封装一层 HTTP 调用省很多事。调通之后建议先跑一个最小测试确认 Qwen3.8-Max 的多模态接口能不能正常返回结构化结果。我当时的测试代码大概长这样from openai import OpenAI client OpenAI( api_keyos.getenv(QWEN_API_KEY), base_urlos.getenv(QWEN_BASE_URL) ) resp client.chat.completions.create( modelqwen3.8-max, messages[ {role: user, content: 介绍一下你自己用3句话说} ] ) print(resp.choices[0].message.content)能正确返回内容就说明环境没问题了。api_key 和 base_url 建议通过环境变量加载不要写死在代码里这不是什么新技巧但确实是很多人容易忽略的安全问题。3.2 文件解析把6份资料变成模型能读的文本体检的第一步是把各种格式的资料解析成文本或图片数据。这一步看似简单其实坑很多。对于Word格式的标题文案、五点描述、属性参数表用 python-docx 解析遍历文档中的所有段落和表格按块提取文本。对于Excel格式的价格库存表用 openpyxl 读取每一个sheet然后转换成JSON结构保留“SKU编码、规格、价格、库存”这几个关键字段。详情页长图这种不会直接转成文本而是保留为图片后面通过 Qwen3.8-Max 的视觉能力来做分析。这里只能先把图片压缩到合适尺寸避免请求体积过大导致超时。解析部分我写了一个简单的函数from docx import Document def parse_docx_table(filepath): doc Document(filepath) rows [] for table in doc.tables: for row in table.rows: cells [cell.text.strip() for cell in row.cells] rows.append(cells) return rows不同版本的Word文档解析结果可能不太一样表格合并单元格会导致某行内容重复解析完最好肉眼抽查一遍。这一步漏了后面全白干因为模型拿到的本身就是错误数据。3.3 规则引擎先用低成本手段扫掉机械类问题文本解析完先别急着把全部内容丢给大模型。我建议先跑一轮规则引擎把那些不需要语义理解就能判断的检查项处理掉。这样做的好处非常明显一是快二是准三是不费token。规则引擎处理哪些项我在代码里先定义了一个规则列表每一项有一个检查函数输入解析好的商品资料字典输出结果列表。比如极限词检查维护一份极限词词表对标题和卖点文案做包含匹配BANNED_WORDS [最, 第一, 顶级, 极致, 全网最低, 永久, 绝对] def check_banned_words(text): hits [] for word in BANNED_WORDS: if word in text: hits.append(word) return hits注意极限词检查不能纯做字符串匹配因为有些词在特定语境下是合法的。比如“最近更新”里的“最”并不是商品宣传层面的极限用词。所以规则引擎跑出来的命中结果只能作为“疑似问题”最终判定还是要看大模型或人工复核。规则引擎的价值是缩小排查范围不是取代最终判定。SKU价格逻辑检查同样适合用规则做。比如计算同一商品所有SKU价格的最高、最低值如果最大价差超过某个阈值就标记为异常。这个阈值按类目而定我这次设的是300%超过就报警。规则引擎跑完会产出一批硬性问题。这些问题直接写入报告不再走大模型复核因为它们的判断标准是确定的。3.4 LLM深度审查用提示词把体检专家经验写进去规则引擎处理不了的才轮到 Qwen3.8-Max 上场。深度审查包含两块一是对图片资料的视觉审查二是对多份文本资料做语义层面的综合比对。提示词设计是整个项目最核心的部分。我一开始图省事写了个“请检查这些商品资料的问题”这种模糊指令结果模型输出了七八条泛泛而谈的意见完全没有按照我定义的体检维度来。后来我把提示词改成了结构化约束式明确告诉模型要检查哪些维度、输出什么格式、每个字段什么含义效果立刻不一样。我用的提示词框架大概是这样的你是一名资深的电商商品合规审核专家拥有5年主流电商平台商品审核经验。 现在请对以下商品资料执行一次全面体检。 资料包括 1. 商品标题{title} 2. 五点卖点描述{bullet_points} 3. 属性参数表{attributes} 4. SKU价格库存表{sku_data} 5. 详情页长图{detail_image} 6. 商品主图{main_image} 请从以下5个维度进行检查 1. 信息一致性标题、详情页、属性表、SKU之间的信息是否一致 2. 合规性极限词、医疗功效宣称、虚假宣传、违禁词 3. 格式与形象主图背景、清晰度、水印遮挡、详情页排版 4. 文案质量堆砌、重复、错别字、单位缺失 5. 逻辑与配置SKU价格、库存、规格命名是否合理 输出要求 - 以JSON数组格式输出不要输出其他任何解释文字 - 每个问题包含字段dimension维度、severity严重级别P0/P1/P2、issue问题描述、evidence依据引用具体原文或图片区域、suggestion修改建议 - 只输出真实存在的问题不要编造这里有两个关键点。第一是“只输出真实存在的问题不要编造”这句话是给模型打的一剂预防针能在一定程度上降低幻觉率。第二是“以JSON数组格式输出不要输出其他任何解释文字”这能让后续的程序直接解析结果不用在自然语言里扒拉数据。参数设置上我把 temperature 调到了0.1max_tokens 设置为2000。温度越低输出越确定适合这种检查任务。太高的温度会让模型在遇到模糊内容时“自由发挥”产生大量不靠谱的问题描述。3.5 主图和详情图的多模态检查文本部分的体检提示词相对简单复杂的是让模型理解图片内容。Qwen3.8-Max 支持图片输入我可以直接把主图和详情页长图传给模型让它在给出的上下文里完成“看图找茬”。这里要特别注意一个细节图片传给模型之前必须做压缩。原图如果是个5MB、3000x3000像素的文件直接塞进API请求里一是速度慢二是有可能超出服务端的单张图片大小限制。我实际的做法是把图片先缩放到最长边1024像素以内再转成base64编码嵌入请求。from PIL import Image import base64, io def compress_image_to_base64(filepath, max_size1024): img Image.open(filepath) img.thumbnail((max_size, max_size), Image.LANCZOS) buffer io.BytesIO() img.save(buffer, formatJPEG, quality85) return base64.b64encode(buffer.getvalue()).decode()压缩之后图片依然能保留足够的视觉信息供模型判断背景色、水印遮挡、清晰度这类问题但请求体积能缩小到原来的十分之一响应时间大幅改善。调用多模态接口时把图片的base64作为消息内容的一部分传过去和文本放在同一个content数组里。这样模型就能同时看到6份资料的文字和两张图的画面在做一致性判断时可以参考图片中的实际视觉信息。3.6 报告汇总按问题等级输出一份可执行的体检单规则引擎的命中和 Qwen3.8-Max 的审查结果最后要合并成一份统一的报告。合并的逻辑很简单两条线的结果都转成一个统一的字典结构然后按严重等级排序P0排最前面P2排最后。报告我选择了输出成Markdown格式因为Markdown在文档工具里直接就能预览也方便转成别的格式。每一条问题输出为一条清单包含等级标签、维度、问题描述、原始证据、修改建议。## 体检结果 ### P0必须修改 1. [合规性] 标题含极限词“最” - 位置商品标题第3个词 - 原文“全网最轻便” - 建议删除“最”或改为“超轻便”这样处理的报告运营同学拿到手就可以直接照着改不需要再去翻原始资料确认问题位置。把“体检报告”做成“可直接执行的任务清单”是这个项目能够真正落地、而不是停留在demo层面的关键。体检的最终目的不是发现问题而是让问题被快速解决。4. 案例复盘一次真实体检的27个问题4.1 从6份资料到27个问题的完整结果规则引擎和深度审查都跑完之后我拿到了第一份完整的体检报告一共27个问题和我预期差不多。其中P0级别7个P1级别9个P2级别11个。P0级别的问题集中在合规性和信息一致性两个维度。合规性方面标题里出现了“最”字极限词详情页有一句关于“静音”的描述被模型判定为疑似夸大性能。信息一致性方面最严重的一处是属性表里净重是1.2kg详情页的参数栏却写的1.5kg这两个数字差了整整300g属于典型的不同资料之间互相矛盾。P1级别里主图背景非纯白底比较典型。那张图用肉眼看是白底但是用模型做视觉检测后它识别出背景其实偏灰并且边角有不均匀的阴影。这种问题在人工审核时很容易被忽略但平台审核系统却可能因为这点退回来要求重新拍摄。另一个P1是SKU规格命名混乱同一个商品属性表叫“曜石黑”SKU表里叫“黑”详情页里又叫“黑色”叫法不统一很容易造成消费者混淆。P2级别的11个问题大多是文案质量和格式优化类。比如标题里堆了不止一个修饰词导致字符数超标五点描述的第一条和第四条表达的意思基本重复某个属性参数只写了“300”没有单位看不出是克还是毫升。从结果分布能看出这套体检方案的价值不仅仅在于查出“硬伤”还在于那些容易被忽略的软性问题。真正影响商品转化率的往往不是某一个致命错误而是这些零碎的小问题累积起来给用户的信任感打折。4.2 高危问题逐个拆解极限词、参数冲突、资质缺失27个问题里有几个典型的、值得单独拎出来讲。极限词这类问题在标题这种纯文本里命中非常直接规则引擎就能抓到。但详情页和卖点文案里的极限词很多时候是长句子里的一个词组没有明显的标识人工很容易扫漏。比如“市场上没有比这个更安静的产品了”这句话里没有“最”字但语义上是最高级表达属于比较隐蔽的极限词需要语义理解才能识别出来。参数冲突是另一个高发问题。属性参数表、详情页、标题、SKU表这四个来源几乎必然会出现同一参数的不同表述。比如重量、尺寸、颜色这些字段在四份资料里可能出现四套写法。模型在这里的价值就是拉齐四份资料做字段级别的交叉比对找出对不上的那一个。资质缺失问题更隐蔽。如果一个商品宣传了“通过了某认证”但资料包里并没有对应的认证证书平台一旦抽查到就可能被判定为虚假宣传。这种问题的判断逻辑是先识别宣传文案中的资质宣称再去资料包里搜索是否有对应支撑文件两步都需要语义理解适合交给大模型处理。我当时在详情页里发现了一处“荣获设计奖项”的描述但资料包里并没有获奖证书或相关证明模型直接把它标成了P0。4.3 模型误报与漏报怎么判断结果靠不靠谱大模型输出的问题清单不能不加验证直接信。我自己跑下来误报率大约在15%左右。最典型的误报场景是模型把详情页里的“非卖品赠品说明”误判成了“虚假宣传价格”还有一次模型把属性表里的“质保1年”和详情页里的“一年保修”判定为“表述不一致”实际这两个意思是完全一样的只是用词不同。漏报也有。印象最深的是SKU表里有一个库存为负数的问题模型完全没有发现。原因是这个SKU数据在Excel里是一个隐藏sheet我在解析的时候根本没读到那个sheet模型自然就看不见。这个问题的根子还是在文件解析环节不在模型本身。所以我在设计报告的时候特地在最后加了一行备注本报告由规则引擎与AI模型自动生成P0级别问题建议人工复核后再执行修改。这不是免责声明而是真实可信的做法。AI体检助手做的是把问题的发现成本降到极低把排查范围缩到极小但最终的判断和决定权还是应该留给人。5. 常见问题与排查技巧实录5.1 模型给出不存在的问题怎么降低幻觉率用大模型做体检大家最担心的就是模型瞎编问题。这个问题确实存在但不是无解。经过多次试验我总结出三个有效的降幻觉手段。第一是给足上下文。模型之所以编造很多时候是因为信息不足它只能靠猜测补全。我后来把属性参数表和SKU表完整结构化地放进提示词里不再只给摘要幻觉率立刻降了一截。第二是限制输出格式强制JSON数组输出并且要求每条问题必须带evidence字段让模型必须引用原文才能输出问题。这个约束很有效模型在编不出“证据”的情况下会选择不报。第三是调低temperature我固定在0.1到0.2之间这个参数对幻觉的影响非常大温度越高幻觉越严重。如果还是发现模型报了明显错误的问题可以把这条问题连同原始资料再次丢给模型让它自我复核用第二轮对话把误报筛掉。我实测这个“二次复核”流程能把误报率再压低接近一半。5.2 同时处理多张图片和长文档接口超时怎么办我刚开始跑的时候把详情页长图原图直接传给API结果频繁超时。排查下来是请求体太大服务端处理时间太长。解决思路是图片压缩上面已经提到过把长图按比例缩放到最长边1500像素以内清晰度足够模型看清文字体积却能减少很多。另外一次超时是因为我把6份资料的文本全部拼进一个请求里文本量太大了。解决方法是拆成多个子任务一个请求专门做图片视觉审查一个请求做文本一致性比对一个请求做SKU逻辑检查。拆分之后每个请求的数据量都控制住了不仅不超时还更容易定位是哪部分输出有问题。拆子任务还有个隐藏好处文本和图片分开审查可以分别调整提示词互不影响。比如SKU逻辑检查用规则引擎就能承担大半文本一致性比对的提示词就可以只关注描述类资料之间的关系。5.3 输出格式不稳定JSON解析老是报错怎么办大模型输出JSON偶尔会在前后加一点废话或者在中途截断。我用过两个比较有效的办法。第一个是容错解析。先尝试json.loads直接解析如果失败就用正则把内容里最外层的大括号或中括号部分抠出来再解析一次。绝大多数情况这样都能救回来。第二个是让模型只输出JSON、不输出解释并且把这句话放在提示词的末尾再加一次强调。对于确实无法解析的输出我做了重试机制最多重试两次重试时在消息里追加一句“上次输出格式无效请严格只输出JSON数组”这种方式通常能解决90%以上的格式问题。还有一个细节如果开启了流式输出有些客户端会返回分片数据需要自己拼接。我图省事直接关了流式max_tokens给足让模型一次性返回完整结果。检查类任务本身响应时长在几秒到十几秒关掉流式体验差异不大。5.4 不同商品类目怎么快速复用这套方案不同品类的商品体检重点不一样。食品类要额外查生产许可证号、保质期、配料表一致性美妆类要查特殊用途化妆品批准文号电器类要查3C认证型号是否与实物对应。我的做法是把“通用体检项”和“类目专属体检项”分开配置。通用体检项就是我前面说的五维度和27个检查项里的公共部分所有商品都能跑。类目专属体检项则做成一个可配置的JSON每种分类放一套规则。上架新商品时先在配置里指定这个商品的类目程序自动加载对应的专属检查项再执行体检流程。这样的话从这个家电商品扩展到其他品类不需要改底层逻辑只需要新增一套配置和提示词片段就行。6. 几点实战心得给想动手搭的同学整套方案从构思到上线跑通实际用时不到一个周末。做完之后最大的感受是这种“体检类”工具非常适合用大模型来做因为它的核心不是生成内容而是理解与判断恰好是大模型最擅长的事情。我自己的经验是不要指望模型一把梭解决所有问题。把任务拆成“规则能做的”和“只有模型能做的”两部分规则部分确定性高、成本低模型部分灵活性强、上限高两者结合效果最好。也不要一上来就追求100%准确率先跑到80%用起来之后发现问题再迭代提示词这种方式效率最高。另外如果手上商品SKU量很大比如几千个建议先跑一轮规则引擎做粗筛把疑似有问题的SKU挑出来再针对这些小批量数据调模型做深度检查。全量数据喂给大模型的成本会比较可观小步快跑才是可持续的方案。这套体检助手现在已经是我处理商品上架前的固定流程了。每次拿新商品先跑一套体检有问题先改再上架审核驳回率肉眼可见地降了下来。后面我打算把报告接入到回复模板里让运营同学在IM工具里直接就能收到体检结果省去登录后台查看的步骤这个已经在着手做了。如果你也在被商品审核反复折磨可以试着把这套思路搬过去结合自己类目的规则改一版大概率会省下不少时间。