企业官网建设流程全解析

做电商的人十有八九都经历过这种慌张：新品好不容易走到上架审批这一步，平台一条消息弹回来——标题含违规词、详情页与规格参数对不上、主图不达标。返工重来还是小事，被抽检处罚、被差评、被索赔才是真肉疼。为了不再靠肉眼和责任心硬扛，我用 Qwen3.8-Max 搭了一个电商商品资料包体检助手，把手上的 6 份文本资料和 1 张商品主图一次性喂进去，它跑完直接给我一张 27 个问题的清单：从极限词到价格倒挂，从规格矛盾到证书型号不一致，全是人工容易漏掉、但每条都可能真金白银的坑。

下面我按设计思路、检查项定义、Prompt 实现、实测结果、踩坑调优的顺序把这个方案完整摊开讲。如果你在做电商运营、商品审核，或者想用大模型做多文档交叉核验，这里面的东西可以直接拿去用。

1. 为什么给商品资料做"体检"：一次漏检的代价有多大

1.1 一个商品资料包里到底装了什么

先对齐一个定义：我说的"商品资料包"，不是一个文件，而是上架一个 SKU 前必须凑齐的一整套素材。在我这边的流程里，一共有 6 份文本类资料加 1 张主图：

• 商品标题文案。几十个字，但它同时是流量入口和平台抽检重点，极限词、堆砌词、虚假宣传的雷基本都埋在标题里。
• 详情页卖点文案。从几百到几千字不等，描述材质、功能、使用场景、售后保障。这份文件最容易出问题，因为运营和美工经常各写一版，最后直接合并了事。
• 规格参数表。供应商发来的表格，通常是材质、尺寸、颜色、重量、产地这些硬参数，还包括 SKU 选项，比如颜色、尺码、套餐组合。
• 价格与促销规则表。日常售价、划线价、活动价、满减、优惠券、会员折扣全在里面。
• 资质与质检文件。质检报告、品牌授权书、3C 证书这一类，很多还是 PDF 或扫描件。
• 库存与物流配置。库存数量、发货时效、运费模板、偏远地区限制。

外加 1 张商品主图。这次体检助手的全部输入，就是这 6+1 份材料。

1.2 人工检查的三个死穴

我过去是纯人工核对这套资料的，试了两个月就放弃了，原因有三个。

第一是疲劳漏检。6 份资料交叉比对，眼睛来回扫，看到第三遍就开始麻木。上次就因为在标题里漏看了一个"最"字，新品刚上架三天就被平台下架，还连累了整个店铺的权重。这种错不是态度问题，是纯人工流程的结构性问题。

第二是跨文档核对效率太低。标题里写"加绒加厚"，详情页写"单层摇粒绒"，这两个信息出现在两份不同文件里，人工要自己记住标题说了什么、再去详情页里找对应描述，来回翻文件，一次上新光核对就要两三个小时。

第三是图文对照几乎没人执行。规格表写"云雾白"，主图拍的到底是偏白的还是偏灰的；质检报告上的型号是 KX-208，标题写的是 KX-280，这种"看图对字"的活儿最容易被跳过去，但恰恰是这类问题最容易引发消费者投诉和平台处罚。

所以我才决定把这件事交给大模型：它能读文档，也能看图（多模态），只要把检查规则和输出格式定义清楚，就能在一轮里同时完成单文档体检、跨文档交叉核对、图文一致性校验这三件事。

2. 体检助手的设计蓝图：让 Qwen3.8-Max 干三类活

2.1 把"检查"拆成三种能力

商品资料检查听起来是一件事，做的时候其实是三种完全不同的能力。

第一种是单文档规则体检。针对某一份资料，按固定的规则去逐条排查。比如标题里有没有绝对化用语，规格表里有没有单位写错、参数值明显离谱，证书有没有过期。这类检查的特点是"规则明确、判定独立"，不需要看其他文件。

第二种是跨文档一致性核对。把两份甚至更多资料里描述同一个信息维度的内容拎出来对比。标题说"纯棉"，规格表写"聚酯纤维"；划线价 299、活动价 199，结果满减算完之后反而低于成本价。这类检查的难点在于要先知道"哪些字段应该互相对应"，然后再判断"语义上是否一致"。

