AI写小说到底怎么做—无限章写长篇小说教程

用 AI 写三千字短篇不难，难的是写到第三百章还不崩人设、不断伏笔、不丢时间线。这篇教程不谈“灵感”，只谈工程：把长篇小说拆成设定层、大纲层、章节层和记忆层，逐层控制上下文、设定漂移与大纲断层。文中所有机制均以「大作家AI写小说」的实际实现为例。
一、长篇小说为什么会“写崩”
短篇和长篇的差别，不是字数，而是状态量。短篇可以靠一次性提示词解决；长篇每一次生成都要回答同一个问题：模型此刻应该知道多少前文？常见的失败可以归为三类。

1. 上下文装不下
   模型的上下文窗口是有限资源。把全书正文一股脑塞进去，既昂贵又会稀释关键信息——越靠后的章节，早期设定越容易被“淹没”。反过来，只给最近一章，人物关系、伏笔、地理设定又会断档。

2. 设定漂移
   人物的口头禅、能力边界、伤势恢复、道具去向、势力关系，如果没有被显式记录，模型每一章都会重新“猜”。几十章之后，读者会发现主角的性格和第一章不是同一个人。

3. 大纲断层
   开书时写的大纲通常只覆盖前几十章。写到中途再临时想剧情，容易出现主线停滞、支线膨胀、节奏失衡。长篇需要的是可增量扩展的大纲结构，而不是一份写死的文档。

结论：AI 写长篇的稳定性，主要来自“数据组织方式”，而不是某一次提示词写得多漂亮。下面四层结构，就是围绕这三个问题设计的。
二、把小说拆成四层数据
在「大作家AI写小说」中，一本小说不是一段长文本，而是分层的结构化数据。写作时，系统按当前章节的需要，从各层抽取内容组装成提示词。

长篇小说系统的四层数据与本地存储对应关系
层级 内容 本地存储 解决的问题
设定层 主线、结局规划、人物弧光、世界观、核心伏笔、人物卡与设定条目 novel_bibles、novel_characters、novel_settings 设定漂移
大纲层 分章大纲、关键冲突、涉及人物、目标字数、结尾钩子 outline_chapters 大纲断层
章节层 正文、字数、生成提示词、章节状态 chapters 稿件管理与重写
记忆层 最近原文、章节摘要、进度卡、时间线、生成记录 generation_records、app_kv 上下文装不下
这套结构的直接好处是：每一章都可以被单独检索、单独重写、单独审稿，而不需要把整本书当成一个不可拆的黑盒。后续所有操作，都是在这四层上做增量和校验。

大作家AI写小说主界面：左侧章节树、中间正文编辑区、右侧写作辅助面板
主界面：左侧是章节结构，中间是正文，右侧是写作与 AI 工具入口。长篇项目的所有操作都围绕这三个区域展开。
三、设定层：先建 Story Bible，再动笔
设定层由系统生成并持久化，核心是六个字段。它们不是装饰性的“作品简介”，而是后续每次生成都会引用的约束。

story_mainline：全书主线的因果链，回答“这个故事到底在讲什么”。
ending_plan：结局方向与关键收束点，防止长篇写到后期无以为继。
character_arcs：主要人物的成长曲线与关系变化节点。
world_building：世界规则、势力、地理、力量体系等硬约束。
core_foreshadowing：核心伏笔与回收计划，避免“挖坑不填”。
extra_notes：题材约定、叙事视角、语言风格等补充要求。
除此之外，人物卡与设定条目会以独立记录保存。写作时，系统会把当前章涉及的人物与设定挑出来，而不是把全部资料平铺给模型。这一点对长篇尤其重要：相关资料优先于全部资料。

操作步骤
新建项目，填写书名、题材、主角名、核心设定与预计章数。
生成小说大纲，系统会先产出设定层内容，再基于设定生成分章大纲。
检查人物弧光与核心伏笔是否符合预期，不满意就修改后重新生成，不要带着错误设定进入正文。
将大纲导入主界面，确认左侧章节结构完整。
经验上，设定层每多写清楚一条硬约束，后面就少一次“人物突然降智”或“世界观前后矛盾”。这一步值得慢一点。
四、大纲层：分批生成，而不是一口气写一千章
一次性让模型输出几百章大纲，结果通常是后段越来越空泛：标题重复、冲突雷同、节奏失速。更可靠的做法是分批生成 + 增量扩展。

