案例教程2026-07-1926 分钟阅读

我用 Codex + gpt-image-2，把一部长篇小说做成了 72 格条漫

从 281 章原著到角色一致、可恢复、可发布的 AI 彩漫生产线：来源映射、视觉圣经、分镜任务、人工 QA 与排版交付全流程实录。

原始来源

AIGOKEY 编辑部

《天魔神谭》小说条漫项目实录

2026-07-19

《天魔神谭》小说仅出于小编对古早网文的个人喜爱作品，进行的尝试，不作任何商业化，如有任何版权异议，联系小编下架文章，谢谢~

编辑部导读本文从公开资料出发，补齐背景、判断和可执行步骤，适合边读边试。

一眼看懂

小说条漫生产线的四个关键控制点

原著入库：保全原稿、统一编码、建立章节索引

改编映射：先拆剧情节拍，再为每个镜头绑定来源

视觉生产：用视觉圣经、参考图和 scene_state 稳定连续性

QA 与交付：局部返修、可恢复续跑、文字后置与平台切片

《天魔神谭》AI 彩漫第一单元封面

很多人第一次尝试用 AI 做漫画，流程通常只有一句话：把小说片段发给模型，让它“画成漫画”。第一张可能很惊艳，到了第三张，人物就换了脸；场景忽然变样；上一格还在手里的道具，下一格凭空消失；模型甚至把对白直接画进画面，生成一堆无法修改的乱码。

我在《天魔神谭》项目里走了另一条路：让 Codex 负责理解小说、拆解剧情、维护设定、编排任务、检查结果和组织文件，让 gpt-image-2 负责视觉生成，再把必须由人判断的审美与连续性审核留在流程中。

最终，项目把一部含 3 部、31 卷、281 个编号章节和 3 个楔子的长篇小说，整理成可追溯的结构化素材库；完成 EP000 至 EP003 共 72 个批准镜头，并排版为 16 张平台切片。更重要的是，这不是一次性的“出图演示”，而是一条可以续跑、返修、复盘和批量生产的流水线。

这篇文章完整拆解这套方法。你可以把它迁移到武侠、玄幻、悬疑、历史、言情等任何需要长期保持人物和世界一致性的小说改编项目中。

先说明权利边界：本项目原始文件中的声明不能证明已获得公开改编或商业传播授权。工作流默认用于内部研究与制作验证。公开发布前，需要自行确认小说文本、角色、剧情及衍生内容所需的权利许可。

一、先看全局：Codex、image2 和人分别做什么

小说条漫生产线：从权利确认、原著入库到发布切片

这条生产线的关键，不是让一个模型包办一切，而是给三类参与者划清职责。

角色	最适合承担的工作	不应该独自决定的事
Codex	读取项目、切分原著、建立索引、提炼剧情节拍、写分镜、生成任务、维护状态、调用脚本、做结构校验	最终审美取舍、版权授权、对角色气质的主观认可
gpt-image-2（下文简称 image2）	根据文本和参考图生成场景、人物、动作、幻兽与气氛；用图像编辑完成局部返修	整话剧情结构、跨镜头事实管理、最终成片排版
人	选择改编范围、批准角色设计、审核关键帧、判断表情与戏剧张力、确认发布	重复搬运文件、手工维护大量镜头状态

一句话概括：Codex 是制片人、编剧、场记和自动化工程师的组合，image2 是执行视觉方案的画师，人是总导演和最终审片人。

二、为什么不能“把整章直接丢给生图模型”

小说和条漫的叙事单位不同。小说可以用一段内心独白跨越十年，也可以在一句话里带过一场战争；条漫必须把信息放进可见的镜头、动作、表情和空间关系里。

直接把一章原文塞进提示词，通常会同时出现五个问题：

信息密度失控。 模型不知道哪些是必须画出的剧情事实，哪些只是气氛描写。
人物身份漂移。 同一个人每格重新“抽卡”，脸、发型、年龄和衣服都可能变化。
时序混乱。 尚未登场的道具提前出现，已经离场的人物又被画回来。
构图不适合手机。 横向群像、海报式拼贴和复杂背景在竖屏上难以阅读。
文字不可控。 对白被直接画进图里，错字和乱码无法像排版文字那样修改。

