脑洞漫工厂

概述

输入一个主题，AI 自动完成故事策划、漫画分镜、Q版图片生成与动画视频制作，让创意一键变成漫画短视频。

使用示例与实际效果见 [README](README.md)。

运行环境

优先复用宿主Agent自带或当前可用的Python 3.10+解释器与环境，不要求用户安装uv或另建一套环境。先检查本次任务所需依赖，只补缺少的包；安装与运行使用同一个解释器及其包管理方式。下文命令中的 python/python3 替换为实际解释器路径。宿主已有uv时可选用，但不是启动前提。只有制作视频时需要FFmpeg和ffprobe。

这是同一个漫画制作 skill，按以下步骤组织：第一步生成内容；第二步提取跨图复用资产并生成参考图；第三步组合逐张提示词并生成漫画画面，整理成可直接交付的图片集；第四步按需用 ffmpeg 合成带 BGM 的视频。第三步的提示词编写与生图是同一步的内部环节，开发调试可以拆开，不再称为第三步和第四步。第二、三步默认包含各自的生图；仅当用户明确要求调试或暂停在 prompt 时，才只交文字。

自动提取的资产库用于保持多张图的一致性，只为实际出现在至少两张不同内容图里的个人、群像、场景和道具另行生成参考图；单张元素留在该张描述里。用户明确提供的IP角色图作为输入素材直接复用，即使仅出场一次也遵守指定形象，不为满足门槛虚增出场或另画一套设定图。

风格独立存放于 [风格配置](references/styles.json)，当前默认 2D Q版漫画。资产描述与参考图版式不固定画风；拼接最终生成 prompt 时，读取本主题选定的 style_id 对应风格。扩展风格只新增配置，不重写资产描述或复制一套提取规则。

用户指定人物与IP角色

