SILLITER.WANG
博客
返回博客

构建实录 / 2026-06-17

电商助手：从"生成一张图"到多租户桌面工作台的产品化

#桌面应用#Electron#Python#产品化

Kosen 电商助手商品主图生成样例

Kosen 电商助手是一个跑在本地的 Temu 上货工作台：AI 选品、Google 趋势洞察、AI 出图（主图/场景图/标题）、PSD 套版、图库比对、Temu 提报包生成，全流程收口。后端约 14000 行 Python，前端 28 个 React 组件，Electron 打包成桌面应用。

这篇不讲它多好用，讲一个"生成图片"的 AI 原型，怎么一步步被推成一个有多租户、有安全边界、有启动自检的 V1 产品——以及产品化真正难的地方在哪。

一、产品图不是"生成一张图"

刚上手时容易把电商 AI 工具想成一句话：输入 prompt，出一张商品图。深入之后会发现，生成图片是整条链路里价值最低的一环。

真实的上货流程是这样的：运营手里有一堆产品数据、SKU、店铺、账号，要给它们生成主图、场景图，套 PSD 模板，查图库去重，按规则命名导出，最后打成 Temu 提报包。任何一环出错——文件名错了、图串了、导出文件夹乱成一团——都是人工返工。

助手要啃的是这条链路的后半段：把产品图生产从"一堆散落文件 + 手工整理"，变成一个能管理、能批量、能追溯的本地工作台。它的端到端业务流有十步：

①登录 → ②Dashboard 刷 Google Trends 生成趋势信号+产品假设
→ ③采纳趋势为选品候选 → ④候选转正式产品 → ⑤维护产品类型/属性/原图
→ ⑥维护标题/主图/场景 prompt → ⑦模型队列生成 → ⑧查看资源+打包
→ ⑨Temu 上架页补申报信息生成提报包（Excel+图片+体检）→ ⑩人工导入供应商后台

生成图片只是第 ⑦ 步。

二、为什么是桌面应用

这个项目的环境依赖对纯 Web 太重了：本地图片和工作区文件、Photoshop 的 COM 接口、SQLite、Python 图像处理、Windows 上的批量输出目录。

硬塞进云端 SaaS，过不了"让浏览器碰用户本地 Photoshop 和文件"这一关。所以它是 React + TS + Vite + Zustand（前端）+ Python（后端）+ Electron（外壳） 的本地桌面应用：前端做 UI，Python 在本机跑服务，Electron 当壳。用户在自己电脑上处理素材，不用一开始就设计云端同步和权限系统，部署门槛也低——装上就能用。

三、后端：标准库 http.server，没有 Web 框架

后端一个刻意的选择：不用任何 Web 框架，直接 Python 标准库的 http.server。

from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
class StudioHandler(BaseHTTPRequestHandler):
    def owner_scope(self): ...   # 每个请求先解析多租户作用域

一个 StudioHandler 手写路由，业务逻辑按服务模块拆在 services/ 下（selection、trends、generation、scene_images、temu_listing、accounts、shops、auth……）。数据层是 SQLite 开 WAL + 一个 workspace 文件区（assets/generated/scenes/exports）。选 stdlib 的理由和电商助手整体气质一致：一个桌面应用要装到非技术用户的机器上，依赖越少启动越稳，14000 行业务逻辑不需要 Flask/FastAPI 来托管一个本地端口。

四、多租户：owner_scope 的 (viewer, me) 设计

最容易被低估的一层是多租户。这本是个本地工具，但只要有第二个用户（一个 admin + 若干 seller），数据隔离就是地基。

隔离机制分两半。数据层：20 张业务表统一加 owner 列（OWNED_TABLES——accounts、shops、products、assets、tasks、temu_submissions……全在内）。请求层：每个请求先算一个作用域，owner_scope() 返回一个精心设计的二元组：

def owner_scope(self) -> tuple[str | None, str | None]:
    """返回 (viewer, me)。
    viewer 用于读/改/删过滤——admin 为 None（看全部），seller 为自己用户名；
    me 用于 create 归属——总是当前用户名。"""
    user = self.current_user()
    me = user.get("username")
    viewer = None if user.get("is_admin") else me
    return viewer, me

这个二元组把"看谁的数据"和"新建归属谁"分开了：viewer 做查询/修改/删除的过滤条件（admin 是 None 所以看全部，seller 是自己所以只看自己），me 做创建时的归属（永远是当前用户）。服务层统一带 owner 参数，越权改删在过滤条件层就被挡住，不靠散落在各处的 if 判断。

安全收口还有几处，都是"图省事就会漏"的地方：

  • /api/media、/api/download 按 owner 校验，防止猜路径越权读他人素材/提报包
  • 批处理、图库比对、导出不接受任意本机路径，固定写 workspace 的 owner 子目录
  • 密钥用 Fernet 加密落盘、PBKDF2 存密码、登录失败锁定
  • Temu 桌面端只回传 cookie 数量/域名摘要，不把 cookie/token/密码原文传给前端或后端

