Go+Wails+Vue3：AI Agent 自动化生成电商详情页流水线实战

1. 这条流水线到底在解决什么问题

做电商详情页这件事，说穿了就是一门“把一张图变成一套图，再把一套图变成一段能卖货的文案”的手艺。传统做法是运营拿到商品图，丢给美工，美工抠图、排版、配文案，一套详情页下来少说半天，多则两三天。如果碰上大促，几十个 SKU 同时上架，美工排期能排到下周去。我身边做淘宝店的朋友，最头疼的不是没流量，而是上新速度跟不上——图还没做完，竞品的链接已经跑出销量了。

所以当我第一次认真琢磨“能不能用 AI Agent 把这条链路自动化”的时候，脑子里想的不是炫技，而是一个很朴素的问题：一张商品图进去，一套能直接上传的详情页出来，中间不需要人盯着。这个目标听起来简单，拆开来看其实包含了好几个环节：图片理解、卖点提炼、文案生成、页面结构编排、前端渲染、最终导出。每一个环节都可以用现成的 AI 能力来做，但把它们串成一条稳定的流水线，才是真正费功夫的地方。

我选 Go 作为主语言来搭这条流水线，原因很直接。第一，Go 的并发模型处理这种“多步骤、多任务、有 IO 等待”的流水线特别顺手，goroutine 加 channel 的组合能把各个环节解耦得很干净。第二，Go 编译出来是单二进制，部署到服务器上不用折腾运行环境，对于我这种不想在运维上花太多时间的人来说太友好了。第三，Go 的生态里有足够多的 HTTP 客户端和 JSON 处理库，跟各家 AI 服务的 API 对接起来不费劲。

前端部分我用的是 Wails v2 加 Vue3。Wails 这个框架可能有些人不熟，它做的事情跟 Electron 类似，但用的是 Go 做后端、系统 WebView 做前端渲染，打包出来的体积比 Electron 小一大截。Vue3 负责详情页的预览和编辑界面，因为详情页本质上是 HTML 加 CSS 的排版，用 Vue3 做组件化渲染非常自然。整个项目跑起来之后，用户看到的是一个桌面应用：左边拖入商品图，右边实时预览生成的详情页，中间可以手动调整文案和排版，最后点导出就能拿到一套完整的图片或者 HTML。

这条流水线适合谁来参考？我觉得有三类人。一类是做电商工具的开发，想了解怎么把 AI 能力集成到实际业务里；一类是学 Go 想找个真实项目练手的，这个项目涉及 HTTP 调用、并发编排、文件处理、桌面应用打包，覆盖面够广；还有一类是运营或者美工出身、想自己动手做点自动化工具的人，代码逻辑不算复杂，照着改改就能用。

2. 整体架构设计与技术选型思路

2.1 为什么是 Go 而不是 Python

很多人做 AI 相关的项目第一反应是 Python，毕竟生态成熟、库多。我一开始也犹豫过，但最后还是选了 Go，核心原因是这条流水线的瓶颈不在模型推理，而在编排和 IO。图片理解要调视觉模型、文案生成要调语言模型、页面渲染要处理模板，这些环节大部分时间都在等网络返回。Python 的 GIL 在这种场景下虽然可以用异步绕过，但代码写起来会变得很绕。Go 的 goroutine 天然适合这种“多个环节并行、每个环节内部串行”的结构，代码可读性反而更好。

另一个考虑是部署。Python 项目部署要处理虚拟环境、依赖版本、系统库兼容，尤其是涉及到图像处理的时候，Pillow 在不同系统上的编译问题能折腾死人。Go 编译出来一个二进制文件，扔到服务器上就能跑，对于我这种一个人维护整个项目的情况来说，省下来的运维时间就是纯赚。

当然 Go 也有不方便的地方，比如图像处理的库没有 Python 那么丰富。我的做法是把图像处理这部分拆出来，能用 Go 原生库解决的（裁剪、缩放、格式转换）就用 Go 做，实在需要复杂处理的（比如抠图）就调外部 API。这样既保持了主流程的 Go 实现，又不用在图像处理上死磕。

2.2 Wails v2 加 Vue3 的前端方案

