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 常见问题速查表问题现象可能原因排查方向解决办法模型返回超时网络波动或服务端负载高查看错误码和响应时间分级重试设置合理超时文案内容泛泛提示词缺少类目约束检查提示词是否包含商品类型加入类目信息和示例JSON 解析失败模型输出格式不规范打印原始返回内容提取 JSON 部分重试并强调格式预览导出不一致字体或图片加载问题对比预览和导出的截图打包字体等待图片加载完成批量处理触发限流并发数过高查看 API 返回的限流错误降低并发数加缓冲 channel图片理解不准图片质量差或背景杂乱检查输入图片的分辨率和背景预处理图片去背景缩放详情页排版错乱数据字段缺失或超长检查 Agent 输出的结构化数据加字段校验和长度截断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 会不断变化但这条流水线的架构思路是通用的换一个模型、换一个平台骨架不用动改改适配层就能继续用。