因此，真正需要设计的是“中间层”：原文不能直接到图片，中间必须经过来源映射、剧情节拍、分镜、视觉参考、镜头状态和排版数据。

三、项目骨架：先把一次创作变成长期工程

《天魔神谭》项目没有把所有东西堆在一个文件夹里，而是按数据职责分层：

source/raw/                 # 唯一权威原稿，不手工修改
source/normalized/          # 统一编码后的全文
source/units/               # 按部、卷、章切分的文本单元
source/index/               # 全书结构索引与质量报告
bible/                      # 世界、角色、地点、幻兽、风格圣经
production/episodes/EP001/  # 单话的来源、脚本、分镜、提示词、任务、生成与 QA
output/masters/             # 1080px 宽条漫母版
output/slices/              # 平台发布切片
scripts/                    # 导入、校验、生图包装、排版脚本

这套目录看起来比“一个 prompts 文件夹”复杂，但它解决了三个生产级问题：原文不会被误改；任何镜头都能追溯到来源；失败后只重跑缺失任务，不必整批推倒重来。

四、步骤 0：先保全原著，再谈改编

项目里的原稿是 GB18030 编码。纯 GBK 严格解码会失败，而 GB18030 可以零替换字符解码。如果一开始用错误编码打开、另存，再继续处理，后续所有分镜都建立在一份已经损坏的文本上。

导入脚本做了四件事：

计算原文件 SHA-256，并与配置中的预期值比对。
用指定编码严格解码，生成 UTF-8 规范化全文。
用“第几部第几卷”“第几章”“楔子”等规则扫描结构。
输出按章切分的文本、全书 JSON 索引和来源质量报告。

配置中的关键字段如下：

{
  "encoding": "gb18030",
  "expected_sha256": "9ff8f7ab...",
  "normalized_path": "source/normalized/book.txt",
  "index_path": "source/index/book.json",
  "units_dir": "source/units"
}

重建索引只需要一条命令：

& scripts\project.ps1 ingest

这里有一条很重要的工程原则：source/raw/ 是不可变事实层。清洗水印、修正错字、统一异体字，都应该放在独立校订层，并记录原行号、改动内容和理由。不要为了“方便”直接改唯一原稿。

五、步骤 1：用来源映射锁住改编边界

条漫不是逐句配图。它需要选择一话讲什么、从哪里开始、在哪里收束，以及哪一段必须保留原著事实。

EP001《没有出息》使用第一部第一卷第一章全文，共 58 行。source_map.json 明确记录来源单元、选取范围和用途：

{
  "episode_id": "EP001",
  "adaptation_policy": "story-beats",
  "sources": [{
    "unit_id": "P01-V01-C001",
    "role": "primary",
    "selection": {"mode": "complete-unit", "start_line": 1, "end_line": 58}
  }]
}

这样做的价值是，审稿时不必凭印象争论“这段是不是原著里的”。每个镜头都能回到具体章节和行号。以后即便一章拆成三话，或把相邻章节重组为一话，来源关系仍然清楚。

六、步骤 2：先拆剧情节拍，再写 14 个镜头

Codex 先把 58 行原文拆成 6 个剧情节拍，而不是立刻写 14 条生图提示词：

节拍	内容	镜头	叙事任务
B01	原曙城与云柳学院	S001-S002	建立世界、学院与力量秩序
B02	幻兽历史课	S003-S004	解释幻兽来源和成长阶段
B03	靠窗的亚芠	S005-S006	建立主角的孤立与迟钝
B04	纳肯的挑战	S007-S008	从课堂转入公开冲突
B05	火虎的羞辱	S009-S012	完成召唤、攻击、嘲讽与离场
B06	英雄之家的凡人	S013-S014	用家族荣光反衬主角困境并留悬念

节拍的作用是控制阅读节奏。世界观说明不宜拖太久，冲突需要逐步升级，结尾需要能把读者推向下一话。EP001 的情绪曲线是“宏大世界观 → 平静课堂 → 压抑孤立 → 暴力羞辱 → 家族重压”，这比简单的“按原文段落切 14 份”更接近漫画编剧的工作。