Wails v2 的定位是“用 Go 写桌面应用”，它的工作方式是把 Go 编译成后端服务，前端用系统自带的 WebView 渲染，两者之间通过绑定调用通信。跟 Electron 比，最大的优势是体积——一个简单的 Wails 应用打包出来可能就十几兆，Electron 动辄上百兆。对于详情页生成这种工具类应用来说，用户不会在意界面多华丽，但会在意安装包大不大、启动快不快。

Vue3 在这里的角色是详情页的渲染引擎。详情页本质上是一堆图片和文字的排版，用 Vue3 的组件化方式来做，可以把“标题区”“卖点区”“参数区”“详情图区”拆成独立组件，每个组件负责自己的样式和布局。生成的时候，Agent 输出的结构化数据直接绑定到组件上，预览区就能实时看到效果。用户手动调整的时候，改的是数据，组件自动重新渲染，不需要操作 DOM。

这里有个细节值得说一下：详情页最终要导出成图片，而 Vue3 渲染出来的是 DOM。我的做法是用 Wails 提供的截图能力，把预览区的 DOM 截成图片。这样用户看到什么，导出就是什么，不会出现“预览和导出不一致”的问题。截图的分辨率可以通过参数控制，一般详情页宽度设 750px 或者 790px，高度根据内容自适应。

2.3 GLM-4.6V 在流水线里的位置

视觉模型这条流水线里承担的是“看懂商品图”的任务。一张商品图里包含的信息其实很多：商品是什么、什么颜色、什么材质、有没有特殊卖点、背景是什么风格。这些信息如果靠人工输入，那自动化就失去意义了。GLM-4.6V 这类视觉语言模型的能力在于，你给它一张图，它能用自然语言描述出图里的内容，还能根据你的提问提取特定信息。

我在流水线里给视觉模型设计的提示词大概是这样的结构：先让它描述商品主体，然后提取颜色、材质、风格这些属性，最后根据商品类型推测可能的卖点。比如一张连衣裙的图，模型会输出“白色雪纺连衣裙，V 领设计，收腰版型，适合夏季通勤穿着”这样的描述。这些描述会作为后续文案生成的输入。

选 GLM-4.6V 而不是其他视觉模型，主要是考虑中文场景下的理解准确度。商品图里的文字、标签、场景元素，中文模型的理解通常更到位。而且它的 API 调用方式跟 OpenAI 兼容，Go 这边用统一的 HTTP 客户端就能对接，不需要为每个模型写不同的适配层。

2.4 流水线的整体数据流

整条流水线的数据流是这样的：用户拖入商品图，Go 后端先把图片转成 base64 或者上传到临时存储拿到 URL，然后调用视觉模型 API 获取图片描述。描述文本经过一轮结构化处理，提取出商品属性，再送给语言模型生成卖点文案和详情页各区块的内容。生成的结构化数据通过 Wails 的绑定传给前端 Vue3，前端渲染出预览。用户确认或者调整之后，触发导出，后端把预览区截图保存成图片文件。

这个流程里，Go 后端负责所有跟 AI 服务、文件系统、截图相关的操作，Vue3 只负责渲染和用户交互。两边通过 Wails 自动生成的绑定代码通信，Go 这边定义的结构体直接映射成前端的 JavaScript 对象，用起来很顺手。

3. 核心环节的实操细节与避坑经验

3.1 图片预处理：别急着调模型

很多人拿到图片直接就往视觉模型里塞，结果要么是图片太大超了 token 限制，要么是模型返回的描述跟商品无关。我在实际跑的时候发现，图片预处理这一步省不得。具体要做几件事：把图片的长边缩到 1024px 以内，这样既能保留足够的细节，又不会超出大多数视觉模型的输入限制；统一转成 JPEG 格式，因为 PNG 的透明通道在模型理解时反而会干扰；如果图片背景很杂乱，可以先做一个简单的背景去除，让商品主体更突出。

背景去除这块我试过几种方案。纯 Go 实现的抠图库效果一般，边缘处理不够干净。后来改成调外部 API，虽然多了一次网络请求，但效果稳定很多。如果你的商品图本身就是白底图，那这一步可以跳过，直接进模型。

还有一个细节是图片的命名。我习惯把商品 ID 或者 SKU 编码作为文件名，这样在后续流程里可以随时追溯是哪张图生成的详情页。批量处理的时候，这个习惯能省很多排查时间。

3.2 视觉模型调用的提示词设计

