AI写长篇小说为什么30章必崩?工程化解法详解
前言
你有没有试过用ChatGPT写小说?
前几章写得挺好,角色鲜明、情节紧凑。但写到30章左右,突然发现:主角的妹妹名字变了,第5章埋的伏笔忘了回收,节奏从爽文变成了流水账,打脸套路千篇一律......
这不是你的问题,也不是模型的问题。是流程的问题。
过去三个月,我作为一个写了7年代码的程序员,用CI/CD的思维重构了AI写作流程,做出了一套叫NovelOps的工具,成功跑通了270章连载小说。这篇文章是我踩了三个月坑之后的完整技术总结。
不是理论空谈,是实际跑通过的工程方案。
三大崩溃点:AI为什么写到30章就废了
先说问题。这三个崩溃点不是偶发的,是结构性的------只要用AI写长篇,一定会遇到。
崩溃点一:一致性丢失------AI没有"记忆"
你写到第30章时,AI已经"忘了"第3章的设定:
- 第3章说主角"永远穿灰色连帽卫衣",第28章突然穿了"白色连衣裙"
- 第7章埋的伏笔,到第30章还没回收
- 第12章口头禅是"该是我的,一分不让",第25章变成了"我一定要赢"
- 第15章建立"不主动伤害无辜者"的人设,第27章为报复搞垮了无辜员工
为什么? 大语言模型的上下文窗口是有限的。即使你用128K上下文的模型,也无法在一次对话中塞入30章 × 1500字 = 4.5万字的正文+设定文档。当你开新对话写第30章时,模型对前29章的"记忆"完全依赖于你在提示词里喂给它的摘要------而摘要必然丢失细节。
这等于一个程序运行到第30个周期时,所有全局变量被重置了------程序当然会崩溃。
崩溃点二:节奏失控------从"爽文"变成"流水账"
- 前10章每3章一个小爽点,到20章后连续5章没有爽点
- 主角连续3章被虐没有反击,读者憋屈到弃书
- 章末没有钩子,读者看完这章没有点下一章的冲动
为什么? AI不懂得"节奏"是什么。你跟AI说"写一章爽文",它能写。但当你让它连续写30章时,它无法自动维护一个跨章节的"节奏曲线"。节奏是一组可量化的指标------张弛比、憋屈连续章数、爽点密度、温度档位------AI在写单章时不会考虑这些跨章指标。
没有节奏规划的AI写作,就像没有节拍器的演奏------前几个小节还行,后面越来越乱。
崩溃点三:套路重复------AI的"叙事形状"固化
- 每次打脸都是"主角说出证据 → 对方脸色一变 → 全场沉默"
- 每次情感场景都是"眼眶一红 → 深吸一口气 → 说了一句硬话"
- 反派反应永远是"脸色一变""嘴角抽搐""握紧了拳头"
为什么? 大语言模型有"叙事惯性"。模型在生成内容时,会倾向于重复它在训练数据中见过最多的模式。写多了之后,这些模板会在上下文中不断强化,导致后续生成越来越趋同。
这不是"写得不好"的问题,是"叙事形状固化"的问题。需要的是有意识的计划性失控。
三个崩溃点的共同点
都是"跨章"问题,不是"单章"问题。 AI写单章没问题,写多章就崩。
这是一个典型的工程问题 ,不是模型能力问题。一个工人单独做一天零件没问题,但你让他做100天的零件,如果不引入质检流程、标准规范、状态追踪,第30天的零件一定和第1天的不一样。
五个核心技术:用CI/CD思维重构写作流程
我是程序员出身,写了7年代码。当我发现AI写长篇的崩溃点和软件工程的经典问题高度相似时,我意识到可以用同样的方法论来解决:
| 软件工程问题 | AI写作对应问题 | 解法 |
|---|---|---|
| 代码质量不一致 | 章节质量不一致 | CI/CD流水线 + 质量门禁 |
| 状态丢失 | 一致性丢失 | 状态持久化(状态轨) |
| 代码重复 | 套路重复 | 代码审查 + 重构机制 |
| 测试覆盖不足 | 节奏/爽点不可量化 | 量化指标 + 自动检测 |
| 部署不可回滚 | 章节不可追溯 | 版本管理 + 状态快照 |
于是我花了3个月,做出了NovelOps------用CI/CD流水线的思路重构网文创作流程。
scss
全局规划(7步) → G1 状态加载 → THINK(章节构思) → DRAFT(正文生成) → G2-G7(6道门禁) → REVISE(退回重写) ↻ G8(人工确认) → 状态更新(15条轨)
↑ 每章循环,直到第270章 ↑
技术一:8级质量门禁
每一章写完都要过8道"安检",任何一级不通过就退回重写。借鉴CI/CD的**"fail fast"**原则------问题越早发现,修复成本越低。
| 门禁 | 名称 | 检查内容 | 不通过怎么办 |
|---|---|---|---|
| G1 | 状态加载 | 15条状态轨是否完整加载 | 阻断写作,修复状态文件 |
| G2 | 输入校验 | 大纲、人物卡、节奏卡是否齐备 | 补全缺失输入 |
| G3 | 大纲对齐 | 本章内容是否与大纲一致 | 退回重写,附偏离说明 |
| G4 | 人设一致性 | Soul Field铁律是否被违反 | 退回重写,标出违反项 |
| G5 | 节奏检查 | 张弛比、温度档位是否达标 | 退回修改,附修正建议 |
| G6 | 反AI味检测 | 句式重复率、词汇多样性等 | 退回修改,附超标项 |
| G7 | 伏笔管理 | 新伏笔/回收旧伏笔 | 更新伏笔登记表 |
| G8 | 人工确认 | 作者最终审核 | 通过→更新状态 / 驳回→退回 |
技术二:15条动态状态轨
解决"一致性丢失"的核心。15条状态轨相当于15张数据库表,每章写完后自动更新,写下一章时自动加载。
核心状态轨包括:
- 角色状态轨:位置、情绪、关系变化、已掌握信息
- 伏笔登记轨:伏笔编号、内容、计划回收章节、当前状态
- 语言指纹轨:口头禅、语气词、说话节奏
- 情感弧线轨:好感度数值变化曲线
- 已确立事实轨:正文中已写过的所有"硬事实"
python
# 每章写完后的状态更新流程
chapter_30.write() # AI生成正文
state_tracks.update(chapter_30) # 自动提取状态变更
# 15条轨自动更新
character_state.update() # 角色A从"愤怒"变为"冷静"
foreshadow.register() # 新埋伏笔#037,计划第45章回收
# 写第31章时
context = state_tracks.load(chapters_1_to_30) # 加载全部状态
chapter_31 = AI.generate(prompt + context) # 带着完整"记忆"写作
这等于给AI装了一个"外部记忆体"。就像程序运行时从数据库查询数据,而不是把整个数据库加载到内存。
技术三:量化反AI味检测
"AI味"不是玄学,是可量化的。我写了个 metrics.py 脚本,自动检测6项指标:
| 指标 | 阈值 | 超标后果 |
|---|---|---|
| 句式重复率 | ≤3次 | G6拦截 |
| 词汇多样性(TTR) | ≥0.45 | G6拦截 |
| AI高频词密度 | ≤5次/千字 | G6拦截 |
| 段落长度方差 | ≥80 | G6拦截 |
| 对话占比 | 30%-60% | 超出预警 |
| 情绪词密度 | ≤8次/千字 | G6拦截 |
"去AI味"不是一个主观判断,是一组客观指标。让"去AI味"从玄学变成工程。
技术四:270章节奏规划卡
写正文前,先生成270章逐章节奏标注。写正文时把当前章的节奏标注作为约束喂给AI:
makefile
章01-10: 张 张 弛 张 张 弛 张 张 弛 爆
规律:每3章1个小爽点(弛),每10章1个大爆点(爆)
憋屈不连续超2章
温度档位:冷(10-15%) / 温(20-25%) / 热(30-35%) / 爆(15-20%) / 极爆(5-10%)
铁律:不可连续5章以上同一温度档位;冷章后必须有热章跟进。
技术五:创意扰动机制
解决"套路重复"的核心。不是随机注入,而是计划性失控------在保证大纲方向不变的前提下,有意识地打破AI的叙事惯性。
触发条件:场景重复、钩子重复、情绪曲线重复、反派反应重复等8种
扰动动作:视角切换、意外插入、时间跳跃、信息反转、情绪错位、形式变异
AI的叙事惯性是"惯性",不是"错误"。套路之所以是套路,是因为它有效。你需要做的是在套路固化的时刻注入变化,让读者始终有"猜不到下一步"的新鲜感。
最终成果
用这套系统跑通了一本270章的职场大女主小说:
| 维度 | 数据 |
|---|---|
| 大纲 | 270章 / 9卷 |
| 人物 | 22个角色(含Soul Field铁律) |
| 伏笔 | 37个(全部登记管理) |
| 节奏卡 | 270章逐章标注 |
| 状态轨 | 15条自动更新 |
| 门禁 | 8级(G1-G7自动 + G8人工) |
270章,没崩。 角色一致、伏笔回收、节奏可控、套路不重复。不是因为用了更强的模型,是因为用了更完善的流程。
总结
AI写长篇的核心挑战,不是"让AI写得更好",而是**"让AI在第30章和第1章保持同样的质量标准"**。这需要的不是更强的模型,而是更完善的流程。
五个核心技术,每一个都借鉴了软件工程的成熟方法论:
- 8级质量门禁 ← CI/CD流水线
- 15条动态状态轨 ← 状态持久化
- 量化反AI味检测 ← 自动化测试
- 270章节奏规划卡 ← 项目规划
- 创意扰动机制 ← 代码重构
工具完全开源免费。如果你也在用AI写小说,也卡在"30章必崩"的瓶颈上,可以试试。
下一步
这篇文章是总览,接下来我会逐个拆解每个技术模块的详细设计。如果你感兴趣,可以关注后续更新。
有问题欢迎在评论区讨论,我会一一回复。
本文是「AI写作工程化」系列第1篇,共11篇。如果觉得有帮助,点个赞吧。