零、效果圖

一、為什么做這個工具

做短視頻、做動畫、做漫畫腳本的人，幾乎都繞不開一個環(huán)節(jié)——分鏡。

傳統(tǒng)流程是：編劇寫好腳本 → 畫師根據(jù)文字描述畫出每一鏡的畫面 → 反復(fù)修改。這個過程慢、貴、且溝通成本高。

于是我想：能不能讓 AI 直接根據(jù)每一句分鏡描述生成圖片？

答案是肯定的?，F(xiàn)在的圖像生成模型（GPT-Image-2、豆包 Seedream 系列）已經(jīng)能根據(jù)文字描述生成相當(dāng)可用的畫面。我要做的，就是把"輸入文字 → 出圖 → 保存"這個流程封裝成一個簡單好用的 Web 工具。

二、需求是怎么一步步清晰的

剛開始我的想法很樸素："調(diào)用 OpenAI 的畫圖 API，輸入提示詞，出圖保存"。

但真正動手前，我和 AI 助手做了一輪 brainstorming，把需求一點點摳清楚。這個過程很重要，模糊的需求一定會導(dǎo)致返工。

第 1 輪：交互形態(tài)

命令行還是 Web 頁面？

我選了 Web 頁面。理由很簡單：分鏡創(chuàng)作是個視覺活，命令行黑框框看著沒感覺，Web 頁面能直接預(yù)覽圖片、能下載、能反復(fù)調(diào)整。

第 2 輪：技術(shù)棧

前端用什么框架？

我選了 純 HTML + 原生 JavaScript。不引任何前端框架。為什么？因為這個工具邏輯極簡——一個輸入框、一個按鈕、一張圖。上 React 純屬殺雞用牛刀，反而增加構(gòu)建復(fù)雜度。原生 JS 一個 IIFE 就搞定了。

后端用 Flask。Python 生態(tài)對 API 調(diào)用友好，F(xiàn)lask 又是最輕量的 Web 框架，單文件就能跑。

第 3 輪：API Key 怎么管

環(huán)境變量還是頁面輸入？

最初我選了頁面輸入（方便演示），但很快意識到這有安全隱患。最后改成 .env 配置文件 + python-dotenv 自動加載。.env 被 .gitignore 排除，密鑰永不進(jìn)版本庫。這是更工程化的做法。

第 4 輪：用哪個模型

這是關(guān)鍵轉(zhuǎn)折點。我一開始說"調(diào) OpenAI 的畫圖 API"，但實際我想用的是 gpt-image-2、gpt-image-2-vip、gpt-image-2-high 和 doubao-seedream-4-0/4-5/5-0 這幾個模型。

這些模型并非 OpenAI 官方直出，而是通過一個第三方代理服務(wù)提供的（兼容 OpenAI 接口格式）。這一步確認(rèn)后，后面所有 API 調(diào)用邏輯都圍繞第三方的文檔來寫。

第 5 輪：要不要做視頻

豆包 Seedream 系列其實也能生成視頻。但我果斷說 只做圖片。

理由：視頻生成耗時長（分鐘級）、文件大、還要輪詢?nèi)蝿?wù)狀態(tài)，復(fù)雜度比圖片高一個數(shù)量級。YAGNI（You Ain't Gonna Need It）——先把圖片做穩(wěn)，視頻以后再說。這個決策讓整個項目復(fù)雜度降了一個檔。

三、讀懂 API 文檔：從同步到異步的踩坑

這是整個項目最關(guān)鍵的技術(shù)轉(zhuǎn)折。

我最初按 OpenAI 標(biāo)準(zhǔn)接口寫代碼：

resp = requests.post(f"{API_BASE_URL}/v1/images/generations", json=payload, headers=headers)
result = resp.json()
image_url = result["data"][0]["url"]  # 直接拿圖

結(jié)果發(fā)現(xiàn)——ToAPIs 的圖像生成是異步的！

打開文生圖官方文檔，返回值長這樣：