系统通过 build_outline_chapter_batch 按章节区间生成轻量大纲，每次只处理一段章节，并携带已有大纲作为上下文。这样每一批都有明确的起止范围，也便于人工检查。

导入已有大纲时怎么处理长文本
如果你已经有几十万字的设定或大纲文本，系统会先做分组分析：当文本超过 200000 个中文字符时按组切分；单块分析上限约 12000 字符，块间保留 700 字符重叠，避免关键信息正好被切断。分析任务默认使用 4 个并发线程，可在 1～100 之间调整。

这套参数的意义在于：长文本不是被粗暴截断，而是分块理解后再合并。对于从其他平台迁移过来的作者，这一步能显著减少“导入后大纲面目全非”的情况。

生成小说大纲对话框：填写题材、人物、设定与剧情方向
生成大纲时填写的信息会同时进入设定层与大纲层；题材、人物和核心冲突越具体，分批大纲的稳定性越高。
五、细纲与结尾钩子：让每一章都有“下一章理由”
分章大纲只是骨架。真正驱动连载的是每一章的两个字段：key_conflict（关键冲突）与ending_hook（结尾钩子）。前者决定本章有没有戏，后者决定读者会不会点下一章。

在 outline_chapters 表中，每章还会记录 characters_involved（涉及人物）与 target_words（目标字数）。这些字段在写作时会被组装进“本章写作任务单”，形成明确的边界：这一章写谁、写什么冲突、写多长、最后停在哪。

章节大纲字段与写作时的作用
字段 作用 缺失后的典型症状
key_conflict 限定本章核心矛盾 整章像流水账，没有推进
ending_hook 设计章末悬念或转折 读者没有追读动力
characters_involved 控制出场人物范围 人物乱入、关系混乱
target_words 控制篇幅节奏 该快的地方拖，该慢的地方赶
如果大纲只有标题没有细纲，可以使用“批量完善大纲”或“生成细纲钩子”补齐。对于长篇，建议至少保证当前卷的每一章都有钩子，再开始批量写。

大纲润色与细纲完善功能界面
细纲完善适合在开写前集中处理：把“第 N 章 转机”这种空标题，补成带冲突与钩子的可执行任务单。
六、三种记忆模式与上下文预算
这是整套系统里最影响长篇体验的部分。所谓“记忆模式”，本质是如何分配有限的上下文字符预算。三种模式对应三种写作阶段和三种成本结构。

三种记忆模式的上下文构成（v2.0.4）
模式 上下文构成 参考预算 适用场景
经典上下文 全书大纲 + 最近原文窗口 大纲 5 万字符；原文窗口 22 万字符 短篇、前期试写、结构简单的中篇
真人作家 作者设定本 + 全书剧情骨架 + 连载进度卡 + 最近原文窗口 + 本章任务单 Flash：骨架 8 万 / 时间线 7 万 / 原文 32 万；Pro：12 万 / 11 万 / 48 万 百万字级连载，强调“像人一样记得住重点”
长文记忆 大纲 + 摘要与索引 + 尽量完整的前文正文 Flash：大纲 14 万 / 摘要 12 万 / 原文 62 万；Pro：22 万 / 18 万 / 82 万 强连续性章节，需要大量原文细节支撑
真人作家模式为什么适合长篇
它的提示词结构是五段式的：先给“作者设定本”，再给“全书剧情骨架”，然后是“连载进度卡”，接着是“最近原文回看窗口”，最后才是“本章写作任务单”。并且明确要求：先延续最近章节的场景位置、人物状态、关系变化、伤势与道具去向，再推进当前章节冲突。

这实际上是在模拟人类作者的记忆方式：不背全文，但记得主线、人物当前状态和上一章停在哪里。相比把大量原文硬塞进上下文，它更稳定，也更省 token。

长文记忆模式什么时候用
当某一章需要大量前文细节——比如回收一个几十章前的伏笔、重写一场多方对峙、需要保持特定语言质感——可以切到长文记忆，让模型看到更多原文。代价是上下文成本更高，因此不建议全书默认开启。

切换模式后，写作日志会输出“记忆加载清单”，包含持久化记忆、上下文预算和本次纳入的章节范围。这个日志非常值得看：它能告诉你模型这一章到底“记得什么”。

模型设置界面：默认模型、API Key、思考模式与记忆模式选择
设置中的模型与记忆模式选项。记忆模式不是全局一劳永逸的，建议按卷或按章节类型调整。
七、无限章的核心：续写扩纲
“无限章”不是让模型无限生成，而是让大纲可以按需增长。当现有大纲写到尽头，执行“续写扩纲”，输入目标总章数，系统会在已有大纲的基础上继续向后规划。

