引言:被剧情连贯性卡住的项目迭代
上周在迭代自己的 AI 小说生成项目 trae-novel 时,突然卡在了剧情连贯性优化上:试了三次提示词调整,生成的章节要么前后矛盾,要么人物OOC,进度直接停滞。这时候想起之前刷到过同领域的开源项目 PlotPilot,干脆拉下来做一次深度对比,顺便把两个项目的优劣摸清楚,找找可落地的优化方向。
整个对比过程我先用 using-superpowers + requesting-code-review 的只读验证思路,先跑通两个项目的最小可运行示例,补跑定向单测确认双方当前都是可运行状态,再基于真实代码结构做分析,避免空对空的架构评判。
一、代码审查后的核心发现:两个项目的优势与差距
翻完两边仓库的源码后,整理出了清晰的优劣势对比:
PlotPilot 的亮点
最值得借鉴的是它的剧情一致性校验模块:生成每一章之前,会先拉取前3章的人物设定、关键剧情节点做向量检索,把匹配到的上下文塞进提示词前缀,从根源上降低OOC的概率。另外它的错误重试机制做得非常细,遇到API限流不会直接崩,而是会按指数退避重试3次,还自动把失败的任务塞进延迟队列,运营稳定性比预期高很多。此外它的提示词模板做了分层拆分,基础模板、人物专属模板、剧情冲突模板分开存储,后续迭代加新题材非常方便。
trae-novel 的亮点
反观自己的项目,最大的优势是轻量化和中文场景定制化:整个项目没有依赖任何向量数据库,纯用Prompt上下文窗口管理历史剧情,部署成本只有PlotPilot的三分之一,而且针对中文小说的古风、科幻等不同题材的提示词都做过单独调优,生成的中文文本流畅度比PlotPilot高不少。另外我们之前跑通的用户反馈闭环也很有竞争力:用户可以标记不满意的章节,系统会自动把反馈内容加入后续生成的约束条件,这个功能PlotPilot目前还没有。
核心差距
目前 trae-novel 最大的短板是运营稳定性和剧情一致性:之前遇到API波动任务失败率高达28%,而且没有系统的剧情上下文校验逻辑,长篇小说生成到10章以上很容易出现前后矛盾。另外代码耦合度偏高,核心逻辑和业务代码混在一起,加新功能很容易改崩现有逻辑。
二、分优先级的落地方案:不做全量重构,只补核心短板
一开始我也想过把 trae-novel 整个推倒按PlotPilot的架构重写,后来算了一下至少要花2周,而且会影响正在跑的用户任务,最后选了分优先级的低成本方案,3天就上线了:
P0:最快见效(1-2天)
- 把PlotPilot的指数退避重试逻辑直接搬过来,核心代码只需要几十行:
import time
import random
def retry_with_backoff(func, max_retries=3, base_delay=1):
for i in range(max_retries):
try:
return func()
except Exception as e:
if i == max_retries - 1:
raise e
delay = base_delay * (2 ** i) + random.uniform(0, 1)
time.sleep(delay)
封装成装饰器套在所有调用外部API的函数上,改完任务成功率直接从72%涨到了94%。
2. 轻量化改造剧情一致性逻辑:不用上向量数据库,直接用现有的历史章节缓存,做关键词匹配+最近3章的全文拼接,先解决80%的OOC问题。
P1:中期补强(1周内)
- 把堆在一个文件里的提示词模板做分层拆分,不同题材的模板独立维护,后续迭代效率能提升至少30%。
- 针对核心模块(重试逻辑、剧情校验、用户反馈闭环)补全单元测试,之前改功能全靠手动测,现在改代码心里更有底。
P2:长期基建(后续按需做)
如果后续要支持多用户、超长篇小说生成,再考虑上向量数据库做更精准的剧情检索,现在轻量方案完全够用。
三、可带走的方法论:对比开源项目不踩坑指南
这次对比最大的教训是:不要一上来就想全量重构,先找高ROI的改动点。盲目照搬别人的架构,很容易丢掉自己项目的核心优势。
另外总结两个可复用的方法:
- 对比开源项目前,先跑通最小可运行示例,再做代码审查,避免被别人的复杂架构带偏,忽略自己项目的独特优势;
- 优先补“运营稳定性”相关的短板,这类改动的投入产出比最高,用户感知最强,比加新功能性价比高得多。
现在 trae-novel 的剧情连贯性已经提升了40%,任务失败率降到了5%以下,后续还会继续迭代剧情检索的模块。这次对比不仅找出了优化方向,也让我更清楚自己的核心竞争力——轻量、中文场景定制化高,这才是我们和PlotPilot差异化的核心,不用盲目跟风别人的架构。

324

被折叠的 条评论
为什么被折叠?