提示词这块我踩过不少坑。最开始写的提示词太开放，让模型“描述这张图片”，结果返回的内容五花八门，有的在讲构图，有的在讲光影，就是不讲商品本身。后来改成结构化提问，效果才稳定下来。

我现在的提示词模板大概是这样的：先给模型一个角色设定，比如“你是一个电商详情页文案助手”，然后明确任务“请分析这张商品图，提取以下信息”，接着列出需要提取的字段：商品名称、主要颜色、材质、风格、适用场景、可能的卖点。最后加一句“如果某个信息无法从图中判断，请留空，不要编造”。

这个“不要编造”很重要。视觉模型有时候会过度推理，比如看到一件衣服就推测出品牌，看到一瓶护肤品就编造成分。加上这句约束之后，返回结果的可靠性明显提升。

调用的时候还要注意超时设置。视觉模型的处理时间比纯文本模型长，我一般把超时设到 30 秒。如果超过这个时间还没返回，就重试一次，重试还失败就跳过这张图，记录到日志里让用户手动处理。不要因为一张图卡住整条流水线。

3.3 文案生成的结构化输出

视觉模型返回的是自然语言描述，但详情页需要的是结构化的内容：标题、卖点列表、参数表格、详情段落。这中间需要一个转换步骤，我用的还是语言模型，但这次要求它输出 JSON 格式。

提示词的设计思路是：把视觉模型的描述作为输入，要求语言模型按照指定的 JSON schema 输出。schema 里定义了每个字段的名称、类型、长度限制。比如标题不超过 30 个字，卖点列表 3 到 5 条，每条不超过 20 个字。这些限制是为了适配详情页的排版，太长的文字在页面上会换行，影响美观。

这里有个坑是 JSON 解析失败。语言模型有时候会在 JSON 外面包一层 markdown 代码块，或者漏掉某个字段。我的处理方式是先用正则把 JSON 部分提取出来，然后尝试解析，解析失败就重试。重试的时候在提示词里加上“请确保输出是合法的 JSON，不要包含任何其他文字”。实测下来，重试一两次基本都能成功。

还有一个经验是给模型提供示例。在提示词里放一个完整的输入输出示例，模型模仿示例格式的准确率会高很多。示例不需要很复杂，一个简单的商品加对应的 JSON 输出就够了。

3.4 Vue3 详情页组件的设计

详情页的 Vue3 组件我拆成了几个部分。最外层是一个容器组件，负责整体的宽度、背景色、字体设置。里面按顺序排列各个区块组件：主图区、标题区、卖点区、参数区、详情图区。每个区块组件接收一个 props，里面是 Agent 生成的数据。

主图区比较简单，就是展示商品图，可以加一些装饰元素比如边框、阴影。标题区展示商品标题和副标题，字体大小和颜色可以通过配置调整。卖点区是一个列表，每条卖点前面加一个小图标或者圆点。参数区是一个表格，左边是参数名，右边是参数值。详情图区是长图展示，如果 Agent 生成了多张详情图，就纵向排列。

这里的关键是数据驱动。组件的样式不写死，而是通过 props 传入配置对象。这样同一套组件可以适配不同的商品类目，服装类目和数码类目的详情页风格差异很大，但组件本身不用改，只改配置就行。

还有一个实用技巧是给每个区块加一个“显示/隐藏”的开关。有些商品不需要参数表，有些商品不需要详情图，用户可以在界面上勾选需要哪些区块，导出的详情页就只包含选中的部分。这个功能实现起来很简单，但用起来很灵活。

3.5 导出环节的分辨率控制

导出成图片的时候，分辨率是个需要仔细考虑的参数。太低看不清，太高文件太大。我的经验是，详情页的宽度设成 750px 或者 790px，这是淘宝详情页的常见宽度。高度根据内容自适应，但单张图片的高度不要超过 2000px，太长的图片在手机上加在速度会变慢。

如果详情页内容很多，超过 2000px，就自动切成多张图。切分的位置要选在区块之间，不要把一个区块切成两半。这个逻辑在 Vue3 里实现起来不难，计算每个区块的高度，累加到接近 2000px 的时候就切一刀。

导出的图片格式我一般用 JPEG，质量设 85 左右，在清晰度和文件大小之间取一个平衡。如果详情页里有文字特别多的地方，可以局部用 PNG，但整体还是 JPEG 更合适。

