ImageGen Studio 重构记录：从出图页面到私有图像工坊

为什么要重构#

一个图像生成页面最开始很好写。前端收集 prompt，后端调用模型，结果返回给浏览器。可只要多用几次，就会遇到一些很实际的问题。

生成任务有时会比较慢，页面如果一直等同步响应，用户不知道到底是在处理、卡住还是失败。提示词优化如果和生成混在一起，流程会变得不清楚。参考图上传如果只是简单存文件，后续编辑和历史恢复会很难做。图片生成出来之后，如果没有历史记录，下次想接着改只能靠自己重新找文件。更麻烦的是，一旦要把这个工具放到公网入口后面，所有请求都不能再按“本地小工具”的标准处理。

这次重构就是围绕这些问题来的。前端要像一个真正工作台，能承载提示词、参数、参考图、任务状态和历史。后端要像一个可靠的服务，负责校验、调用模型、处理文件、保存记录和控制访问边界。部署层要足够简单，不能为了一个个人工具引入太重的架构。

我对这个工具的期待也变了。早期只要能生成一张图就行，后来更关心它能不能接住完整流程。比如写博客时要做封面图，通常不是一次就满意；做素材时可能要透明背景；做视觉草稿时希望保留几版方向；做复杂画面时又希望能分层继续修。单纯的出图页面很难覆盖这些场景。

所以这次重构更像是把零散能力整理成一条工作流。提示词、参考图、任务、历史、编辑、导出，每一步都不算新鲜，但连起来之后，工具的使用方式会发生变化。它不再只是“请求一次模型”，而是能围绕一个图像需求反复打磨。

技术栈的选择#

前端换成了 React、Vite 和 TypeScript。React 适合这种状态比较多的工作台页面，Vite 构建和开发都比较轻，TypeScript 则能让参数、任务状态和组件之间的约定更清楚。

后端使用 Express。它足够直接，路由、中间件、文件上传、静态资源和反向代理适配都很好处理。ImageGen 不是一个复杂到必须拆成多服务的系统，单体后端反而更容易维护。

数据层使用 SQLite。这个选择很适合当前规模：不需要额外维护数据库服务，备份也直接，放在服务器持久化目录里就能跑。它承担的是任务、历史、使用记录、导出记录和一些基础配置，不需要一开始就引入更重的数据库。

图片处理交给 Sharp。上传图需要检查和重新处理，输出格式也可能需要转换。Sharp 在 Node 生态里比较成熟，性能也够用。

部署仍然走 Docker 和 Nginx。Docker 负责把运行环境固定下来，Nginx 负责入口转发、静态资源和基础防护。这样 ImageGen 可以和博客在同一台服务器上共存，但不会把运行逻辑混到博客项目里。

这里没有追求很复杂的架构。ImageGen 现在的重点是稳定和可维护，而不是把每个能力都拆成单独服务。前端、后端、数据和文件处理都在一个清晰的应用边界里，部署起来更直接，出了问题也更容易定位。

如果后续使用强度真的变大，再把队列、存储或数据库拆出去也不晚。现在阶段先保持简单，反而更容易快速迭代。很多个人工具的问题不是架构不够宏大，而是维护成本一高就不想继续改了。

前端工作台的变化#

现在的前端不再只是一个大输入框加一个生成按钮。它更像一个围绕图像生成整理出来的工作区。

使用时，最核心的还是提示词。你可以直接写中文需求，也可以配合提示词优化，把自然描述整理成更适合图像模型理解的表达。这里的优化不是替你改主意，而是帮你补全画面语言，比如主体、场景、构图、光线、材质和风格倾向。

参数选择也比之前更清楚。尺寸、质量、背景、格式、数量这些选项都放在工作台里，用户不需要记模型参数，只需要根据用途选择。比如博客配图更关注观感和加载体积，透明素材更关注格式和背景，产品感图像更关注主体边缘和材质。

参考图上传是另一个很常用的入口。有些需求只靠文字很难描述，比如某个构图、角色姿态、颜色气质、已有素材的延续。把参考图作为输入后，编辑任务就能围绕已有图片继续做，而不是每次都从零开始。

历史记录也很重要。图像生成经常不是一次成功，很多时候是“这一张方向不错，再改一点”。如果没有历史，每次都要重新复制 prompt、重新选参数、重新找文件。现在历史记录可以把之前的结果、参数和提示词一起保留下来，后续继续调整会顺很多。

实际使用时，工作台更像一个草稿板。你可以先写一个比较粗的想法，让提示词优化补一下表达，再生成几张方向图。看到某张图的构图不错，就从历史里接着调；如果主体不错但背景不合适，就用编辑流程继续修；如果只是想要素材，就调整背景和格式，让结果更适合后续使用。

这种体验和普通聊天式生成不太一样。聊天式生成更自由，但素材管理会比较散。工作台把参数、历史和文件都放在同一个地方，反而更适合反复做图。尤其是为博客配图时，经常要考虑尺寸、主题、颜色和页面搭配，有一个固定的工作区会省很多事。

任务化处理#

