企业官网建设流程全解析

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用fitz（PyMuPDF），Word用python-docx，Excel用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.py

main.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的接口时，我做了以下参数设置：

• temperature：0.1。体检场景要求稳定、严谨，不需要创造性发挥。温度越低输出越稳定，高温度容易让模型“放飞”，凭空给商品编故事。
• top_p：0.9。这也是一种控制随机性的方式。配合低温度，实测输出质量最稳。
• max_tokens：2048。有些问题列表比较长，如果上限太小，JSON会被截断。2048够用，还能兼顾成本。
• response_format：json_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开干。

打个比方，这个体检助手就像给商品资料包做了一次全身体检，把以前靠编辑肉眼一行行扫的体力活，变成了五秒出报告的标准流程。刚开始可能还要花点时间调提示词，但一旦跑通，后面每次上架新品都能直接复用，省下来的时间和精力非常可观。

做这个项目最大的感受是：大模型的价值不在于替你做判断，而在于帮你把最耗时间的“找问题”环节干掉，把人的精力集中在“决策怎么修”上。如果你手上也经常要处理成堆的电商上架资料，建议照着上面的思路，动手搭一个属于自己的体检助手，跑一次就知道值不值了。