这是我们交付的第一个完整平台。它的结果比预期好——客户没有把它当内部工具，而是直接拿去做成了对外业务。
下面把过程记下来，重点是那个架构决定，以及它带来的差别。
客户要的不是「生成」，是「项目」
最初的沟通里，客户说的是「想要一个能出图的 AI 工具」。
但聊下去会发现，真实需求不在生成那一步。他们做的是视觉内容项目，一条内容从开始到交付，要经过很多次生成、比较、返工和确认。工具解决的是「一次生成」，而项目需要解决的是另外几件事：
- 素材要能存住、能被找到，而不是生成完就散在一堆对话框里
- 同一个创意要能出多个版本，并且能来回比较
- 上下文要能保留——为什么要这么改、参考的是哪张图
- 图像和视频要能接上，而不是各做各的
- 每一笔资源消耗花在哪，要说得清
把这几件事收进同一个空间，才叫生产线。这是整个项目真正的需求。
唯一关键的架构决定
技术上最重要的一个决定，是把「核心」和「发行版」分开。
具体做法是：同一套核心代码，通过编译期发行版机制支持多个品牌独立发布。每个发行版有自己的品牌、数据、对象存储和部署实例，彼此完全隔离。这个边界是在构建阶段确定的，不是靠运行时开关去隐藏。
为什么不用运行时开关？因为开关本质上是一份代码里塞了很多条件分支——它会把「客户版」和「自营版」的能力差异变成运行期的 if-else，时间一长，两边互相污染，谁也说不清某个功能到底属于谁。
编译期隔离带来的直接好处是：
- 能力边界在构建产物里就固定了，不会被误开
- 差异化功能不会泄漏到不该有的版本里
- 第二套发行版的交付成本大幅下降——核心是现成的，只需要做适配和品牌替换
这个决定在交付阶段没有体现出多少价值，但在第二个发行版上线的时候，差别就明显了：它让「第一个客户花两个月」和「第二个客户要多久」不再是同一个数量级的问题。
交付了什么
两个月完成，范围覆盖整个系统的运行：
创作端
- 无限画布：节点编排、语义连线、分组、版本快照与恢复
- 九种语义参考角色：创作指令、普通参考、首帧、尾帧、蒙版、主体、背景、深度、序列
- 图像与视频生成：多模型接入、画幅与分辨率配置、批量生成、任务队列
平台端
- 素材中心：上传与生成结果统一入库、检索、标签、回收站
- 团队协作：成员角色、容量与积分预算
- 积分与计费：预占、结算、退款、双边账本
- 后台治理：用户、空间、模型线路、审计、运营
上线之后
系统交付后由客户自主运营，他们已经把它开放给外部用户使用。
截至 2026 年 10 月初，服务器访问日志的实测数据是：
| 指标 | 数值 |
|---|---|
| 统计区间 | 2026-09-19 至 2026-10-02（13.5 天） |
| 累计请求 | 132 万次 |
| 活跃工作空间 | 163 个 |
| 独立访问来源 | 472 个 |
| 日均独立访问 | 80–120 个 |
（独立 IP 不等于独立用户——存在多人共用出口 IP、以及单人使用多设备的情况，所以这里说「访问来源」。）
这个体量不算大，但它的意义在于：有人在上面真的干活，不是点进来看一眼就走。 请求量超过 5000 次的那批来源，是长时间在线做实际生产的用户。
复盘
回头看，做对的主要是三件事。
一、先定义问题，再定义功能。
如果一开始就按「做个出图工具」去理解需求，交付物会是一个生成器。真正的判断是：客户缺的不是生成能力，是把生成能力组织成生产流程的那一层。功能清单是后面推导出来的结果，不是起点。
二、把架构边界放在构建期，而不是运行期。
运行时开关写起来快，但它把复杂度推到了未来。编译期隔离下手更重，换来的是一条不会随时间腐烂的边界。
三、交付之后还看得见。
系统上线不是终点。日志、健康检查、备份与回滚这些「不显眼」的部分，决定了交付物能不能真的被客户拿去做生意。这次能拿到实测数据，也是因为这些东西从一开始就在。
如果你也在做类似的事——不管是想找人交付，还是想评估一个方案的可行性——可以直接联系我们聊聊。