图像生成和编辑都不是普通的快速接口。它可能需要几十秒，也可能因为上游繁忙而失败。如果前端一直卡在一次请求里，体验会很差。

所以现在改成任务化处理。用户提交请求后，后端先完成必要校验，然后创建任务，前端拿到任务状态后持续查看进度。任务完成时展示结果，失败时给出错误反馈。

这个设计的好处是，前端不会像死等一样卡住。用户能看到当前是在等待、处理中、完成还是失败。后端也能更好地管理同时进行的任务，避免一堆耗时请求直接压在同一个同步链路上。

提示词优化也走类似思路。它虽然通常比图片生成快，但本质上也是一次模型调用。把优化和生成都放进任务模型里，整个工作流会更统一。

任务化还有一个好处是失败更容易被处理。同步请求失败时，前端常常只能告诉你“失败了”。任务记录会保留更多上下文，后续可以区分是参数问题、上游问题、超时问题，还是文件处理问题。即使现在提示还可以继续优化，至少流程已经留出了位置。

对工具来说，知道失败也很重要。图像生成本来就不是每次都稳定，不能把失败当成异常之外的东西。任务模型让失败成为工作流的一部分，而不是把页面直接拖进不可用状态。

生成和编辑怎么配合#

ImageGen 现在主要围绕几类使用场景。

第一类是普通文生图。你写一段描述，选择尺寸和风格倾向，然后生成结果。这适合做博客封面、插图、视觉草稿、头像素材或一些氛围图。

第二类是参考图编辑。已有图片不满意，或者想沿着某个素材继续做变化，就可以把参考图传上来，再写修改说明。这个场景比纯文生图更接近真实使用，因为很多时候我们不是凭空要一张图，而是已经有一个方向，只想把它调整得更好。

第三类是历史图继续调整。之前生成过的图如果方向不错，可以从历史里找回来，继续作为编辑依据。这样不会浪费已经试出来的结果。

第四类是分层生成。复杂画面如果一次生成，后期很难改。把背景、主体、前景、效果这些层次分开，会更适合继续加工。这个思路也是 PSD 导出的基础。

这些能力放在一起之后，ImageGen 就不只是“输入一句话，拿一张图”，而是能围绕一张图持续做几轮处理。

我比较常用的方式是先用文字生成找方向，再用编辑流程收窄。纯文字生成适合探索，因为它自由度高；参考图编辑适合修正，因为它有明确起点。两者配合起来，比单独依赖其中一种更自然。

比如做一张文章封面，可以先生成几张不同气质的图，看哪种构图和色彩适合文章。选中方向后，再调整主体细节、留白位置或背景氛围。如果后续要放到页面里，还要考虑图片是否压得住文字、移动端裁切是否还能看、色彩会不会和站点主题冲突。生成工具如果不能支持这种来回调整，就很难真正进入日常使用。

还有一些更小的使用习惯，也会影响工作台该怎么设计。比如我经常会把一组方向图先留在历史里，不急着删，等文章排版或页面色调确定之后再回头挑；有些透明素材看预览时不错，放进真实页面后才发现边缘不够干净，这时就需要从原来的记录继续改，而不是重新描述一遍需求。工具如果只关心生成那一刻，就会忽略这些很琐碎但很真实的后续动作。

所以前端没有把所有能力都藏进一个巨大的表单里，而是尽量让常用步骤有明确位置。提示词区域负责表达想法，参数区负责控制输出倾向，参考图和历史负责承接上下文，结果区负责继续编辑和导出。这样看起来只是界面整理，实际是在减少重复劳动。每次做图时少找一次文件、少复制一次提示词、少猜一次参数，长期用下来差别会很明显。

PSD 导出为什么要做#

PSD 是这次重构里我比较在意的一块。很多网页生成工具只把最终图片展示出来，最多给一个下载按钮。这样当然也能用，但如果想继续修图，就会比较受限。

做设计或配图时，很多时候需要分层处理。背景可以单独调色，主体可以单独锐化，前景可以加遮罩，光效可以关掉重做。如果所有东西都压成一张图，后面再改就很麻烦。

ImageGen 的分层思路是：先把画面按背景、主体、前景、效果等方向拆开，每一层生成独立素材，再把这些素材导出成 PSD。导出的 PSD 可以继续交给 Photoshop 或其他支持 PSD 的工具处理。你可以调整图层顺序、开关可见性、继续加蒙版、改颜色、补细节。

实际用的时候，可以先在工作台里规划画面：背景是一间房间还是一片风景，主体是人物、物件还是某个视觉焦点，前景是否要加植物、光斑、窗框之类的遮挡，效果层是否要做雾、光、粒子或氛围。每层单独生成之后，导出 PSD，再到专业工具里做后续整理。

这个能力不是为了把 ImageGen 变成 Photoshop，而是为了让生成结果能进入后续设计流程。网页里预览只是第一步，真正要用到文章封面、项目展示或素材制作时，能不能继续细修很关键。

PSD 用法比较适合两类场景。一类是封面和宣传图，需要后期调整文字、留白、色调和局部细节。另一类是素材制作，需要把不同元素拆出来复用。生成模型一次给出的合成图可能很好看，但不一定方便修改；分层导出能让结果从“看起来不错”进一步变成“可以继续加工”。