{
  "id": "task_img_abc123def456",
  "object": "generation.task",
  "model": "gpt-image-2",
  "status": "queued",
  "progress": 0,
  "created_at": 1703884800
}

注意：第一次請求只返回 task_id 和狀態(tài)，不返回圖片！ 你得拿著 task_id 去另一個接口輪詢：

GET /v1/images/generations/{task_id}

直到 status 變成 completed，才能在 result.data[0].url 拿到真正的圖片地址。

文檔里還貼心地給了輪詢策略建議：

初始等待: 2 秒
輪詢間隔: 3 秒
最大等待: 120 秒
典型耗時: 5-30 秒

還有一個坑：生成的圖片 URL 有效期只有 24 小時。所以必須在拿到 URL 后立刻下載到本地，不能只存 URL。

于是后端邏輯變成了三步走：

1. 提交任務(wù) → 拿 task_id
2. 輪詢狀態(tài) → 每 3 秒查一次，最多 40 次（約 120 秒）
3. 下載圖片 → 保存到 ./images/，返回本地 URL 給前端

# 提交任務(wù)
resp = requests.post(f"{API_BASE_URL}/v1/images/generations", json=payload, headers=headers, timeout=30)
task_id = resp.json().get("id")

# 輪詢
for attempt in range(40):
    time.sleep(3)
    status_resp = requests.get(f"{API_BASE_URL}/v1/images/generations/{task_id}", headers=headers, timeout=30)
    status_data = status_resp.json()

    if status_data.get("status") == "completed":
        image_url = status_data["result"]["data"][0]["url"]
        # 下載并保存
        img_resp = requests.get(image_url, timeout=30)
        filename = f"image_{int(time.time())}_{os.urandom(4).hex()}.png"
        with open(os.path.join(IMAGES_DIR, filename), "wb") as f:
            f.write(img_resp.content)
        return jsonify({"image_url": f"/images/{filename}"})
    elif status_data.get("status") == "failed":
        return jsonify({"error": "圖片生成失敗"}), 500

另外還有一個模型差異細(xì)節(jié)：Seedream 系列的分辨率參數(shù)要走 metadata.resolution，而 GPT-Image-2 系列直接用 resolution 頂層字段。后端要根據(jù) model 名字判斷走哪條路：

if model.startswith("doubao-seedream") and resolution:
    payload["metadata"] = {"resolution": resolution}

這種"看文檔才發(fā)現(xiàn)的細(xì)節(jié)"，是遠(yuǎn)程 API 集成最耗時的部分。沒有捷徑，就是讀文檔 + 試錯。

四、前端：從單輸入框到多輸入框的演進(jìn)

第一版前端就一個 textarea，用戶把所有分鏡塞進(jìn)去，用換行分隔。簡單，但不好用：

• 想刪中間某一條得手動挪光標(biāo)
• 看不清自己一共寫了幾條
• 沒法對單條單獨操作

于是改成 動態(tài)多輸入框：

• 默認(rèn)一個輸入框
• 點「+ 添加提示詞」按鈕新增一個
• 每個輸入框右上角有「刪除」按鈕
• 聚焦時才顯示刪除按鈕，避免界面雜亂

核心就是一段 DOM 操作：

function addPromptGroup(promptText) {
  var group = document.createElement("div");
  group.className = "prompt-group";

  var textarea = document.createElement("textarea");
  textarea.className = "promptInput";
  // ...

  var removeBtn = document.createElement("button");
  removeBtn.textContent = "刪除";
  removeBtn.addEventListener("click", function() {
    group.remove();
  });

  group.appendChild(textarea);
  group.appendChild(removeBtn);
  promptsContainer.appendChild(group);
}

收集所有提示詞時遍歷一遍：

function getPrompts() {
  var inputs = promptsContainer.querySelectorAll(".promptInput");
  var prompts = [];
  for (var i = 0; i < inputs.length; i++) {
    var val = inputs[i].value.trim();
    if (val.length > 0) prompts.push(val);
  }
  return prompts;
}

