运营同学半夜把链接甩过来，说“明天要上首页大促，这详情页你再帮我看看有没有问题”的时候，我内心是拒绝的。六个资料文件加一张主图，人工一份份点开查，前后少说得花一两个小时，还容易漏。后来我干脆用 Qwen3.8-Max 搭了一个电商商品资料包体检助手，把标题、文案、卖点、属性、图片一次性丢进去自动过一遍模型，6份资料加1张商品图，一轮跑完直接给出27个具体问题。这篇文章就把整个实现思路、检查维度、Prompt设计和踩过的坑完整拆开讲，给同样被商品资料审核折磨的运营、电商开发朋友做个参考。

这件事现在想想，本质上不复杂，就是把“人肉审资料”变成“机器先审一遍，人只看结果”。但真正做起来，比想象中琐碎得多。资料格式乱七八糟，编码混乱，图片信息藏在角落里，模型输出还不一定稳定。我磨合了好几天才把流程跑顺，中间遇到过漏检、误报、截断、乱码各种问题，最后沉淀下来的这套做法，我觉得对做电商中后台、商品运营工具的人都有一定借鉴意义。

1. 这个体检助手到底在解决什么问题

1.1 电商商品资料的真实痛点

电商场景里，一个商品要正常上架售卖，伴随的绝不是一张图片和一个标题那么简单。以我这次处理的商品为例，资料包里有商品主图、详情页长图、标题文案、卖点提炼文档、规格参数表、售后说明、资质证书扫描件，一共6份文档加1张商品图片。这些东西分散在不同人手里，运营写文案，采购给参数，美工做图片，最后汇总到一起时，问题就来了：标题里堆满了关键词导致超字数，卖点文案和参数表对不上，图片上文字被压缩到看不清，售后说明和详情页描述自相矛盾。

这些矛盾在人工审核时容易被忽略，因为人看资料是“跳跃式”的，注意力会跟着视觉重点走。而模型不一样，它只要被明确告知“每份资料都要交叉比对”，就能老老实实把所有字段拉齐了看。我那27个问题，几乎都是跨文件比对才发现的，单看任何一份资料都看不出来。

1.2 为什么选 Qwen3.8-Max 而不是传统规则引擎

按过去的思路，这种检查需求可以写一套规则脚本，比如“标题超过30个字就报警”“参数表和详情页里的规格如果不一致就提示”。这种方案对付单项规则还行，但一旦涉及语义层面的判断，比如“详情页文案是否存在夸大宣传”“卖点提炼是否覆盖了核心参数”，规则就完全不够用了。

Qwen3.8-Max 这类大模型相对适合做这件事，因为它同时具备两个能力：一是能处理长文本和多种格式内容的输入，二是具备一定的“商品理解”能力，读得懂标题、卖点、参数之间的语义关系。比如“充电功率最高支持120W”和“充电速度极快，一杯咖啡充满”这两句话，规则引擎只能各自单独查关键词，模型却能识别出后者是对前者的合理演绎，不构成冲突。

我当时的选型逻辑很直接：这个任务本质上是个“语义一致性体检”，需要的是理解能力，而不是精确匹配能力。与其维护几百条正则规则，不如让模型直接读全文，从语义层面找矛盾、找缺失、找违规。

2. 体检维度与问题分类体系设计

2.1 资料包检查的五个核心维度

我一开始也是拍脑袋让模型“随便看看资料，有什么问题就列出来”，结果模型输出一堆正确废话，比如“建议优化标题”“建议提高图片清晰度”，完全没有落地价值。后来我花了大半天时间，重新梳理了自己平时审资料时的检查习惯，最后把体检分成五个维度，每个维度再拆出细项。

• 标题与关键词维度：标题字数是否超限、是否有无效堆砌、是否包含禁用词、核心卖点是否前置
• 卖点与描述维度：卖点是否具体可验证、是否夸大宣传、是否出现绝对化用语、卖点之间是否矛盾
• 规格参数一致性维度：各文件中同一参数（如重量、尺寸、材质、接口）是否保持一致
• 图片与视觉信息维度：图上文字是否与文案匹配、是否存在遮挡、关键卖点在图上是否可见
• 合规与资质维度：售后政策是否完整、认证资质是否齐全、是否缺少必要的警示语

