从参考图到批量出图，我用 Seed-2.1-pro-0915 做了一个可验证的电商视觉工作台

大家好！我是一点一木。

先别急着听我讲，直接看成果演示。

可惜了，视频上传太复杂了，还是算了。。。就用图片代替一下吧！

这不是一次普通的生图，而是我用 Seed-2.1-pro-0915 从零做出来的一个项目：Visual Director，一个本地优先、自带密钥的电商商品图 AI 工作流。它把参考图变成可确认、可复用的视觉配方，经人工确认后再生成、逐张验收，再把同一套已发布工作流复用于整批商品。

它干的事说起来不复杂，把参考图变成你能确认、能复用的视觉配方，再安全地一批一批出图。更准确点讲，它是一个面向静物电商的视觉生产工作台。先让模型说清楚「这张画面到底由什么构成」，你点头之后它才去生成，然后逐张验收，最后把同一套已经发布的工作流，原样复用到整批商品上。

如果只看最终页面，它有点像一个节点式生图工具。但我真正想解决的，并不是「再做一个输入提示词、点击生成的页面」。我想做的是，把电商生图里那些原本散落在脑子里、聊天记录里和不同工具里的判断，变成一条能检查、能修改、能保存，也能重复执行的工作流。这两者看起来只差几个功能，实际做起来，差得还挺远。它想解决的不是"再多一个生图按钮"，而是一个更实际的问题：怎么把一次成功的生成方法存下来，让人能检查、能修改、能发布，再用到下一批商品上。

一次参考图辅助全流程的成品：模型保留了黑红耳机的商品主体，吸收了参考图的粉色氛围。

核心功能

从参考图分析、提示词确认、商品场景生成，到工作流复用和批量处理，每个环节都能点开看、能往回查。

参考图分析与视觉配方。 上传 1～5 张参考图，模型把画面解析为用途、主体位置、拍摄角度、构图、背景、光线方向、光质、调色、材质表现、氛围等 12 个结构化字段，每个字段附带置信度与图像证据。它只描述画面本身，不猜测、也不声称恢复了原图的提示词。

商品身份锁定。 上传同一商品 2～3 张多角度照片，模型提取形状、部件、颜色、材质、Logo、纹理等候选特征。所有候选默认是“待确认”状态，只有人工确认后才成为不可改变的硬约束——模型的推测不会自动升级成事实。

结构化提示词确认。 提示词由已确认的配方与身份编译生成，只读、可核对；自由文本不能反向覆盖已经确认的结构，避免一句话冲掉全部约束。Seed-2.1-pro-0915 的初次理解不是终版指令，而是一份可检查、可修改的中间结果。

商品场景生成。 按渠道选择画幅比例（1:1、16:9 等）、分辨率（1K/2K/3K）与出图数量，把商品放进符合配方的场景中。生成通道独立配置，没配也不影响其他功能使用。

四维结果验收。 从商品身份（权重 0.4）、视觉配方（0.3）、场景任务（0.2）、技术质量（0.1）四个维度逐张检查：严重错误一票否决；证据不足时一律标记「需人工复核」，不强行通过。

定向修复。 验收失败时，只针对问题点做一次定向修复再重新生成；形态、Logo、材质、虚构文字等高风险问题必须停车，由人确认后才继续。

首版面向静物电商：陶瓷、花瓶、香薰、摆件这类商品的主图、详情页场景图，以及一组 SKU 的批量换景。边界同样写在产品里：不做人像换装，不承诺复杂包装文字渲染，图片里的品牌标识和细小结构仍需人工核验。

工作流复用：画布可以改，版本不能动

新建项目有两个模板：「直接生成」和「参考图辅助生成」。后者默认露出五个节点：参考图分析、商品图、提示词编辑与优化、商品场景生成、结果展示。

被复用的不是某句提示词，而是一份可追溯的工作流快照。

批量处理：同一版本，多件商品受控开跑

批量任务只接受已发布版本。批量页面里，多件商品共享同一套参考风格和发布好的工作流，同时每一行商品的素材、状态、结果、错误都是独立的。

每批最多 5 件，每件 2 到 3 张图。某一件出问题，只影响它自己，不会把整批拖下水。密钥、额度、服务端这种系统级错误，才会让整批暂停。

