1. 项目概述与技术方案1.1 核心需求解析事情是这样的有个做电商运营的朋友给我丢过来一堆文件说是一套商品的上架资料包让我帮忙“看看有没有问题”。我打开一看——商品卖点手册PDF、SKU信息表Excel、详情页文案Word、质检报告PDF、说明书PDF、赠品清单Excel外加一张商品主图总共7个文件。说实话光靠人工逐份核对少说也得折腾两三个小时而且很容易漏。我当时的想法很简单能不能把这堆材料一股脑丢给大模型让它把体检结果一次性全部列出来。正好手头有Qwen3.8-Max的API权限就顺手搭了一个“电商商品资料包体检助手”。核心思路是把所有文本类资料解析成纯文本把商品图转成图片描述统一送进模型上下文让模型以质检员的口吻逐项核对同时用JSON Schema约束输出结构再把结果自动整理成报告。这里要说明一下标题里写的Qwen3.8-Max实际我调用的是阿里云百炼平台当前开放的Qwen-Max系列模型版本具体型号名称以你开通时的线上版本为准。不同版本在长文本和多图理解上的表现会有些波动但整体方案是通用的你换成同系列的其他型号也能跑。这套东西能解决什么问题说白了就是帮你把“人肉核对”变成“机器预审”。适合谁用电商运营、品牌方内容审核、代运营团队、甚至做跨境商品上架的都能用上。尤其是那种SKU很多、文案来回改、老板天天催上架的场景这个助手能省下大量时间。1.2 技术选型与架构设计方案定下来之后最关键的问题就是怎么让模型“看懂”这么多不同类型的文件。我用的是Python脚本文档解析这块用了三个库PDF用fitzPyMuPDFWord用python-docxExcel用openpyxl。这三个库都是老牌工具部署简单文本抽取做得也比较干净。图片处理则是把商品图调成base64格式直接传给Qwen3.8-Max的多模态接口。如果你碰到比较复杂的PDF比如扫描件fitz抽出来的文本可能不满整套内容。这种情况建议前置一层OCR比如PaddleOCR或者阿里云的文档智能。没有OCR能力的可以把扫描页面转成图片再让多模态模型直接读图实测也能处理就是token消耗会大不少。整体架构我画了一条很直接的处理链路本地文件 - 解析层(按类型拆分文本) - 拼接层(按序号组织上下文) - LLM接口(Qwen3.8-Max) - JSON输出 - 报告生成(Markdown)这个架构看着简单但有个关键点不同文件拆出来的文本不能一股脑塞给模型。得做“分段标记”让模型知道每一段文字来自哪个文件。比如用“【文件1商品卖点手册-PDF】”这样的标记模型在回答的时候才能准确指出“问题出在第3份资料里”。这个设计我非常推荐实测效果立竿见影。如果不做文件标记模型经常会把几个文档的内容搞混尤其是Excel里很多缩写字段跟PDF里的表述对不上号时它甚至会脑补出一些不存在的“问题”很坑。1.3 为什么要设计“多轮体检”而不是“一次性审完”我最初的想法确实是一次性把所有内容丢进去问模型“请体检所有问题”。但跑了一轮之后发现效果并不理想。原因有两个第一链路太长。7个材料每个几千字模型要同时做“理解、关联、比对、判断”四个动作推理深度不够出来的问题都很泛比如“请确认商品描述是否一致”这种不具备操作性的废话。第二容易遗漏。当所有内容平铺在上下文里时模型对细节的注意力会被稀释。它会重点关注卖点那些明显文本SKU表里的缺失项、图片上的参数冲突这类更隐藏的问题很容易被漏掉。所以我改成了“三轮体检”策略第一轮让模型逐份资料单独体检只管“单文档内部有没有错误”比如错别字、参数异常、违禁词第二轮让模型做“跨文档一致性比对”专门找不同资料之间互相冲突的问题第三轮才做“商品主图文本资料”的交叉核对。每一轮跑完之后我要求模型按编号输出一个小的JSON数组然后人工轮次之间把上一轮的结果一并作为上下文传给下一轮。这样既能控制上下文长度又能保证问题不会漏。实测三轮跑下来一次能查出20多个问题质量比一次性审完高很多。2. 核心环节实现与提示词设计2.1 文件解析的“坑”与参数细节在写解析脚本的时候有几个细节特别值得注意处理不好会直接影响后面的体检准确率。先看PDF解析。fitz默认抽取文本时会保留排版但有些PDF的表格结构会被拆得七零八落。比如商品卖点手册里有一个参数表列名是“材质”但抽出来的文本可能是“材质 聚酯纤维”被拆成了两行。为了防止这种问题我在抽取后加了一步“规则清洗”把单行文本长度小于等于2的残片合并到上一行末尾并用空格隔开。这个小操作对Excel行数据的识别帮助特别大。再来看Excel。openpyxl读取单元格的时候要特别注意单元格的“数据类型”。如果SKU信息表里的“库存数量”是数字格式读出来是int如果某个单元格是公式比如“VLOOKUP(...)”读出来的可能直接是None。我的做法是判断单元格值是否为None或空字符串如果是公式或引用打印警告并跳过同时把该位置标记为“值缺失可能为公式”。这样模型在体检的时候就不会把“公式单元格”误判成“数据缺失”减少无效报警。Word文档解析相对干净但要注意标题层级。python-docx里可以通过段落style判断是不是标题。我会把“标题1”“标题2”等段落前置一个“【标题】”标记方便模型快速扫描文档结构。比如详情页文案里如果写了两版标题模型能更准确地判断哪个是废弃版本。图片部分我是用PIL把商品图压缩到宽度不超过1024像素转成JPEG的base64字符串再传到接口。压缩大图不是为了省流量主要是为了让多模态识别更快更稳。不压缩的话4K原图可能因为太大而超出接口限制反而容易报错。2.2 提示词让模型当“质检员”而不是“文员”提示词是这个项目的灵魂。如果只是简单说“请检查这些资料”模型大概率会给你来一段“整体来看商品资料包有以下优点和不足……”的客套话一点用没有。我的做法是给模型设定一个明确的岗位和行动规则。下面是主提示词的一部分可以直接抄你现在是一名拥有10年经验的电商合规审核员。你的工作是对平台提供的商品资料包做全面体检。 任务要求 1. 对每一份资料逐项检查文本中的错误、缺失、不一致、风险点。 2. 输出格式必须是JSON数组每个问题对象包含以下字段 - issue_id问题编号数字自增 - file_name涉及的文件名 - issue_type问题类型错别字/缺失数据/参数异常/图文不一致/跨文档冲突/疑似违禁词 - description问题详细描述要具体到段落或单元格位置 - suggestion建议修改方式 3. 注意只输出JSON数组不输出任何额外解释。 4. 如果某类问题确实不存在不要强行编造。宁可少报不可误报。这里有几个细节“只输出JSON数组”这句话不能省。不约束输出格式的话模型会给你一堆前后缀解释解析脚本还得再清洗麻烦。“不要强行编造”这句话有奇效。加了这句之后模型的误报率明显下降不会拿着放大镜找不存在的问题。我还引入了一个“置信度”字段取值0到1。置信度低于0.6的问题脚本会单独放进“待人工复核”章节不跟高置信度问题混在一起。第一轮单文档体检的提示词会再细一些例如你现在只检查“文件1-商品卖点手册.pdf”。请逐页检查 1. 是否有错别字、明显语句不通 2. 是否有产品参数遗漏比如材质、尺寸、重量、保修期等 3. 是否有疑似广告违禁词或极限词 4. 是否有与常理不符的数据。 只输出这个文件范围内的JSON结果。第二轮跨文档比对我用的提示词是这样以下是6份资料解析后的文本目录。请做跨文档比对重点检查 1. 同一商品在不同文档中的名称、型号、规格是否一致 2. SKU信息表中的库存/价格与卖点手册里描述是否一致 3. 赠品清单与详情页文案中提到的赠品是否一致 4. 质检报告中的检测结论是否与其他文档中宣称的卖点冲突。 请只输出存在“跨文档冲突”的问题单文档内部的问题不要重复汇报。这样设计的思路是与其让模型自己决定看什么不如给它一张“检查清单”把人和机器的分工划清楚。人负责定标准机器负责照单执行。2.3 结构化输出的解析与回退策略模型输出JSON不一定会100合法偶尔会多一个逗号、少一个括号、或者干脆把JSON包在代码块里。我写了解析函数尝试用json.loads直接解析失败了就用正则把大括号内的内容提取出来再试还不行就把字符串交给模型自己修补提示“你的JSON格式有误请修复后重新输出”。这一套三级回退策略是我在实际调试中逐步加上的。第一版只做了直接解析结果大概有15的请求因为JSON格式问题白跑一趟。加了回退之后成功率到了99.5以上。那几个实在回退不成功的基本都是因为某份资料文本太长模型在截断处丢了半个JSON这种情况下最简单的处理是把该文件单拎出来重新跑一轮。2.4 体检结果的合并与报告生成三轮全部跑完之后三组JSON数组汇总到一个列表里。我按issue_type字段做了分类统计然后生成一份Markdown报告。报告包含三大部分体检概览问题总数、按类型分布、涉及的资料清单详细问题列表每条问题带编号、类型、位置、描述、建议并按严重程度排序待人工复核清单置信度低于0.6的疑似问题以及模型建议人工确认的冲突项。报告生成之后我会用Python的datetime模块在文件名里打上时间戳比如“体检报告_20240118_1430.md”方便回溯。这个命名习惯别看简单项目跑久了你就知道有多重要尤其是多轮优化后对比两版报告之间的差异时时间戳能让你一眼找到对应版本。生成的报告长什么样我拿真实案例测试过一次体检完直接列出了27个问题。这里举几个代表性例子商品卖点手册中写“面料成分100棉”但详情页文案里写的是“棉85聚酯纤维15”两处直接打架SKU信息表里有一行库存为“None”后来排查发现是Excel里的公式单元格商品主图上有“限时五折”的水印但所有文本资料里都没有找到对应的促销说明和活动时间属于图文不一致赠品清单里写了“送原装数据线”详情页文案写的却是“送高保真耳机”两个赠品对不上说明书的型号一栏写着“M300 Pro”其他所有资料都是“M300”疑似标题不一致。这些问题放在一起看确实都不是什么高深的技术问题但它们恰恰是上架前最容易漏掉、上线后最容易引发客诉的点。所谓“体检”本来就是查小病防大病。3. 实操部署与运行说明3.1 环境准备与依赖安装这个项目跑起来很简单一台有Python 3.9以上环境的机器就够了。我是直接在Windows笔记本上跑的后来也测试过Linux服务器都没有问题。依赖库只有五个用pip一把装完pip install pymupdf python-docx openpyxl pillow requests百炼平台的SDK我没有额外装直接用requests调用HTTP接口。如果你偏好官方SDK也可以装dashscope代码差别不大。另外需要去阿里云百炼平台开通模型服务拿到API Key然后设置环境变量set DASHSCOPE_API_KEY你的API密钥或者直接在脚本里配置。但我建议用环境变量不要硬编码进代码里不然代码一到处发密钥就泄露了。3.2 文件放置和主流程脚本我把项目目录固定成这样project/ materials/ # 放待体检的资料包 output/ # 报告输出目录 main.py # 主脚本 parser.py # 文件解析 report.py # 报告生成 config.py # 配置模型版本、API密钥等materials目录下放那6份资料和1张商品图。然后执行python main.pymain.py里的逻辑是from parser import parse_directory from llm_client import run_first_round, run_second_round, run_third_round from report import generate_report files parse_directory(materials) first_result run_first_round(files) second_result run_second_round(files, first_result) third_result run_third_round(files, second_result) generate_report(first_result second_result third_result)这个代码逻辑很直白重点全在解析和提示词里。第二轮、第三轮之所以要带上一轮的结果是为了让模型“知道之前已经查过哪些问题”避免重复汇报也方便它在比对时引用前一轮发现的点位。3.3 调用参数设置与成本控制调用Qwen3.8-Max的接口时我做了以下参数设置temperature0.1。体检场景要求稳定、严谨不需要创造性发挥。温度越低输出越稳定高温度容易让模型“放飞”凭空给商品编故事。top_p0.9。这也是一种控制随机性的方式。配合低温度实测输出质量最稳。max_tokens2048。有些问题列表比较长如果上限太小JSON会被截断。2048够用还能兼顾成本。response_formatjson_object。如果接口支持结构化输出直接开启解析会轻松很多。成本方面6份文本资料加1张商品图大约消耗1.5万到2万token的输入整体成本非常低。但如果你的资料包特别大比如一份PDF有100页建议拆分成几个小块分别体检而不是全部塞进上下文否则单次成本会线性上涨而且效果反而下降。3.4 首次运行验证清单第一次跑通之后建议按以下清单检查一下结果输入文件是否全部被正确解析看解析日志里每个文件抽出的字符数如果Excel只抽出几个字符说明读取逻辑有问题输出JSON是否合法统计JSON解析失败率高于5说明提示词里的格式约束不够强问题数量是否合理如果一份资料查出40多个问题大概率是模型在幻觉需要检查提示词里的“不要强编”是否生效报告里的文件来源是否准确抽查两条问题回到原始文件里人工核对确认模型没有张冠李戴。这套清单其实比跑通本身更重要。我见过太多人把脚本跑通了就宣布成功结果模型在满嘴跑火车报告根本不敢信。体检助手这种工具准确率永远大于覆盖率误报太多会浪费大量复核时间最后反而得不偿失。4. 常见问题排查与避坑实录4.1 解析环节的经典故障问题一PDF抽出来的文本乱序表格数据被拆散。排查思路先看文本顺序是不是完全乱的。如果只有表格区域错乱大概率是PDF的文本流顺序跟视觉顺序不一致。fitz可以用page.get_text(blocks)按坐标块输出再把块按y坐标从上到下、x坐标从左到右排序基本能还原视觉顺序。改造之后表格数据的正确率提升非常明显。问题二Excel里有合并单元格openpyxl只能读到左上角的值。解决方法用openpyxl的merged_cells属性找出所有合并区域然后把左上角的值批量填充到整个合并区域。不处理的话模型会把合并区域的空白单元格当成“缺失数据”报一堆无效问题。问题三Word里的图片无法直接抽取。解决方法python-docx只能拿到文本图片需要另做处理。我的方案是让模型直接忽略文档内嵌的图片只在解析日志里标注“检测到n张图片已跳过未参与体检”。如果你确实需要检查Word里的图建议先把Word转成PDF再用PDF解析链路处理。但这种情况我会单独拆分处理避免整批资料解析报错。问题四PDF是扫描件抽不出任何文本。方案转图片OCR。效率最高的做法是用fitz把每一页渲染成PNG再用OCR批量识别识别后的文本同样打上页码标记再进入体检流程。4.2 模型输出异常的处理套路跑了几十轮测试之后我总结出三类高频异常与处理方法第一类是JSON格式解析失败。处理方式有两个一是加回退逻辑必要时让模型自己修复二是在提示词里强调“只输出JSON数组”并且不给模型任何发挥空间。实测后者能把失败率从15压到5以内。第二类是模型报出来的问题太笼统。比如“部分描述不太准确”。这种情况一般是提示词里没有给出“必须定位到具体段落或单元格”的要求。加了定位要求之后模型的输出质量显著提升描述从“有错别字”变成“商品卖点手册第3页第2段‘高效’应为‘高效能’”可直接执行。第三类是模型出现幻觉把不存在的问题编得有模有样。这就要靠置信度字段和“待复核清单”来兜底。我还会把上一轮的结果传给后一轮让后一轮在已知信息的基础上继续查降低重复幻觉的概率。4.3 成本与速率控制心得新手很容易忽略一个问题如果资料包很大把全部内容一次性送入模型费用会迅速膨胀。我建议按文件大小先做预估超过5万字符的就拆成子包分别体检后再合并。速率控制方面百炼平台的接口有QPS限制具体以开通时的配额为准。如果并发请求太高会收到限流错误。我的做法是设置一个小重试队列请求返回429时线程sleep 1秒再重试最多重试3次。这样可以跑得稳又不会把接口打爆。另外多模态那一环最费token。商品图如果只是做基础核验建议就压到512像素以内字符数能省一半识别准确率并不会明显下降。只有需要看水印、小字、条码这类细节时才把宽度放到1024以上。这个“按需分档”的思路长期跑下来能省不少钱。4.4 独门避坑技巧给资料编号给问题分级最后分享一个我自己摸索出来的重要技巧在把文件内容送入模型前先给每一份资料编一个唯一序号而且这个序号必须在整个链路中保持恒定。比如【文件1】商品卖点手册.pdf 【文件2】SKU信息表.xlsx 【文件3】详情页文案.docx 【文件4】质检报告.pdf 【文件5】说明书.pdf 【文件6】赠品清单.xlsx 【文件7】商品主图.jpg这样模型在输出问题的时候会带上“文件1”“文件2”的编号报告生成阶段再映射回真实文件名。如果直接用真实文件名很容易因为字符长度太长、中文引号等特殊符号干扰模型注意力导致输出格式不稳定。问题分级也很有用。我把问题按严重程度分成三级P0涉及合规风险、价格矛盾、侵权隐患必须修P1影响转化率的信息缺失或表达不清建议修P2错别字、格式问题、不影响主流程的小瑕疵有空再改。报告生成时按P0/P1/P2排序修问题的时候就不用逐条翻原始资料了直接从最严重的a开干。打个比方这个体检助手就像给商品资料包做了一次全身体检把以前靠编辑肉眼一行行扫的体力活变成了五秒出报告的标准流程。刚开始可能还要花点时间调提示词但一旦跑通后面每次上架新品都能直接复用省下来的时间和精力非常可观。做这个项目最大的感受是大模型的价值不在于替你做判断而在于帮你把最耗时间的“找问题”环节干掉把人的精力集中在“决策怎么修”上。如果你手上也经常要处理成堆的电商上架资料建议照着上面的思路动手搭一个属于自己的体检助手跑一次就知道值不值了。