Manga2Novel 是我做过的一个很有意思的垂直 AI 工具。它的目标很明确：把漫画图片转换成连续小说。
这个项目不是简单地把图片丢给模型，然后等一个结果。真正做起来以后，我发现“漫画转小说”其实是一条很长的流程：图片要按顺序整理，内容要逐页分析，剧情要综合，章节要写作，最后还可能需要整本润色。
所以 Manga2Novel 对我来说，最大的价值不是“它能生成文字”，而是它让我学会把一个复杂的 AI 创作任务拆成多个可控制、可重试、可编辑的阶段。
为什么选择纯前端
Manga2Novel 是一个纯前端部署的工具。它使用 Next.js、React、TypeScript 和 Tailwind，最终可以构建成适合 GitHub Pages 的静态站点。
这个架构有一个明确取舍：项目本身不提供后端中转，浏览器直接请求用户配置的模型接口。
这样做的好处是部署简单，图片预处理和任务状态都可以在浏览器里完成。用户的 API Key 保存在本地浏览器，并通过 AES-GCM 加密后写入 LocalStorage。图片和提示词不会先经过项目服务器，而是直接到达用户选择的模型服务商。
当然，这也意味着用户需要自己确认模型服务商的隐私策略和接口稳定性。这个取舍让我更清楚地理解了前端工具的边界：纯前端可以很轻，但不能假装自己解决了所有数据安全问题。
把流程拆开
这个项目最核心的地方，是任务编排。
我没有把漫画转小说做成“一键请求一次模型”。相反，它被拆成了多个阶段：
- 上传多张图片或整个文件夹；
- 本地压缩图片，保留阅读顺序；
- 逐页分析每张漫画图；
- 分块综合剧情；
- 整书综合；
- 章节写作；
- 可选的全书润色；
- 最后导出 TXT 或 MD。
项目还支持两种主流程：一种是更稳的“逐页分析”，另一种是链路更短的“直综合写作”。前者中间结构更完整，适合排查和手动修正；后者更依赖整书综合质量，适合希望减少中间步骤的场景。
这让我意识到，AI 应用的稳定性很多时候不是靠一个更长的 Prompt 解决的，而是靠流程拆解解决的。
控制权很重要
做这个工具时，我一直在想一个问题：如果模型中间某一步失败了，用户是不是只能从头再来？
如果答案是“是”，那这个工具就很难真正好用。因为漫画转小说可能涉及几十张甚至上百张图片，一次失败就重跑整本，成本太高。
所以项目支持自动重试、暂停、继续、跳过当前项、重试当前项、重置任务。用户还可以编辑逐页分析、整书综合、写作前统稿、章节正文和最终润色稿。
这个设计让我明白，AI 工具不应该把用户变成旁观者。模型生成只是其中一步，用户应该能看到中间结果，修正中间结果，然后继续往下跑。
多模型和多阶段配置
Manga2Novel 支持 OpenAI、OpenRouter、SiliconFlow、DeepSeek、任意 OpenAI 兼容接口，也支持 Google Gemini 原生接口。
更重要的是，它支持按阶段切换接口和模型。比如图片分析阶段可以优先使用支持视觉输入的模型，文本写作阶段可以切到更擅长长文写作的模型。章节写作时也可以选择是否附带场景图，如果遇到上下文过大、空回或兼容接口不稳定，可以改成纯文本写作。
这让我更清楚地看到：不同阶段对模型能力的要求不一样。视觉理解、剧情综合、长文写作、润色，它们不是同一个问题。
我学到的东西
第一，我学到垂直场景比通用聊天更需要流程设计。漫画转小说不是一句“请帮我改写”就能解决的，它需要顺序、结构、中间状态和可恢复能力。
第二，我学到前端也可以承担复杂任务。图片压缩、拖拽排序、任务状态、实时预览、导出、加密存储，这些都可以在浏览器里完成。只要边界清楚，纯前端工具也能做得很完整。
第三，我学到 AI 工具要给用户留修改空间。越是长流程任务，越不能把所有中间过程藏起来。用户能编辑、重试、续跑，工具才有真正的可用性。
回头看
Manga2Novel 是我从“调用模型”走向“编排模型”的一次练习。
它让我理解，一个垂直 AI 工具的价值不只是生成结果，而是把不稳定、不可控的生成过程变成一条相对清晰、可观察、可修正的工作流。
这也是我做 AI 项目过程中非常重要的一次成长。