• 用户给了角色参考图、名字、人设或角色分工时，先使用这些信息安排内容；只有未指定的配角才自行设计。不把用户IP仅当作画风样本，也不让多个剧情人物都变成同一个IP。
• 同一个IP可以担任主角、提问者、讲解员或指定剧情角色，依用户用途安排；已有文案时按稳定角色ID绑定，不因换参考图擅改原稿对白或人物关系。只有多个人物对应关系确实无法判断时才询问。
• 参考图的物种、脸部、标志、配色和身体比例优先于默认Q版设定。表情、姿势可随剧情变化；换装和造型改动遵从用户明确要求。人物身份与独立画风分别处理，不用默认头身比重塑用户IP。
• 用户有现成形象但尚未给图时，可先写内容；进入视觉阶段前取得其参考图或明确的文字设计要求，不声称凭名字就已复用其私有形象。具体导入与复用规则见 [用户提供的角色参考](references/asset-extraction.md#用户提供的角色参考)。

按当前任务执行

• 用户给主题、要求创作或修改文案：执行下文第一阶段。
• 用户要求执行第二步：读取 [第二阶段：资产提取与参考图生成](references/asset-extraction.md)，以用户选定的内容版本为唯一剧情来源，完成提取、prompt拼接和参考图生成。
• 用户要求第三步或根据参考图生成漫画画面：读取 [第三步：画面组合与参考图绑定](references/shot-composition.md)，使用第一步内容和第二步已保存的实际图片，完成逐张提示词及生成。当前只要求编写或检查提示词时，停在提示词交付，不调用生图。
• 用户只要图片/图片集：执行到第三步并完成图片集整理后交付，不进入视频步骤，不检查或索取BGM。图片集始终独立可用，images/comic/ 只放按剧情编号、命名的当前通过检查的图片，不含v1/v2、重复图、草稿或参考资产；未采用版本移入 images/not-selected/，不删除。
• 用户要求第四步、合成视频或添加 BGM：读取 [第四步：视频与配乐](references/video-composition.md)，默认每张约 3.5 秒、0.5 秒交叉淡化，不推拉；转场与图片运动独立配置，保留完整漫画文字和既定总时长。BGM 优先用户指定文件夹，用户提供的曲库优先于默认的热歌偏好；没有指定曲库时再使用平台常用热歌及已配置的实际音源。无音源时经用户确认导出待平台加音乐版，不声称已带 BGM。
• 用户明确说“只提取 prompt、检查后再出图”时，才停在文字；该暂停仅用于当次调试，用户之后要求正常执行第二步或生图时即恢复生成，不沿用为永久限制。
• 用户要求进入生图时，按下方“生图能力选择”执行；确定接入顺序本身不代表本轮已要求出图。
• 面向最终用户可以在授权范围内衔接各步骤；开发阶段的逐步验收不等于最终用户必须反复确认。不把尚未接通的供应商 API 宣称为已实现。

生图能力选择

顺序固定为：已有 API 凭证 → 宿主 agent 的生图技能和工具 → 器灵浏览器授权生图 → 确实不可用时说明缺口。 用户明确选择器灵时可直接使用。

1. 先用 API。 用户已要求生图，且有明确配置的生图 API 时，优先按该 API 的接口或既有适配脚本执行。使用指定服务、模型、凭证引用与参数，不硬编码供应商，不擅自换模型。只检查本项目或用户指定位置的配置，不搜集其他项目的密钥，不把真实凭证放进 skill、prompt、输出或日志。
2. 没有 API 配置时，再检查宿主能力。 查看当前 agent 提供的技能和工具。若有 imagegen 等生图技能，读取其规则，并确认有实际可调用的工具后使用。技能文件本身不等于工具能力；不绑定某台电脑的绝对路径，也不要求没有 API 的用户先补 API Key 才检查宿主能力。
3. 两者都没有时使用器灵授权。 读取 [器灵授权与图片通道](references/qiling-api.md)，默认平台 https://toolsoul.daniu7.cn、模型 doubao-seedream-5-0-flash，用官方SDK打开浏览器让用户登录并确认API Key授权；agent不能代用户批准。完成后作为API通道复用第二、三步任务。不因配置中有默认地址就认为已经授权，也不因宿主缺少imagegen便直接停止。
4. 器灵也不可用时说明缺口。 用户拒绝授权、授权过期、依赖/安全凭据库/网络不可用时保留内容与prompt，说明需要解决的具体条件；不伪造授权或图片，不自动换模型/账户或要求用户把Key贴到会话里。

“没有配置 API”与“API 请求失败”分开处理：已配置 API 的认证失败、额度不足或请求异常，先按该服务的失败信息处理，不自动改用宿主工具。尤其结果不明时，不跨通道重复提交同一任务。

各生图通道使用相同的风格选择、已拼接prompt、用户IP与跨图资产ID。器灵实现位于 scripts/qiling_images.py，API Key授权与生图配置见 [器灵通道](references/qiling-api.md)。参考图实际生成后保存在本主题目录，后续保持一致性时实际传图，不仅复述描述。已有其他供应商配置继续按其既有适配方式执行。

第二、三步共用 scripts/image_jobs.py：prepare --stage 2|3 --topic 主题目录 编译任务，宿主按选定路由执行，record --source 生成PNG路径 --route 通道名称 从标准输入读取对应任务并保存结果。用户IP用 import-character 导入后直接复用，第二步不再为它生成新角色。其他第二步任务是 text_to_image，reference_images 为空；第三步是 image_to_image，该数组必须按图号传入实际图片。这里的图生图是使用参考图生成新画面，不要求对单张参考图做原地编辑。该脚本不调用任何供应商，不读取密钥。

生成结果先保存在 images/candidates/assets|comic/，检查后以 review: "passed" 标记，未通过的图片放入 images/not-selected/。阶段完成时执行 image_jobs.py finalize --stage 2|3 --topic 主题目录：只选择通过检查的当前版本，移动未采用文件、同步引用路径。第三步最终图片为 001-标题.png 等，交付 images/comic/、images/comic.zip 和外置预览；不复制一份混有工作文件的整目录给用户，也不靠删除重复画面来凑齐数量。

宿主有参考图数量上限时，prepare可加 --max-reference-images 数量，以输入素材板保留全部原图并同步转换图号；这只是工具适配，不改变API的逐图资产协议。只有此项输入包装需要已有Pillow，不影响普通任务编译与保存。

以下为第一阶段规则。第二、三步通过已有API、宿主工具或器灵授权通道生图；第四步使用本地ffmpeg。器灵客户端只在选用该通道时运行，不改变公众号登录/发布脚本或其他项目凭证。

输入与默认值

• 必填：主题。用户没有给出主题时，只询问“你想做什么主题的动漫漫画？”，不要自行编造主题。
• 可选：画面数量、受众、题材、语气、指定IP角色的参考图/名字/人设/剧情分工，以及结局偏好。只给主题也能开始，其他内容按主题合理选择并在开头简要说明。
• 默认 12 张画面，通常为 10–20 张。用户指定的正整数数量优先，包括区间以外的数量；这里的“张”指一张独立图片对应的一个画面，不是一页多格漫画。
• 用户给的是范围时，在范围内选定具体数量并说明。只有零、负数、小数或无法确定含义的数量需要澄清。
• 默认中文、适合一般读者阅读的动漫叙事。用户提供真实素材时依照素材改编；涉及真实事实而没有依据时，不把虚构情节写成事实。
• 每个主题独立创作。只使用本主题、用户明确指定的参考及为此核实的事实，不带入其他会话的任务、账号、代码或私有数据；保存时使用独立主题目录。

先完成解释，再拆画面

先辨别主题类型。用户问“为什么”“如何”“是真的吗”等知识问题时，以解释问题为主线，不默认改写为一场完整冒险。用户明确要故事时，再以人物目标、阻碍、行动、变化组织剧情。

知识问题先完成以下推理，确认成立后再分配画面：

1. 问题与直觉：读者具体困惑什么，为什么会产生这个疑问？保留原问题的矛盾，不通过换一个更容易的话题绕开它。
2. 前提与答案：检查“必然”“所有”等前提，用简短说明纠正过度概括，然后继续回答前提中合理的部分。写出能直接回应原问题的核心答案。
3. 因果链：说明现状或限制如何造成问题，采取某行动如何改变这些条件，改变后为什么有助于目标。不能从“有这个问题”直接跳到“做这件事”，省略作用机制。
4. 替代选择与边界：比较读者直觉中的做法；说明为什么有时不用它，以及在什么条件下它反而更好。需要时回应最强的反问，不机械堆砌例外。
5. 中间目标与最终目标：例如“拖延进攻”不等于“解决缺粮”；解释争取的时间准备用来等外援、补充物资还是改变其他条件。不要把局部成功写成问题已经解决。

涉及历史等事实时核实关键论据，区分原始资料支持的结论、合理推演和虚构演示。不用编造的数字、战役或必胜结果填补逻辑缺口。参考图只用于理解表达方式，不照搬其文案或把其中观点当作已核实事实。

拆成漫画内容

• 每张承担一个明确的解释任务，或一个必要的故事推进任务。先分配论点，再设计画面；不为凑数量增加无关支线和重复打斗。
• 科普漫画以旁白承载解释，人物对白用于提问、反问或把抽象问题落到具体情境；对白和旁白互补，不重复朗读同一个结论。
• 结尾直接回答开头的问题，给出作用机制和适用边界。只写“主角懂了”“要随机应变”“都是为了胜利”不足以收束知识问题。
• 通常使用 1–3 名主要人物和少量场景。人物、地点、关键物件称呼一致。每张画面以一个可画出的瞬间为主，避免一幅图塞进多个先后动作。
• 画面内容通常 30–70 字；对白和旁白合计通常控制在 40–90 字，宁可删修饰也不删关键因果。用户调整数量时，重分配信息密度，不直接截断解释。
• 不提前撰写外观设定卡、人物/场景/道具提示词、镜头参数或图像模型参数。

白话润色：人物怎么开口

完成因果解释后，单独改一遍对白与旁白。参考 Humanizer、Humanizer-zh 和 Stop Slop 的编辑方法，按中文科普漫画的文体使用，不做词语替换游戏。

• 让人物对眼前的事说话。 新兵会问粮够不够、门开不开、敌人怎么没来；不要让他替作者说“收益是否值得承担”“局部成果如何转化”。守将回答他正在担心的事，不轮流背论点。
• 分清两个人的口气。 新兵可以急、怕、嘴硬或想当然；守将话可以短，有判断、有指令，必要时才解释。他们都能说日常白话，不需要装成古文，也不必每张都一问一答。
• 抽象解释主要交给旁白。 台词中出现“提供防御优势”“创造机会”“实际转机”等概括时，先换成具体人、物、动作。确需保留的条件放在自然的讲解句里，不给每个人都套一层限定语。
• 不强凑警句。 删掉重复上一句的顿悟、排比、对仗和段尾升华。结尾仍须回答原问题，但不必让新兵说“我明白了”或复述全文提纲。
• 对白与画面互相接得上。 当人物指着粮车说话，读者应看得见粮车；不要为了自然感补造事实、战果、数字、亲历或引文。虚构演示可调整动作和表情，不能借此改动科普结论。
• 参考样本的说话习惯。 用户给漫画参考时，借鉴句长、停顿、人物关系和幽默程度；不复制原句，不因为参考中出现脏话就给所有人物加脏话。
• 口语仍然要准。 “有机会补进粮”不能改成“粮肯定进得来”。真实反问、必要条件和有意义的对比可以保留，不因命中某个句式就机械删除。
• 允许轻重和留白。 别把每张都写成同样长的两句对白；顺口的原句可以留下。语气词、网络梗、口头禅和夸张反应只在人物确实需要时使用。

针对本类漫画的示例（仅示范口气，不作为其他主题的固定台词）：

这些例子改变的是一句话在场景中的说法，不是完整论证的替代品；涉及粮食、外援、退路等解释，仍须在相邻文案中说清。

输出

先给标题、画面数量和基调。知识主题附上核心问题、核心答案（50–100 字）和一行因果链，便于用户先审逻辑；故事主题给不超过 150 字的梗概。随后按序号输出恰好 N 张内容：

### 第 1 张
本张作用：提出疑问、解释某个原因、回应反问或收束答案等具体任务。
地点：具体地点名称
出场人物：人物称呼，无人时写“无”
画面内容：一个可画出的瞬间。
对白：人物：一句简短对白。没有则写“无”。
旁白：本张的讲解文案。没有则写“无”。

地点、人物字段仅记录本张剧情中的名称，不展开第二阶段的提取工作。

输出前做三次阅读：

1. 只读旁白与对白：不看人物成长和画面，仍能复述“为什么会这样、行动如何起作用、什么时候不成立”；检查是否以列举理由代替因果解释。
2. 逐张检查画面：画面确实帮助理解本张论点；数量与编号完整，关键名词一致；没有把完成过程、结尾或必要前提删掉来迎合数量。
3. 只读角色台词，再对照旁白：每个人为什么在此时说这句话？像人说话，还是像作者在念提纲？删改后是否丢了前提、否定、范围或因果？内部完成改写与复核，只交付成稿，不附“人味评分”或检测器通过率。

科普稿如果只讲成“一次行动成功了”的故事，或结尾没有正面回答原问题，先修正逻辑再交付。史实依据放在正文之后，不把查证过程混进漫画文案。

用户调整数量时，交付完整的新版本，默认保留既定主题、核心结论与用户认可的人物；用户要求改变时再调整。用户反馈逻辑缺失时，先修改解释链，再修改逐张内容。

当前开发中，完成用户指定阶段即停止。第二、三、四步按上方入口执行；只有实际生成并保存的图片、音频和视频才算完成，不把规划或提示词当作最终媒体。

编辑方法参考

2026-10-21 通过 find-skills 检索并阅读以下项目的实际技能文件，改写为上述漫画对白规则。当前 skill 自带这些规则，不依赖另行安装或外部改写服务。

• Humanizer-zh：保留语义与证据强度、贴合中文文体、按上下文处理模板表达。
• Humanizer：识别结构上的重复和空洞收尾，改写后再通读检查声音与信息。
• Stop Slop：删铺垫、写具体动作、调整机械节奏。本 skill 不照搬“禁用所有副词/被动句”等绝对禁令。