我用 Qwen3.8-Max 搭了一个电商商品资料包体检助手，6 份资料和 1 张商品图一次查出 27 个问题

背景：我为什么要搭这个

我平时接触商品上架资料时，最费时间的不是写一个标题，而是确认这个标题有没有被说明书、检测报告和平台规则支持。产品说明书、检测报告、品牌授权书、平台发布规则、商品信息表和待发布文案，往往分散在不同文件里，商品图片还可能是另一份信息来源。

人工检查时，我需要在六份材料之间来回切换，逐项对型号、规格、企业、授权渠道和有效期，再判断文案中的功效有没有证据。这个过程很容易漏掉细节，也很难把每个问题的证据位置记录完整。

所以我想做一个能直接上传资料使用的工具：把一套商品资料和商品图放进去，它自己完成解析、比对、合规审查，最后给出可以回到原文件复核的问题清单。测试商品只是验证流程用的样本，代码里不能写死它的字段和答案。

最终效果

最新版本一次上传 6 份资料和 1 张商品图 ，页面给出 27 个问题：高风险 25 个、中风险 2 个，结论是"不建议发布"。问题里既有资料之间的型号、净含量、品牌和商品名称冲突，也有宣传语超出证据范围、授权渠道和有效期方面的风险。

商品图没有被我手动抄成文字再塞进输入框。增加图片功能时，我只要求把图片直接以多模态消息传给 Qwen3.8-Max。Qoder 里的 Qwen3.8-Max 完成代码后，自己生成了一张测试商品图，又把这张图走了一遍完整审查流程。图片上传区、生成的测试图和开发过程同时保留在这次操作记录里。

这张图被直接送入 qwen_vision，模型从可见内容中提取出品牌、商品名称、型号和净含量 4 个字段。它们随后和六份资料一起进入一致性检查，图像中的字段因此也能影响最终问题清单。对我来说，这个环节把"支持上传图片"和"真正理解图片"区分开了：前者只是输入形式，后者必须在后续核验结果中留下痕迹。

最终运行记录很清楚：模型调用 2 次 ，Prompt Tokens 1652 ，Completion Tokens 6087 ，Total Tokens 7739 ，总耗时 125.3 秒 。其中 qwen_vision 用了 1959 Tokens、约 14 秒，qwen_chat 用了 5780 Tokens、约 111.1 秒。页面把两个调用拆开记录，我可以分别判断图片理解和文字审查各自花了多少 Token 与时间，而不是只看到一个无法解释的总数。

开头的录屏记录了从上传商品图到结果页的完整操作过程，图片识别和资料解析、规则检查、结果输出是在同一次运行中完成的。

搭建过程

先把需求问清楚

我没有直接把"做一个商品资料审查工具"丢给代码编辑器。先在 Qwen3.8-Max 网页端免费体验，把业务流程、页面、接口、数据结构、工具调用和验收条件问完整，要求它给出能执行的设计，而不是只列几个功能名。

这次回答一直写到第 25 部分 ，并且列出了 16 项交付物，从前端页面、后端 API，到解析器、规则检查器、模型适配层、证据索引和测试用例都有对应位置。

网页端先把业务目标展开成页面、接口和验收条件，后续的长回答都围绕这些条件继续细化。我关心的不是篇幅本身，而是它有没有把"问题必须能回溯到材料"这类细节带进后续实现。

我把"每条问题都要能定位到文件名和页码或表格位置"反复保留在设计里。后面代码迭代时，这个要求没有因为上下文变长而消失。

让 Qoder 先读资料，再动手

我准备了一套普通电商商品的虚构资料包，包括产品说明书、产品检测报告、品牌授权书、平台商品发布规则、商品信息表和待发布商品草稿。资料中故意保留了型号、净含量、宣传用语、授权渠道和有效期冲突，用来检验工具是否真的会跨文件判断。

接着在 Qoder CN 里选择 Qwen3.8-Max，让它先检查当前目录和这六份材料。它把说明书、检测报告和授权书识别为事实依据，把商品信息表和待发布文案识别为被检查内容，把平台规则识别为审查依据。

它先把第一版范围收窄到上传解析、字段一致性、宣传风险、授权检查和报告展示，没有把网页端的完整设计一次性全部做完。先做这几个能验收的环节，后面接真实模型时才有稳定的输入和输出位置。

从 Mock 版本到真实 API

Qoder 注册页提供了两周试用和 300 Credits。我先让它检查 Python、Node、npm 和 PDF 解析环境，再创建 Vue 3 前端、FastAPI 后端和本地 Mock 规则引擎，先保证上传、解析、检查、展示这条路径能跑起来。