在这个基础上，storyboard.json 才逐镜头记录：来源行号、出场角色、地点、景别、机位、动作、对白、旁白和连续性状态。

一个镜头的数据大致长这样：

{
  "shot_id": "EP001-S010",
  "source_line_range": [37, 39],
  "characters": ["亚芠", "纳肯", "火虎"],
  "shot_size": "强动作全景",
  "camera": "火球沿对角线击中亚芠胸口",
  "action": "亚芠被正面击倒跪地",
  "continuity_state": {
    "props_required": ["single compact fireball"],
    "props_forbidden": ["blood", "multiple fireballs"],
    "preserve": ["Ayen, Naken and fire tiger identities", "lake layout"]
  }
}

注意，props_forbidden 和 preserve 与“画什么”同样重要。模型很容易把动作场面自动升级成多颗火球、巨大猛兽或重伤流血；把禁止项写成结构化状态，比在长提示词末尾随手加一句“不要出错”可靠得多。

七、步骤 3：先做视觉圣经，再做连续镜头

EP001 角色参考图：亚芠、纳肯、兰妮、伊廉和盖斯老师

角色一致性不是靠在每条提示词里反复写“同一个人”实现的，而是靠“身份不变量 + 批准参考图 + 每镜头明确映射”实现的。

项目的视觉圣经固定了以下规则：

媒介是日系动画赛璐璐彩漫，使用干净线条和二到三级明暗。
手机阅读优先，主体和表情必须在小屏上可辨。
每个批准角色都需要正面、侧面、背面、表情和关键服装参考。
提示词重复脸型、发型、体型、服装色板和标志物等身份不变量。
场景布局和道具出现时序写入 scene_state，未来道具不能塞进全局前缀。
生图阶段不生成对白、旁白、拟声字、水印或任何可读文字。

EP001 先生成了五人角色参考图和火虎参考图。后续需要人物的镜头统一走 image-to-image，由参考图控制身份；纯环境建立镜头则可以使用文本生成。

同一学院的两个连续环境镜头：建筑和色板被前一张图继续约束

场景连续性也可以用同样方法。S001 先建立云柳学院的蓝色琉璃瓦、白墙、淡青和克制金色；S002 再把 S001 作为输入图，延续建筑语言和色板。参考图不只控制人物，也可以控制地点、道具、怪物和画风。

八、步骤 4：把提示词拆成“系列前缀 + 镜头任务”

项目没有把所有设定复制进每一条任务，而是分成两层。

第一层是 series-prefix.txt，定义整部系列都要遵守的规则：

作品类型：高品质中文竖屏彩漫全幅镜头。
画风：日系动画赛璐璐、稳定线稿、受控明暗。
构图：2:3 竖幅、单一视觉焦点、向下阅读流、为后期文字留安全区。
世界约束：古代奇幻文明与失落高科技遗迹并存，不加入现代消费品牌。
文本约束：画面内没有标题、对白、气泡、拟声字、数字、标志和水印。

第二层是每个镜头自己的任务，只写当前镜头必须完成的内容。以火虎攻击为例：

Input images:
Image 1 controls Ayen Stark and Naken Silva.
Image 2 controls the cat-sized fire tiger Tiger King.

Primary request:
Tiger King fires one compact orange fireball diagonally into Ayen's chest.
The impact knocks Ayen backward and down onto one knee.

Constraints:
Preserve all three identities and scale; show exactly one fireball.

Avoid:
No gore, no multiple fireballs, no giant tiger, no text, no watermark.

EP001-S010：参考图控制人物与火虎，镜头任务控制动作、尺度和伤害程度

提示词的实用结构可以总结为六段：输入图分别控制什么、主要请求、主体与动作、构图与镜头、光线与情绪、约束与禁止项。不要把参考图只作为附件上传；要逐张说明 Image 1、Image 2 各自负责什么，否则模型容易把多个角色的特征混在一起。

