漫画生成流水线：风格工厂、Prompt 编译与多页阅读器

说明：本次草稿依据提交记录，未逐行核对实现。提交只写了做了什么，未给出每一处细节；查不到的，本文只讲思路，不补具体文件名、函数名与参数。

背景：难点在“成组”，不在“单张”

某 AI 日记应用是 AI 日记应用：先写日记、聊天，再把一天变成内容。漫画是其中最重的一环。单张图好看不难，难的是多页之间人物一致、画风稳定、叙事连贯。一次提交（2026-09-25）把这件事拆成三块：风格工厂、漫画生成系统、阅读器工作流。本文就按这三块讲。

风格工厂：把风格变成可注册的包

早期风格管理常很随意：一张参考图、一段写死在代码里的提示词。能跑，但改不动、复用不了。风格工厂要解决的，就是把风格从散落的描述变成可注册、可组合、可替换的包。

按提交记录，工厂包括 Prompt 编译器、注册表、像素风预设。注册表负责“有哪些风格”：每种风格是一个包，有自己的描述与约束；加风格是往表里加包，而不是改生成逻辑的分支。像素风预设就是其中的一个实例，证明机制不是空架子。

Prompt 编译器负责“风格怎么变成提示词”。它不画图，只把角色、场景、风格拼成结构稳定、可复现的提示词。同样的角色、场景与风格，拼出的结构应一致；换风格，只换风格那一段。通用模式可写成：

1
2
3

输入：角色描述 + 场景描述 + 风格包
编译：按固定模板拼接，先角色、再场景、再风格约束
输出：结构稳定的提示词，交给生图环节

模板的具体字段提交里没有给出，本文不编。关键是三点：模板存在、结构固定、风格可替换。

多页生成：规划、生成、成册

提交提到的流水线包括 planner、source、books、store 等概念。本文按其命名理解分工，未逐行核对实现。

规划是第一步：把一段日记拆成多页，每页讲什么、画面有什么、台词是什么。没有规划就直接画多页，结果往往各自为政。生成是第二步：按规划逐页生成，角色、场景、风格由编译器统一提供，目标是多页一致；某一页走样，应能重生成该页，而非整本推倒重来。成册是第三步：把页面组织成一本“书”，有顺序、封面、归属与状态，可以保存、再次打开、继续完善。

三段合起来就是“规划 → 生成 → 成册”。没有规划，多页没有叙事；没有成册，生成结果无处留存。

阅读器：时间线、风格过滤与统计

生成是上游，阅读才是用户接触到的部分。提交里的阅读器包括时间线导航、风格过滤、统计视图，分别对应三种需求：按时间找漫画、按画风找漫画、看整体创作情况。时间线与日记本身的组织方式一致；风格过滤的前提，是风格真的被注册和管理起来了；统计视图则服务于“作品积累”这个目标：漫画不是生成一次就消失的东西。

分享与解锁权益

一次提交（2026-10-18）与一次提交（2026-10-15）都提到漫画分享。分享的前提是先有“一本完整的漫画”；只有页面散落时，分享体验会碎。其中一次提交还提到 iOS 小组件、灵动岛与屏幕方向等打磨，说明漫画是与聊天、日记等模块一起演进的。

其中一次提交还提到“漫画 7 天解锁权益服务”。提交里没有给出具体规则，本文不展开。它在架构上的位置可以讲清：它不属于生成流水线，而属于“谁能看、能用多久”这一层。生成负责产出，权益负责控制访问，二者分开，生成逻辑才不会被权益规则污染。

已实现与规划中：必须分清

按提交记录可以确认：风格包工厂、Prompt 编译器、注册表、像素风预设、多页流水线、阅读器、分享、7 天解锁权益服务，这些概念都在提交里出现过。

但另有两份实证要同时摆出。第一，README 记载：漫画设置、日期与角色准备接口已存在，人物形象可以生成，但完整日记漫画的规划、生成、保存链路当时尚未完全接入。零件可能有了，端到端链路还没有完全接通。第二，文档《漫画生成、作品留存与电子册技术方案》记录了规划、生图、版本、浏览、制册的设计，但设计文档不代表功能已经实现。

因此，风格工厂与流水线的设计思路成立，部分能力已在提交里出现；但“从日记到成册漫画”的完整链路，在 README 记录的时间点上尚未完全接入。后续验证应以实际跑通一次完整链路为准，而非以提交标题或设计文档为准。