关键机制有三点：

目标总章数驱动：扩纲以“最终总章数”为目标，而不是“再写 N 章”，便于按卷规划。
连续性校验：扩纲完成后会校验新增章节数量与章节编号是否连续，避免出现跳号、重号。
上限保护：目标总章数上限为 5000 章，超出会被拦截。这是一个工程上限，不是推荐值。
实际写作中，更合理的节奏是滚动扩纲：当前大纲剩余 30～50 章时，就扩到下一卷的规模。这样既能保持对剧情的控制，又不会一次性生成大量用不上的空大纲。

在扩纲入口填写目标总章数，例如从 120 章扩到 200 章。
等待生成完成，在扩纲工作台检查新增章节的主线推进、人物出场与钩子分布。
确认无误后应用到主界面，再继续写正文。
每完成一卷，回到设定层检查伏笔回收情况，必要时同步更新核心伏笔字段。
扩纲要“提前做、少量做”。等到大纲用完再临时扩，容易出现主线仓促转向；一次扩几百章又难以逐章检查。卷级滚动是最稳的方式。
八、批量写与断点续写
当大纲和细纲都稳定后，可以使用“批量写”连续生成多章。系统会逐章推进，并在 generation_records 中记录生成过程，章节本身带有状态字段。

批量写不是无人值守的“一键成书”。建议把它当成“把已经想清楚的部分快速落成初稿”，并且：

每批控制在 3～5 章，写完先抽查人物状态与钩子是否接上。
关闭软件或中断后，从最后一章已保存的状态继续，不要重复覆盖已有正文。
批量写期间不要同时大幅修改设定层，否则前后批次会引用不同版本的设定。
单章生成时，输出长度由目标字数控制，并有上限保护，避免模型失控输出超长文本。对连载来说，稳定的单章字数比偶尔爆字更重要。

九、中间章节兼容重写
写到第 180 章发现第 120 章有个逻辑漏洞，是长篇最常见的困境。直接重写第 120 章，后面的 60 章可能全部失效。

系统提供“兼容后文重写”：生成新版本时，会把后续章节的摘要与开头（约 380 字）作为约束传给模型，要求它在修正当前章节的同时，尽量保持与后文的衔接。这样改动的是一章，而不是整卷。

适用与不适用的边界要说清楚：

场景 建议
修补逻辑漏洞、补充动机、调整对话 兼容重写，保留后文
改变关键人物生死、主线走向 不要兼容重写，应从该节点起重新扩纲并重写后续
只是语言不满意 用去痕或对话改稿，不必整章重生成
十、去痕与六维审稿
去痕：处理“AI 味”，但别过度
去痕针对的是模板化表达、机械排比、解释性旁白过多等问题。系统提供三档：标准版（推荐）、精修进阶版、极简快修。三档的差别在于改写幅度与保留原意的程度。

标准版：日常使用，兼顾自然度与稳定性。
精修进阶版：适合重点章节，改写幅度更大，需要人工复核。
极简快修：只处理明显问题，适合批量初稿快速过一遍。
建议顺序是：先审稿发现问题，再去痕处理表达。反过来做，可能把需要修改的剧情问题“润色”得更难发现。

AI去痕功能界面，提供标准版、精修进阶版与极简快修三档模式
去痕的三档模式对应不同的改写强度。重点章节建议精修后人工复核，避免语义偏移。
六维审稿：把“感觉不对”变成可检查项
审稿不是简单问一句“写得好不好”，而是按六个维度检查：

爽点：本章是否有明确的情绪释放或期待建立。
设定一致性：人物能力、世界规则、时间线是否与前文冲突。
节奏：参考三线配比——Quest（主线推进）约 60%、Fire（冲突爆发）约 20%、Constellation（关系与群像）约 20%。
人物 OOC：言行是否符合人物卡与当前关系阶段。
叙事连贯：场景切换、因果链、信息交代是否顺畅。
追读钩子：章末是否留下有效的下一步期待。
审稿分三级：单章检查、5 章聚合检查、整卷终审。聚合检查能发现单章看不出的问题，比如连续多章没有主线推进，或某个角色长时间消失。系统还设置了断档红线提示（5 / 10 / 15 章），用于提醒长时间未回收的线索或未出场的人物。

