AI 写长篇小说，为什么写到 40 章就崩？我们用一个 8 环节状态机智能体糖糖写作做了 260 章的实测

一、用通用大模型写长篇小说，普遍现象是：前 10 章尚可，20 章勉强，40 章开始散架。

常见的归因是"模型上下文不够长""换个更强的模型"。但我把 40 章之后的失败样本逐条拆开，发现三类问题都不属于推理能力范畴：1.进度丢失， 模型不知道"现在该写什么"，只会顺着往下编，状态管理问题；2.风格漂移， 前 10 章是冷硬悬疑，第 30 章变成甜宠，规则注入问题；3.事实冲突，人设前后矛盾、埋伏笔忘收、章号错乱、金额物品前后不一致，外部记忆问题。

这三类问题，换更强的模型、写更长的提示词都解决不了，因为它们不属于"生成质量"问题，属于"流程"问题。

二、方案：把三样东西从模型手里拿走

2.1 结构：8 环节状态机

把"一次写一本"改成"一步一步走"，每个环节有明确产出，上一环的产出**强制注入**下一环：

关键设计：状态机记录"当前处于哪个环节"，每一环的字段有独立存储位，缺上一环字段则下一环不启动。

2.2 记忆：四本结构化台账

不把前文全塞进上下文，而是按当前环节需要什么就取什么：

这样做的直接好处：上下文长度从"随章数线性增长"变成"按需常量级"。

2.3 约束：规则卡分层加载

不把全部写作要求一次性塞进提示词（写到十几万字早被冲淡），而是按环节只加载当前环节需要的规则。

实测：分层加载后，单次请求的 system prompt 体积下降约 60%，而风格一致性反而提升（因为当前环节的约束没有被无关规则稀释）。

三、实测条件与判据（★这是本文最有价值的部分）

3.1 测试条件（必须公开，否则数据无意义）

3.2 判据（先说清楚什么算"崩"）

"崩"的定义是三条同时成立：

1. 人物一致性失败：主角行为与人物卡冲突（例：设定"不会武功"却在打斗中使出轻功）

2. 事实冲突：前文已定的事实被推翻（例：第 5 章说"父亲已死"，第 60 章父亲出场）

3. 伏笔断线：埋设超过 30 章仍未回收，且后文无呼应

未达到这三条的，不算崩，只算"质量波动"。

3.3 数据

上下文开销这一项是最关键的验证： 如果做到第 260 章时上下文还在 6-7 万字符，说明记忆机制确实把"线性增长"变成了"常量级"，而且99%以上都是缓存命中极大减低token费用。

四、失败案例

案例 1：DEEPEN 环节字段缺失，导致反复重试

现象：深化构思环节要求产出"故事核因果骨架四问"（谁被困在两难中 / 被什么逼 / 不得不做什么 / 不做会失去什么），模型连续 3 次未按字面标签输出。

原因：任务指令只给了语义描述，没有给出这三个字面标签，而校验按字面匹配。这是"语义写对了、字面判缺"的错配。

处理：改为"只打回第 1 次，第 2 次起放行"，并补全指令里的字面标签。**代价：单次多花 3-5 分钟。**

案例 2：上游 524/504 超时

现象：长文本生成时上游偶发 524/504，2 天共 3 次。

原因：单次请求 token 量大 + 上游负载波动。

处理：超时重试。

五、这套方案的边界

不适合的场景：

写非小说文体（公文/论文/营销文案）的——四层结构是为长篇叙事设计的，对其它文体反而添乱

已知未解决问题：

- 跨线（换题材）时台账需要清空重建，目前是手动

六、结论

40 章之后崩，不是模型能力问题，是流程问题。把状态管理、规则约束、事实记忆这三件事从模型手里拿走，交给程序侧的流程与台账，可以让长篇连续推进的稳定性显著提升，对此测评下来糖糖写作在流程控制上已经具备小说构思的思考模型。