尧图网站建设 
AI_NovelGenerator长篇写到第100章上下文靠什么不跑偏【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator用AI写百章小说最头疼的不是单章写得差而是第20章角色性格已经变了第3章埋的伏笔再也想不起来。AI_NovelGenerator 是一个用大模型生成多章节长篇的图形化工具逐章维护上下文与伏笔适合网文作者和长篇故事写作者。一句话说清输入一个主题输出一部记得住前文的长篇输入是主题、类型、章节数和一个 API Key处理过程是把「设定生成 → 章节目录 → 逐章草稿 → 定稿更新状态」拆成四个阶段每阶段的产物都是本地 txt/json 文件外加一个 Chroma 向量库存住所有历史正文输出是一组可逐章人工修改、重新生成、再定稿的小说章节。先跑起来4 条命令打开小说生成 GUI环境要求 Python 3.9推荐 3.10–3.12以及一个 OpenAI 兼容接口的 API Key本地 Ollama 也可以git clone https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator cd AI_NovelGenerator pip install -r requirements.txt python main.pymain.py 只有 12 行建一个 customtkinter 窗口并启动。判断启动成功几秒内弹出主窗口再在配置页填入 API Key、主题、章节数点「Step1 Generate Settings」输出目录里出现Novel_architecture.txt整条链路就算通了。原理走查连点四次按钮背后按什么顺序执行按钮逻辑集中在 generation_handlers.py每个按钮都开一个后台任务调 LLM窗口不会卡死。以「生成第 N 章」为例实际顺序是Step1 生成设定。architecture.py 依次跑四个提示词核心种子 → 角色动力学 → 世界观 → 剧情架构每步结果立刻存进partial_architecture.json最后合并成Novel_architecture.txt并顺手生成初始character_state.txt。Step2 生成目录。blueprint.py 把逐章标题和简短提示写入Novel_directory.txt章节多时按「每章约 200 tokens」估算块大小分块生成已有文件就自动解析最大章号接着写。Step3 起草章节。chapter.py 先让 LLM 从本章信息里解析出最多 5 组「地点·事件」关键词拿它们去 Chroma 向量库检索检索条数 k 默认 2检索结果再过一道规则命中最近 2 章的直接跳过3–5 章前的标记为需改写 40% 以上。同时把全局摘要global_summary.txt、角色状态、以及最近 3 章全文get_last_n_chapters_text默认 n3拼进提示词。Step4 定稿。finalization.py 调模型重写global_summary.txt和character_state.txt再把这章写入向量库按 500 字切块相似度阈值 0.7供后续章节检索。状态文件用「先写临时文件再替换」的原子写入进程中途被杀也不会写坏文件。可选一致性校对。consistency_checker.py 扫描最新章节的角色逻辑与剧情冲突结果打进日志区。为什么不一口气生成三个关键设计决策1. 四段式设定每段落盘一次。选择architecture.py 把四段生成结果逐段写入partial_architecture.json中途失败就把已有部分保存后退出。原因一次设定生成要连续调用 4 次 LLM任何一段都可能碰上 504 超时或非 JSON 返回README FAQ Q1 就是这类错误。效果下次运行自动跳过已完成阶段从断点续跑前面调过的 API 不白花。2. 上下文记忆双通道固定状态文件 按需向量检索。选择global_summary.txt和character_state.txt无条件进每章提示词全文则切 500 字块存进输出目录下的vectorstoreChroma需要时才检索。原因百章小说塞不进上下文窗口全量拼接会让关键信息淹没在噪音里。效果每章提示词是「全局摘要 当前章最相关的前文」而检索关键词由 LLM 根据当前章内容决定不是盲目搜全文。3. 不同任务路由不同模型。选择配置的choose_configs给架构、章节目录、草稿、定稿、一致性校对五类任务分别指定模型。原因设定与目录阶段吃长上下文能力草稿阶段调用次数最多、对成本最敏感。效果设定用强模型草稿用便宜快的模型还能让本地 Ollama 与云端 API 混着用。适合谁用谁别碰适合章节多、伏笔重的长篇网文、连载故事需要设定和角色状态逐章维护想控制每一章设定、目录、草稿都能在编辑器里人工改完再生成或定稿本地模型与云端 API 混用不适合 / 需要额外工作「一键生成整本」四个阶段仍要按顺序点generation_handlers.py 里的批量按钮只减少草稿定稿的重复操作中途换 embedding 模型必须手动清掉vectorstore目录重建索引README 明确要求输出上限取决于模型能力API 返回错误页时会抛 Expecting value 这类 JSON 解析错误单机 GUI无多人协作、无 Web 界面扩展指引接入一个新模型后端最实际的扩展点是 llm_adapters.pyBaseLLMAdapter只定义了一个方法invoke(prompt) - str现有 DeepSeek、OpenAI、Gemini 等后端都是实现这一个方法。想接一个列表外的模型照现有适配器写一个同名签名的类再接进create_llm_adapter所有生成流程即可直接使用。AI_NovelGenerator 的要点不在模型而在「把状态落成文件、逐章更新状态」每一章都建立在一套可检查、可编辑的本地文件之上。建议先用本地模型把四个阶段完整走一遍 3–5 章原理自然就清楚了。【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AI_NovelGenerator：长篇写到第100章，上下文靠什么不跑偏？
AI_NovelGenerator长篇写到第100章上下文靠什么不跑偏【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator用AI写百章小说最头疼的不是单章写得差而是第20章角色性格已经变了第3章埋的伏笔再也想不起来。AI_NovelGenerator 是一个用大模型生成多章节长篇的图形化工具逐章维护上下文与伏笔适合网文作者和长篇故事写作者。一句话说清输入一个主题输出一部记得住前文的长篇输入是主题、类型、章节数和一个 API Key处理过程是把「设定生成 → 章节目录 → 逐章草稿 → 定稿更新状态」拆成四个阶段每阶段的产物都是本地 txt/json 文件外加一个 Chroma 向量库存住所有历史正文输出是一组可逐章人工修改、重新生成、再定稿的小说章节。先跑起来4 条命令打开小说生成 GUI环境要求 Python 3.9推荐 3.10–3.12以及一个 OpenAI 兼容接口的 API Key本地 Ollama 也可以git clone https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator cd AI_NovelGenerator pip install -r requirements.txt python main.pymain.py 只有 12 行建一个 customtkinter 窗口并启动。判断启动成功几秒内弹出主窗口再在配置页填入 API Key、主题、章节数点「Step1 Generate Settings」输出目录里出现Novel_architecture.txt整条链路就算通了。原理走查连点四次按钮背后按什么顺序执行按钮逻辑集中在 generation_handlers.py每个按钮都开一个后台任务调 LLM窗口不会卡死。以「生成第 N 章」为例实际顺序是Step1 生成设定。architecture.py 依次跑四个提示词核心种子 → 角色动力学 → 世界观 → 剧情架构每步结果立刻存进partial_architecture.json最后合并成Novel_architecture.txt并顺手生成初始character_state.txt。Step2 生成目录。blueprint.py 把逐章标题和简短提示写入Novel_directory.txt章节多时按「每章约 200 tokens」估算块大小分块生成已有文件就自动解析最大章号接着写。Step3 起草章节。chapter.py 先让 LLM 从本章信息里解析出最多 5 组「地点·事件」关键词拿它们去 Chroma 向量库检索检索条数 k 默认 2检索结果再过一道规则命中最近 2 章的直接跳过3–5 章前的标记为需改写 40% 以上。同时把全局摘要global_summary.txt、角色状态、以及最近 3 章全文get_last_n_chapters_text默认 n3拼进提示词。Step4 定稿。finalization.py 调模型重写global_summary.txt和character_state.txt再把这章写入向量库按 500 字切块相似度阈值 0.7供后续章节检索。状态文件用「先写临时文件再替换」的原子写入进程中途被杀也不会写坏文件。可选一致性校对。consistency_checker.py 扫描最新章节的角色逻辑与剧情冲突结果打进日志区。为什么不一口气生成三个关键设计决策1. 四段式设定每段落盘一次。选择architecture.py 把四段生成结果逐段写入partial_architecture.json中途失败就把已有部分保存后退出。原因一次设定生成要连续调用 4 次 LLM任何一段都可能碰上 504 超时或非 JSON 返回README FAQ Q1 就是这类错误。效果下次运行自动跳过已完成阶段从断点续跑前面调过的 API 不白花。2. 上下文记忆双通道固定状态文件 按需向量检索。选择global_summary.txt和character_state.txt无条件进每章提示词全文则切 500 字块存进输出目录下的vectorstoreChroma需要时才检索。原因百章小说塞不进上下文窗口全量拼接会让关键信息淹没在噪音里。效果每章提示词是「全局摘要 当前章最相关的前文」而检索关键词由 LLM 根据当前章内容决定不是盲目搜全文。3. 不同任务路由不同模型。选择配置的choose_configs给架构、章节目录、草稿、定稿、一致性校对五类任务分别指定模型。原因设定与目录阶段吃长上下文能力草稿阶段调用次数最多、对成本最敏感。效果设定用强模型草稿用便宜快的模型还能让本地 Ollama 与云端 API 混着用。适合谁用谁别碰适合章节多、伏笔重的长篇网文、连载故事需要设定和角色状态逐章维护想控制每一章设定、目录、草稿都能在编辑器里人工改完再生成或定稿本地模型与云端 API 混用不适合 / 需要额外工作「一键生成整本」四个阶段仍要按顺序点generation_handlers.py 里的批量按钮只减少草稿定稿的重复操作中途换 embedding 模型必须手动清掉vectorstore目录重建索引README 明确要求输出上限取决于模型能力API 返回错误页时会抛 Expecting value 这类 JSON 解析错误单机 GUI无多人协作、无 Web 界面扩展指引接入一个新模型后端最实际的扩展点是 llm_adapters.pyBaseLLMAdapter只定义了一个方法invoke(prompt) - str现有 DeepSeek、OpenAI、Gemini 等后端都是实现这一个方法。想接一个列表外的模型照现有适配器写一个同名签名的类再接进create_llm_adapter所有生成流程即可直接使用。AI_NovelGenerator 的要点不在模型而在「把状态落成文件、逐章更新状态」每一章都建立在一套可检查、可编辑的本地文件之上。建议先用本地模型把四个阶段完整走一遍 3–5 章原理自然就清楚了。【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考