五、依次生成 vs 并行生成：兩種模式的設(shè)計

分鏡往往一畫就是十幾張。如果一張一張串行生成，10 張圖每張 20 秒就要等 3 分鐘。如果并行，理論上 20 秒就能全拿回來。

所以加了「處理模式」下拉框：

依次生成（sequential）

for (var i = 0; i < prompts.length; i++) {
  var img = await generateOne(prompts[i], model, size, resolution);
  appendResult({ prompt: prompts[i], url: img.image_url, index: i });
}

特點：一張完成才生成下一張。好處是省 API 配額、出錯好定位、前端能看到逐張出現(xiàn)的過程。壞處是慢。

并行生成（parallel）

var tasks = prompts.map(function(p, i) {
  return generateOne(p, model, size, resolution)
    .then(function(img) {
      appendResult({ prompt: p, url: img.image_url, index: i });
    })
    .catch(function(err) {
      appendResult({ prompt: p, error: err.message, index: i });
    });
});
await Promise.all(tasks);

特點：所有任務(wù)同時發(fā)出，誰先回來誰先顯示?？?，但要注意的限流（429 錯誤）。如果配額吃緊，建議用依次模式。

兩種模式都用 try/catch 包裹單張生成，一張失敗不影響其他張——這對分鏡這種"批量但單張獨立"的場景很重要。

六、那些調(diào)試中的小坑

坑 1：點擊生成按鈕沒反應(yīng)

部署完第一次點按鈕，毫無響應(yīng)。打開瀏覽器控制臺，發(fā)現(xiàn)：

GET http://127.0.0.1:5000/script.js 404 (NOT FOUND)

原因：Flask 默認(rèn)靜態(tài)文件目錄是 static/，訪問路徑必須是 /static/script.js，不是 /script.js。改一行：

<!-- 錯誤 -->
<script src="script.js"></script>

<!-- 正確 -->
<script src="/static/script.js"></script>

坑 2：API_BASE_URL 寫成了完整路徑

.env 里我一開始寫了：

API_BASE_URL=https://xxxxx.com/v1/images/generations

但 app.py 里又拼了一遍 /v1/images/generations，導(dǎo)致最終 URL 變成：

https://xxxx.com/v1/images/generations/v1/images/generations

404。改成只寫根域名：

API_BASE_URL=https://xxxxx.com

配置項只放根地址，路徑在代碼里拼——這是慣例，避免重復(fù)。

坑 3：pip 命令找不到

PowerShell 里直接敲 pip install 報 "無法識別"。原因是沒激活虛擬環(huán)境，且系統(tǒng) Python 沒把 pip 加進(jìn) PATH。

解法是用 py -m pip 或激活虛擬環(huán)境后用 python -m pip：

venv\Scripts\Activate.ps1
pip install -r requirements.txt

七、最終項目結(jié)構(gòu)

畫圖程序/
├── app.py              # Flask 后端：異步任務(wù) + 輪詢 + 本地保存
├── static/
│   ├── index.html      # 前端：多輸入框 + 參數(shù)選擇 + 結(jié)果展示
│   └── script.js       # 前端邏輯：多輸入框管理、依次/并行生成
├── .env                # 配置：API_KEY + API_BASE_URL（不提交）
├── .env.example        # 配置模板
├── requirements.txt    # flask / requests / python-dotenv
├── .gitignore          # 排除 .env / images/ / venv/
├── README.md           # 使用文檔
├── venv/               # 虛擬環(huán)境
└── images/             # 運行時生成圖片存放

啟動：

cd "D:\Users\opencode\畫圖程序"
venv\Scripts\Activate.ps1
python app.py

瀏覽器打開 http://127.0.0.1:5000，界面長這樣：

• 頂部一個提示詞輸入框（可點「+ 添加提示詞」新增）
• 模型下拉框（6 個模型可選）
• 寬高比下拉框（1:1 / 4:3 / 16:9 / 9:16 / 21:9 等）
• 分辨率下拉框（1K / 2K / 4K，僅 Seedream 系列生效）
• 處理模式下拉框（依次生成 / 并行生成）
• 生成按鈕