九、步骤 5：把每个镜头写成可续跑的 JSONL 任务

最终生图任务放在 jobs/final.jsonl 中，一行一个 JSON。核心字段包括：

{
  "scene_id": "EP001-S010",
  "operation": "img2img",
  "images": ["cast-reference.webp", "fire-tiger-reference.webp"],
  "input_fidelity": "high",
  "prompt": "...",
  "out": "EP001-S010.webp",
  "size": "1024x1536",
  "scene_state": {
    "characters_present": ["Ayen", "Naken", "Tiger King"],
    "props_required": ["single compact fireball"],
    "props_forbidden": ["blood", "multiple fireballs"],
    "preserve": ["identities", "lake layout"]
  }
}

operation 必须真实反映任务类型。参考图任务使用 img2img，调用图像编辑接口并携带图片；不能用纯文本 generate 冒充“参考图生成”。项目还专门写了预检脚本，确认任务会走 /v1/images/edits 且请求中确实包含 Image 1。

正式生图前的命令顺序如下：

# 1. 校验本机 AGK2IMG 配置，不发起生图
& scripts\project.ps1 doctor

# 2. 验证参考图任务的路由和图片输入，不发起生图
& scripts\project.ps1 reference-dry-run

# 3. 预览批任务解析结果，不发起生图
& scripts\project.ps1 dry-run

# 4. 批量生成 final
& scripts\run_agk2img.ps1 final EP001

包装脚本默认并发数为 2，使用 --skip-existing 跳过已存在输出，并把请求结果、耗时和状态写入 manifest。这样，批处理中途断线时，恢复任务不会重复生成已经成功的镜头。

十、步骤 6：先审两张关键帧，再放大到整批

不是所有镜头都值得在试制阶段生成。最省时间的做法，是先选两类高风险镜头：

一个近景人物镜头，用来检查脸、发型、年龄、服装和表情。
一个多人或复杂场景镜头，用来检查身份混合、空间连续性和参考图是否真正生效。

这两张过关后，再批量生成整话 final。否则，角色参考图方向一旦错了，14 张甚至 26 张都要重做。

EP002 的生产记录更能说明这个原则。它先做 5 张新增参考图、2 张关键 draft 和 1 张 draft 返修，再生成 26 张 final。前置验证看似多了一步，实际是在更便宜的位置暴露问题。

十一、步骤 7：人工 QA 不是“看着顺眼”，而是逐项验收

每张图至少检查以下六类问题：

身份： 人脸、发型、年龄、体型、服装和标志物是否一致。
时序： 当前应该出现和不应该出现的人、道具、伤痕是否正确。
空间： 教室、湖边、庄园等场景的布局和光线是否连续。
动作： 攻击方向、受力关系、手脚结构和数量是否合理。
文字： 是否混入乱码、标志、水印、气泡或可读招牌。
移动端可读性： 缩小到手机宽度后，主体和表情是否仍然清楚。

项目里的 QA 不是一句“视觉通过”，而是有镜头完整性、尺寸、角色、道具、文字、来源覆盖、排版和切片边界等检查项。

一个真实返修：老师为什么混进了学生群像

返修前后：盖斯老师被错误继承到学生冲突场景，局部编辑后替换为普通学生

EP001 的角色参考图把亚芠、纳肯、兰妮、伊廉和盖斯老师放在同一张图上。S007 需要“纳肯和四名同伴围住亚芠”，模型把参考图中的盖斯老师也当成了同伴。这个错误随后沿着场景连续性进入湖边镜头。

解决办法不是重抽整批，而是建立 5 条局部编辑任务，把错误人物替换为普通少年学生，同时保留其他人的脸、构图、光线和场景。返修记录明确保存父图、修订原因、输出图、状态和 API 时间。

这个案例带来两个经验：

参考图越全，模型可用的信息越多，但误用不相关角色的风险也越高。最好按场景准备更小的角色子集参考图。
返修要写“只改什么、必须保留什么”，不能把修订任务写成整张图的重新描述。

十二、步骤 8：画面不带字，文字统一在排版层完成