第三种是图像与文本交叉验证。主图分辨率够不够、文字有没有被裁切、商品颜色和文案描述是否一致、图中主体和标题卖点是否相符。这类检查对传统脚本最不友好，因为图片里的信息要先"看"出来才能判断，而大模型的多模态能力正好补上了这一环。

2.2 为什么选大模型而不是死写规则

我知道很多人第一反应是：这些检查用正则表达式加 Python 脚本不就行了？价格倒挂算一下、分辨率用 PIL 读一下、极限词做个词表匹配，都能搞定。

确实能搞定一部分。但问题是，我面对的 6 份资料来自不同的人、不同的系统，同样的信息在不同文件里的表达完全不一样：规格表里写"成分：棉 100%"，详情页写"纯棉材质"，标题写"全棉透气"。脚本想识别这是同一个语义，得先做一堆同义词映射和别名维护，维护成本比写检查逻辑还高。

大模型的优势在于语义理解。它不需要我维护同义词表，就能判断"纯棉"和"100% 棉"是同一个信息；它能从两段完全不同的句式里抽出同一维度的信息做比对。而 Qwen3.8-Max 这类带视觉能力的大模型，还能把图片里的文字、颜色、商品主体都读出来，等于三种能力在一个模型里打通，不用再接一个 OCR 再加一个图像分类模型。

当然，我的方案也不是全交给大模型。确定性的检查我仍然用脚本处理，比如分辨率、价格计算、日期过期判断。大模型负责语义判断的部分，两边各干各擅长的，最后合并成一份报告。这个"脚本搭骨架、大模型做判断"的思路，是整套方案稳定的关键。

2.3 一整套管线的运行顺序

整个体检助手按下面这条管线跑：

1. 加载 6 份资料和主图，把文本资料按类型分类，图片单独走视觉通道。
2. 第一轮并行做单文档规则体检，每份文档一个独立请求。
3. 第二轮做跨文档一致性核对，把需要互相对应的字段组合两两配对，分批请求。
4. 第三轮做图像与文本交叉验证，喂主图加商品关键信息。
5. 三轮结果合并，按"检查项 + 引文"去重，然后按严重程度排序输出报告。

这样设计有一个好处：每一轮请求都是独立的，任何一轮挂了或者结果不满意，重新跑那一轮就行，不需要从头再来。后面实测的时候这个特性帮我省了很多事。

3. 27 类问题清单：从"业务事故"反推出来的检查项

3.1 问题库的三个来源

检查项不是拍脑袋定的，我整理这几类问题主要来自三个渠道。

第一是平台规则和广告相关法规。绝对化用语、"最"字类、虚假宣传、医疗用语跨界使用，这些都是平台明文列出的违规类型，也是处罚最重的。我从平台规则中心和历史处罚通知里，把所有出现过的高频违规点摘了出来。

第二是真实的业务事故复盘。我翻了过去一年店铺里所有的差评、退换货、投诉记录，凡是和资料描述不符相关的，都列出来拆解成因。比如"买家收到的颜色和图片不一样""尺码表写错了导致退货""产地标注冲突被职业打假人盯上"，这些事故背后全都能对应到一个具体的检查项。

第三是行业常识和数据合理性。这个比较玄但很有用：尺码是均码但 SKU 里有 S/M/L，正常的商品不会这样；一件 299 元的衣服活动价打完折低于成本价，一定有价格逻辑错误；一件 T 恤重量写 150kg，明显是单位写错了。这些不需要查任何规则，光靠常识就能识别，但人工看的时候经常被忽略。

3.2 四类 27 项检查清单全表

我把所有检查项归成四大类，正好 27 项：

我在项目里把它们维护成一个 JSON 配置，而不是散落在 Prompt 里。每一类问题对应一份 rules 配置，包括规则编号、规则名称、适用资料类型、判定标准、严重级别初始值。这样以后想加检查项或者改判定标准，改配置就行，不用动代码。

