要可靠地制作一部 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 文档 通过嵌套的分页对象支持多页输入。以下是一个请求结构示例，并非本文实际执行的请求：

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

不要将这种分页模式与 fixPanelNum 组合使用。请妥善保管 API 令牌的私密性。存储返回的生成 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.

修复后，审阅相邻分镜，并且只刷新使用了变更页面的导出文件。参考变更审计指南 介绍了更广泛的依赖变更处理方法。

第 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 中的三页简报开始。只有当你能解释为什么这些页面通过时，再继续扩展。对于团队制作需求，企业方案 可以帮助界定集成范围。

FAQ

我可以一次请求全部四十页吗？

请根据当前 API 和账户限制来判断可接受的规模。编辑批次大小也应反映你的团队在继续之前能够审阅多少内容。

API 任务完成是否意味着页面已获批准？

不是。完成是一个技术状态。批准则要求根据简报对结果进行审阅。

一个失败的分镜是否应该触发整个批次重跑？

首先确定原因。局部缺陷通常可以单独修复；而共享参考或脚本问题可能会影响多个页面，此时应触发影响审计。

产品文档审阅于 2026 年 11 月 2 日。图示和规划台账均为教学示例；本文不声称提供任何关于四十页的速度或成本基准。