零、效果图一、为什么做这个工具做短视频、做动画、做漫画脚本的人，几乎都绕不开一个环节——分镜。传统流程是：编剧写好脚本 → 画师根据文字描述画出每一镜的画面 → 反复修改。这个过程慢、贵、且沟通成本高。于是我想：能不能让 AI 直接根据每一句分镜描述生成图片？答案是肯定的。现在的图像生成模型（GPT-Image-2、豆包 Seedream 系列）已经能根据文字描述生成相当可用的画面。我要做的，就是把"输入文字 → 出图 → 保存"这个流程封装成一个简单好用的 Web 工具。二、需求是怎么一步步清晰的刚开始我的想法很朴素：“调用 OpenAI 的画图 API，输入提示词，出图保存”。但真正动手前，我和 AI 助手做了一轮 brainstorming，把需求一点点抠清楚。这个过程很重要，模糊的需求一定会导致返工。第 1 轮：交互形态命令行还是 Web 页面？我选了Web 页面。理由很简单：分镜创作是个视觉活，命令行黑框框看着没感觉，Web 页面能直接预览图片、能下载、能反复调整。第 2 轮：技术栈前端用什么框架？我选了纯 HTML + 原生 JavaScript。不引任何前端框架。为什么？因为这个工具逻辑极简——一个输入框、一个按钮、一张图。上 React 纯属杀鸡用牛刀，反而增加构建复杂度。原生 JS 一个 IIFE 就搞定了。后端用Flask。Python 生态对 API 调用友好，Flask 又是最轻量的 Web 框架，单文件就能跑。第 3 轮：API Key 怎么管环境变量还是页面输入？最初我选了页面输入（方便演示），但很快意识到这有安全隐患。最后改成.env配置文件 + python-dotenv 自动加载。.env被.gitignore排除，密钥永不进版本库。这是更工程化的做法。第 4 轮：用哪个模型这是关键转折点。我一开始说"调 OpenAI 的画图 API"，但实际我想用的是gpt-image-2、gpt-image-2-vip、gpt-image-2-high和doubao-seedream-4-0/4-5/5-0这几个模型。这些模型并非 OpenAI 官方直出，而是通过一个第三方代理服务提供的（兼容 OpenAI 接口格式）。这一步确认后，后面所有 API 调用逻辑都围绕第三方的文档来写。第 5 轮：要不要做视频豆包 Seedream 系列其实也能生成视频。但我果断说只做图片。理由：视频生成耗时长（分钟级）、文件大、还要轮询任务状态，复杂度比图片高一个数量级。YAGNI（You Ain’t Gonna Need It）——先把图片做稳，视频以后再说。这个决策让整个项目复杂度降了一个档。三、读懂 API 文档：从同步到异步的踩坑这是整个项目最关键的技术转折。我最初按 OpenAI 标准接口写代码：resp=requests.post(f"{API_BASE_URL}/v1/images/generations",json=payload,headers=headers)result=resp.json()image_url=result["data"][0]["url"]# 直接拿图结果发现——ToAPIs 的图像生成是异步的！打开文生图官方文档，返回值长这样：{"id":"task_img_abc123def456","object":"generation.task","model":"gpt-image-2","status":"queued","progress":0,"created_at":1703884800}注意：第一次请求只返回 task_id 和状态，不返回图片！你得拿着 task_id 去另一个接口轮询：GET /v1/images/generations/{task_id}直到status变成completed，才能在result.data[0].url拿到真正的图片地址。文档里还贴心地给了轮询策略建议：初始等待: 2 秒 轮询间隔: 3 秒 最大等待: 120 秒 典型耗时: 5-30 秒还有一个坑：生成的图片 URL 有效期只有 24 小时。所以必须在拿到 URL 后立刻下载到本地，不能只存 URL。于是后端逻辑变成了三步走：提交任务→ 拿task_id轮询状态→ 每 3 秒查一次，最多 40 次（约 120 秒）下载图片→ 保存到./images/，返回本地 URL 给前端# 提交任务resp=requests.post(f"{API_BASE_URL}/v1/images/generations",json=payload,headers=headers,timeout=30)task_id=resp.json().get