这五个维度基本覆盖了我在日常审品时关注的全部要点。把它们交代给模型后，输出质量立刻上了几个台阶。所以说，Prompt写得再花哨，都不如先把检查维度定义清楚，这是整个项目里最值得花时间的地方。

2.2 27个问题究竟是怎么分类的

拿到模型输出的27个问题之后，我没有直接丢给运营看，而是先按优先级和类型做了分类，方便他们处理。分类逻辑如下：

问题类型	数量	处理优先级	典型示例
硬性违规类	6	立即修复	标题含绝对化用语“顶级”；主图上出现“限时秒杀”但无活动说明
信息不一致类	9	高优先级	参数表标注重量为180g，详情页写“仅重150g”；售后说明与详情页退换政策矛盾
内容缺失类	5	中优先级	缺少充电安全警示语；资质证书编号未填写
表达质量问题	4	低优先级	卖点描述过于空泛；标题后半段堆叠无关词
视觉易读性问题	3	中优先级	图片文字过小；核心参数在缩略图下被遮挡

这个分类的意义在于，运营拿到报告后不用逐条去问“这个要紧吗”，直接照优先级处理就行。说实话，人工审的时候最容易漏掉的就是第二类“信息不一致”，因为需要跨文件穿越很多障碍才能发现。模型做这个反而擅长，只要你能正确引导它去比对，它会老实地把每处矛盾都揪出来。

3. 手把手搭建流程：从文件解析到结构化报告

3.1 预处理：先解决“喂给模型的资料长什么样”

要调用 Qwen3.8-Max 替我看资料，第一步不是写Prompt，而是把这些文件统一转化成模型能读懂的格式。我的资料里有Word文档、Excel参数表、PDF资质证书、JPG商品图，每种格式都要单独处理。

Word文档我用 python-docx 库读取文本内容，Excel用 openpyxl 逐行读取转成Markdown表格，PDF如果是有文本层的直接提取，扫描件的资质证书则转成图片交给视觉能力处理。关键的坑在于，Excel参数表转成纯文本后，宽表变成长文本，模型很容易搞混列与列的关系。我后来处理方式是，每行转成一个“键：值”的键值对，例如“电池容量：5000mAh”，模型读起来就清晰多了。

# 参数表转键值对文本的参考实现
from openpyxl import load_workbook

def excel_to_kv_text(path):
    wb = load_workbook(path, read_only=True, data_only=True)
    lines = []
    for ws in wb.worksheets:
        rows = list(ws.iter_rows(values_only=True))
        if not rows:
            continue
        header = rows[0]
        for row in rows[1:]:
            kv = []
            for h, v in zip(header, row):
                if h and v is not None:
                    kv.append(f"{h}：{v}")
            if kv:
                lines.append("；".join(kv))
    return "\n".join(lines)

商品图不需要预处理成文本，Qwen3.8-Max 原生支持图片输入，我直接把图片文件转成Base64编码塞进请求里就行。

import base64

def image_to_base64(path):
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

3.2 Prompt工程：让模型输出稳定的JSON体检报告

预处理完成之后，真正决定体检质量的就是Prompt设计。我试过好几个版本，踩过一些坑，最后形成的稳定版Prompt结构分四部分：角色设定、资料内容、检查维度、输出格式。其中输出格式是最重要的，必须明确要求模型只输出JSON，不要任何额外解释。

我先让模型输出一次看效果，结果发现它有点“发散”，会输出很多夹叙夹议的内容，我拿到结果还要二次清洗。后来我在Prompt里做了两处调整。第一处是输出格式里严格限定schema，告诉模型必须输出一个 problems 数组，每个元素包含 type 、 severity 、 location 、 description 、 suggestion 五个字段。第二处是加了“如果某个维度没有问题，也要在该维度输出一条 "type": "ok" 的记录”，这样我就能确认模型是真的检查过这个维度，而不是漏掉不写。

{
  "problems": [
    {
      "type": "hard_violation",
      "severity": "high",
      "location": "标题文案.docx",
      "description": "标题中包含绝对化用语“顶级”，违反广告法相关规定",
      "suggestion": "删除“顶级”，改用可验证的量化描述，如“续航实测48小时”"
    }
  ],
  "summary": {
    "total": 1,
    "high": 1,
    "medium": 0,
    "low": 0
  }
}

