若要穩定地製作一部 40 頁漫畫，請先核准一小段試作篇，以可審查的批次生成，修補失敗的分鏡，並從已核准的版本組裝匯出檔。成功送出一次生成請求，只是製作流程中的一個階段。

當你需要可重複的整合方式時，請從 LlamaGen.AI Comic API 開始。本指南提供一個針對四十頁、每頁四格的規劃範例。本文並不宣稱已為這篇文章生成或基準測試了四十頁完整成品。

為什麼長篇漫畫需要製作台帳

困難的問題通常不是某一頁是否改了，而是還有哪些頁面依賴這個變更。一則關於 40 頁漫畫的創作者討論 描述了更新角色後，團隊如何不確定哪些頁面及後續資產會受到影響。

請為每一頁指定穩定的 ID，並將其連結到已核准的腳本、參考版本、生成作業、審查決策與匯出結果。這份紀錄能讓修正具備可追溯性，也有助於保護已經核准的內容。

我們的範例講述 Mira 在一座火車站中的懸疑故事。她的銅色鮑伯短髮、青綠色外套與黃銅羅盤維持固定。整本書共有四十頁，每頁規劃四個分鏡：總計 160 個預定分鏡欄位。封面與宣傳裁切圖則是獨立的交付項目。

第 1 步：鎖定簡報並拆分全書

在提交工作前，先撰寫一份簡短的製作簡報：

Project: Station Compass
Length: 40 story pages, 4 panels per page
Character: Mira, copper bob, teal coat, brass compass
Location: rainy station, blue train, warm lamps
Reading direction: left to right
Dialogue: maintained separately for final lettering
Approval owner: named editor

接著選擇保留審查空間的批次排程：

這些是編輯批次，並不是 API 請求可接受最大頁數的保證。請在決定請求大小前，先確認目前的帳號限制。

第 2 步：讓試作篇具有代表性

在前三頁中的某處納入寬景建立鏡頭、臉部特寫、道具互動、雙人對話，以及翻頁節點。三頁幾乎相同的肖像畫面，無法揭露這本書最棘手的問題。

此插圖展示的是核准結構，並不是四十頁生成內容的截圖。

審查試作篇時，不只要看畫面品質，也要檢查故事是否清楚。確認羅盤保持可辨識、角色不會隨著鏡頭距離改變而漂移，且對話能放入而不遮住手或臉。在擴大製作之前，先保存已核准的參考資料與腳本版本。

如果試作篇失敗，請記錄原因並更新共享簡報。在試作階段修正共同指令，可以限制後續頁面繼承同一問題的數量。

第 3 步：使用已記錄的請求並保留作業 ID

目前的 Comic API 文件 透過巢狀的 pagination 物件支援多頁輸入。以下內容是請求結構範例，並非本文實際執行的請求：

{
  "prompt": "Create the first three pages of Station Compass from the approved panel script.",
  "preset": "japanese_manga",
  "pagination": {
    "totalPages": 3,
    "panelsPerPage": 4
  }
}

請勿將這種 pagination 模式與 fixPanelNum 一起使用。請妥善保密 API 權杖。儲存回傳的 generation ID，然後使用文件記載的狀態端點取得狀態與資產。請記錄實際回傳的用量，而不是估算一個通用的每頁價格。

對每一個提交的作業，都要將輸入與回應一併保存。當回應延遲時，請先檢查現有作業，再決定是否提交另一個請求。遵循文件所述的冪等性行為；變更重試鍵可能會建立另一個獨立作業並產生額外成本。

第 4 步：把技術成功與編輯核准分開

作業可能已完成，但某頁仍可能缺少一個敘事節拍、出現錯誤的外套，或沒有可讀的對話框空間。請將生成狀態與編輯狀態分別存放在不同欄位。

page_id,batch,script_version,reference_version,job_id,review_state,export_version
P001,pilot,v03,mira-v02,record-returned-id,approved,v01
P002,pilot,v03,mira-v02,record-returned-id,repair-required,
P003,pilot,v03,mira-v02,record-returned-id,awaiting-review,

