别闷头重构：从PlotPilot里找到3个AI小说生成器落地优化方案

上周做 AI 小说生成器的长文连载迭代，被两个老问题卡住：写到 10 章以上主角人设就崩，运营侧每天还收十几条「生成任务卡半天没反应」的反馈。我本想直接闷头做全量重构，同事提醒可以参考开源的 PlotPilot，于是拉了两边仓库的完整代码做了一遍审查，最后不仅找到自研项目的核心短板，还整理出两周就能落地的优化方案。

两套架构到底差在哪

对比的两个项目定位差得远：PlotPilot 是主打可视化剧情编排的开源项目，把大纲拆解、角色设定、章节生成做成低代码工作流，社区活跃，很多中小团队在用；自研的 novel-阶跃星辰 走垂直场景深度定制，支持多模态输入（上传参考图、设定集）和长文连载自动续写，已经跑通部分商业化。两边都基于大模型 API 做生成，但底层模块划分、数据流转逻辑差异极大——所以我这次的目标从来不是照搬全量架构，而是把 PlotPilot 已验证的成熟思路嫁接到自己的场景里，先解决最痛的点。

从源码里挖出的三个短板

扫完整量代码，我梳理出三个投入小、收益极高的优化点。

剧情一致性校验缺失。PlotPilot 内置了专门的角色状态追踪器，每次生成新章节前会先拉取历史章节里该角色的所有属性、行为记录，整理成结构化前缀注入 prompt，从底层避免设定冲突。我之前的实现是直接把前 3 章原文塞进 prompt，长文到 10 章以上就设定冲突——之前测过 10 章长度的用例，角色设定崩塌率高达 32%。

运营侧异常处理能力弱。PlotPilot 给所有生成请求加了幂等键 + 分级重试，用户提交后如果 API 超时，会自动切换备用模型重试，不丢任务。我之前的实现是请求失败就全部返回给用户手动重试，运营侧每周要处理近 50 条相关投诉，占到了所有用户反馈的 40%。

架构扩展性不足。PlotPilot 的生成引擎和提示词模板完全解耦，换模型或调 prompt 只改配置文件；我之前把提示词硬编码在生成逻辑里，上次要适配新的阶跃模型，前后改了 3 天才跑通。

按优先级落地，没动一行核心架构

我整理出三档改造计划，全程不碰全量重构，都是基于现有代码的增量优化：

• P0（最快见效，2 天）：直接复用 PlotPilot 的角色状态追踪逻辑，在 prompt 组装阶段加一步历史信息抽取，不用改核心生成逻辑。改完测试用例的角色设定崩塌率直接降到 5%，上线后关于人设崩塌的反馈减少了 70%。
• P1（中期补强，1 周）：参考 PlotPilot 的幂等 + 重试机制，给所有生成任务加唯一 ID，配置三级超时重试规则，超时后自动切换备用模型。改完运营侧的生成失败投诉直接降了 80%。
• P2（长期基建，2 周）：把硬编码的提示词逻辑抽成配置化模板，和生成引擎解耦，后续适配新模型、做 A/B 测试的效率能提升至少一倍。

做 AI 原生应用迭代，完全没必要一上来就追求全量重构。先把代码审查做细，找高投入产出比的点先改，效率会高得多。跨项目参考的时候也别只盯着表面功能，多去看底层模块的设计思路——你踩过的坑，别人大概率在开源项目里已经踩过一遍了，直接复用成熟实现，能省下几个月的试错时间。