边界也要说清楚：批量引擎的代码已经写完，但我还没用真实商品跑完过一次完整批量任务。上面这些是设计和单测里的行为，不代表它在大量商品上已经被验证稳定——这部分我会在真正跑过几批之后再下结论。

还有个我很在意的细节，刷新页面的时候，还在跑的任务一律判成中断，需要你手动恢复。它不会假装自己在后台还好好跑着。这种诚实，比什么都重要。

为什么会有这个项目

讲完它能干什么，说说这事怎么来的。

起因很简单。身边做电商视觉的朋友问我，能不能把同类里表现不错的图拿来参考，再结合自己的商品，快速生成新图。

听起来不难：找张图，上传商品，写一句「参考这张图生成类似效果」，然后等结果。但真正做电商图时，麻烦的恰恰是那些一句话说不清的部分——商品放在哪、主体占画面多大、背景怎么分层、光从哪个方向进来、整体什么色调，哪些可以借鉴，哪些品牌、文字和产品特征不能照搬。这些判断，最后都要变成图片模型能理解的描述。

做一张图，可以反复试。可一旦几十件商品要统一视觉方向，分析、写词、传图、生成、筛选就要重复几十遍。偶尔出了一张好图，参考素材、提示词和参数还可能散落在不同地方，下一次再做，还是从零开始。

所以最初的问题只有一个：

能不能让视觉语言模型（VLM）先拆解参考图的视觉语言，再把这套语言用到我自己的商品上？

正好赶上 Seed-2.1-pro-0915 升级上线。官方介绍里，它强化了多模态理解、Agent 长程任务和 Coding 工程实践。我想认真测一测它的 VLM 能力，看它能不能理解参考图里那些说不清的视觉规则。这个任务也几乎正好对应：项目有需求、数据结构、风险和验收文档，输入里既有代码和文字，也有参考图和页面截图；开发不是生成几个文件就结束，而是不断运行、发现问题、回到代码继续修。

所以我决定直接用它做一次完整项目，而不是只测几个零散问题。

我是怎样把它做出来的

这次开发全程在豆包工作里完成，模型选的就是 Seed-2.1-pro-0915（火山方舟上的 API 名是 Seed-Evolving，二者是同一版本）。

选它的理由很直接：项目不是单文件 Demo，既要 VLM 分析参考图和商品身份，又要 Coding 做工程、画布和批量，中途还得把页面截图丢回去判断问题类型。豆包工作能挂载本地目录，读文档、写代码、跑命令、开浏览器自测全在一个会话闭环，视觉输出和代码修改不用来回搬运。新模型也能直接在里面用，顺手验证多模态 Coding。

开工前先做需求调研，产出一组产品文档，然后分阶段推进。阶段一只做最小闭环：参考图拆成结构化视觉配方、商品多角度图提取身份特征、生成结果按商品身份/配方/用途/质量验收。没有一上来就铺画布和批量。

结果第一步就遇到「高峰期算力紧张」，好在点继续后恢复了。阶段一跑完，它交付完成报告：用时 33 分 22 秒，从零创建 43 个工程文件，分两次提交进 Git，技术栈 React + TypeScript + Vite + Zod + Vitest，三探针、密钥会话存储、官方域名白名单全部落地。

阶段一结束，项目已经能在浏览器里跑起来：上传参考图和商品图、看调用预算、走三道分析。

之后是逐步迭代：固定主干、节点画布、版本发布、批量引擎。中间反复经历「运行测试 → 修 BUG」，豆包工作的额度一度用完，而且用了两张重置卡，后续就只能换时间接着跑。

真实运行记录也值得放上来。9 月 22 日凌晨到上午，我一共跑了四次：一次成功，三次超时——两次卡在参考图分析，一次卡在图片生成，当时的超时阈值都是 180 秒。成功的那次，参考图辅助全流程（两次模型调用）节点记录用时 203.8 秒；两次不用参考图的直接生成，分别是 90.5 秒和 89.2 秒。这些只是这几次的真实记录，不能包装成平均性能。后来我把生成超时从 180 秒放宽到 300 秒、增加 1K 预览分辨率，才有了上午那次完整跑通。

运行记录会标明失败具体卡在哪个节点，而不是弹一句模糊的"生成失败"。