4. 常见问题排查与实战避坑指南

4.1 模型返回超时或者失败怎么办

这是跑流水线最常见的问题。AI 服务的 API 不是百分百稳定的，偶尔超时或者返回错误是正常现象。我的处理策略是分级重试：第一次失败等 2 秒重试，第二次失败等 5 秒重试，第三次还失败就跳过当前任务，记录到错误日志里。

重试的时候要注意，如果是提示词本身有问题导致的失败，重试再多次也没用。所以我在重试之前会先判断错误类型，如果是网络超时或者 5xx 错误，就重试；如果是 4xx 错误，说明请求本身有问题，直接跳过并记录。

还有一个技巧是给每个任务设置独立的超时时间。图片理解的任务超时设长一点，30 秒；文案生成的任务超时设短一点，15 秒。这样不会因为一个慢任务拖垮整个流水线。

4.2 生成的文案不符合预期怎么调

文案质量取决于提示词的质量。如果生成的文案太泛、没有针对性，通常是提示词里缺少具体的约束。我的做法是在提示词里加入商品类目的信息，比如“这是一件女装连衣裙”，模型就会往服装的方向去生成，而不是给出通用的卖点。

如果文案太长或者太短，就在提示词里明确字数限制。比如“标题控制在 20 到 30 个字之间”，模型会尽量遵守。如果还是不行，就在后处理阶段做截断或者补充。

还有一个办法是提供几个示例文案，让模型参考风格。比如给三个不同类目的示例，模型会模仿示例的语气和结构。这个办法对统一多个商品的文案风格特别有效。

4.3 详情页预览和导出不一致

这个问题通常是因为预览用的字体和导出用的字体不一样。Vue3 在 WebView 里渲染的时候用的是系统字体，截图的时候如果系统字体缺失，就会 fallback 到默认字体，导致排版变化。解决办法是在 CSS 里明确指定字体栈，并且把字体文件打包到应用里，确保渲染和截图用的是同一套字体。

另一个可能的原因是图片加载。预览的时候图片可能还没加载完，截图就触发了，导致图片区域是空白的。我的做法是在截图之前检查所有图片的加载状态，全部加载完成之后再触发截图。Wails 这边可以通过绑定调用前端的 JavaScript 函数来检查，前端返回一个 Promise，所有图片加载完才 resolve。

4.4 批量处理时的并发控制

批量处理几十张图的时候，如果一次性全部并发调模型，很容易触发 API 的速率限制。我的做法是用一个带缓冲的 channel 来控制并发数，比如同时最多 5 个任务在跑。每完成一个就从 channel 里取下一个，保持稳定的吞吐量。

并发数设多少合适？这个要看 API 的速率限制和你的账户等级。我一般从 3 开始试，如果没触发限流就加到 5，再往上加收益就不明显了，因为模型处理本身需要时间。而且并发太高的话，本地 CPU 和内存也会吃紧，尤其是图片预处理那一步。

还有一个细节是错误隔离。批量处理的时候，某一张图失败不应该影响其他图。每个任务独立处理，失败的任务记录到单独的错误列表里，最后统一展示给用户，让用户决定是重试还是手动处理。

4.5 常见问题速查表

5. 几个提升效率的实战技巧

5.1 用缓存减少重复调用

同一张商品图如果多次生成详情页，没必要每次都调模型。我的做法是把图片的哈希值作为 key，模型返回的结果作为 value，存到本地的一个轻量级缓存里。下次遇到同样的图片，直接读缓存，省掉一次 API 调用。这个优化在调试阶段特别有用，因为调试的时候经常反复跑同一张图，有缓存的话响应速度会快很多。

缓存的过期时间我设的是 7 天，因为商品信息可能会变，太久之前的缓存可能不准确。缓存文件用 JSON 格式存，方便查看和手动清理。

5.2 日志要记全，但别记敏感信息

流水线跑起来之后，出问题的时候全靠日志排查。我的日志里会记录每个环节的开始时间、结束时间、耗时、是否成功、错误信息。但有一点要注意，API key 和用户上传的图片内容不要记到日志里。API key 记到日志里是安全隐患，图片内容记到日志里会让日志文件变得巨大。

我的做法是只记录图片的文件名和哈希值，不记录图片本身。API key 从环境变量读取，日志里只记录“key 已加载”这样的状态信息。