點生成后，每張圖獨立卡片展示：序號 + 提示詞預(yù)覽 + 圖片 + 任務(wù) ID + 單獨下載按鈕。

八、幾個關(guān)鍵設(shè)計決策的復(fù)盤

決策 1：為什么不用 React/Vue

這個工具前端邏輯總共不到 150 行 JS。引入 React 要配 Babel、Webpack、JSX，構(gòu)建鏈比業(yè)務(wù)邏輯還復(fù)雜。技術(shù)選型要看場景，不是越新越好。 原生 JS + IIFE 對這種小工具是最佳解。

決策 2：為什么后端要做"下載圖片到本地"這一步

選擇生成的圖片 URL 只有 24 小時有效期。如果前端直接用這個 URL，第二天分鏡文件就全裂圖了。所以后端必須把圖片下載到本地 images/ 目錄，前端拿的是本地路徑 /images/xxx.png，永久有效。

這也是為什么有個 /images/<filename> 路由——專門serve本地圖片。

決策 3：為什么用 .env 而不是環(huán)境變量

環(huán)境變量要每次啟動前手動 $env:API_KEY = "..."，換臺機器就忘。.env 文件跟著項目走（雖然不進(jìn) git），改一次永久生效，用 python-dotenv 一行加載：

from dotenv import load_dotenv
load_dotenv()
API_KEY = os.getenv("API_KEY")

開發(fā)體驗比純環(huán)境變量好太多。

最后修改這個文件，修改這兩個變量API_BASE_URL 和 API_KEY為實際值：

決策 4：為什么單張失敗不阻塞其他張

分鏡生成是"批量但單張獨立"的場景——第 3 張失敗了，第 4、5、6 張照樣該生成。所以每張生成單獨 try/catch，失敗的那張顯示錯誤信息，成功的照常出圖。這個容錯設(shè)計讓工具在弱網(wǎng)或 API 抖動時也不至于全盤崩潰。

九、后續(xù)可以加什么

這個版本是 MVP（最小可用版本）。如果要繼續(xù)打磨，我會考慮：

1. 批量打包下載 —— 生成完 10 張圖后，一鍵打包成 zip 下載，省得一張張點
2. 提示詞模板 —— 內(nèi)置幾套分鏡模板（如"電影感""賽博朋克""水墨"），點一下自動填到輸入框
3. 歷史記錄 —— 把每次生成的 prompt + 圖片路徑存到 SQLite，方便回溯
4. 圖生圖（reference_images） —— 上傳一張參考圖，讓 AI 基于它改風(fēng)格。ToAPIs 文檔里這個能力是現(xiàn)成的，前端加個上傳組件即可
5. 進(jìn)度條 —— 輪詢時把 progress 字段（0-100）回傳前端，做個真進(jìn)度條，而不是干等

十、總結(jié)

打開后頁面樣式

輸入提示詞后等待樣式

生成后結(jié)果

這個項目本身不復(fù)雜，但有幾個點值得新手注意：

1. 需求要摳清楚再動手 —— 一輪 brainstorming 省下后面 3 輪返工
2. 讀 API 文檔比寫代碼重要 —— 同步還是異步、參數(shù)走頂層還是 metadata、URL 有效期多久，這些細(xì)節(jié)不看文檔全是坑
3. 小工具別上重框架 —— 原生 JS + Flask 單文件，部署簡單、改起來快、看代碼一目了然
4. 容錯要從單點做 —— 批量任務(wù)里每條單獨 try/catch，一條掛了不影響其他
5. 密鑰管理要工程化 —— .env + .gitignore，別圖省事硬編碼

以上就是用Codex從零搭建一個腳本分鏡圖片生成器的流程步驟的詳細(xì)內(nèi)容，更多關(guān)于Codex搭建腳本分鏡圖片生成器的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論