AI审稿结果界面：按爽点、设定一致性、节奏、人物、连贯性与钩子给出问题
审稿输出的是可执行的问题清单，而不是一个笼统分数。优先处理“设定一致性”和“主线停滞”，再处理语言层面。
卡文时用灵感锦囊，而不是硬写
灵感锦囊提供三种模式：卡文锦囊、冲突升级、关系推进。它输出的是结构化的剧情建议卡片，可以应用到本章摘要或继续写作。把它当作“备选方案生成器”，而不是让 AI 替你决定剧情。

AI灵感锦囊界面：卡文锦囊、冲突升级、关系推进三种模式
灵感锦囊适合在细纲阶段使用：先选上下文范围，再生成建议，最后人工挑选并入大纲。
十一、数据存储与备份
整套系统是本地桌面应用，作品数据保存在本机 SQLite 数据库与项目文件中，不依赖云端账号。核心表包括：

novels：作品基本信息。
novel_bibles、novel_characters、novel_settings：设定层。
outline_chapters、outline_generation_tasks、outline_generation_logs：大纲与扩纲任务。
chapters：正文、字数、生成提示词与状态。
generation_records：生成记录，用于追溯与恢复。
本地存储的好处是数据可控、便于迁移；代价是备份责任在自己。建议：

每周备份一次数据库文件与项目目录，重要节点额外备份。
大版本修改前先导出当前稿件，保留可回退的文本版本。
不要把唯一副本放在系统盘或临时目录。
备份与恢复相关设置界面
长篇项目的备份频率应高于短篇。数据库文件与导出稿件建议同时保留。
十二、可复用的操作流程
把上面的机制串起来，一本长篇的稳定生产流程大致如下：

建设定层：写完主线、结局、人物弧光、世界观与核心伏笔，确认没有硬冲突。
生成首批大纲：覆盖前 50～100 章，逐章检查关键冲突与结尾钩子。
选记忆模式：前期可用经典上下文试写；进入稳定连载后切换真人作家模式。
写前 3 章做校准：检查人物语气、叙事节奏、单章字数是否符合预期，再决定是否批量。
批量推进：每批 3～5 章，写完后抽查连续性。
滚动扩纲：剩余 30～50 章时扩到下一卷，扩完先审大纲再写正文。
定期审稿：单章检查 + 5 章聚合检查，每卷做一次终审。
统一去痕与排版：剧情稳定后再处理语言，最后导出投稿版本。
这套流程并不追求“全自动”。它把 AI 放在合适的位置：负责按约束生成大量初稿，人负责设定、判断与取舍。写得越长，这个分工越重要。

十三、常见问题
AI 写长篇小说最多能写多少章？
上限取决于大纲规划与记忆策略。「大作家AI写小说」的续写扩纲目标总章数上限为 5000 章，实际可写长度还受单章字数、设定复杂度和模型上下文能力影响。建议按卷推进，每 50～100 章做一次扩纲与一致性审稿。

写长篇小说应该选哪种记忆模式？
经典上下文适合短篇和前期试写；真人作家模式用设定本、剧情骨架、进度卡和最近原文窗口组合上下文，适合百万字级连载；长文记忆模式尽量保留更多前文正文，适合需要强连续性的章节。可在设置中切换，并观察日志里的上下文预算。

如何避免前后设定矛盾？
把人物、世界观、伏笔放进设定层并持久化存储；每章大纲记录关键冲突、涉及人物与结尾钩子；出现矛盾时用六维审稿检查设定一致性，再用兼容后文重写修正中间章节，而不是直接推翻整卷。

中间章节写坏了怎么办？
使用兼容后文重写。系统会把后续章节的摘要与开头作为约束传给模型，在修正当前章的同时尽量保持后续剧情可衔接，避免改一章导致后面全部失效。

AI 生成的小说需要去痕和审稿吗？
建议保留。去痕用于降低模板化表达和机械句式，分为标准版、精修进阶版和极简快修三档；审稿从爽点、设定一致性、节奏配比、人物 OOC、叙事连贯和追读钩子六个维度给出问题与修改建议。

小说数据存在哪里，会不会丢？
作品数据保存在本机 SQLite 数据库与项目文件中，不依赖云端账号。仍建议定期备份整个项目目录和数据库文件，并利用导出功能保留阶段性稿件。

本文基于「大作家AI写小说」v2.0.4 的实际功能与参数整理，用于说明长篇 AI 写作的工程方法。功能与参数可能随版本调整，请以软件内实际界面为准。