这个JSON格式我后续处理起来非常方便，可以直接转成运营能看的HTML报告，也可以导入到表格里做问题追踪。模型只要遵循了这个结构，整个流程就顺了。这里有个细节： severity 的取值我固定为 high/medium/low 三档，不许模型自由发挥。一开始模型会输出类似“严重”“一般”“轻微”这样的中文词，后面统一管理时就很难聚合统计，所以我强烈建议在Prompt里把枚举值写死。

3.3 图片体检：视觉能力是怎么用的

图片这块是最容易出效果的部分，因为人工审图要仔细看每个角落，模型一眼就能扫完。Qwen3.8-Max 的多模态能力可以直接接收图片，我传给它的图片不仅包括商品主图，还包括我从详情页长图里截取的关键区域图。

我主要让模型查这么几个点：图片上的文字是否清晰可读、是否有频繁出现的无效字样（比如“限时抢购”这种无时间说明的文案）、图上标注的参数是否与文档参数一致、是否存在信息遮挡、核心卖点是否在首屏就能看到。让我比较意外的是，模型对“图片上有字但字很小”这种情况的识别很到位，它会直接在问题描述里提醒我“文字尺寸过小，在手机端难以辨认”。

图片这块还要注意上下文规划，如果一张长图内容太多，模型会漏看。我的习惯是长图先切成长度不超过2048像素的分段图，再把分段图依次传给模型，并把上下文关系在Prompt里写清楚，比如“这是某商品详情页的第2屏，请只检查当前图片范围内的信息”。

3.4 结果汇总与报告呈现

模型给出27个问题之后，我做了两件事。第一件是写了个小脚本把JSON转成Markdown格式的问题清单，并且每条附上文件来源和修改建议，方便运营按图索骥。第二件是把问题按前面表格里的优先级排序，把“硬性违规”和“信息不一致”这两类排在最前面，并且用醒目标记标出，让运营可以跳过其他低优先级内容。

这个报告我直接发到群里，运营没再过来追问“这个问题在哪个文件里”，因为每条我都标注了 location 字段，点开就能定位。如果以后问题数量上去了，还可以接入工单系统，把每条问题自动创建一个修复任务，分派给对应负责人。目前这个阶段，一个脚本加一个模板Markdown，已经完全够用。

4. 实测效果与成本、稳定性考量

4.1 一次体检的实际耗时和token消耗

我完整跑完一次体检（6份资料+1张商品图），包含文本提取、Base64编码、模型调用、结果解析，整条链路大概花了35秒到40秒。其中绝大部分时间花在模型推理上，本地文件处理基本是瞬时完成的。我又看了一下token账单，一次完整的体检大概消耗了9000到11000个token。如果按当前的API定价来算，单次成本不高，哪怕一天跑几十个商品，成本也可控。

这个数字说明，用大模型做这种“非高频、重质量”的检查任务，性价比是比较合适的。真正贵的是那种每天要跑几万次的场景，但商品资料体检通常只是上架前或活动前做一次，不追求实时性。35秒对运营来说完全能接受，他们以往人工审一个品都要半小时起步。

4.2 准确率、误报与漏报的权衡

模型审资料不是100%准确，这一点必须有心理预期。我在测试阶段拿了一批已知有问题的历史商品资料去验证，整体准确率大概在85%到90%之间，剩下的10%左右是误报和漏报。

• 误报：模型把“规格参数表里写的是整机重量，详情页写的是单机重量”判断为矛盾，但实际上两个数据指的不是同一个东西。这类误报我通过优化Prompt，告诉模型“注意区分整机重量和单机重量，如果单位与口径不同不算矛盾”，明显减少了。
• 漏报：主要是图片里的小字信息，模型有时候扫不仔细。我把图片切细后，漏报情况也下降了。
• “幻觉”：模型偶会会编造资料里不存在的问题。比如资料里根本没有提到“电池容量”，模型却提示“电池容量存在缺失”。这个我通过要求模型在每条问题中引用原文来解决，“如果找不到原文，不要提出该问题”，幻觉大幅减少。

实操中我的体会是，不用追求模型完全零误报，只要把误报率控制在运营可以快速二次确认的范围内，这个工具就有很大价值。毕竟它的定位是“体检助手”，不是“终审法官”，最终判断权还是由人来掌控。

5. 常见问题与排查技巧实录

5.1 文本截断导致漏检怎么办

