来到智利从零开始（有机会我会写一篇介绍我的经历），由于不懂西班牙语，我把目光投向了唐人街。
在这里，我真正明白了一句很久以前听过的话——商品不是从货架上长出来的。
和店主们交流了一段时间后，我逐渐理解了这里大部分店铺的运作模式：批发和零售一体的实体店。
日常要点货、理货、上架、发货、管仓库、补货；还没走上正轨的店铺，更要自己拍照、录入商品信息、运营线上渠道、管理客户。
这恰好是我擅长的领域。于是我找到一家批发业务正在走向成熟、却苦于没能打通线上批发渠道的店铺，开始合作，启动了 neo-studio 项目。
下面我主要从产品的角度来介绍它。
S · Situation：一家百货店的上架难题
店里卖的东西很杂：锅碗瓢盆、袜子、雨伞、香水、文具……每批到货都有一堆新商品要上架，这里的“上架”也包括线上。
上架这件事本身很琐碎：
- 录入：一件件记货号、条码、品名（中文和西语各一份）、规格、装箱数。
- 拍图：在柜台上随手拍，背景是杂乱的桌面，光线也不稳定，拍出来的图没法直接给顾客看。
- 分发：同一个商品要在好几个地方各录一遍——微信上的友购商城、Facebook / Instagram 的商店、店铺自己的网站，还有店里的 ERP。
- 配货：员工有时对着配货单找不到货——单子上的实拍图很小，也没有库位信息。
每一步都不难，但加在一起，一批货要花掉好几个小时；数据散落在各处，拍完照还得对着数据再整理一遍，改一个价格就要改好几个地方。
T · Task：我给自己定的目标
我想要的不是一个”更好用的表格”，而是把整条链路打通：
- 录入要快：店员用自己的手机扫码、拍照就能录，几个人可以同时录，不需要专门的扫码枪。
- 图要美观：很多店铺既没有专业的拍摄设备，也没有专业的修图人员。于是我决定用 AI，把柜台上随手拍的照片变成专业的白底、多角度、带规格和条码的商品图。
- 一处录入，到处可用：数据只维护一份，一键同步到各个销售平台。
- 操作要简单：给店员简单培训一下，就能投入日常使用。
- 帮助配货：配货单上打印条码，员工遇到看不清的图，可以扫码查看商品信息、库位，并放大看细节；多人协作配货时，还能知道其他人已经找齐了什么。
还有两个现实约束：为了获得店主的信任，数据要留在本地；店里原来使用的 ERP 没有对外 API。
A · Action：我是怎么做的
先看整体架构。下面这张图是可以交互的——点击任意节点，下方会显示它负责什么、用了什么技术：
主工作台：产品网格、详情抽屉、AI 批量渲染与精调、排版模板编辑、订单与平台同步。任务队列和进度通过 WebSocket 实时推送。
点击节点查看细节 · 节点可以拖动
整个系统围绕三件事组织：录入、生产、分发。
录入：手机就是扫码枪
手机端是一个独立的 React 页面，店员在店里的局域网内通过 HTTPS 访问。
扫条码自动带出货号，拍照直接上传，中西文品名、规格、装箱数集中一次填完。几个人可以同时录入，录完的商品会实时出现在 PC 端。
生产：从随手拍到商业图
PC 端叫 Neo Studio，是主要的工作台。
所有商品以网格展示，每张卡片下方的三个小圆点分别代表 hero / side / detail 三个视角的渲染状态：
打开一个商品，可以看到原始实拍图、三个 AI 生成的视角，以及最终的合成图。
某个视角不满意，可以一键重生成，也可以用文字指令做精调：
这是一次真实的”重生成”操作录屏：先看一眼实拍图，再让视角 2 重新生成——十几秒就能拿到新图，合成图也会自动更新：
生成好的视角图，最后会按排版模板合成为成品图——模板定义了每个视角放在哪里、商品名和规格怎么排、条码和店铺 logo 的位置。
模板本身也是可视化编辑的：
不同品类可以用不同的模板，比如下面这个把主视角放大、细节图放在右侧：
生成这件事，本质上只有两种操作：Generate（全新生成，没有上下文）和 Refine（在上一次结果的基础上改）。
界面上的”重生成”和”精调”分别对应这两种。
精调的难点是”记住上一次”——如果只是把上一张图当普通参考图发过去，模型并不知道那是它自己刚画的。
Gemini 返回图片时会带一个 thought signature，代表这一轮的内部状态；把它和上一轮对话一起发回去，模型才真正知道”这是我上次画的，现在要在它的基础上改”，而不是重新瞎画一张。
不同品类需要不同的生成提示（雨伞要撑开还是收起、香水要不要带包装盒）。
这些提示词我不再是自己反复试错调出来的，而是让 AI 来调：把提示写进数据库、触发一次渲染、用 Gemini API 直接看生成的图、判断哪里不对、改写提示、再来一轮，收敛之后再存档到代码里。
相当于让 AI 当自己的裁判。我把这个流程称为 laag。
它的好处不是省时间，而是不容易像人工调参那样，调着调着就忘了之前踩过的坑。
而且同一品类的提示词，事实上沉淀成了重要的数据资产——如果将来产品化成 SaaS，这会是很重要的数据壁垒。
下面是另外两个品类的生成前后对比，左边是参考图管理里的实拍图，右边是自动合成的成品图（雨伞为撑开的主视角 + 收起的细节图，厨具则加上了手持使用的场景图）：
分发：一处录入，多平台同步
所有数据只存在一个地方——本地的 SQLite。
每个外部平台在后端有自己独立的一层对接：友购、Meta 商品目录、店铺网站的 CMS 各一个。
每一层负责把本地字段翻译成平台字段，并记录两边的数据有没有”漂移”。
三个平台的脾气完全不一样。友购没有开放 API，对接方式是直接读写它的数据库；商品编码来自店里的货号，但货号并不保证唯一，重复时会自动加上商品 ID 后缀（比如 r00008_61），不然两个商品会在友购那边互相覆盖。Meta 的商品目录接口返回成功，只代表它收到了请求——审核是异步的，会不会真的出现在 Facebook / Instagram 的商店里，要另外拉一次审核状态回写。店铺网站的登录态是一小时过期的 JWT，我选择在第 50 分钟就主动刷新，而不是等请求失败了再补救。
店里的 ERP 没有公开接口，所以按店里的要求，直接对接本机上的业务数据，同时保留了 Excel 手动导入作为兜底——集成出问题的时候，业务不会停。
产品的尺寸标注需求
这时就体现出数据集中录入的好处了：录入阶段员工已经把需要的数据都填好，不用再单独整理，标注时可以直接从界面上拉出已录入的尺寸，快速标到图上。
ps：回想起我的第一份工作是结构工程师，主要工作就是用 CAD、Creo 做标注、维护图纸，以及把 PLM 和 Excel 的数据同步。
现在我亲手构建了这样一套系统，不禁有点得意 (｡•̀ᴗ-)✧
配货：让员工不再对着小图找货
批发店的订单，往往是一长串”哪个货、多少箱”。以前的配货单只有一行行文字和很小的实拍图，员工经常对着单子找不到货。
现在，订单在系统里生成后，可以一键打印出带实拍图、中西文品名、货号、装箱数和条码的配货单：
打印出来就是员工手里的这张纸，左边是图，中间是品名，右边是条码和数量，最后一列留着打勾：
碰到图看不清的商品，员工掏出手机扫一下条码，就能看到商品信息、库位，并放大看细节。
多人一起配同一张单时，每个人在手机上点 OK 或 Falta（缺货），其他人的屏幕会同步更新，谁找到了什么、还缺什么，一目了然：
让它能在店里跑起来
最后用 Electron 把整个系统打包成一个 exe：双击就会启动本地后端，后端再托管 PC 端和手机端页面。
店里的电脑不需要装任何开发环境（打包过程中的坑，后面会单独写一篇）。
我还给它做了一个 MCP Server，把产品库暴露成 AI 可以调用的工具——查询商品、启动批量渲染、精调某个视角。
平时维护，很多事情可以直接用自然语言交给大模型去做，但受限于客户的付费能力，这部分我没有开放给客户，目前只有开发者自己能用。
R · Result：结果
最直观的是图片。左边是店员在柜台上随手拍的照片，右边是系统自动生成并合成的成品图——白底、多角度，带容量、货号、条码和店铺 logo：
- 系统已经在店里日常使用，帮助店铺迅速搭建了线上销售渠道，并同时管理线下仓库，补货。
- 一批货的上架时间，从几天缩短到几分钟。
- 数据只维护一份，同步到各个平台只需要点一下。
- 配货不再靠“看小图猜货”，扫码、多人同步，漏配、错配明显少了。
- 帮店铺沉淀了数据资产（产品数据库、各品类的生成模板），降低了之后做独立站、数据分析的开发成本。
- 我赚到了在智利生存下去的钱 (๑•̀ㅂ•́)و✧
还好当初留了后路：AI 模型“过期”了
店里有一天反馈说，AI 生成图片的功能突然用不了了——点重生成就一直失败。我打开项目排查，发现是两个问题叠在一起：
- 模型名称：项目里用的还是 Gemini 图片模型的预览版名称（
-preview结尾）。现在正式版已经发布，预览名称迟早会下线，所以统一换成了正式版名称，并把模型名收拢到一个地方维护。 - 额度：换上新的 key 之后，接口返回 429——AI Studio 的免费层对图片生成模型的额度是 0。最后把后端切到了 Vertex AI（用 API key 的简易模式，走 GCP 计费）。
切到 Vertex 还带出一个连锁问题：项目原本会把商品图上传到 Gemini 的 File API 做 47 小时缓存，而 Vertex 没有这个 API。
好在当初把缓存设计成了”可选的”——任何缓存失败都会自动退回到直接内联图片，所以只需要在 Vertex 下跳过缓存，渲染逻辑本身一行都不用改。
同理，如果有一天店里原来用的电商 ERP 出了问题，我可以走 Excel 兜底模式：让他们通过我的系统，导出符合 ERP 要求格式的 Excel 来同步数据，我只需要修改这一层兼容代码就可以了。
下一篇
这一篇主要从产品角度来写，没有展开技术细节。接下来几篇会聊技术：取舍、数据库、任务队列，以及 Electron 打包。