AI 生图里的文字几乎不可维护。项目因此规定：图像生成阶段禁止对白、旁白、拟声字、标题和水印；所有中文文字统一在 layout/layout.json 中管理，再由排版脚本写进条漫。

布局文件为每格指定实际采用的图片、标签和文字。例如返修后的 S007 会显式引用 EP001-S007-r1.webp：

{
  "panel_id": "EP001-S007",
  "image": "EP001-S007-r1.webp",
  "label": "07｜围堵",
  "caption": "纳肯：亚芠大少爷，你的幻兽带来了没？\n亚芠：幻兽？什么幻兽？"
}

排版脚本完成以下工作：

把不同原始尺寸的镜头按宽度等比统一到内容宽度。
使用微软雅黑渲染中文标签、对白和旁白。
生成 1080px 宽、sRGB、PNG 格式的长条母版。
按人工指定的镜头边界切片，避免切断图片或文字。
校验每张切片高度不超过 12000px。

& scripts\project.ps1 compose-ep001

EP001 完成后的 1080px 条漫被切为 3 张发布切片

EP001 的母版尺寸为 1080 × 27227px，最终切为 3 张，尺寸分别是 1080 × 9984、1080 × 9321 和 1080 × 7922px。切点选在第 5 格和第 10 格之后，没有切断旁白或镜头。

十三、失败恢复：生产流程必须允许“从第 9 张继续”

批量生图最容易被忽略的不是提示词，而是网络、进程和文件状态。

EP003 首批并发生成在 S009 后遇到 TLS EOF。项目没有删除全部结果重跑，而是按下面的顺序恢复：

确认原进程已经退出，任务锁由活跃变为 stale。
单独恢复 S009，验证接口和输出目录恢复正常。
把并发降低到 1，从 S010 安全续跑到 S024。
使用 --skip-existing 避免重复生成 S001-S008。
把恢复任务写入独立 manifest，保留完整生产记录。

另外，图像接口的实际输出尺寸并不总是完全一致。项目中既有 1366 × 2048，也有 1024 × 1536，还出现过 1023 × 1537 和 1024 × 1535。处理原则是：先验证图像是否完整、视觉是否合格，再在无网络的排版阶段按宽度等比归一；不要因为一两个像素差异盲目重生整张图。

十四、用数据看这条流程跑到了什么程度

EP000-EP003 的批准镜头和返修数量

话数	来源	批准镜头	返修输出	母版高度	发布切片
EP000 楔子	P01-V01-PR	8	1	15765px	2
EP001 没有出息	P01-V01-C001	14	5	27227px	3
EP002 奇异幻兽	P01-V01-C002	26	3	50326px	6
EP003 家族的危机	P01-V01-C003	24	8	46529px	5

四话合计 72 个批准镜头、17 个返修输出和 16 张发布切片。EP001 的 14 张初稿加 5 张返修，批准成片累计 API 处理时间约 1867 秒；包含草稿与超时在内的开发累计约 2261 秒。这里的“API 时间”是各请求累计值，不等同于并发后的真实墙钟时间。EP000 的首批 API 累计约 405 秒，而并发 2 的批处理墙钟时间约 212 秒，正好说明两者的区别。

这些数字的意义不在于展示速度，而在于说明：当镜头数从 8 增长到 26，项目仍然能回答“哪张来自哪段原文、用了哪些参考图、为什么返修、最终采用哪个文件、切片在哪里”。这才是可持续生产。

十五、可以直接复用的提示词与状态模板

下面是一份适合多数小说条漫镜头的模板。方括号里的内容由 Codex 根据分镜填充：

Use case: identity-preserve illustration-story
Asset type: full-bleed vertical panel for a premium color webtoon
Style/medium: [系列画风]

Input images:
Image 1 controls [角色 A 的身份与服装].
Image 2 controls [角色 B / 怪物 / 地点 / 道具].

Primary request:
[一句话说明当前镜头发生什么]

Subject and action:
[人物位置、动作、朝向、情绪、相互关系]

Composition:
[景别、机位、视觉焦点、竖屏阅读方向、文字安全区]

Lighting and mood:
[时间、主色、光源、情绪]

