1. 从标题拆解这个项目到底在做什么1.1 核心需求解析“GPT Image 2.5 API 调用教程Node.js 实现图片生成与编辑”这个标题本质上描述的是一个后端服务集成场景用 Node.js 作为服务端语言调用 OpenAI 提供的图片生成与编辑接口把“文字描述变图片”和“已有图片按指令修改”这两个能力嵌入到自己的应用里。它解决的核心问题是很多开发者想在产品里加一个“AI 画图”或“AI 改图”的功能但不想从零训练模型也不想依赖某个网页端手动操作而是希望通过代码自动化完成。比如电商后台批量生成商品场景图、内容平台给文章自动配图、设计工具里加一个“一键换风格”按钮这些都属于这个项目的典型应用场景。适合谁来参考有基础 JavaScript/Node.js 经验的后端或全栈开发者对 REST API 调用不陌生想快速把图片生成能力接入自己项目的人。如果你完全没写过 Node.js建议先补一下npm、async/await、fetch这些基础否则后面看代码会有点吃力。1.2 为什么选 Node.js 而不是 PythonOpenAI 官方文档里 Python 示例最多但实际项目里 Node.js 的出场率非常高原因很实际前后端同构如果你的前端是 React/Vue后端用 Node.js整个项目一套语言维护成本低。异步 IO 天然适配图片生成是典型的“发请求-等结果”模式Node.js 的事件循环处理这种 IO 密集型任务很顺手。部署轻量一个 Express 或 Fastify 服务配合dotenv管理密钥几十行代码就能跑起来不需要额外装一堆科学计算库。我自己的经验是如果只是做 API 编排和业务逻辑Node.js 比 Python 更省心尤其是你要把生成结果直接存到对象存储或者推给前端的时候。1.3 图片生成与编辑的能力边界这里要区分两个动作生成generation给一段文字描述返回一张全新图片。编辑edit给一张已有图片加一段指令返回修改后的图片比如“把背景换成纯白”“给人物加一顶帽子”。编辑功能通常需要上传原图或提供图片引用接口会返回新的图片数据。实际使用中编辑对原图格式、尺寸、透明通道都有要求后面会详细讲。注意不同版本的图片接口在参数命名和返回结构上可能有差异写代码前务必以你账号后台看到的接口文档为准不要照搬网上过时的示例。2. 环境准备与依赖安装2.1 Node.js 版本选择与安装图片接口的 SDK 和fetch能力对 Node.js 版本有要求。实测下来Node.js 18 LTS 及以上都能正常工作推荐直接用 20 LTS长期支持、生态兼容性好。安装方式按系统分Windows去 Node.js 官网下载 LTS 安装包一路下一步即可。装完在终端执行node -v和npm -v确认。macOS推荐用nvm管理版本nvm install 20然后nvm use 20。Ubuntu/Debian不要直接用apt install nodejs版本往往太旧。用 NodeSource 的源或者nvm安装 20 版本。# 用 nvm 安装 Node.js 20 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 node -v提示如果你在 Ubuntu 上遇到权限报错不要用sudo npm install -g容易把全局目录搞乱。正确做法是配置 npm 的全局目录到用户目录下或者直接用 nvm 管理。2.2 初始化项目与安装依赖新建一个目录初始化package.json然后装几个核心依赖mkdir gpt-image-demo cd gpt-image-demo npm init -y npm install openai dotenv express multer各依赖的作用依赖用途openai官方 SDK封装了鉴权和请求dotenv从.env读取密钥避免硬编码express起一个 HTTP 服务方便前端调用multer处理图片上传编辑功能需要如果你不想用 SDK也可以直接用 Node.js 内置的fetch发请求但 SDK 帮你处理了重试、超时和错误结构省事。2.3 密钥管理与安全配置在项目根目录建一个.env文件OPENAI_API_KEY你的密钥然后立刻把.env加进.gitignore。我见过太多人把密钥直接写进代码然后推到公开仓库结果被人扫到盗刷。密钥泄露的后果是实打实的账单不是开玩笑。echo .env .gitignore echo node_modules .gitignore注意密钥只放在服务端绝对不要塞进前端代码或浏览器请求里。前端要调就让前端调你自己的后端由后端去调图片接口。3. 核心实现图片生成3.1 最小可运行示例先写一个最简单的生成脚本generate.jsimport dotenv/config; import OpenAI from openai; import fs from fs; const client new OpenAI({ apiKey: process.env.OPENAI_API_KEY, }); async function generateImage(prompt) { const result await client.images.generate({ model: gpt-image-1, prompt: prompt, size: 1024x1024, n: 1, }); const imageData result.data[0].b64_json; fs.writeFileSync(output.png, Buffer.from(imageData, base64)); console.log(图片已保存为 output.png); } generateImage(一只戴着宇航头盔的柴犬扁平插画风格纯色背景);这段代码做了三件事初始化客户端、发请求、把返回的 base64 数据写成文件。跑之前确认package.json里加了type: module否则import语法会报错。3.2 关键参数逐个说清楚生成接口的参数不多但每个都影响结果和成本model指定使用的图片模型。不同模型在质量、速度、价格上差异明显选之前先看官方定价页。prompt文字描述是决定图片内容的核心。写得越具体结果越可控。size输出尺寸常见有1024x1024、1024x1536、1536x1024等。尺寸越大耗时和费用越高。n一次生成几张。批量生成时注意成本会线性增长。quality部分模型支持质量档位低质量快而便宜高质量慢而贵。关于 prompt 的写法我的经验是遵循“主体 动作 环境 风格 构图”的结构。比如“一只橘猫主体趴在窗台上动作环境水彩画风格风格特写构图构图”比只写“一只猫”效果好得多。3.3 返回数据的处理方式接口返回的图片数据有两种常见形式b64_jsonbase64 编码的图片字符串直接解码写文件即可。url一个临时链接需要再发一次请求下载。base64 的好处是不依赖外部链接适合直接存数据库或转存对象存储缺点是字符串很长内存占用大。如果一次生成多张高分辨率图注意 Node.js 的内存限制必要时分批处理。// 处理多张返回 for (let i 0; i result.data.length; i) { const buf Buffer.from(result.data[i].b64_json, base64); fs.writeFileSync(output-${i}.png, buf); }提示base64 字符串转 Buffer 时一定要指定base64编码否则写出来的文件是坏的打开会提示格式错误。这个坑我踩过不止一次。4. 核心实现图片编辑4.1 编辑接口的输入要求编辑和生成最大的区别是编辑需要一张原图。原图通常通过 multipart 表单上传接口对格式有要求支持 PNG、JPG、WebP 等常见格式。如果原图带透明通道比如 PNG 的 alpha编辑时可能被要求保留或去除看具体接口说明。文件大小一般有上限超过要先压缩。用multer接收上传文件再转交给编辑接口import multer from multer; const upload multer({ storage: multer.memoryStorage() }); app.post(/edit, upload.single(image), async (req, res) { const result await client.images.edit({ model: gpt-image-1, image: req.file.buffer, prompt: req.body.prompt, size: 1024x1024, }); const buf Buffer.from(result.data[0].b64_json, base64); res.set(Content-Type, image/png); res.send(buf); });这里用memoryStorage把文件放在内存里避免落盘产生临时文件。小图没问题大图要注意内存占用。4.2 编辑指令的写法技巧编辑的 prompt 和生成的 prompt 逻辑不同。生成是从零描述编辑是描述变化。好的编辑指令应该明确“改什么、改成什么、保留什么”。比如原图是一个人站在灰色背景前差的指令“改一下背景”——太模糊模型不知道改成什么。好的指令“把背景换成纯白色保留人物和服装不变保持原有光影方向”。再比如给产品图去瑕疵“去除图片左下角的文字水印用周围背景纹理填充不要改变产品本身”。注意编辑不是万能的。如果指令涉及大幅改变构图或添加原图中不存在的复杂元素结果可能不理想。这时候更稳妥的做法是重新生成而不是硬编辑。4.3 生成与编辑的组合流程实际项目里生成和编辑经常串起来用。一个典型流程用生成接口产出一张基础图。把基础图作为输入用编辑接口做局部调整换色、加元素、去瑕疵。再编辑一次做最终微调。这种“生成-编辑-再编辑”的链路比一次性写超长 prompt 更容易控制结果。每一步只改一个变量出问题也容易定位是哪一步的指令不对。async function generateThenEdit(basePrompt, editPrompt) { const gen await client.images.generate({ model: gpt-image-1, prompt: basePrompt, size: 1024x1024, }); const baseBuf Buffer.from(gen.data[0].b64_json, base64); const edited await client.images.edit({ model: gpt-image-1, image: baseBuf, prompt: editPrompt, size: 1024x1024, }); return Buffer.from(edited.data[0].b64_json, base64); }5. 常见问题与排查技巧实录5.1 高频报错速查表现象可能原因排查方向401 未授权密钥错误或未加载检查.env是否被读取密钥有无多余空格429 请求过多触发频率限制加退避重试降低并发400 参数错误size/prompt 不合法对照文档核对参数取值范围返回图片打不开base64 解码错误确认 Buffer 编码参数为base64编辑报格式错原图格式不支持转成 PNG 再试请求超时图片尺寸过大降尺寸或加长超时时间5.2 重试与退避策略图片接口偶尔会因为网络或服务端波动失败直接抛错给用户体验很差。加一个简单的指数退避重试async function withRetry(fn, retries 3) { for (let i 0; i retries; i) { try { return await fn(); } catch (err) { if (i retries - 1) throw err; const wait Math.pow(2, i) * 1000; console.log(第 ${i 1} 次失败${wait}ms 后重试); await new Promise(r setTimeout(r, wait)); } } }注意只对可重试的错误超时、429、5xx重试401、400 这类参数错误重试多少次都没用反而浪费配额。5.3 成本控制与批量处理图片接口按张计费批量生成很容易超预算。几个实用做法开发调试阶段用低质量、小尺寸确认流程通了再切高质量。批量任务加队列控制并发数避免一次性打出去几百个请求。记录每次调用的 token/张数和费用做个简单日志月底对账心里有数。提示不要把“生成失败但已计费”的情况忽略掉。有些错误是在服务端处理后才返回的可能已经产生费用。日志里把请求 ID 记下来方便和账单核对。5.4 内容合规与审核图片生成服务通常带有内容审核机制某些描述会被拒绝。作为开发者你需要在产品层面做一层过滤和提示对用户输入的 prompt 做基础校验拦截明显违规内容。接口返回内容被拒时给用户友好提示而不是直接抛原始错误。保留调用日志便于追溯。这不是可选项而是上线前必须处理的环节。否则用户投诉和平台风险都会找上门。6. 工程化建议与个人经验6.1 把调用封装成独立模块不要把接口调用散落在各个路由里。抽一个imageService.js统一处理鉴权、重试、错误转换和日志export async function generate(prompt, options {}) { return withRetry(() client.images.generate({ model: options.model || gpt-image-1, prompt, size: options.size || 1024x1024, n: options.n || 1, })); }这样业务层只关心“我要一张图”不关心底层怎么调。以后换模型或加缓存只改一个文件。6.2 结果存储与缓存生成结果建议直接存对象存储如 S3 兼容服务数据库里只存 URL 和元数据。原因图片是二进制大文件塞数据库会拖慢查询。对象存储有 CDN前端加载快。相同 prompt 的结果可以缓存避免重复生成浪费钱。缓存 key 可以用prompt size model的哈希命中就直接返回旧图。6.3 我踩过的几个坑第一个坑是密钥加载顺序。dotenv/config必须在new OpenAI()之前执行否则process.env.OPENAI_API_KEY是 undefined。用 ESM 的import dotenv/config放在最顶部最稳妥。第二个坑是base64 内存。一次生成 4 张 1536x1536 的图base64 字符串加起来能到几十 MBNode.js 默认堆内存可能扛不住。解决办法是限制单次生成数量或者用流式处理边收边写。第三个坑是编辑接口的图片方向。手机拍的照片带 EXIF 旋转信息直接上传可能方向不对。上传前用sharp之类的库统一转正能省很多麻烦。6.4 后续可以扩展的方向这套基础跑通后可以往上加的东西不少接入队列做异步任务、加 WebSocket 推送生成进度、做 prompt 模板库让用户一键套用、把生成历史做成画廊。核心的 API 调用逻辑不变变的只是外围的业务编排。如果你打算把这个能力做成对外的服务记得在网关层加限流和鉴权别让一个用户的滥用拖垮整个服务。这块的经验就是先跑通最小闭环再逐步加工程化不要一上来就设计过度复杂的架构。 
长河君 · 2026/10/14 13:27:16 · 阅读 1.2k GPT Image 2.5 API 调用教程：Node.js 实现图片生成与编辑
1. 从标题拆解这个项目到底在做什么1.1 核心需求解析“GPT Image 2.5 API 调用教程Node.js 实现图片生成与编辑”这个标题本质上描述的是一个后端服务集成场景用 Node.js 作为服务端语言调用 OpenAI 提供的图片生成与编辑接口把“文字描述变图片”和“已有图片按指令修改”这两个能力嵌入到自己的应用里。它解决的核心问题是很多开发者想在产品里加一个“AI 画图”或“AI 改图”的功能但不想从零训练模型也不想依赖某个网页端手动操作而是希望通过代码自动化完成。比如电商后台批量生成商品场景图、内容平台给文章自动配图、设计工具里加一个“一键换风格”按钮这些都属于这个项目的典型应用场景。适合谁来参考有基础 JavaScript/Node.js 经验的后端或全栈开发者对 REST API 调用不陌生想快速把图片生成能力接入自己项目的人。如果你完全没写过 Node.js建议先补一下npm、async/await、fetch这些基础否则后面看代码会有点吃力。1.2 为什么选 Node.js 而不是 PythonOpenAI 官方文档里 Python 示例最多但实际项目里 Node.js 的出场率非常高原因很实际前后端同构如果你的前端是 React/Vue后端用 Node.js整个项目一套语言维护成本低。异步 IO 天然适配图片生成是典型的“发请求-等结果”模式Node.js 的事件循环处理这种 IO 密集型任务很顺手。部署轻量一个 Express 或 Fastify 服务配合dotenv管理密钥几十行代码就能跑起来不需要额外装一堆科学计算库。我自己的经验是如果只是做 API 编排和业务逻辑Node.js 比 Python 更省心尤其是你要把生成结果直接存到对象存储或者推给前端的时候。1.3 图片生成与编辑的能力边界这里要区分两个动作生成generation给一段文字描述返回一张全新图片。编辑edit给一张已有图片加一段指令返回修改后的图片比如“把背景换成纯白”“给人物加一顶帽子”。编辑功能通常需要上传原图或提供图片引用接口会返回新的图片数据。实际使用中编辑对原图格式、尺寸、透明通道都有要求后面会详细讲。注意不同版本的图片接口在参数命名和返回结构上可能有差异写代码前务必以你账号后台看到的接口文档为准不要照搬网上过时的示例。2. 环境准备与依赖安装2.1 Node.js 版本选择与安装图片接口的 SDK 和fetch能力对 Node.js 版本有要求。实测下来Node.js 18 LTS 及以上都能正常工作推荐直接用 20 LTS长期支持、生态兼容性好。安装方式按系统分Windows去 Node.js 官网下载 LTS 安装包一路下一步即可。装完在终端执行node -v和npm -v确认。macOS推荐用nvm管理版本nvm install 20然后nvm use 20。Ubuntu/Debian不要直接用apt install nodejs版本往往太旧。用 NodeSource 的源或者nvm安装 20 版本。# 用 nvm 安装 Node.js 20 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 node -v提示如果你在 Ubuntu 上遇到权限报错不要用sudo npm install -g容易把全局目录搞乱。正确做法是配置 npm 的全局目录到用户目录下或者直接用 nvm 管理。2.2 初始化项目与安装依赖新建一个目录初始化package.json然后装几个核心依赖mkdir gpt-image-demo cd gpt-image-demo npm init -y npm install openai dotenv express multer各依赖的作用依赖用途openai官方 SDK封装了鉴权和请求dotenv从.env读取密钥避免硬编码express起一个 HTTP 服务方便前端调用multer处理图片上传编辑功能需要如果你不想用 SDK也可以直接用 Node.js 内置的fetch发请求但 SDK 帮你处理了重试、超时和错误结构省事。2.3 密钥管理与安全配置在项目根目录建一个.env文件OPENAI_API_KEY你的密钥然后立刻把.env加进.gitignore。我见过太多人把密钥直接写进代码然后推到公开仓库结果被人扫到盗刷。密钥泄露的后果是实打实的账单不是开玩笑。echo .env .gitignore echo node_modules .gitignore注意密钥只放在服务端绝对不要塞进前端代码或浏览器请求里。前端要调就让前端调你自己的后端由后端去调图片接口。3. 核心实现图片生成3.1 最小可运行示例先写一个最简单的生成脚本generate.jsimport dotenv/config; import OpenAI from openai; import fs from fs; const client new OpenAI({ apiKey: process.env.OPENAI_API_KEY, }); async function generateImage(prompt) { const result await client.images.generate({ model: gpt-image-1, prompt: prompt, size: 1024x1024, n: 1, }); const imageData result.data[0].b64_json; fs.writeFileSync(output.png, Buffer.from(imageData, base64)); console.log(图片已保存为 output.png); } generateImage(一只戴着宇航头盔的柴犬扁平插画风格纯色背景);这段代码做了三件事初始化客户端、发请求、把返回的 base64 数据写成文件。跑之前确认package.json里加了type: module否则import语法会报错。3.2 关键参数逐个说清楚生成接口的参数不多但每个都影响结果和成本model指定使用的图片模型。不同模型在质量、速度、价格上差异明显选之前先看官方定价页。prompt文字描述是决定图片内容的核心。写得越具体结果越可控。size输出尺寸常见有1024x1024、1024x1536、1536x1024等。尺寸越大耗时和费用越高。n一次生成几张。批量生成时注意成本会线性增长。quality部分模型支持质量档位低质量快而便宜高质量慢而贵。关于 prompt 的写法我的经验是遵循“主体 动作 环境 风格 构图”的结构。比如“一只橘猫主体趴在窗台上动作环境水彩画风格风格特写构图构图”比只写“一只猫”效果好得多。3.3 返回数据的处理方式接口返回的图片数据有两种常见形式b64_jsonbase64 编码的图片字符串直接解码写文件即可。url一个临时链接需要再发一次请求下载。base64 的好处是不依赖外部链接适合直接存数据库或转存对象存储缺点是字符串很长内存占用大。如果一次生成多张高分辨率图注意 Node.js 的内存限制必要时分批处理。// 处理多张返回 for (let i 0; i result.data.length; i) { const buf Buffer.from(result.data[i].b64_json, base64); fs.writeFileSync(output-${i}.png, buf); }提示base64 字符串转 Buffer 时一定要指定base64编码否则写出来的文件是坏的打开会提示格式错误。这个坑我踩过不止一次。4. 核心实现图片编辑4.1 编辑接口的输入要求编辑和生成最大的区别是编辑需要一张原图。原图通常通过 multipart 表单上传接口对格式有要求支持 PNG、JPG、WebP 等常见格式。如果原图带透明通道比如 PNG 的 alpha编辑时可能被要求保留或去除看具体接口说明。文件大小一般有上限超过要先压缩。用multer接收上传文件再转交给编辑接口import multer from multer; const upload multer({ storage: multer.memoryStorage() }); app.post(/edit, upload.single(image), async (req, res) { const result await client.images.edit({ model: gpt-image-1, image: req.file.buffer, prompt: req.body.prompt, size: 1024x1024, }); const buf Buffer.from(result.data[0].b64_json, base64); res.set(Content-Type, image/png); res.send(buf); });这里用memoryStorage把文件放在内存里避免落盘产生临时文件。小图没问题大图要注意内存占用。4.2 编辑指令的写法技巧编辑的 prompt 和生成的 prompt 逻辑不同。生成是从零描述编辑是描述变化。好的编辑指令应该明确“改什么、改成什么、保留什么”。比如原图是一个人站在灰色背景前差的指令“改一下背景”——太模糊模型不知道改成什么。好的指令“把背景换成纯白色保留人物和服装不变保持原有光影方向”。再比如给产品图去瑕疵“去除图片左下角的文字水印用周围背景纹理填充不要改变产品本身”。注意编辑不是万能的。如果指令涉及大幅改变构图或添加原图中不存在的复杂元素结果可能不理想。这时候更稳妥的做法是重新生成而不是硬编辑。4.3 生成与编辑的组合流程实际项目里生成和编辑经常串起来用。一个典型流程用生成接口产出一张基础图。把基础图作为输入用编辑接口做局部调整换色、加元素、去瑕疵。再编辑一次做最终微调。这种“生成-编辑-再编辑”的链路比一次性写超长 prompt 更容易控制结果。每一步只改一个变量出问题也容易定位是哪一步的指令不对。async function generateThenEdit(basePrompt, editPrompt) { const gen await client.images.generate({ model: gpt-image-1, prompt: basePrompt, size: 1024x1024, }); const baseBuf Buffer.from(gen.data[0].b64_json, base64); const edited await client.images.edit({ model: gpt-image-1, image: baseBuf, prompt: editPrompt, size: 1024x1024, }); return Buffer.from(edited.data[0].b64_json, base64); }5. 常见问题与排查技巧实录5.1 高频报错速查表现象可能原因排查方向401 未授权密钥错误或未加载检查.env是否被读取密钥有无多余空格429 请求过多触发频率限制加退避重试降低并发400 参数错误size/prompt 不合法对照文档核对参数取值范围返回图片打不开base64 解码错误确认 Buffer 编码参数为base64编辑报格式错原图格式不支持转成 PNG 再试请求超时图片尺寸过大降尺寸或加长超时时间5.2 重试与退避策略图片接口偶尔会因为网络或服务端波动失败直接抛错给用户体验很差。加一个简单的指数退避重试async function withRetry(fn, retries 3) { for (let i 0; i retries; i) { try { return await fn(); } catch (err) { if (i retries - 1) throw err; const wait Math.pow(2, i) * 1000; console.log(第 ${i 1} 次失败${wait}ms 后重试); await new Promise(r setTimeout(r, wait)); } } }注意只对可重试的错误超时、429、5xx重试401、400 这类参数错误重试多少次都没用反而浪费配额。5.3 成本控制与批量处理图片接口按张计费批量生成很容易超预算。几个实用做法开发调试阶段用低质量、小尺寸确认流程通了再切高质量。批量任务加队列控制并发数避免一次性打出去几百个请求。记录每次调用的 token/张数和费用做个简单日志月底对账心里有数。提示不要把“生成失败但已计费”的情况忽略掉。有些错误是在服务端处理后才返回的可能已经产生费用。日志里把请求 ID 记下来方便和账单核对。5.4 内容合规与审核图片生成服务通常带有内容审核机制某些描述会被拒绝。作为开发者你需要在产品层面做一层过滤和提示对用户输入的 prompt 做基础校验拦截明显违规内容。接口返回内容被拒时给用户友好提示而不是直接抛原始错误。保留调用日志便于追溯。这不是可选项而是上线前必须处理的环节。否则用户投诉和平台风险都会找上门。6. 工程化建议与个人经验6.1 把调用封装成独立模块不要把接口调用散落在各个路由里。抽一个imageService.js统一处理鉴权、重试、错误转换和日志export async function generate(prompt, options {}) { return withRetry(() client.images.generate({ model: options.model || gpt-image-1, prompt, size: options.size || 1024x1024, n: options.n || 1, })); }这样业务层只关心“我要一张图”不关心底层怎么调。以后换模型或加缓存只改一个文件。6.2 结果存储与缓存生成结果建议直接存对象存储如 S3 兼容服务数据库里只存 URL 和元数据。原因图片是二进制大文件塞数据库会拖慢查询。对象存储有 CDN前端加载快。相同 prompt 的结果可以缓存避免重复生成浪费钱。缓存 key 可以用prompt size model的哈希命中就直接返回旧图。6.3 我踩过的几个坑第一个坑是密钥加载顺序。dotenv/config必须在new OpenAI()之前执行否则process.env.OPENAI_API_KEY是 undefined。用 ESM 的import dotenv/config放在最顶部最稳妥。第二个坑是base64 内存。一次生成 4 张 1536x1536 的图base64 字符串加起来能到几十 MBNode.js 默认堆内存可能扛不住。解决办法是限制单次生成数量或者用流式处理边收边写。第三个坑是编辑接口的图片方向。手机拍的照片带 EXIF 旋转信息直接上传可能方向不对。上传前用sharp之类的库统一转正能省很多麻烦。6.4 后续可以扩展的方向这套基础跑通后可以往上加的东西不少接入队列做异步任务、加 WebSocket 推送生成进度、做 prompt 模板库让用户一键套用、把生成历史做成画廊。核心的 API 调用逻辑不变变的只是外围的业务编排。如果你打算把这个能力做成对外的服务记得在网关层加限流和鉴权别让一个用户的滥用拖垮整个服务。这块的经验就是先跑通最小闭环再逐步加工程化不要一上来就设计过度复杂的架构。