它在 IDE 里直接检查环境、创建目录、安装依赖、执行命令和启动服务。第一版已经能在 5173 和 8000 端口运行，变更记录里一共接受了 37 个文件。我在这里把"能否启动"作为一个单独检查点，先确认页面和 API 真的连得上，再继续增加模型调用。

环境检查完成后，它才开始写业务文件；我能在同一处看到依赖安装、目录创建和服务启动的结果。这个顺序让第一版出现问题时，能分清是环境没有准备好，还是上传与检查逻辑本身出了问题。

页面跑通后，我在 百炼 Qwen3.8-Max 模型页配置真实 API。模型 Code 使用 qwen3.8-max，密钥放在本地 .env，不写进前端，也不提交到版本库。百炼页面当时显示输入输出价格和 1,000,000 的免费额度。我先确认接口配置和额度，再把 Mock 替换成真实审查，便于判断问题到底来自代码还是模型返回。

我先把价格、免费额度和模型 Code 记下来，再进行 API 接入。这样后面看到 Token 统计时，可以把开发阶段的 Qoder 调用和成品运行时的百炼调用分开看，也不会把两种额度混在一起。

接入后，工具先由本地解析器读取 PDF 和 Markdown，再由本地检查器处理明确的字段冲突、禁用词、授权渠道和有效期，最后把整理好的事实和证据交给 Qwen3.8-Max 做语义审查。这样模型面对的是结构化材料，而不是一堆没有来源的文本。

把过程也显示出来

我把六份材料上传后，第一次看到的是"不建议发布"和一串问题，但我还不知道它到底读取了哪些文件、调用了什么、花了多少 Token。

上传页按材料角色分成六个位置，资料没有齐全时不会开始审查。这个限制能避免模型在缺少依据时仍然给出看似完整的结论，也让我在测试时知道每一次运行到底用了哪些输入。

我随后要求它把审查过程放到页面里，显示已读取文件、解析规模、工具调用、模型调用次数、Token 和耗时，同时明确不能伪造工具记录，也不展示模型隐藏思考内容。这个改动会直接影响后端事件格式和前端状态展示，所以我让它在原项目上修改并重新运行，而不是另起一个演示页面。

我希望看到的是实际发生过的调用，而不是一段写在页面上的说明。只有把文件、工具、Token 和耗时都作为运行事件记录下来，问题清单才有复查的入口。

Qwen3.8-Max 在原项目上继续修改，把后端事件改成流式记录，前端增加过程面板，Token 直接读取接口返回的 usage。一次中间验证记录为 4849 Tokens、85.7 秒，Qoder 的开发调用额度从 192 / 800 变成了 241 / 800。

最后加上商品图片

文本流程稳定后，我又提出一个很具体的要求：让工具支持直接上传商品图，并把图片识别结果加入已有字段比对。Qoder 里的 Qwen3.8-Max 不只修改了上传组件和后端客户端，还生成了测试商品图并立即执行调用测试。

代码中，原始图片字节被编码为 base64，并以 image_url 类型放进发给 qwen3.8-max 的消息。识别结果进入现有的一致性检查，和文档字段一起参与问题合并。最终页面把六份文档和 1 张商品图分开列出，方便我判断输入是否完整。

技术选型

• 前端使用 Vue 3，负责六份资料、商品图上传、进度事件和问题清单展示。
• 后端使用 FastAPI，负责文件接收、解析、检查编排和结果下载。
• PDF、Markdown 先由本地解析器处理；字段一致性、宣传合规、授权渠道和有效期有独立检查器。
• Qwen3.8-Max 负责跨材料的语义复核和商品图理解，分别记录为 qwen_chat 和 qwen_vision。
• Qoder CN 提供文件读取、终端执行、服务启动和迭代修改所需的 Agent 工作环境。
• API 配置使用 .env：QWEN_API_KEY、QWEN_BASE_URL、QWEN_MODEL=qwen3.8-max。密钥只在后端使用。

本地检查器与模型并不是二选一：能确定的冲突先给证据位置，需要理解上下文的宣传风险再交给模型，结果页把两类过程放在同一份报告里。

核心 Prompt / Agent 编排

我给 Qoder 的第一条开发要求很短，但把验收条件写清楚了：

请先读取当前目录和 test-data 中的资料，做一个可运行的电商商品资料包体检工具。
使用 Vue 3 + FastAPI，先用 Mock 跑通上传、解析、字段比对、合规检查和报告展示，
再接入 Qwen3.8-Max API。不要把测试商品的字段、规则、问题或答案写死。
每条问题保留文件名、页码或表格位置，运行后启动前后端并自行测试。

增加多模态时，我追加的是这一段：

再增加商品图片识别，将图片以多模态消息格式直接传给 Qwen3.8-Max。
将识别出的品牌、商品名称、型号、净含量加入现有字段比对和问题清单，
并在审查过程中显示真实的 qwen_vision 调用、图片数量、Token 和耗时。
请生成一张测试商品图，完成一次端到端调用测试。