这些东西在 demo 里看不出来，但它们决定这个工具能不能从"自己玩"走到"给别人用"。有第二个用户的那一刻，这些边界就是底线。

五、任务层：单 worker 串行队列 + 启动恢复 + 精准重试

AI 出图、批处理是耗时任务，不能堵住 HTTP 请求。任务层是单 worker 串行队列（tasks / model_queue）——刻意不做并发，因为本地机器 + 单张显卡/单个网关额度，并发只会互相拖累，串行反而稳。

两个可靠性设计：启动恢复——服务重启时 restore_queued_tasks 把中断的排队任务捞回来接着跑，cleanup_stale_tasks 清理僵死任务，进程崩了不丢活。精准重试——失败任务能单独 retry_task，不用整批重来。对本地工具，"关了再开能续上"比"永不宕机"实在得多。

六、启动自检：把"打不开"变成可定位状态

桌面应用最高频的问题从来不是某个功能写不出来，是用户环境千奇百怪：Python 没装或 PATH 不对、Pillow 缺失、SQLite 文件不可写、Photoshop 不可用、端口被别的程序占了、Electron 壳起不来。用户只会说"打不开"，你面对一个黑盒。

所以加了启动自检，开机时跑一遍并落 startup_check.json，设置页可见。检查项覆盖了最常见的八个失败点：

_check_python()          # 版本/可执行
_check_workspace_write()  # 工作区可写
_check_database()         # SQLite 可连可写
_check_frontend_build()   # 前端产物存在
_check_login_password()   # 登录口令配置
_check_port()             # 端口可用
_check_pillow()           # 图像库可用
_check_photoshop()        # PS COM 接口

这一步把"打不开"这种黑盒报告，变成"Photoshop COM 检查失败"这样能定位的状态。对一个面向非技术用户的本地工具，这比多一个生成功能有用得多——错误信息还统一过 sanitize_public_error 脱敏，不把内部路径抖给用户。

七、V1 是靠"不做什么"定义的

AI 原型有个通病：无限膨胀。今天想加趋势选品，明天想做完整 PSD 编辑器，后天想接 Temu 官方 API 自动上传。想法够多，永远发不了版。

这个项目还刻意画了一条"不做清单"当定位铁律——对标同类运营工具「淘金」，明确不做这些：

  1. 不做 IP 隔离 / 指纹浏览器——不提供多店铺防关联能力
  2. 不做自动登录 / 批量 RPA——封号风险高、平台风控，桌面端 Temu 能力只在用户手动登录并确认后执行采集/录制/直连提交
  3. 不做店铺批量运营自动化——核价/合规/库存的"操作执行"是别人的领域
  4. 核价不替代——全托管商品由 Temu 买手核价，Kosen 只产出物料 + 提报包

差异化护城河反而在淘金这类工具都不具备的地方：AI 选品 + 趋势洞察 + AI 出图——"内容从无到有的生产"，而不是"店铺操作的自动化"。定位清楚了，工作量才收得住。

技术决策与取舍

决策取舍
桌面应用（Electron + Python）能碰本地 PS/文件/SQLite；代价是分发和环境适配
后端用 stdlib http.server零 Web 框架依赖、启动稳；代价是路由手写
SQLite WAL 单机一个文件搞定；写并发是上限
单 worker 串行队列本地资源下更稳；不追并发吞吐
owner 全表隔离多用户地基；每张表每个查询都要带 owner
刻意不做 RPA/指纹避开封号与风控；放弃"店铺自动化"市场

现在的状态与路线图

助手在 V1 产品化阶段，核心链路全部跑通：本地 React+Electron+Python 架构、产品/店铺/账号/类目模板管理、AI 选品与 Google 趋势 Dashboard、AI 主图/场景图、图库比对、PSD 上传与单图预览、POD 批处理与失败追踪、Temu 提报包生成、飞书每日趋势推送、外部验收红绿灯台账、多租户隔离与启动自检。部署在国内服务器（systemd 服务，kosen.silliter.com 经 Cloudflare 入口），桌面端 Electron + NSIS 安装包。

路线图缺口也清楚：提报体检目前是简化规则、待接真实合规；海外采集器待建（解决国内访问 Google Trends 的问题）；卖家精灵 MCP 待接；Temu 直连提交仍需用户手动登录态下录制接口合约。

这版最大的收获是一句朴素的话：AI 原型不是产品。 一个能生成图片的 demo 一下午能搭起来，但真正的产品化几乎全发生在边界、失败处理、权限、日志和自检这些不上镜的地方——多租户的 (viewer, me)、串行队列的启动恢复、八项自检的 startup_check.json，没有一个能在演示里被看见，但它们才是"作品"和"产品"的分界线。