3.3 每条检查项都要配"体检标准"

只有问题名是不够的。我对大模型的要求是"只输出问题，不输出诗意"，所以每条检查项都必须写清楚判定标准，否则模型容易自由发挥。

比如"极限词"这条，我的配置里写的是：检出"最、第一、顶级、极致、全网、国家级、最佳、100%"等前缀或同义表达，视为命中，但如果上下文是"同类产品中排名前多少"且有数据支撑，不算命中。再比如"价格倒挂"这条，标准是：活动价减去所有可用优惠后的到手价，低于"成本价 × 1.05"，或者高于划线价的 7 折，都算异常。

把判定标准写成这样，大模型才有据可依。这一步很枯燥，但直接决定了体检报告的质量。一开始我这步偷懒了，规则写得很粗，结果模型把"颜色为灰白"这种描述也当成"颜色不一致"报出来，误报率一度超过三成。把每一条标准细化之后，报告的可用性才上来。

4. 核心实现：三层 Prompt 设计与多文档交叉核对

4.1 API 接入与最小运行环境

我用的是 Qwen3.8-Max 的 OpenAI 兼容接口，Python 侧只需要一个 openai 库就能调起来：

pip install openai

from openai import OpenAI client = OpenAI( api_key="你的API-KEY", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", timeout=180 ) MODEL = "qwen3.8-max"

需要说明的是，我之前也试过用本地小模型跑这套流程，效果不太行，主要问题出在长文档指令跟随和图片细节理解上。Qwen3.8-Max 这类云端大模型在这两方面明显更稳，尤其是图文交叉校验那一步，小模型经常"看图说话"说不到点子上。所以最终方案就是云端 API 直连，省掉部署成本。

4.2 第一层：单文档规则体检

单文档体检是最基础的一层，每一份资料发一个请求。Prompt 的核心是：给角色、给规则、给内容、给格式约束。

RULE_BASED_PROMPT = """ 你是一名资深电商合规审核员，负责对商品资料做单文档规则体检。 本次需要执行的检查项： {rules} 待检查资料： 【资料类型】{doc_type} 【资料内容】 {content} 请逐条对照检查项排查问题。只输出 JSON 数组，不要输出任何多余文字。 每个问题对象包含： - check_item: 命中的检查项编号 - severity: high / medium / low - quote: 原文中最能定位问题的片段（不超过 50 字） - issue: 具体问题说明 - suggestion: 修改建议 如果没有问题，输出 []。 """

有个细节：rules 不是把全部 27 项都塞进去，而是根据 doc_type 只传入适用的那几项。比如给标题文件体检，只传极限词、违禁词、品牌信息缺失这类标题维度规则；给规格参数表体检，传单位错误、参数值离谱、字段缺失这些规则。这样既省 token，又避免模型在无关规则上瞎报。

4.3 第二层：跨文档一致性核对

这一层是整套方案的核心，也是最容易翻车的地方。我的做法不是把 6 份文档一次性全塞给模型让它"自由比对"，那样信息太多，模型会顾此失彼。正确做法是：先维护一张"字段对应关系表"，明确哪些字段需要在哪些文档之间互相比对，然后按"字段 × 文档对"拆成一组组小任务。

CROSS_CHECK_PROMPT = """ 你是电商商品信息一致性审核员。针对指定信息维度，核对下面两份资料。 【资料A：{doc_a_name}】 {content_a} 【资料B：{doc_b_name}】 {content_b} 需要核对的维度：{fields} 判定要求： 1. 数值类信息先统一单位，再比较数值是否超出合理偏差。 2. 描述类信息（材质、颜色、卖点）语义一致即视为一致，不要求逐字相同。 3. 只有一方有值另一方缺失时，归入完整性类别，不要报为一致性冲突。 4. 无法确定是否一致时，返回 confidence 字段（0~1），并把 confidence 低于 0.6 的问题标为 pending。 只输出 JSON 数组，每个对象包含： - check_item, severity, quote_a, quote_b, issue, suggestion, confidence 如果没有问题，输出 []。 """

最关键的就是第 4 条：confidence 字段。这是我在第二轮调优时加的，后面会专门讲。没有它之前，模型经常在一段模棱两可的描述上强行下结论，加了 confidence 之后，拿不准的问题会流到"待人工复核"列表，而不是直接污染最终报告。

字段对应关系表长这样：

FIELD_MAP = { "材质": [("规格参数表", "详情页卖点文案"), ("标题文案", "详情页卖点文案")], "颜色": [("规格参数表", "详情页卖点文案"), ("规格参数表", "主图")], "价格": [("价格与促销规则表", "详情页卖点文案")], "型号": [("标题文案", "资质与质检文件"), ("规格参数表", "资质与质检文件")], "产地": [("规格参数表", "详情页卖点文案")], "尺码": [("规格参数表", "库存与物流配置")], "库存与发货": [("库存与物流配置", "详情页卖点文案")], }

4.4 第三层：图像与文本交叉校验

图像校验走的是多模态通道，把主图和从文本资料里提取出来的关键信息一起发给模型。这一步要注意的是：不要让模型做主观审美判断（比如"这张图好不好看"），只让它做能客观核对的事。

IMAGE_CHECK_PROMPT = """ 这是一张商品主图。结合下面的商品文本信息，从可客观判断的维度进行校验。 商品关键信息： - 商品型号: {model_no} - 颜色: {color} - 核心卖点: {selling_point} 校验维度： 1. 图片分辨率是否明显不足（从清晰度、锯齿、马赛克程度判断）。 2. 图片中是否有文字被截断、遮挡或压到画面边缘。 3. 商品主体是否被促销贴纸、边框、角标遮挡超过一定比例。 4. 图中商品主色调与文本颜色描述是否冲突（色系层面，不追求完全一致）。 5. 图中商品是否体现标题中的核心卖点（如"加绒"则图中应是毛绒内里或外层纹理）。 只输出 JSON 数组，每个对象包含： - check_item, severity, issue, suggestion 如果图片无法判断某项，该项不要输出。 """

实测下来，第 5 项"卖点是否在图中有体现"是最容易被模型过度解读的。比如标题写"加绒"，主图如果只拍了外观没拍内里，模型有时候会判"未体现"，有时候会判"无法判断"。我的处理方式是在 Prompt 里明确：图片中未体现不等于商品没有该卖点，只有图中出现了与卖点明显矛盾的元素（比如标题写加绒、图中是单层薄纱）才算问题。这样调整之后，误报大幅下降。

4.5 结果合并、去重与报告生成

三层检查跑完后，把所有结果合并。去重是个关键动作，因为同一个问题可能被不同层同时报出来。比如质检报告型号和标题型号不一致，在"单文档体检"里不会被发现，但"跨文档一致性"和"图文校验"可能同时报一次。

我的去重逻辑是按"检查项编号 + 引文前 30 字"做 key，重复的只保留严重级别更高、置信度更高的一条。然后按严重程度排序，高危排最前，输出 Markdown 报告：

def dedup_problems(problems): seen = set() result = [] for p in problems: key = (p["check_item"], p.get("quote", "")[:30]) if key not in seen: seen.add(key) result.append(p) return result def sort_problems(problems): level = {"high": 0, "medium": 1, "low": 2} return sorted(problems, key=lambda p: level.get(p["severity"], 3))

报告开头放一段总结：共发现问题数、高危数、中危数、低危数、待人工复核数，然后是分模块的问题明细。这份报告直接发给运营和美工，他们照着一条条改就行。

5. 实测复盘：6 份资料 + 1 张主图查出的 27 个问题

5.1 一次体检的运行全流程

第一次完整跑通用的是一批真实待上新的女装商品资料：标题文案、详情页、规格参数表、价格与促销规则表、资质文件、库存物流配置，外加一张 800×800 的主图。

整个流程跑了 9 分钟左右，其中单文档体检 6 个请求并行，跨文档核对拆了 7 组任务，图文校验 1 个请求，一共消耗不到 90 万 token，按 Qwen3.8-Max 的接口定价折算，一次全量体检的成本在几块钱级别。相比人工核对两三个小时的人力成本，这个开销可以忽略不计。

模型输出的原始 JSON 里一共报了 31 条问题，去重后剩 29 条，再过滤掉 confidence 低于阈值的 2 条"待复核"，最终落在正式报告里的是 27 条。

5.2 27 个问题的分布明细

这 27 个问题按类别拆开是这样的：

合规类的 7 个问题里，4 个高危全部和极限词、绝对化用语相关：标题里的"全网首发"、详情页里的"最佳材质""100% 不刺激皮肤"、授权书品牌与售卖品牌不一致。有一个很隐蔽的是医疗用语跨界，详情页里写了"抗菌消炎"，这个在服饰、美妆类目都是高风险词。

一致性类的 8 个问题是最有价值的。其中"标题写加绒加厚、详情页写单层摇粒绒"直接是卖点矛盾，属于会引发差评和退货的类型。"划线价 299 元、活动价 199 元，平台又有满 200 减 30 的券，叠加后到手 169 元，低于这条商品的成本线 180 元"这种价格倒挂，人工核对的时候最容易忽略，因为三个数字来自三张不同的表。

完整性类的 7 个问题全是低危和中危，典型的是规格参数表没有产地字段、详情页没有售后政策、SKU 里黑色选项没配图、标题漏了品牌词。这类问题单个看不致命，但叠加起来会让商品信息完整度评分很难看，直接掉搜索权重。

图像类的 5 个问题里最扎眼的是主图分辨率只有 800×800，低于平台要求的 1000×1000；另外主图边缘有一块促销贴纸正好挡住了商品下摆，文字也有轻微裁切；图片主体是米白色，但文案写"云雾白"，色系上存在偏差。这些问题靠脚本只能查出分辨率，后面那几条必须靠多模态模型。

5.3 三个最值钱的问题：错过任何一个都是钱

27 个问题里，我挑三个最能说明价值的展开讲，因为它们在人工核对时大概率会被漏掉。

第一个是价格倒挂。人工核对三个价格通常只会看"活动价是否低于日常价"，很少有人会把满减、优惠券、会员折扣全叠一遍再和成本线比。结果就是这个 SKU 一旦上架，每卖一件就亏 11 元，卖得越多亏得越多。模型在做跨文档价格核对时，把几份表里的价格信息全抽出来按规则算了一遍，直接报了高危，并给出了建议售价。

第二个是证书型号错位。质检报告上的型号是 KX-208，但标题和规格表里全是 KX-280。这种字母数字顺序的错位，人眼很难发现，而且分布在不同文件里。但正是这种问题，在平台抽检或消费者索要证书时会被无限放大。模型在核对"型号"字段时同时比对了标题、规格表、资质文件三处，精准抓了出来。

第三个是加绒加厚 vs 单层摇粒绒。这是一致性类问题里最典型的一个：标题是运营写的，突出保暖卖点；详情页是美工从供应商素材里扒的，写了真实材质"单层摇粒绒"。两个说法单看都没毛病，放一起就是虚假宣传风险。这类语义层面的矛盾是正则脚本完全无能为力的。

6. 从"能跑"到"好用"：我踩过的坑和调优手段

6.1 大模型幻觉导致的误报：从三成降到接近零

第一版跑完，我自己人工复核了一遍报告，发现 29 条里有 8 条是误报，其中大部分集中在一致性核对环节。

最典型的一个：规格表写"成分：聚酯纤维 100%"，详情页写"面料：涤纶"，模型报了"材质冲突"。但实际上涤纶就是聚酯纤维的俗称，语义完全一致。这让我意识到，模型在自己不确定的时候不会说"我不确定"，它会硬着头皮给结论。

排查过程是这样的：我先看误报问题的原文引用，发现所有误报的 quote 都有一个共同特点——两边的用词在字面上完全不同。于是我回到跨文档核对的 Prompt，加了三条约束：第一，语义一致算一致，不能只看字面；第二，所有问题必须带 confidence 字段；第三，confidence 低于 0.6 的归入 pending，不进正式报告。同时我用一个简单的语义相似度测试集去调 Prompt 措辞，反复改了三四版，最终把误报从 8 条压到了 2 条，而且这 2 条都被 confidence 阈值挡在了"待复核"里。

这个教训是：大模型做交叉核对的产出，必须自带置信度，否则报告里掺着幻觉问题，比没有报告还危险。

6.2 长文档超出上下文窗口：先抽事实、再做比对

6 份资料里详情页文案最长，一份就有四千多字，再加上规格表和价格表，直接全塞进上下文很快就顶到窗口上限。第一版我把所有资料一股脑塞进去，结果模型开始丢信息，后半段的内容明显没有被认真比对。

我的解决方案是把"核对"拆成"抽取"和"比对"两步：先用一个 Prompt 让模型把每份文档里的关键信息抽取成结构化的事实条目（字段 = 值），比如材质=聚酯纤维、颜色=云雾白、型号=KX-280、到手价=169 元；然后再把多份文档的事实条目放在一起做比对。这样既压缩了文本量，又让比对的对象从"四千字散文"变成"几十条结构化断言"，准确率反而更高了。

FACT_EXTRACT_PROMPT = """ 把下面的商品资料抽取成结构化事实条目，只保留与上架审核相关的信息。 每条事实输出为 JSON 对象：{"field": "字段名", "value": "字段值", "source": "原文引用"} 【资料类型】{doc_type} 【资料内容】 {content} """

这一步还有一个额外收获：事实条目本身可以直接用于生成商品结构化信息，喂给平台的属性填写，算是检查之外的副产品。

6.3 图片核验的边界要画清楚

图像类检查我踩的坑最微妙。第一版我让模型"检查主图质量"，结果模型开始自由发挥，报了一堆"构图不够精致""背景杂乱""模特姿势不自然"之类的主观审美问题，运营看到直接懵了。

后来我把图片核验的边界收窄到"能客观判断"的范围内：分辨率、文字裁切、遮挡比例、颜色偏差、卖点元素是否存在矛盾。审美类问题一律不纳入自动检查，因为那是设计评审的事，不是合规体检的事。边界画清楚之后，图像类问题的可落地性高了很多。

另外提醒一点：图片相关的 Prompt 里，最好显式告诉模型"无法判断的项不要输出"。多模态模型在信息不足时会脑补，比如图片里根本看不到商品内里，它也会硬说"内里材质与描述不符"。加这一句之后，这种脑补问题基本消失。

6.4 成本、限流与缓存

最后说说不性感但很现实的问题：成本和限流。

单文档体检那 6 个请求可以并行发，但我第一次并行把 6 个请求一次性打过去，直接被限流，报了一串 429。后来我改成"3+3"分批并行，并发控制在 3，重试两次，就再没遇到限流。跨文档核对那 7 组任务同理，分组跑，每批最多 4 组。

成本上有个省钱的技巧：文档抽取的事实条目结果会被缓存下来。同一套资料如果只改了一张主图，重新体检时只需要重跑图文校验那一轮，其余结果直接读缓存。后面我把这个体检助手挂成定时任务，每天早上自动跑一遍当天要上新的商品，新增资料才触发新请求，月成本压得很低。

调到最后，这套体检助手的定位已经很明确了：它不是替代人工审核，而是把人工审核从"从头到尾扫一遍"变成"只需要看高置信度的问题清单"。运营和美工收到报告后，按高危、中危、低危的顺序逐条改，半小时能处理完一次上新，而这半小时在以前连核对材料都不够用。

我个人实际用下来最深的一个体会是：大模型做这种"资料体检"最有价值的点，不在于它一次查出多少问题，而在于它把"不可见的风险"变成了"可见的清单"。合规风险、价格风险、描述冲突风险，过去全凭经验和运气，现在至少有一个系统性的兜底。后面我还在琢磨两个扩展：一是把平台规则更新自动同步进检查项配置，二是把这套核对思路用到客服话术、直播口播稿的合规检查上，逻辑是完全一样的。如果你也在做类似的事，建议先把检查项标准和置信度机制设计好，这两样决定了你最终拿到的是"有用的体检报告"还是一堆模型幻觉。