請使用明確的決策狀態，例如 awaiting-review、repair-required 與 approved。為每一次退件指定負責人與原因。在替代版本通過審查之前，請保留較早已核准的檔案。

在每個批次結束時，檢查它與下一批次之間的銜接。最後一格與第一格即使各自都正確，仍可能在角色站位或道具由哪一隻手持有上彼此不一致。

第 5 步：只修補受影響的分鏡

假設 P017 中有一格出現 Mira 穿著紅色外套。請只記錄這個單一缺陷，而不是退回整個批次中的每一張圖。

API 文件中記載了針對既有生成內容進行分鏡更新的請求。頁面與分鏡索引皆以零為起始。請依實際作業結果對應這些索引；你書中的 P017 並不會自動等於每個批次中的第 16 個頁面索引。

可使用如下的修補簡報：

Restore Mira's teal coat and copper bob in this panel.
Preserve the camera, station, compass, pose and other characters.
Do not revise the surrounding panels.

修補完成後，請審查相鄰分鏡，並只更新使用了該變更頁面的匯出檔。reference-change audit guide 涵蓋了更廣泛的相依變更。

第 6 步：在匯出前稽核 40 頁台帳

檢查唯一性、頁面覆蓋完整性、核准狀態，以及目前的匯出版本。簡單的本機規劃檢查，就能在任何人組裝整本書之前抓出缺漏紀錄：

expected = {f"P{i:03d}" for i in range(1, 41)}
actual = [row["page_id"] for row in pages]
assert len(actual) == len(set(actual)), "Duplicate page ID"
assert set(actual) == expected, "Missing or unexpected page"
assert all(row["review_state"] == "approved" for row in pages)
assert all(row["export_version"] for row in pages)

在隨附的本機規劃練習中，有一頁刻意設為未核准，因此在其審查紀錄修正前會阻擋匯出。這是在測試台帳規則，而不是四十頁漫畫的視覺品質。編輯仍然需要通讀整本書。

你應該追蹤哪些時間與點數成本？

請分別追蹤生成、審查、修補、字稿配置、組裝與最終通讀。保存每個作業實際回傳的用量，並以相同的批次邊界來衡量人工審查時間。

使用以下預算結構：

Total production cost = pilot + accepted batches + repairs + export work
Total elapsed time = generation waits + review + repair + assembly

不要因為一格看起來很吸引人的分鏡，就外推整本書的情況。一個有用的試作估算，必須包含被拒絕的結果與清理成本。

發布檢查清單

• 四十個獨特的故事頁 ID 皆已依預定順序存在。
• 每一頁都有編輯核准與目前的匯出版本。
• 角色、場景與道具參考皆可追溯。
• 對話與署名都已完成校對。
• 頁面邊界與場景轉換閱讀起來連續順暢。
• 檔案可在另一台裝置上重新開啟，且不缺少資產。
• 封面、縮圖與宣傳裁切圖皆使用已核准的版本。

先從 Comic API 中的三頁簡報開始。只有在你能說明這些頁面為何通過後，再進一步擴展。若有團隊製作需求，enterprise route 可協助你界定整合範圍。

常見問題

我可以一次請求全部四十頁嗎？

請依目前的 API 與帳號限制判斷可接受的範圍。編輯批次大小也應反映你的團隊在繼續之前能審查多少內容。

API 作業完成，是否代表頁面已核准？

不是。完成是技術狀態。核准則需要依據簡報審查結果。

單一失敗的分鏡是否應該觸發整個批次重跑？

請先找出原因。局部缺陷通常可以單獨修補；若是共享參考或腳本問題，則可能影響數個頁面，應觸發影響稽核。

產品文件於 2026 年 11 月 2 日審閱。圖示與規劃台帳皆為教學範例；本文不主張任何四十頁的速度或成本基準。