Constraints:
[必须保留的身份、尺度、伤痕、场景状态]

Avoid:
[当前绝不能出现的人、物、文字、错误动作和视觉风格]

配套状态建议至少包含：

{
  "characters_present": [],
  "props_required": [],
  "props_forbidden": [],
  "props_introduced": [],
  "environment_changes": [],
  "preserve": []
}

把这些字段保存在 JSON 中，而不是只写在自然语言里，Codex 才能在后续镜头、QA 和返修中继续使用它们。

十六、完整执行清单

原著与权利

[ ] 确认文本来源和改编、复制、传播权限。
[ ] 原稿只读保全，记录编码和 SHA-256。
[ ] 生成 UTF-8 派生文本、章节单元、索引和质量报告。

改编与分镜

[ ] 在 source_map.json 登记本话来源范围。
[ ] 先写剧情节拍、情绪曲线和结尾悬念。
[ ] 每格记录来源、角色、地点、景别、动作、对白、旁白和状态。
[ ] 确认不是机械地“一章对应一话”。

视觉与生图

[ ] 建立系列风格圣经和角色、地点、怪物参考图。
[ ] 为每张输入图说明它控制什么。
[ ] 生图阶段禁止生成文字。
[ ] 先 dry-run，再审近景人物和多人场景两张关键帧。
[ ] final 批处理开启 manifest、--skip-existing 和受控并发。

QA、返修与交付

[ ] 逐格检查身份、时序、空间、动作、文字和移动端可读性。
[ ] 返修任务只改问题区域，并声明保留项。
[ ] 布局文件明确引用批准版本，不依赖“最新文件”猜测。
[ ] 输出 1080px 宽、sRGB PNG 母版。
[ ] 切片不超过平台高度限制，不切断文字和镜头。
[ ] 保存 QA 清单、返修日志和生产报告。

十七、这套方法最值得保留的五条原则

原文、改编、视觉、生成、排版是五个不同的数据层。 不要让一条超长提示词承担所有职责。
参考图必须有控制范围。 “上传了图片”不等于模型知道该继承谁的什么特征。
连续性需要状态，不只需要记忆。 当前人物、道具、伤痕、环境变化都应该结构化记录。
文字后置。 画面和排版分离，才有可修改的中文对白、旁白和平台版本。
失败是流程的一部分。 manifest、锁、--skip-existing、局部返修和恢复任务决定了项目能否从样片走向连载。

今天可以试

选一个短篇或单章，先建立只读原稿、规范化文本和来源索引，不急着生图。
把一章拆成 4 至 6 个剧情节拍，再为每个节拍安排镜头，而不是按段落平均切分。
先生成一张人物近景和一张多人场景关键帧，用它们验证身份、构图和参考图映射。
把 characters_present、props_required、props_forbidden 和 preserve 写进 JSON，再开始批量任务。

结语

用 Codex + image2 做小说条漫，真正的难点从来不是“能不能生成一张好看的图”，而是能不能把几十万字原著变成一套长期保持事实、人物和视觉一致的生产系统。

当原著有不可变来源层，改编有清楚映射，角色有批准参考，镜头有状态，生图有可恢复任务，返修有记录，文字有独立排版层时，AI 才不再只是灵感工具，而会成为可以协作、可以交付的制作能力。

《天魔神谭》目前完成的 72 个批准镜头，只是这条生产线的前四次运行。接下来每增加一话，最有价值的资产并不是某一张图，而是不断变厚的角色圣经、地点圣经、镜头状态、返修经验和可复用脚本。它们会让下一话比上一话更稳定，也让一部长篇小说真正具备被持续改编成条漫的可能。

项目案例数据口径：本文统计来自项目 README.md、config/project.json、EP000-EP003 的 source_map.json、storyboard.json、jobs/*.jsonl、layout/layout.json、qa/revision-log.json 与 qa/production-report.json。统计截至 2026 年 7 月 19 日。

编辑说明

本文是对公开来源的归纳与实践建议，不直接代表原作者立场。涉及产品能力、价格和实时信息时，请以官方最新页面为准。