5.3 给用户留一个手动干预的入口

全自动的流水线听起来很美好，但实际用起来，用户总会有想手动调整的地方。比如模型生成的标题差一个字，或者卖点的顺序想换一下。如果每次都要重新跑一遍流水线，体验就很差。

所以我在 Vue3 界面上给每个字段都做了可编辑的支持。用户可以直接在预览区点击文字进行修改，改完之后导出用的就是修改后的内容。这个功能的实现成本不高，但用户满意度提升很明显。

5.4 版本管理：提示词也要进 Git

提示词是这条流水线的核心资产之一，它的迭代频率不比代码低。我习惯把提示词单独放在一个文件里，跟代码一起进 Git 管理。每次调整提示词都提交一次，这样出问题的时候可以回滚到之前的版本，也能看到每次调整带来的效果变化。

提示词文件里我会加注释，说明每个版本改了什么、为什么改。比如“v3：增加了不要编造的约束，减少了模型幻觉”。这些注释在几个月后回头看的时候特别有价值。

5.5 性能优化的几个观察

跑了一段时间之后，我观察了一下各个环节的耗时分布。图片预处理大概占 5%，视觉模型调用占 40%，文案生成占 30%，前端渲染和导出占 25%。也就是说，AI 调用占了七成的时间。所以优化的重点应该放在减少 AI 调用的次数和提升单次调用的速度上。

减少调用次数的办法就是前面说的缓存。提升单次调用速度的办法，一是选响应更快的模型，二是优化提示词的长度。提示词太长会增加模型的处理时间，所以我在保证效果的前提下尽量精简提示词。把一些固定的约束放到系统提示里，用户提示里只放跟当前商品相关的内容，这样也能减少每次请求的 token 数。

6. 这条流水线还能往哪些方向扩展

6.1 接入更多模型做对比

现在流水线里用的是 GLM-4.6V 做视觉理解，语言模型用的是另一家。其实可以把模型调用抽象成一个接口，支持配置不同的模型提供商。这样用户可以根据自己的需求和预算选择模型，也可以同时调多个模型，对比生成效果，选最好的那个。

这个扩展的实现难度不大，主要是把模型调用的部分抽象成接口，每个提供商写一个适配器。Go 的接口机制做这件事很自然，定义一个VisionModel接口和一个LanguageModel接口，每个提供商实现这两个接口就行。

6.2 支持更多电商平台的详情页模板

现在只做了淘宝的详情页模板，其实拼多多、京东、抖音小店的详情页规格都不太一样。可以把模板做成可配置的，每个平台一套配置，包括宽度、字体、区块顺序、导出格式。用户选择平台之后，流水线自动套用对应的模板。

模板配置我建议用 JSON 或者 YAML 来写，不要硬编码在代码里。这样非开发者也能调整模板，改个配置文件就行，不用重新编译。

6.3 加入 A/B 测试能力

同一个商品，让模型生成两套不同风格的文案，导出两个版本的详情页，投放到不同的渠道，看哪个版本的转化率更高。这个功能对于做精细化运营的商家来说很有价值。

实现上就是在文案生成环节跑两次，用不同的提示词或者不同的温度参数，得到两组结果。前端可以并排预览两个版本，用户选择其中一个导出，或者两个都导出。

6.4 把流水线做成服务

现在的形态是桌面应用，如果做成服务端 API，就可以集成到商家的 ERP 或者商品管理系统里。商家上传商品图之后，系统自动调用流水线生成详情页，全程不需要人工干预。

做成服务的话，需要考虑的东西就更多了：任务队列、并发控制、结果存储、鉴权。Go 在这方面有天然的优势，标准库里的 HTTP 服务器和并发原语足够支撑一个中等规模的服务。如果量再大，可以引入消息队列来做任务分发，但那是另一个阶段的事情了。

我个人在实际操作中的体会是，这条流水线最值钱的地方不是用了多先进的模型，而是把各个环节串起来之后形成的自动化能力。单个环节的 AI 调用谁都会写，但要让整条链路稳定跑起来，处理好超时、重试、缓存、并发、错误隔离这些工程问题，才是真正拉开差距的地方。模型会不断更新，API 会不断变化，但这条流水线的架构思路是通用的，换一个模型、换一个平台，骨架不用动，改改适配层就能继续用。