讲一个真实的修 BUG 过程。工作台首页的项目卡片封面出现了浏览器裂图。我没有让它直接改代码，而是要求先分析、给方案：

它定位到：数据链路已通，但视图层把 <img> 的 src 写成了空字符串，浏览器把当前页面 URL 当图片请求。方案是补素材 ID 解析、悬空 ID 回退、加载失败占位。确认后才动手，同时补了组件测试，改前改后对比明显。

这种「先取证、再下结论、经确认才改」的节奏，和我给产品设计的人工闸门是同一思路。

工作台完成后，缺一个让新用户看懂的入口，于是让它做官网首页：

在现有项目中新增一个独立的产品官网首页，让新用户快速了解 Visual Director 的定位、核心功能、使用场景、操作流程和实际效果，并提供清晰的“进入工作台”入口。首页重点呈现“参考图分析、提示词确认、商品场景生成、工作流复用和批量处理”等核心能力。保留现有工作台功能与路由，使用真实项目素材，整体设计专业、统一且具备商业产品感。请结合现有项目自主完成页面结构和视觉设计，不重构无关功能，只做必要的基本检查。

它先去读我写的官网规格文档，再从运行中的工作台采集真实界面截图，后产出了完整的单页官网：Hero、痛点、六项能力、流程、工作流复用、批量、数据安全、FAQ，一次成型。

也说明一下当前状态：项目已经跑通了参考图分析到出图验收的核心链路，证明这条路可行；但它仍是一个持续迭代中的项目，节点会继续增加（18 个规划节点等着接通），批量和跨品类还要补功能。

模型分工

这次实际用到的模型分工很清晰：

密钥与数据边界

项目不内置模型额度，需要填写自己的方舟 Key。安全策略上：

• 项目数据只存在本机浏览器 IndexedDB；
• Key 只进当前标签页的 sessionStorage，关闭标签页即清除；
• 不写入数据库、Cookie、URL 或导出文件。

一句话：模型各司其职，数据留在本地，Key 不落盘。

总结：三点真实感受，和没做完的部分

做完这版，我对 Seed-2.1-pro-0915 的多模态 Coding 有了具体感受。对照官方这次升级方向，有三点是我在项目里真正用到的：

一是VLM 能落到结构化产出。它能稳定输出带字段、带置信度的结构化描述。这正是「VLM + Agent」能成立的前提——后续的提示词编译、人工确认、验收和版本复用，都建立在这份机器可读的中间结果上。

二是工具调用讲证据。官方发布说明提到，新版强化了「调用必要工具取证、等待真实结果、检查返回内容再声明完成」。我的开发过程里，无论是先分析裂图根因再改、测试真实跑过才报告通过，还是产品里给模型设计的 Schema 校验和人工确认闸门，方向都一致：让 AI 的每一步都有可检查的证据。

三是端到端 Coding 能交付完整工程。从零初始化、类型化节点、图校验、执行计划、不可变版本到本地持久化。这不是单文件 Demo，而是一个有数据层、安全边界和测试网的工程——投稿前我又把测试完整跑了一遍：44 个测试文件、333 个用例全部通过。

不足同样清楚：参考图分析耗时偏长，高峰期有排队。节点库一共定义了 35 个节点：5 个已经接通执行适配器，30 个仍标记为规划中，能查看、能拖进画布，但没有适配器就不能运行或发布。

这次开发也逼着我重新分清三种状态：哪些是真接通了，哪些只是做了界面，哪些还在规划里。从「批量页面调用画布工作流」这么一句话，到它真能执行，中间得补齐版本冻结、执行计划、输入契约、逐件状态和中断恢复。只做一个页面入口，根本不等于功能完成。

一张好图当然重要，但决定它能不能进生产流程的，是生成前后那些环节：参考怎么被拆解，模型理解怎么被人确认，流程怎么保存，批量怎么保证同一版本，失败后怎么定位到具体节点。这个项目目前只证明了一件事：这条路走得通。

AI Coding 真正让人兴奋的，不是它一天能写多少行代码，而是一个原本只停留在脑子里的想法，真的可以被一点点做出来。剩下的，我会接着往下做。

如果你也在做电商视觉，欢迎上手试试：

• GitHub 仓库：github.com/chnjames/vi…
• 在线体验：visual-director-pearl.vercel.app