当然，分层生成也不是万能的。它需要在一开始就想清楚画面结构，否则导出的图层可能只是形式上分开，实际后期仍然不好用。后续我还想继续优化这部分，让图层规划和导出结果更稳定，尽量减少手动整理成本。

文件处理和历史保存#

文件处理看起来是边角工作，但它决定了工具能不能长期用。

上传图不能简单信任浏览器传来的文件。服务端会对图片做检查和处理，确认它确实是可接受的图片，再保存成服务端可管理的素材。这样可以减少异常文件带来的麻烦，也能统一后续编辑流程。

生成结果也不是只存在浏览器里。后端会保存文件，并把结果和任务、提示词、参数、时间等信息关联起来。前端展示的是这些记录的结果，而不是一堆散落的临时文件。

历史记录的价值在于延续性。图像生成很依赖试错，如果每次刷新页面就丢掉上下文，这个工具就只能偶尔玩一下。保存历史之后，它更像一个工作台：之前做过什么、哪个方向不错、哪些参数还能复用，都能回头找。

导出文件也是同样的思路。PSD 不是生成完就随手扔出去，而是作为一次可追踪的导出结果保存。之后要重新下载或继续整理，都有依据。

这里还有一个取舍：文件管理不能太复杂，但也不能完全没有结构。太复杂会让维护成本变高，太随意又会让历史、编辑和导出都变得不可追踪。现在的做法是由后端统一管理文件和记录，前端只通过工作台查看和操作。这样使用时不需要关心文件到底怎么放，维护时又能找到对应关系。

安全边界只讲原则#

ImageGen 会调用模型接口，也会处理上传文件和生成结果，所以不能按普通静态页面来对待。这里不写具体规则，只说设计原则。

入口层会把普通页面、静态资源和动态请求分开处理，并加上必要的基础防护。应用层会保护登录态，写操作需要额外校验，上传内容会经过服务端检查。文件访问不会简单暴露目录，而是由后端确认访问者和文件之间的关系。关键操作也会留下记录，方便之后排查。

这些措施不是为了让使用变麻烦，而是为了让工具可以安心挂在服务器上。图像生成涉及成本和文件，如果边界不清楚，很容易从“自己用的小工具”变成一个难以控制的入口。

我更倾向于把安全当成工程卫生，而不是事后补丁。能少暴露一点就少暴露一点，能在服务端确认的就不要只靠前端，能记录的关键行为就记录下来。这样后续维护时心里会踏实很多。

部署和博客的关系#

ImageGen 和博客放在同一台服务器上，但它们不是一个系统。

博客更偏静态内容展示，核心是文章和页面。ImageGen 是动态工具，核心是任务、文件和模型调用。把它们拆开，能避免互相影响。博客构建失败不应该影响 ImageGen 的运行，ImageGen 的生成任务也不应该进入博客的构建链路。

部署上，ImageGen 仍然保持单体服务。前端构建成静态资源，后端提供页面和接口，运行数据挂到持久化目录，入口由 Nginx 转发。这个结构对个人服务器比较友好，排查问题也直接。

如果以后使用强度变大，队列、文件存储、数据库都可以再拆。但现在这个阶段，轻量单体更合适。能稳定跑，能方便备份，能快速更新，比一开始就拆得很复杂更重要。

后续还会继续维护#

这次重构只是把基础打得更完整，不代表已经结束。

后面我还想继续优化几个方向。提示词优化还可以更贴近不同用途，比如博客封面、产品图、透明素材、角色图这些场景的表达不一样。PSD 工作流也还有空间，比如图层命名、导出前预览、素材尺寸一致性，都可以继续磨。

历史管理也可以更好。生成次数多了之后，如何筛选、收藏、归类和复用结果，会变得越来越重要。现在的历史能解决“找回来”的问题，后面还可以继续解决“整理好”的问题。

失败提示也值得继续改。模型调用失败、上传不合适、任务超时、参数冲突，这些情况如果只是给一句笼统错误，用户很难知道该怎么调整。更清楚的提示会让工具更像日常能用的东西。

部署稳定性也会继续维护。服务更新、数据备份、运行日志、健康检查这些工作不显眼，但它们决定工具能不能长期放在那里不用天天盯着。

还会继续改#

ImageGen Studio 现在更像一个围绕自己需求长出来的工具。它的核心不是套一层模型 API，也不是做一个看起来很复杂的控制台，而是把图像生成这件事整理成可以反复使用的流程。

写提示词、传参考图、等待任务、继续编辑、保存历史、导出 PSD、再到设计工具里细修，这些步骤串起来之后，它才真正变成一个图像工坊。

它还会继续维护。后面可能还会改界面、改提示词流程、改 PSD 细节、改历史管理，也可能根据实际使用慢慢删掉一些不顺手的设计。工具这种东西，最重要的不是一次做得多完整，而是用起来之后还愿意继续改。只要它能稳定地帮我做图，能接进博客和日常素材制作里，这次重构就算有意义。