我最开始直接调用模型时没有设置好参数，长一点的内容被截断，导致那个商品最关键的售后条款根本没被读到，模型自然没有发现售后和详情页的矛盾。后来我做了两件事：第一是在调用时把 max_tokens 调高，给足输出空间；第二是把输入内容按文件逐个传入，而不是把所有资料拼在一个超长上下文里。

按文件逐个传还有一个好处：当模型输出某条问题时， location 字段能精确到具体文件。之前把全部资料拼在一起传，模型只能模糊回答“在某个文档中”，定位效率低很多。我现在采用“主Prompt先传标题文件，再附加其他文件内容”，每个文件前加上“【文件：xxx.docx】”的分隔标记，模型输出位置信息时就会引用这个标记。

5.2 模型“乱编”问题怎么约束

“乱编”问题本质上就是前面说的幻觉，它对资料里不存在的内容进行推测性判断。我的约束方式其实很简单：在Prompt里加一条硬规则——如果某个问题没有在对应资料中找到明确的原文依据，不要输出该问题。同时我在输出schema里增加一个 evidence 字段，要求模型必须引用原文作为证据。

加了这两个约束之后，输出质量明显变稳了。我抽查了20条模型标注为 hard_violation 的问题，其中18条都能在原文中找到对应的依据，剩余两条即使存在但也属于“有争议”的判断，不再出现纯凭空捏造的情况。这些改进与其说是技巧，不如说是想清楚了大模型的边界：它擅长的是“基于给定语料的推理”，而不是“凭空记忆某个规范”，我们要做的是把它限制在“基于语料”的范围内。

5.3 文件解析乱码的坑

文件解析这块，几种小坑都遇到过。比如Word文档里的自动编号，被 python-docx 读出来是一堆奇怪的占位符；Excel单元格里有换行符，转成文本后让键值对裂开；PDF扫描件没有文本层，直接提取出来是一堆乱码。

对应处理方案：Word文档优先读段落，忽略占位符和目录域；Excel读取时把单元格内的 \n 替换成空格；PDF扫描件直接走图片识别线路，不再尝试提取文本。如果文件是那种混合型的（部分可复制部分扫描），我建议直接全部转图片，交给多模态能力处理，省心且稳定。

5.4 并发调用限流如何处理

单个商品跑40秒还行，但如果你想批量体检，比如一天要跑几十上百个商品，就要考虑并发和限流。Qwen3.8-Max 的API接口是有并发限制的，我一开始没有做并发控制，连续跑多个任务时遇到过限流报错。

我的建议是做一个简单的队列，限制同时只有3到5个任务在跑。更稳妥的方式是直接利用官方提供的异步批量接口，但要处理回调逻辑。我的场景下来，本地线程池加限流的方式最简单可控：

from concurrent.futures import ThreadPoolExecutor
import time

executor = ThreadPoolExecutor(max_workers=3)

def run_check(product_files):
    # 单商品资料包的体检逻辑
    pass

futures = [executor.submit(run_check, files) for files in product_list]
for f in futures:
    f.result()  # 失败自动重试或记录日志

同时要做好失败重试和结果缓存。模型接口偶尔会超时，给每个请求加个重试，重试间隔按指数退避，能极大降低失败率。结果缓存则是为了断点续跑，万一跑到第50个商品时接口出问题，前面49个已经跑完的结果不用重新跑一遍。

最后分享一个实际使用中的小技巧

给模型传图片的时候，尽量用原图别压缩太狠。压缩过的商品图在手机端看问题不大，但模型对图像细节的敏感度会被压缩算法影响，图上的一些小字和Logo细节容易模糊。我现在都是直接把美工给的原始JPG转Base64传进去，不经过任何压缩处理。

还有一点想提一下，Prompt不要一版定终身。我第一个版本的Prompt和最终的版本差别很大，中间隔了大概十几次调试。我自己习惯每个版本都保存下来，配一个示例运行结果，这样能清楚看到哪次Prompt改动导致了哪类问题的变化，而不是凭感觉盲改。

这套体检助手做出来后，现在运营每次上新品前都会先跑一遍，再针对报告里的问题逐条确认。原本需要花半小时到一小时的人工审核，压缩成了“跑一次40秒加人工确认十分钟”的流程，而且比人工查得更全。后续我还在想能不能把这个能力接入到商品发布的后置流程里，商品提交时自动触发一次体检，有问题直接拦截在草稿阶段。这个方向做起来，对综合效率的提升会更明显。