运行时的编排关系保持得很简单：

六份文档 -> PDF/Markdown parser -> 字段提取与本地检查器
商品图片 -> qwen_vision -> 可见字段
文档事实 + 图片字段 + 规则结果 -> qwen_chat -> 问题、证据和整改建议

Qwen3.8-Max 在 Qoder 中还要处理另一类工作：读已有代码，判断改动会影响哪些接口，执行测试，查看运行结果，再继续修正。它不是只生成一段孤立代码，而是沿着同一个工作区持续推进。

踩坑记录

第一版的问题不是不能运行，而是结果不够可核验。页面上的问题数量、合并后的检查结果和最终报告曾经不同步；我能看到结论，却看不到六份文件是否都读过，也无法区分本地检查和模型补充。

我把要求改成"只记录真实执行过的事件"，让它给每个解析器、检查器和模型调用留下名称、输入对象、耗时和 Token。后端从接口 usage 读取数据，接口没有返回时显示 0，Mock 模式则明确标注未调用大模型。改完后，报告里的工具数量、模型调用次数和总 Token 可以互相对上。

图片功能又暴露了另一个问题：如果只是把图片路径当普通文本交给模型，就不能证明模型真的看到了图片。我改成直接发送 base64 图片消息，并要求识别结果进入原有字段比对。生成测试图、调用 qwen_vision、把四个可见字段带入冲突检查，才形成了可重复的验证。

效果对比

只用文字资料时，成品记录为 1 次 qwen_chat 调用，Prompt 389 、Completion 5134 、Total 5523 Tokens ，耗时 96.7 秒 ，输出 26 个问题。

加入商品图后，增加了 1 次 qwen_vision 调用：图片识别使用 1959 Tokens、约 14 秒 ；最终运行变为 2 次调用、7739 Tokens、125.3 秒 ，问题数变成 27 个。多出来的问题来自图片字段与基准资料的冲突，而不是把图片当成装饰上传。

人工方式需要把六份文件和商品图逐份打开，来回核对型号、净含量、文案证据、授权渠道和有效期，再把问题位置记下来。我按这套资料实际走一遍，至少需要 10 分钟 ，而且还要额外整理一份问题清单。这个工具把相同工作压缩成一次上传和一次运行：文字资料版本在 96.7 秒 内返回 26 个问题，加入商品图后在 125.3 秒内返回 27 个问题，同时保留文件、工具、Token、耗时和整改建议。

按百炼页面当时的每百万 Tokens 输入 12 元、输出 36 元估算，最后一次运行的理论费用约 0.24 元 ；这次实际使用的是免费额度。完成4次调用后，页面还显示免费额度剩余 975,567 / 1,000,000（98%） 。

总结：Qwen3.8-Max 在这个场景下的表现

这次让我最有感的是它能在一个持续变动的项目里保持上下文：从长需求、六份资料，到前后端代码、运行结果和多次改动，不需要我每次重新解释项目背景。百炼页面标注的 1M 上下文，在这种跨文件、跨代码、跨多轮修改的场景里有了实际用处。

商品图功能则把它的原生多模态能力落到了运行结果上：图片直接进入 qwen_vision，识别字段再参与资料核验。Qoder 里的 Agent 工作流还让它完成了生成测试图、修改代码、启动服务和端到端测试，这些过程都能在记录面板里复查。

最新一次完整审查需要 125.3 秒，页面会同步展示资料解析、图片识别、规则检查和语义审查的执行进度。

复现指南

环境是 Python 3.9.7 、Node 22.12.0 、npm 10.9.0。后端用 FastAPI，前端用 Vue 3；后端端口 8000，前端端口 5173。

先在后端启动服务：

cd backend
.venv/bin/uvicorn main:app --port 8000

再启动前端：

cd frontend
npm run dev

在后端 .env 中配置：

QWEN_API_KEY=你的百炼API密钥
QWEN_BASE_URL=你的百炼兼容接口地址
QWEN_MODEL=qwen3.8-max

把六份测试资料上传到对应位置，再选择一张商品图片，点击开始体检。结果页应当先列出 6 份已读取文件和 1 张已识别图片，再显示本地检查器、qwen_vision、qwen_chat、问题清单和下载结果。用同一套资料复现时，最终记录应接近 27 个问题、2 次模型调用、7739 Tokens、125.3 秒，网络和接口响应速度不同会带来小幅波动。

复现多模态部分时，关键不是把图片文字手动抄进输入框，而是保留图片消息的 image_url 数据，并让识别出的字段继续进入一致性检查。API 密钥不要放到前端代码、截图或提交记录中。