企业官网建设流程全解析

AI_NovelGenerator深度解析：AI长篇小说生成系统如何让写作不断线

【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说，自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator

AI_NovelGenerator是一款基于大语言模型、自动生成长篇小说的本地GUI工具，它用"设定→目录→草稿→定稿"四阶段流水线和一套文件化记忆系统，解决AI写长篇时最常见的三个问题：上下文遗忘、设定漂移、伏笔消失。本文按数据流拆解每个模块的代码职责与设计动机，并给出三步跑通的配置方法，读完后你既能用它创作，也能理解这类AI写作流水线是怎么搭的。

🧭 从痛点切入：AI写长篇会断的三件事

先说清楚这个系统到底在解决什么。让大模型一口气写完五十章小说，通常会断在三处：

• 装不下：模型有上下文窗口（一次能"看到"的文本上限），写到后期，前文根本塞不进提示词；
• 记不准：每次调用模型都是"失忆"的，同一个角色的性格、同一个设定的细节会被反复重新解释；
• 忘伏笔：第三章埋的线索，到第三十章彻底没人记得。

AI_NovelGenerator 的思路不是"让模型记住更多"，而是把记忆外置到输出目录里的一堆文本文件，每一步只把该看的内容装进提示词。这是它全部设计的出发点。

🗺 打开输出目录：先看记忆长什么样

跟着一次完整生成走一遍，产物全部落在你指定的输出文件夹里，都是可直接打开、可直接手改的纯文本：

• Novel_architecture.txt：世界观、角色动力学、三幕式情节架构
• Novel_directory.txt：全书目录，每章一段（定位、核心作用、伏笔设计、悬念密度）
• chapters/chapter_N.txt：各章正文
• global_summary.txt/character_state.txt：全局摘要与角色状态表，每章定稿后更新
• vectorstore/：本地向量索引

所有"长期记忆"都以落盘文件形式存在。这意味着任何一步出错、任何一处不满意，你都能改完文件接着生成——这也是整个系统"可断点"能力的地基。

⚙️ 四阶段流水线怎么走：设定、目录、草稿、定稿

第一步·设定层：四步链路，失败可续传

novel_generator/architecture.py负责设定生成，内部是串联四次模型调用：核心种子→角色动力学→世界观→三幕式情节，后一步引用前一步的结果。

每个步骤完成后立即写入partial_architecture.json；若中途API报错，下次进入会从断点步骤继续，而不是从头再来。全部完成后合并输出Novel_architecture.txt，并顺带初始化character_state.txt。这样设计的原因很直接：长链路调用必然遇到偶发失败，分步落盘等于给生成过程装了存档点。

第二步·目录层：分块生成，目录不怕长

novel_generator/blueprint.py依据设定生成全书目录。它做了三层防护：

• 按max_tokens粗略估算单批能写多少章（compute_chunk_size），超出就分批生成；
• 检测到已有目录时，解析其中最大章号，从下一章继续，不重跑；
• 传给模型的旧目录只保留最近100章（limit_chapter_blueprint），防止提示词膨胀。

写200章小说的目录，一次生成几乎必然失败；分块+断点续传+窗口截断，就是为这种规模准备的。

第三步·草稿层：五路上下文拼成一份提示词

novel_generator/chapter.py是整条流水线里最复杂的一环。build_chapter_prompt把五路信息组装进提示词：

• 全局摘要（global_summary.txt）
• 角色状态表（character_state.txt）
• 上一章结尾最后800字，保证语气和场景接得上
• 最近三章由模型生成的短摘要（截断至2000字）
• 向量检索出的历史内容（见下一节）

检索关键词不是人工填的：模型先根据本章信息生成最多5组"人物·场景"式关键词，再逐组检索。检索结果会打上[TECHNIQUE]/[SETTING]/[GENERAL]标签，近两章内容标记为"跳过"、3到5章前的标记"需改写40%以上"，最后再经模型过滤一轮。这一步本质是组装简报而非倾倒全文，token预算因此可控。

第四步·定稿层：状态合并与索引更新一步完成

novel_generator/finalization.py的finalize_chapter做三件事：

• 用模型把新章节内容合并进global_summary.txt和character_state.txt；
• 写入采用"先写临时文件、再原子改名"（_write_text_atomic），中途崩溃也不会留下半个损坏文件；
• 将正文按约500字符切段后插入向量库，供后续章节检索。

草稿只是"临时稿"，定稿才是记忆正式生效的时点，这个边界划分得很清楚。

🔍 向量检索怎么配：调取"第三章发生过什么"

向量检索是把文本转成数值向量后按含义找相似段落，适合回答"很久以前写过什么"这类问题。novel_generator/vectorstore_utils.py把它做得很轻量：

• 向量库用本地 Chroma，直接持久化在输出目录的vectorstore/子目录，不需要部署任何服务；
• 入库前把句子合并为约500字的段落（split_text_for_vectorstore）；
• 检索取最相关的 k 条，单次结果上限2000字符，避免一次灌太多；
• novel_generator/knowledge.py还支持把外部资料文件（如你的设定集）导入同一个向量库，让检索同时覆盖"写过的剧情"和"参考资料"。

分工很清晰：摘要和近章文本负责"最近发生了什么"，向量检索负责"更早之前发生过什么"，两者拼成长程记忆。注意切换 Embedding 模型后建议清空vectorstore/，旧向量与新模型不兼容。

🧩 任务怎么分配模型：质量与成本的平衡手册

系统把五个环节各自独立配置模型：设定、目录、草稿、定稿、审校，在config.example.json的choose_configs里指定。典型策略是设定和定稿用强模型，草稿这种高频调用用便宜快速的模型，成本与质量都能调。

审校环节在consistency_checker.py：定稿后可选调用，把最新章节与小说设定、角色状态、全局摘要、未解决的剧情要点（plot_arcs.txt）放在一起，让模型列出明显冲突；提示词温度固定0.3，要的是稳定判断而非发挥。全部提示词集中在prompt_definitions.py（另有英文版prompt_definitions_en.py），业务代码与提示词完全分离，改文案不用翻逻辑。

🚀 三步跑起来：配置、安装、启动

第一步，把config.example.json复制为config.json，填入至少一个模型预设的 API Key 和按任务分配；核心字段长这样：

{ "llm_configs": { "DeepSeek V4 Flash": { "api_key": "", "base_url": "https://api.deepseek.com", "model_name": "deepseek-v4-flash", "temperature": 0.7, "interface_format": "DeepSeek" } }, "choose_configs": { "prompt_draft_llm": "DeepSeek V4 Flash" } }

第二步，克隆代码并安装依赖后启动（本地 Embedding 用 Ollama 时，需先ollama serve并ollama pull nomic-embed-text）：

git clone https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator cd AI_NovelGenerator pip install -r requirements.txt python main.py

第三步，在界面里依次执行「生成设定→生成目录→生成章节草稿→定稿当前章节」，每步产物都会落盘，可随时暂停、手改文件再续。配置里还预留了代理与 WebDAV 字段，方便内网访问和输出目录上云同步。

一句话收束：AI_NovelGenerator 的理念是把长程记忆全部外置为"文件+索引"，让模型每步只看见该看的内容。若想继续深入，值得探索的方向是把伏笔的"埋设→回收"做成显式状态机，让伏笔管理从提示词约定升级为可校验的约束。

【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说，自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator