# 从一个生图页到可运营平台：Imagen Studio 的开发记录
## 前言
这段时间，我把 `Imagen Studio` 从一个偏演示性质的 AI 生图页面，逐步打磨成了一个可以真实上线、可以持续运营、也可以继续扩展的轻量内容创作平台。
它现在不只是“调用一下模型生成图片”，而是已经具备了完整的业务闭环：
- 用户注册、登录、邮箱验证
- 图片生成、视频生成、参考图生成
- 提示词广场
- 积分体系与充值流程
- 管理后台
- 渠道切换与价格配置
- 本地化数据落盘
- SQLite 持久化
- PM2 + Nginx 线上部署
线上地址：
- `https://img2.gosql.cn`
这篇文章主要记录两个部分：
1. 这个平台是什么、解决什么问题
2. 我是怎么一步步把它做出来并推到线上运行的
## 一、平台定位：一个面向真实使用的 AI 创作平台
`Imagen Studio` 的目标不是做成一个“只有输入框和生成按钮”的工具页，而是做成一个真正能让普通用户使用、让管理员运营、让平台长期维护的内容创作平台。
当前平台主要提供三类能力：
- AI 图片生成
- AI 视频生成
- 提示词资产沉淀与复用
对普通用户来说，核心体验是：
- 输入提示词
- 选择模型、比例、质量
- 上传参考图
- 快速生成图片或视频
- 查看最近生成与历史记录
- 通过充值获得积分继续创作
对管理员来说，核心能力是：
- 查看平台概览
- 管理用户
- 调整积分
- 管理充值记录
- 切换上游渠道
- 配置价格倍率
这意味着它从一开始就不是单页工具，而是一个轻量 SaaS 雏形。
## 二、为什么要自己做这样一个平台
很多第三方 AI 平台的问题其实很一致：
- 入口很多，但流程混乱
- 能生成，但参数不清楚
- 模型切换成本高
- 充值和计费逻辑不透明
- 提示词没有沉淀机制
- 出了问题很难定位是前端、后端、数据库还是上游渠道的问题
我做这个平台时，最核心的思路只有一句话：
**把“创作能力”“运营能力”“排障能力”放到同一个系统里。**
所以它不是只追求“能生成”，而是同时追求：
- 用户能用
- 管理员能管
- 系统能查
- 问题能修
## 三、技术选型：为什么是 Next.js + SQLite
平台当前技术栈并不复杂，但很务实。
### 1. 前后端一体化
我使用的是：
- `Next.js 16`
- `App Router`
- `TypeScript`
- `shadcn/ui + Tailwind CSS`
这样做的好处很直接：
- 页面、接口、权限控制都在一个项目里
- 开发和部署路径统一
- 后续新增业务页很快
### 2. 数据持久化选择 SQLite
我最后没有继续依赖云数据库，而是把核心数据迁回了本地 `SQLite`。
原因很现实：
- 部署简单
- 数据结构清晰
- 本地和线上行为一致
- 备份恢复成本低
- 对当前平台体量完全够用
当前主要数据落在：
- `data/app.db`
生成结果、调试日志、上游返回内容等落在：
- `outputs/`
这套结构让系统的“可恢复性”和“可排障性”明显更强。
## 四、功能演进：平台是怎么一步步长出来的
### 1. 先完成基本创作链路
最开始的平台核心只是生成能力：
- 文生图
- 图生图
- 多参考图支持
- 视频生成
在这个阶段，重点不是 UI，而是先把调用链路跑通：
- 前端参数选择
- 后端调用上游
- 轮询任务状态
- 落库生成记录
- 返回结果给用户
### 2. 再补用户系统和积分体系
只有生成接口，其实不能叫平台。
所以第二步我补了完整的用户体系：
- 注册
- 登录
- 邮箱验证
- 会话持久化
- 角色区分
然后把“积分”放进来，让生成行为真正和业务挂钩：
- 生成前校验积分
- 生成成功扣积分
- 生成失败返还积分
- 管理员可手动调额
这样系统才从“技术演示”进入“可运营状态”。
### 3. 再补提示词广场
很多用户实际缺的不是模型，而是提示词。
所以我给平台加了“提示词广场”，并且批量整理导入了大量优质案例，变成数据库驱动的内容模块，而不是写死在前端页面里。
这样做有两个好处：
- 用户可以直接浏览和复用案例
- 平台首页和推广内容也有了持续的素材来源
### 4. 再补后台管理
当用户、充值、生成记录、上游渠道都进入系统以后，后台就不是可选项，而是必需品。
后台最终包含了：
- 管理概览
- 用户管理
- 用户详情
- 渠道管理
- 充值记录处理
尤其是渠道管理页，后续变成了平台运维的关键入口。
## 五、最重要的一步：把“能生成”改成“能稳定保存”
这是这次开发里一个非常关键的调整。
一开始，平台的“最近生成”里保存的是上游渠道返回的远程 URL。这样虽然能显示，但有个致命问题：
- 上游链接会过期
- 对方会清理资源
- 历史记录会失效
- 用户回头看时图片已经没了
这对平台来说是不合格的，因为“最近生成”本质上应该是平台自己的资产，而不是上游临时链接的转发。
所以我后来把这条链路改成了：
1. 上游生成完成
2. 服务端立即把图片或视频下载到本地 `outputs/`
3. 平台生成自己的访问地址
4. 数据库里保存本地 URL，而不是远程 URL
5. 前端最近生成、历史记录、预览下载全部走站内地址
这个改动看起来不大，但它直接决定了平台是否真正“拥有”自己的生成结果。
这也是从“工具页”走向“产品”的分水岭。
## 六、渠道接入与切换：为什么要做成可配置
这个平台不是只接一个上游接口，而是逐步接入和兼容了多个能力源：
- `Pic2API`
- `GRSAI`
并且根据实际能力做了策略划分：
- 某些模型走 `GRSAI`
- 某些能力继续走 `Pic2API`
- 后台可切换默认生图渠道
这一步很重要，因为真实业务里，上游接口不会一直稳定：
- 价格会变
- 可用性会变
- 模型支持会变
- 返回格式会变
如果把渠道写死在代码里，后面维护成本会非常高。
所以我最终做法是：
- 渠道参数配置化
- 管理后台可切换
- 上游日志本地保存
- 失败信息尽量完整记录
这样出了问题，不需要每次都从前端开始猜。
## 七、充值体系：先让流程跑通，再逐步升级
支付系统一开始并没有直接一步到位。
真实开发里，这块经历了几个阶段：
### 阶段一：接入自动支付思路
一开始尝试接标准支付网关，把充值做成自动回调入账。
### 阶段二：发现通道不稳定，改成手动过渡方案
当时支付通道不够稳定，所以先切到了微信收款码 + 管理员后台手动加积分的方案。
这个方案看起来“土”，但它有两个优点：
- 业务可以先跑
- 不阻塞平台整体上线
### 阶段三：保留原支付代码，后续可随时切回
我没有把之前的支付代码删掉，而是把手动充值作为当前稳定方案，把自动支付作为后续可恢复能力保留。
这也是我这次开发中比较明确的一个原则：
**先保证业务闭环，再优化流程自动化。**
## 八、UI 设计：不是炫技，而是要降低理解成本
这个项目在视觉上经历了几次比较明确的迭代。
首页最终选择的是：
- 左右双栏
- 左侧信息和入口
- 右侧品牌视觉展示
- 轻量 3D 透视效果
而登录后页面则刻意收敛：
- 更工具化
- 更少装饰
- 参数和结果优先
- 卡片化布局
原因很简单：
- 首页负责建立品牌感
- 创作页负责提升操作效率
- 后台负责清晰管理
不同页面承担不同目标，不应该用同一种视觉密度强行统一。
## 九、运维和部署：这部分比写页面更重要
平台真正上线以后，我花了不少精力放在部署安全上，而不是继续堆功能。
原因也很简单：
如果一个平台上线一次就把线上 `SQLite` 覆盖掉，那前面所有开发都是白做。
所以部署环节我专门做了这些保护：
- 不同步线上 `data/`
- 不同步线上 `outputs/`
- 不覆盖线上 `.env.local`
- 部署前自动备份 `data/app.db`
- PM2 reload 重启
- 本机健康检查
现在线上部署已经形成了比较稳定的流程：
1. `rsync` 同步代码
2. 排除持久化目录
3. 远端执行部署脚本
4. 自动备份数据库
5. `next build`
6. PM2 reload
7. 健康检查确认
这一步虽然不显眼，但它决定了平台能不能持续迭代。
## 十、内容增长：平台不只是技术产品，也要能推广
做完平台本身之后，另一个现实问题是：
**有了产品，不代表就会有用户。**
所以我后面又开始补“内容推广”这条线，包括：
- 整理提示词案例
- 做网站推广海报
- 生成二维码入口图
- 自动化生成小红书素材
- 研究图文推广链路
这个过程反过来也促进了产品优化，因为在做推广时会不断暴露新的问题，比如：
- 图片链路不能依赖远程地址
- 提示词案例必须可沉淀
- 平台入口不能只靠文本链接
- 首页需要更有吸引力的示例图
也就是说，推广不是平台开发结束之后的事，而是反向推动产品成熟的一部分。
## 十一、当前平台已经具备什么能力
到现在为止，`Imagen Studio` 已经具备了这些比较完整的能力：
- 本地 SQLite 持久化
- 图片与视频生成
- 本地保存生成结果
- 稳定的最近生成和历史记录
- 积分计费体系
- 后台运营能力
- 上游渠道切换
- 提示词广场
- 线上部署与数据库备份机制
如果只看功能数量，这个平台并不算“小”。
但我觉得更重要的是，它已经形成了一个比较健康的系统结构：
- 数据、文件、页面、运营、部署不是分裂的
- 各模块之间能形成闭环
- 出问题时有日志、有备份、有恢复路径
## 十二、接下来还会继续做什么
虽然平台已经能跑，但后续还有几件事值得继续推进：
### 1. 更完整的支付闭环
- 恢复和稳定自动支付
- 订单状态更细化
- 退款和异常处理更规范
### 2. 更细的媒体资产管理
- 生成结果分类
- 批量删除
- 生命周期管理
- 存储空间占用统计
### 3. 更强的内容增长能力
- 提示词专题页
- 首页案例轮播优化
- 推广素材自动化
- 社媒内容批量生成
### 4. 更稳的运维能力
- 定时清理无用文件
- 日志分级管理
- 备份保留策略优化
- 更多线上自检接口
## 结语
回头看这个项目，最明显的感受不是“功能越做越多”，而是系统越来越像一个真正的平台。
从最开始只关注“能不能生成”，到后来关注：
- 数据怎么存
- 文件怎么保
- 用户怎么用
- 管理员怎么管
- 上线怎么不出事
- 内容怎么推广
这些事情拼在一起，平台才真正成形。
`Imagen Studio` 现在还不是一个大而全的商业系统，但它已经从“一个功能页”跨进了“一个可运营产品”的阶段。
对我来说，这比单纯多接几个模型接口更有价值。
如果后面继续迭代，我也会优先坚持现在这条路线：
**功能要能用，数据要能保，系统要能运维，产品要能增长。**
