简介这是一款基于Gemini大模型的超长篇小说生成器专为网络小说作者、编剧及AI应用开发者设计针对百万字级长篇创作场景解决剧情连贯性差、设定易崩塌、逻辑矛盾频发等常见痛点。压缩包为zip格式共30个文件核心为20个Python脚本对应小说设定工坊、智能章节生成、状态追踪、语义检索、自动审校等完整功能模块另有配置文件示例、README说明文档与文本资源整体仅106KB轻量易部署便于快速上手与二次开发。目前已有139人学习浏览。代码脉络清晰通过可视化工作台即可一站式完成世界观架构、角色设定与剧情蓝图规划并借助基于向量的语义检索引擎与伏笔管理系统维护长程上下文一致性自动检测剧情矛盾和逻辑冲突保障多阶段生成的连贯性配合状态追踪系统与知识库集成可实时记录角色发展轨迹、管理伏笔并引用本地文档作为创作参考。对于希望搭建个人AI写作流水线、研究大模型长文本生成或快速启动网文创作项目的开发者均具有不错的参考价值与实践意义。1. 百万字网络小说生成器为什么说 Gemini 是唯一敢接“整本书”这个活的模型拿到“基于 Gemini 大模型的超长篇小说生成器”这个压缩包时很多人第一反应是把它当成一个“输入几个关键词就哗啦啦吐十万字”的玩具。实际上只要跑过一轮就会发现真正的技术难点不在单次生成而在“百万字”这三个字——怎么让模型不忘记第一卷埋的伏笔怎么让第一百章的文风和第三章保持一致怎么让角色三十万字之后开口说话还是原来那个人。这些问题靠一次 prompt 解决不了它需要一条可拆解的流水线。而 Gemini 的百万级上下文窗口恰恰是这条流水线能成立的前提。这个 zip 包本质上是一个工程模板围绕 Gemini API 把超长篇小说生成拆成大纲、分卷、章节、摘要记忆和重复检测几个模块。适用对象是有 Python 基础、申请了 Google AI Studio API Key、想自己搭一套批量产出长篇的从业者。新手照着配置能跑通最小流程熟手可以按自己的需求替换模型、改提示词模板。下面我从架构开始讲。2. 先把生成器拆成流水线大纲 → 分卷 → 章节的三级约束架构2.1 为什么长上下文模型是超长篇的唯一出路写长篇小说最头疼的不是写不出来是“写到后面忘了前面”。传统模型做文本生成时上下文窗口只有几千到几万个 token塞下几个人物设定和开篇三章就满了。想要保证前后一致只能把前文一并丢进输入窗口立刻爆炸。Gemini 系列主推百万级 token 的上下文窗口相当于可以把一部中长篇的网络小说正文完整放进一次请求里。但这里有一个常见误区我一般不建议真的把“整本书”塞进一个 prompt 让模型一口气续写。原因有两个。其一输出长度有上限Gemini API 单次输出的 token 数远小于输入上限指望它输出几十万字文本不现实。其二模型注意力在超长输入上会衰退真正用到的往往是输入尾部的内容中间的情节容易被稀释。长上下文的意义不是“一次生成百万字”而是“在需要回顾时装得下足够长的记忆”。这个定位很关键。2.2 三级约束为什么“直接让模型写全文”必崩在跑通这个 zip 包的工程结构之后我发现它的设计思路和网文编辑的审稿流程很像先定全书主题再拆成卷每卷再拆成章节。三级结构每一层都调用一次 Gemini但 prompt 完全不同。第一级是“全书大纲”。给模型一个故事题材、主角设定、结局方向让它输出三五十个字的卷级标题和每卷的核心冲突。第二级是“分卷细纲”。把某一卷的标题和结局事件交给模型让它拆出十几章的小节每节一百字左右包含本章要发生的三到四个关键情节点。第三级是“章节正文”。拿着细纲中的一章内容加上人物状态卡让模型扩写成三千到五千字的正文。为什么这么分因为一次性让模型规划百万字它给出的框架往往是空的诸如“主角成长”“对手出现”这类没法直接落地执行。拆到章节这一级时每一章输入里可以包含准确的出场人物、地点、时间线、章节目标事件模型发挥空间被约束在真实可写的范围内。这比“给一个笼统设定靠模型自己编”稳定得多。2.3 zip 包内的目录结构配置、缓存、与输出分离解压这个生成器 zip 包之后我通常先不看代码而是看它的目录组织。一个合格的生成器工程应当把“配置”“中间产物”“最终输出”三者分开否则跑长篇时会乱成一锅。novel_generator/ ├── config/ │ ├── api_config.json │ ├── characters/ │ │ └── 主角_林晚.json │ └── style_config.json ├── outlines/ │ ├── book_outline.json │ ├── volume_01.json │ └── chapter_01_plan.json ├── chapters/ │ ├── generated/ │ └── checkpoints/ ├── cache/ │ ├── summaries/ │ └── raw_responses/ ├── scripts/ │ ├── generate_outline.py │ ├── generate_chapter.py │ └── memory_builder.py └── requirements.txtapi_config.json 存放 API Key 和模型名characters 目录下每个角色一个 JSON 文件字段包括身份、性格、说话习惯、当前状态。outlines 下存三级大纲chapters 下存最终生成的正文和断点cache 目录存每次调用 Gemini 返回的原始响应。这样设计的好处是某一章生成失败时可以直接使用 cache 里的原始响应做断点续调不必重新花 token 生成一遍——这一点在后面避坑章节会展开讲。2.4 配置化存储用 JSON 做结构化记忆我最看重这个 zip 方案里的一点是小说不是“文本流”而是“状态流”。人物状态、地点状态、物品归属这些信息如果用自然语言塞进 prompt模型会模糊处理。用 JSON 结构存储读取时按 key 取用写入时按 key 更新才能实现精确控制。# scripts/character_state.py import json def load_character(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def update_character_state(path: str, updates: dict) - None: char_data load_character(path) char_data[current_state].update(updates) with open(path, w, encodingutf-8) as f: json.dump(char_data, f, ensure_asciiFalse, indent2)这段代码做的事情很简单读取角色的 JSON 状态文件更新 current_state 字段再写回。但它在长篇生成中起到的作用是“唯一事实源”。比如主角在第三卷断了一条手臂这个状态必须写进 JSON 文件然后在后续章节的 prompt 里明确注入“林晚右臂已断”而不是靠模型自己记住。参数说明ensure_asciiFalse 保证中文以明文写入避免 \uXXXX 转义indent2 是让文件可读方便人工检查和回滚。血泪经验是最初我偷懒把角色状态靠模型“自行保持”结果第二卷还没结束主角就长出了新手。从那时起状态必须落盘不存在例外。3. 用 Gemini API 跑通第一个最小章节生成脚本3.1 环境准备API Key 与依赖安装安装依赖时建议在虚拟环境里做。这个 zip 包里的 requirements.txt 一般包含 google-generativeai 这个官方 SDK以及用于 JSON 处理和文本匹配的库。我这里只说最小集。python -m venv venv source venv/bin/activate pip install google-generativeai pip install python-dotenv安装完成后在项目根目录创建 .env 文件写入你的 API Key。.env 文件不要提交到代码仓库也不要放进分发给别人的 zip 包里。有经验的读者会问为什么 .env 会被写进 zip这正是要提醒新手的第一件事——网上流传的生成器资源里若自带 API Key那通常是发布者的极有可能已过期或被平台风控直接用大概率报 403 或 429。GEMINI_API_KEYAIzaSy...你的密钥... GEMINI_MODELgemini-1.5-pro代码逻辑说明python-dotenv 负责读取 .env 里的键值对google-generativeai 在初始化时通过 os.getenv(GEMINI_API_KEY) 拿到密钥。模型名这里写的是示例实际应以你在 Google AI Studio 控制台可见的模型标识为准。需要留意的是网页版 Gemini 登录状态、Gemini Code Assist 订阅资格、学生认证权益这些都和 API Key 是分离的。经常有人拿着网页版账号来问为什么脚本报 not eligible那是两套体系API 计费和控制台权限归属另一个体系。3.2 人物卡与世界观模板的组装函数长篇生成器的核心资产是提示词模板。下面是组装“章节生成 prompt”的函数它把人物状态、上一章摘要、本章细纲拼接成一段结构化输入。# scripts/build_prompt.py from typing import List, Dict def build_chapter_prompt( book_setting: str, characters: List[Dict], previous_summary: str, chapter_plan: Dict ) - str: char_lines [] for c in characters: char_lines.append( f- {c[name]}性格{c[personality]}状态{c[current_state]} ) prompt f 【全书设定】 {book_setting} 【当前人物状态】 {chr(10).join(char_lines)} 【前情提要】 {previous_summary} 【本章细纲】 {chapter_plan[event_description]} 【章节目标】 本章结束时需要推进到{chapter_plan[ending_event]} 请以上内容为唯一事实依据写一篇 3000 字的小说章节。 遵循以下文风{chapter_plan[style_hint]} return prompt逻辑说明这个函数把四类信息放进一个字符串。人物状态是动态读取 JSON 文件后传进来的前情摘要是上一章生成后单独压缩出来的细纲和章节目标是从 outlines 目录读出的。顺序上有讲究——人物状态在前、前情提要在中、章节目标在尾部Gemini 对输入尾部指令的遵从度通常更高所以把最关键的“结束事件”放在最后。参数说明style_hint 字段可以指定本章句式偏好比如“多用短句、少用成语、对话占比不低于 40%”它来自风格配置文件。3.3 调用 Gemini 生成章节完整脚本下面这个脚本是最小可运行版本它把前三节的东西串起来。# scripts/generate_chapter.py import os from dotenv import load_dotenv import google.generativeai as genai from build_prompt import build_chapter_prompt load_dotenv() genai.configure(api_keyos.getenv(GEMINI_API_KEY)) model genai.GenerativeModel( model_nameos.getenv(GEMINI_MODEL, gemini-1.5-pro), generation_configgenai.GenerationConfig( temperature0.7, top_p0.95, max_output_tokens2048, ), ) book_setting 都市异能题材主角表面是废柴外卖员实际是前世渡劫失败的剑仙。 characters [ {name: 林晚, personality: 谨慎、嘴硬心软, current_state: 刚觉醒前尘记忆}, ] previous_summary 主角在出租屋内第一次感知到灵气波动旧识李青瓷找上门。 chapter_plan { event_description: 李青瓷试探主角修为二人交手主角控制力量后约定共同寻找师门遗物。, ending_event: 主角答应合作但隐瞒了自己恢复记忆的程度。, style_hint: 对话推动情节每段不超过三行打斗描写简练。, } prompt build_chapter_prompt(book_setting, characters, previous_summary, chapter_plan) response model.generate_content(prompt) print(response.text)这段代码的逻辑并不复杂但有三点参数细节要说明。第一temperature0.7 是生成小说章节的初始推荐值不要低于 0.5否则文风会变得机械人物对话像说明书。第二max_output_tokens2048 并不等于生成 2048 个汉字——Gemini 的 tokenizer 下一个汉字通常占 1 到 2 个 token连续标点、常见人名可能被合并压缩。经验做法是想要 3000 字正文max_output_tokens 至少给到 4000。第三top_p0.95 保留一定随机性在长篇小说里完全贪心解码会让段落之间出现“复读机”现象这个值到了后续章节甚至可以放宽到 0.98。跑通这个脚本等于打通了“输入细纲 → 输出正文”的任督二脉。接下来真正的工程问题才开始浮现怎么让下一章的输入包含上一章的信息同时不让输入无限膨胀。这正是下一章要解决的。4. 让长篇小说不崩的三件事摘要记忆、风格锚点与重复检测4.1 摘要记忆不是把前文塞回去而是压缩后循环注入很多第一次搭生成器的人会犯同一个错误写第 20 章时把前 19 章正文全部拼进 prompt认为这样模型就“记得”前文。结果 token 消耗巨大不说生成质量明显下降——模型在超长上下文里对前文细节的忠实度很低基本只能记住最近几章的内容。这个现象我称它为“长文黑匣子”输入看起来什么都有实际上模型只处理了尾部。正确做法是摘要记忆。运行完每一章生成后立刻调用一次 Gemini用固定模板让模型输出本章的 150 字摘要包括关键事件推进、人物状态变化、留下的线索。然后把摘要追加到前情提要的字符串末尾。这样第 N 章的 prompt 里前情提要是前面 N-1 章的压缩版而非原文。# scripts/memory_builder.py import google.generativeai as genai SUMMARY_TEMPLATE 请阅读以下小说章节输出一份不超过 200 字的摘要。 必须包含 1. 本章结束时的情节状态 2. 出场人物的状态变化 3. 埋下的伏笔或未解决冲突 不要输出任何与摘要无关的内容。 【正文】 {chapter_text} def build_summary(chapter_text: str) - str: model genai.GenerativeModel(gemini-1.5-flash) response model.generate_content(SUMMARY_TEMPLATE.format(chapter_textchapter_text[:6000])) return response.text.strip()这里特意用了 gemini-1.5-flash 而不是 pro因为摘要是高频操作flash 成本低、速度快。截断 6000 字的做法是防护逻辑单个章节超长时只截取开头、中间、结尾各 2000 字避免摘要 prompt 本身超长。章节正文的关键信息通常分布在中后段所以截取策略里中段比例最大。摘要生成后存进 cache/summaries/文件名用 f{book_name}_ch{chapter_num:03d}.txt排序方便拼接。4.2 风格锚点用禁词表和句式偏好控制文风一致性网络小说最怕的是前二十章还带着冷峻文风写到五十章突然变成轻松搞笑那多半不是故事崩了而是模型在无人约束的情况下自行漂移。zip 包里通常会在 config/style_config.json 里定义风格锚点它是一个列表每次生成章节 prompt 时都注入。{ hard_restrictions: [ 禁止在段落开头连续两次使用“只见”, 禁止使用“微微一笑”“眸光一冷”, 对话内不使用现代网络用语, 每个段落不得超过四行 ], preferred_rhythm: [ 动作描写优先于心理描写, 章节结尾必须留下一个未解决的悬念, 打斗场景用短句一句一个动作 ] }这些规则看着简单实际作用远大于那些“请写出优美小说”的空话。模型对具体禁令的遵从度远高于风格形容。我曾试过在 style_hint 里写“文风要大气磅礴”模型输出全是陈词滥调改成“每段不超过四行、禁用‘不由有些’‘心中暗想’”之后文风立刻利落了不少。这套配置文件不仅是给模型看的也是给生成后处理程序看的。比如“每个段落不得超过四行”这种规则可以在脚本里用正则做二次校验误判时抛给重写流程。人机双重约束比单纯依赖模型自律靠谱得多。4.3 重复检测本地拦截别把返工全压在模型身上长篇小说生成到三五十章时模型会开始重复自己类似的环境描写、类似的反派台词、类似的转折套路。单一章节内看着没问题跨章节对比才能发现问题。这种重复无法靠调温度完全解决需要在本地加一个检测器。# scripts/dedup_check.py from difflib import SequenceMatcher def check_duplicate(prev_text: str, new_text: str, threshold0.55) - bool: prev_chars list(prev_text[-2000:]) new_chars list(new_text[:2000]) ratio SequenceMatcher(None, prev_chars, new_chars).ratio() return ratio threshold if check_duplicate(prev_chapter, new_chapter): print(疑似与上一章开头重复度过高触发重写)逻辑说明这里只对比上一章的结尾 2000 字和本章的开头 2000 字原因在于模型“复读”往往发生在接续处——它会把上一章结尾场景重新展开一遍。SequenceMatcher 返回两个序列的相似度55% 以上的相似度需要警惕80% 以上基本可以断定就是复读。阈值可以根据文风调整开头连续出现同一场景的桥段可以考虑调低到 0.45而对话风格固定、高频套路的作者可以放宽到 0.6。这个检测器不是判断“能不能用”而是判断“要不要花 token 重写”输出一个二值信号人最后拍板。4.4 参数分级参考不是全程一个 temperature生成阶段推荐模型temperaturetop_p说明全书大纲gemini-1.5-pro0.50.9需要结构稳定分卷细纲gemini-1.5-pro0.60.92允许一定发散章节正文gemini-1.5-pro0.70.95兼顾剧情推进与文风章节摘要gemini-1.5-flash0.30.9压缩任务不允许发散续写重写gemini-1.5-pro0.80.98重写时提高随机性参数不是越大越好。正文阶段 temperature 到 0.8 以上后剧情开始不受控地偏离细纲常见表现是主角做出计划外行动、支线人物突然登场。摘要阶段降到 0.3 是因为摘要要求“准确压缩”发散会让摘要引入原文不存在的情节进而污染后续所有章节的前情提要。这个分级表是我在实际跑完一卷之后定下来的回头客的做法是先把表固化到 config再根据自己题材调整上限。5. 落地避坑API 限流、上下文超长与 zip 解压翻车的 5 个记录5.1 报错 403 PERMISSION_DENIED账号没问题是 Key 没有权限现象按教程配好了 .env运行时 Gemini API 返回 403 PermissionDenied错误信息里带着 your account is not eligible 之类字样。原因这里要分清两件事。网页版 Gemini、Gemini Code Assist、Google AI Studio 的 API Key 是三个独立的体系。申请到 API Key 不等于有权限调用所有模型也不等于在 Google Cloud 项目里启用了 Generative Language API。大部分 403 来自项目未开通对应服务少数来自模型名称写错导致路由失败。解决登录 Google AI Studio 控制台确认当前项目已经启用 Generative AI 服务重新生成一把 API Key 并立刻复制到 .env注意不要带换行。模型名以控制台开发者文档为准不要照着旧教程写已被替换的型号名。5.2 429 RESOURCE_EXHAUSTED免费额度被打穿批量生成到一半停摆现象脚本单章跑没问题循环批量生成到十几章后开始频繁报 429有时间隔几分钟重试又能过但再过几章又挂。原因API 有每分钟请求次数或每日 token 配额限制免费档额度有限。批量脚本没有做限速一秒钟连发好几个请求直接打穿配额。解决引入指数退避和请求队列。报 429 后等待 30 秒重试还失败就翻倍等待。最省事的实现是给每次调用加上重试装饰器。另一个血泪经验是cache 目录里保存的原始响应绝对不能跳过批量中断后从最后成功一章的序号继续而不是从头再跑一遍。删除已成功的章节重跑既费 token 又可能让前后章节风格不一致。5.3 提示词超长生成章节前突然报 400 INVALID_ARGUMENT现象跑前几章正常跑到某章后build_chapter_prompt 生成的 prompt 被 API 拒绝返回 400。原因最常见的是前情提要无限累积。摘要虽然压到了 200 字但每章都追加跑到上百章后摘要串本身也有两万多字加上角色卡和细纲触到了单次请求的输入长度限制。其次是个别章节文本异常庞大导致 summary 的截断逻辑失效。解决为摘要串设置一个硬上限。每追加新摘要后检查总长度超出 8000 字符时从头到尾再调用一次 Gemini把所有摘要二次压缩成一份新的 2000 字前情提要。这样前情提要永远维持在一个可控规模。注意二次压缩的 prompt 也要用模板否则压缩出来的内容会丢掉基本信息。5.4 章节内容重复几十章后主角行为像平行时空现象同一章细纲换个随机种子生成两次第二次竟然还和第一次某些段落一模一样跨章节时主角在第 21 章已经知道的事第 23 章又重新发现了一遍。原因第一是生成时 temperature 过低导致采样路径单一第二是前情提要没有把“已知信息”单独列出来。模型看到的世界观和人物状态没有更新自然只能复述旧节奏。解决在章节 prompt 里加入“已知信息锁定”区块内容来自角色 JSON 的 current_state 和前情提要中的已解决问题列表。这个区块的作用是告诉模型这些事情发生过不要重复。配合 4.3 节的重复检测器本地指标异常时自动重写。另外random seed 不要固定Gemini API 不承诺同一个 seed 产生同一个结果固定 seed 反而容易让后续章节陷入同一条采样路径。5.5 zip 解压乱码、目录缺失、依赖对不上现象花力气从网上下载了“基于 Gemini 大模型的超长篇小说生成器.zip”在电脑上双击解压结果目录全是乱码或者按 README 运行时报 ModuleNotFoundError。原因这类 zip 多为 UTF-8 编码文件名老版本 Windows 资源管理器默认按本机 ANSI/GBK 解码中文目录名直接显示成乱码。模块找不到则常见于资源打包者把 requirements.txt 里写了一大堆但核心代码用的是另一套版本。解决优先用 7-Zip 或 WinRAR 解压这两个工具对 UTF-8 文件名支持更完整。如果已经解压乱了用 Python 的 zipfile 模块重新解压指定编码为 utf-8。解压后不要急跑主脚本先建虚拟环境再装 requirements.txt。如果遇到 zip 本身带解压密码不要轻信网上所谓的“移除密码”宣称先在新版本发布说明或附带的 txt 文件里找密码暴力破解这类资源不现实也不划算。6. 进阶验证用上一章结尾做续写校验把返工率压到最低批量生成长篇之后的返工一大半来自章节接缝处。上一章停在主角走进古宅下一章却从主角在客栈醒来开始这种断裂感读者一眼就能察觉。我习惯在每次生成下一章正文之前先做一次“接缝校验”把上一章最后的 200 字文本作为硬约束放进一个独立的校验 prompt让 Gemini 判断待生成细纲中的起始事件是否与这段接缝自然衔接。校验通过才调用正文生成。这么做多了一次 API 调用但省掉的返工远大于成本。另一个参数值得固化到脚本里把上一章结尾的物理位置、在场人物、时间线作为 JSON 字段写进 chapter_plan下一章的起始状态全部从这些字段推导而不是让模型自由发挥。人判断接缝是“感觉对不对”生成器接缝是“字段是否连续”两者结合才稳。我自己的习惯是每次批量生成前先在 cache/summaries 目录跑一遍摘要构建确认前情提要链表完整跑完一卷后再把全书大纲拿去对照实际章节事件检查有没有偏离原定走向。一旦发现有偏差就用对应的卷级细纲重写受影响章节而不是从头返工。这算是我的“后悔药”每次翻车之前都能兜底。希望帮到你。本文还有配套的精品资源点击获取 基于Gemini的超长篇小说生成器：百万字文本生成的工程实践
简介这是一款基于Gemini大模型的超长篇小说生成器专为网络小说作者、编剧及AI应用开发者设计针对百万字级长篇创作场景解决剧情连贯性差、设定易崩塌、逻辑矛盾频发等常见痛点。压缩包为zip格式共30个文件核心为20个Python脚本对应小说设定工坊、智能章节生成、状态追踪、语义检索、自动审校等完整功能模块另有配置文件示例、README说明文档与文本资源整体仅106KB轻量易部署便于快速上手与二次开发。目前已有139人学习浏览。代码脉络清晰通过可视化工作台即可一站式完成世界观架构、角色设定与剧情蓝图规划并借助基于向量的语义检索引擎与伏笔管理系统维护长程上下文一致性自动检测剧情矛盾和逻辑冲突保障多阶段生成的连贯性配合状态追踪系统与知识库集成可实时记录角色发展轨迹、管理伏笔并引用本地文档作为创作参考。对于希望搭建个人AI写作流水线、研究大模型长文本生成或快速启动网文创作项目的开发者均具有不错的参考价值与实践意义。1. 百万字网络小说生成器为什么说 Gemini 是唯一敢接“整本书”这个活的模型拿到“基于 Gemini 大模型的超长篇小说生成器”这个压缩包时很多人第一反应是把它当成一个“输入几个关键词就哗啦啦吐十万字”的玩具。实际上只要跑过一轮就会发现真正的技术难点不在单次生成而在“百万字”这三个字——怎么让模型不忘记第一卷埋的伏笔怎么让第一百章的文风和第三章保持一致怎么让角色三十万字之后开口说话还是原来那个人。这些问题靠一次 prompt 解决不了它需要一条可拆解的流水线。而 Gemini 的百万级上下文窗口恰恰是这条流水线能成立的前提。这个 zip 包本质上是一个工程模板围绕 Gemini API 把超长篇小说生成拆成大纲、分卷、章节、摘要记忆和重复检测几个模块。适用对象是有 Python 基础、申请了 Google AI Studio API Key、想自己搭一套批量产出长篇的从业者。新手照着配置能跑通最小流程熟手可以按自己的需求替换模型、改提示词模板。下面我从架构开始讲。2. 先把生成器拆成流水线大纲 → 分卷 → 章节的三级约束架构2.1 为什么长上下文模型是超长篇的唯一出路写长篇小说最头疼的不是写不出来是“写到后面忘了前面”。传统模型做文本生成时上下文窗口只有几千到几万个 token塞下几个人物设定和开篇三章就满了。想要保证前后一致只能把前文一并丢进输入窗口立刻爆炸。Gemini 系列主推百万级 token 的上下文窗口相当于可以把一部中长篇的网络小说正文完整放进一次请求里。但这里有一个常见误区我一般不建议真的把“整本书”塞进一个 prompt 让模型一口气续写。原因有两个。其一输出长度有上限Gemini API 单次输出的 token 数远小于输入上限指望它输出几十万字文本不现实。其二模型注意力在超长输入上会衰退真正用到的往往是输入尾部的内容中间的情节容易被稀释。长上下文的意义不是“一次生成百万字”而是“在需要回顾时装得下足够长的记忆”。这个定位很关键。2.2 三级约束为什么“直接让模型写全文”必崩在跑通这个 zip 包的工程结构之后我发现它的设计思路和网文编辑的审稿流程很像先定全书主题再拆成卷每卷再拆成章节。三级结构每一层都调用一次 Gemini但 prompt 完全不同。第一级是“全书大纲”。给模型一个故事题材、主角设定、结局方向让它输出三五十个字的卷级标题和每卷的核心冲突。第二级是“分卷细纲”。把某一卷的标题和结局事件交给模型让它拆出十几章的小节每节一百字左右包含本章要发生的三到四个关键情节点。第三级是“章节正文”。拿着细纲中的一章内容加上人物状态卡让模型扩写成三千到五千字的正文。为什么这么分因为一次性让模型规划百万字它给出的框架往往是空的诸如“主角成长”“对手出现”这类没法直接落地执行。拆到章节这一级时每一章输入里可以包含准确的出场人物、地点、时间线、章节目标事件模型发挥空间被约束在真实可写的范围内。这比“给一个笼统设定靠模型自己编”稳定得多。2.3 zip 包内的目录结构配置、缓存、与输出分离解压这个生成器 zip 包之后我通常先不看代码而是看它的目录组织。一个合格的生成器工程应当把“配置”“中间产物”“最终输出”三者分开否则跑长篇时会乱成一锅。novel_generator/ ├── config/ │ ├── api_config.json │ ├── characters/ │ │ └── 主角_林晚.json │ └── style_config.json ├── outlines/ │ ├── book_outline.json │ ├── volume_01.json │ └── chapter_01_plan.json ├── chapters/ │ ├── generated/ │ └── checkpoints/ ├── cache/ │ ├── summaries/ │ └── raw_responses/ ├── scripts/ │ ├── generate_outline.py │ ├── generate_chapter.py │ └── memory_builder.py └── requirements.txtapi_config.json 存放 API Key 和模型名characters 目录下每个角色一个 JSON 文件字段包括身份、性格、说话习惯、当前状态。outlines 下存三级大纲chapters 下存最终生成的正文和断点cache 目录存每次调用 Gemini 返回的原始响应。这样设计的好处是某一章生成失败时可以直接使用 cache 里的原始响应做断点续调不必重新花 token 生成一遍——这一点在后面避坑章节会展开讲。2.4 配置化存储用 JSON 做结构化记忆我最看重这个 zip 方案里的一点是小说不是“文本流”而是“状态流”。人物状态、地点状态、物品归属这些信息如果用自然语言塞进 prompt模型会模糊处理。用 JSON 结构存储读取时按 key 取用写入时按 key 更新才能实现精确控制。# scripts/character_state.py import json def load_character(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def update_character_state(path: str, updates: dict) - None: char_data load_character(path) char_data[current_state].update(updates) with open(path, w, encodingutf-8) as f: json.dump(char_data, f, ensure_asciiFalse, indent2)这段代码做的事情很简单读取角色的 JSON 状态文件更新 current_state 字段再写回。但它在长篇生成中起到的作用是“唯一事实源”。比如主角在第三卷断了一条手臂这个状态必须写进 JSON 文件然后在后续章节的 prompt 里明确注入“林晚右臂已断”而不是靠模型自己记住。参数说明ensure_asciiFalse 保证中文以明文写入避免 \uXXXX 转义indent2 是让文件可读方便人工检查和回滚。血泪经验是最初我偷懒把角色状态靠模型“自行保持”结果第二卷还没结束主角就长出了新手。从那时起状态必须落盘不存在例外。3. 用 Gemini API 跑通第一个最小章节生成脚本3.1 环境准备API Key 与依赖安装安装依赖时建议在虚拟环境里做。这个 zip 包里的 requirements.txt 一般包含 google-generativeai 这个官方 SDK以及用于 JSON 处理和文本匹配的库。我这里只说最小集。python -m venv venv source venv/bin/activate pip install google-generativeai pip install python-dotenv安装完成后在项目根目录创建 .env 文件写入你的 API Key。.env 文件不要提交到代码仓库也不要放进分发给别人的 zip 包里。有经验的读者会问为什么 .env 会被写进 zip这正是要提醒新手的第一件事——网上流传的生成器资源里若自带 API Key那通常是发布者的极有可能已过期或被平台风控直接用大概率报 403 或 429。GEMINI_API_KEYAIzaSy...你的密钥... GEMINI_MODELgemini-1.5-pro代码逻辑说明python-dotenv 负责读取 .env 里的键值对google-generativeai 在初始化时通过 os.getenv(GEMINI_API_KEY) 拿到密钥。模型名这里写的是示例实际应以你在 Google AI Studio 控制台可见的模型标识为准。需要留意的是网页版 Gemini 登录状态、Gemini Code Assist 订阅资格、学生认证权益这些都和 API Key 是分离的。经常有人拿着网页版账号来问为什么脚本报 not eligible那是两套体系API 计费和控制台权限归属另一个体系。3.2 人物卡与世界观模板的组装函数长篇生成器的核心资产是提示词模板。下面是组装“章节生成 prompt”的函数它把人物状态、上一章摘要、本章细纲拼接成一段结构化输入。# scripts/build_prompt.py from typing import List, Dict def build_chapter_prompt( book_setting: str, characters: List[Dict], previous_summary: str, chapter_plan: Dict ) - str: char_lines [] for c in characters: char_lines.append( f- {c[name]}性格{c[personality]}状态{c[current_state]} ) prompt f 【全书设定】 {book_setting} 【当前人物状态】 {chr(10).join(char_lines)} 【前情提要】 {previous_summary} 【本章细纲】 {chapter_plan[event_description]} 【章节目标】 本章结束时需要推进到{chapter_plan[ending_event]} 请以上内容为唯一事实依据写一篇 3000 字的小说章节。 遵循以下文风{chapter_plan[style_hint]} return prompt逻辑说明这个函数把四类信息放进一个字符串。人物状态是动态读取 JSON 文件后传进来的前情摘要是上一章生成后单独压缩出来的细纲和章节目标是从 outlines 目录读出的。顺序上有讲究——人物状态在前、前情提要在中、章节目标在尾部Gemini 对输入尾部指令的遵从度通常更高所以把最关键的“结束事件”放在最后。参数说明style_hint 字段可以指定本章句式偏好比如“多用短句、少用成语、对话占比不低于 40%”它来自风格配置文件。3.3 调用 Gemini 生成章节完整脚本下面这个脚本是最小可运行版本它把前三节的东西串起来。# scripts/generate_chapter.py import os from dotenv import load_dotenv import google.generativeai as genai from build_prompt import build_chapter_prompt load_dotenv() genai.configure(api_keyos.getenv(GEMINI_API_KEY)) model genai.GenerativeModel( model_nameos.getenv(GEMINI_MODEL, gemini-1.5-pro), generation_configgenai.GenerationConfig( temperature0.7, top_p0.95, max_output_tokens2048, ), ) book_setting 都市异能题材主角表面是废柴外卖员实际是前世渡劫失败的剑仙。 characters [ {name: 林晚, personality: 谨慎、嘴硬心软, current_state: 刚觉醒前尘记忆}, ] previous_summary 主角在出租屋内第一次感知到灵气波动旧识李青瓷找上门。 chapter_plan { event_description: 李青瓷试探主角修为二人交手主角控制力量后约定共同寻找师门遗物。, ending_event: 主角答应合作但隐瞒了自己恢复记忆的程度。, style_hint: 对话推动情节每段不超过三行打斗描写简练。, } prompt build_chapter_prompt(book_setting, characters, previous_summary, chapter_plan) response model.generate_content(prompt) print(response.text)这段代码的逻辑并不复杂但有三点参数细节要说明。第一temperature0.7 是生成小说章节的初始推荐值不要低于 0.5否则文风会变得机械人物对话像说明书。第二max_output_tokens2048 并不等于生成 2048 个汉字——Gemini 的 tokenizer 下一个汉字通常占 1 到 2 个 token连续标点、常见人名可能被合并压缩。经验做法是想要 3000 字正文max_output_tokens 至少给到 4000。第三top_p0.95 保留一定随机性在长篇小说里完全贪心解码会让段落之间出现“复读机”现象这个值到了后续章节甚至可以放宽到 0.98。跑通这个脚本等于打通了“输入细纲 → 输出正文”的任督二脉。接下来真正的工程问题才开始浮现怎么让下一章的输入包含上一章的信息同时不让输入无限膨胀。这正是下一章要解决的。4. 让长篇小说不崩的三件事摘要记忆、风格锚点与重复检测4.1 摘要记忆不是把前文塞回去而是压缩后循环注入很多第一次搭生成器的人会犯同一个错误写第 20 章时把前 19 章正文全部拼进 prompt认为这样模型就“记得”前文。结果 token 消耗巨大不说生成质量明显下降——模型在超长上下文里对前文细节的忠实度很低基本只能记住最近几章的内容。这个现象我称它为“长文黑匣子”输入看起来什么都有实际上模型只处理了尾部。正确做法是摘要记忆。运行完每一章生成后立刻调用一次 Gemini用固定模板让模型输出本章的 150 字摘要包括关键事件推进、人物状态变化、留下的线索。然后把摘要追加到前情提要的字符串末尾。这样第 N 章的 prompt 里前情提要是前面 N-1 章的压缩版而非原文。# scripts/memory_builder.py import google.generativeai as genai SUMMARY_TEMPLATE 请阅读以下小说章节输出一份不超过 200 字的摘要。 必须包含 1. 本章结束时的情节状态 2. 出场人物的状态变化 3. 埋下的伏笔或未解决冲突 不要输出任何与摘要无关的内容。 【正文】 {chapter_text} def build_summary(chapter_text: str) - str: model genai.GenerativeModel(gemini-1.5-flash) response model.generate_content(SUMMARY_TEMPLATE.format(chapter_textchapter_text[:6000])) return response.text.strip()这里特意用了 gemini-1.5-flash 而不是 pro因为摘要是高频操作flash 成本低、速度快。截断 6000 字的做法是防护逻辑单个章节超长时只截取开头、中间、结尾各 2000 字避免摘要 prompt 本身超长。章节正文的关键信息通常分布在中后段所以截取策略里中段比例最大。摘要生成后存进 cache/summaries/文件名用 f{book_name}_ch{chapter_num:03d}.txt排序方便拼接。4.2 风格锚点用禁词表和句式偏好控制文风一致性网络小说最怕的是前二十章还带着冷峻文风写到五十章突然变成轻松搞笑那多半不是故事崩了而是模型在无人约束的情况下自行漂移。zip 包里通常会在 config/style_config.json 里定义风格锚点它是一个列表每次生成章节 prompt 时都注入。{ hard_restrictions: [ 禁止在段落开头连续两次使用“只见”, 禁止使用“微微一笑”“眸光一冷”, 对话内不使用现代网络用语, 每个段落不得超过四行 ], preferred_rhythm: [ 动作描写优先于心理描写, 章节结尾必须留下一个未解决的悬念, 打斗场景用短句一句一个动作 ] }这些规则看着简单实际作用远大于那些“请写出优美小说”的空话。模型对具体禁令的遵从度远高于风格形容。我曾试过在 style_hint 里写“文风要大气磅礴”模型输出全是陈词滥调改成“每段不超过四行、禁用‘不由有些’‘心中暗想’”之后文风立刻利落了不少。这套配置文件不仅是给模型看的也是给生成后处理程序看的。比如“每个段落不得超过四行”这种规则可以在脚本里用正则做二次校验误判时抛给重写流程。人机双重约束比单纯依赖模型自律靠谱得多。4.3 重复检测本地拦截别把返工全压在模型身上长篇小说生成到三五十章时模型会开始重复自己类似的环境描写、类似的反派台词、类似的转折套路。单一章节内看着没问题跨章节对比才能发现问题。这种重复无法靠调温度完全解决需要在本地加一个检测器。# scripts/dedup_check.py from difflib import SequenceMatcher def check_duplicate(prev_text: str, new_text: str, threshold0.55) - bool: prev_chars list(prev_text[-2000:]) new_chars list(new_text[:2000]) ratio SequenceMatcher(None, prev_chars, new_chars).ratio() return ratio threshold if check_duplicate(prev_chapter, new_chapter): print(疑似与上一章开头重复度过高触发重写)逻辑说明这里只对比上一章的结尾 2000 字和本章的开头 2000 字原因在于模型“复读”往往发生在接续处——它会把上一章结尾场景重新展开一遍。SequenceMatcher 返回两个序列的相似度55% 以上的相似度需要警惕80% 以上基本可以断定就是复读。阈值可以根据文风调整开头连续出现同一场景的桥段可以考虑调低到 0.45而对话风格固定、高频套路的作者可以放宽到 0.6。这个检测器不是判断“能不能用”而是判断“要不要花 token 重写”输出一个二值信号人最后拍板。4.4 参数分级参考不是全程一个 temperature生成阶段推荐模型temperaturetop_p说明全书大纲gemini-1.5-pro0.50.9需要结构稳定分卷细纲gemini-1.5-pro0.60.92允许一定发散章节正文gemini-1.5-pro0.70.95兼顾剧情推进与文风章节摘要gemini-1.5-flash0.30.9压缩任务不允许发散续写重写gemini-1.5-pro0.80.98重写时提高随机性参数不是越大越好。正文阶段 temperature 到 0.8 以上后剧情开始不受控地偏离细纲常见表现是主角做出计划外行动、支线人物突然登场。摘要阶段降到 0.3 是因为摘要要求“准确压缩”发散会让摘要引入原文不存在的情节进而污染后续所有章节的前情提要。这个分级表是我在实际跑完一卷之后定下来的回头客的做法是先把表固化到 config再根据自己题材调整上限。5. 落地避坑API 限流、上下文超长与 zip 解压翻车的 5 个记录5.1 报错 403 PERMISSION_DENIED账号没问题是 Key 没有权限现象按教程配好了 .env运行时 Gemini API 返回 403 PermissionDenied错误信息里带着 your account is not eligible 之类字样。原因这里要分清两件事。网页版 Gemini、Gemini Code Assist、Google AI Studio 的 API Key 是三个独立的体系。申请到 API Key 不等于有权限调用所有模型也不等于在 Google Cloud 项目里启用了 Generative Language API。大部分 403 来自项目未开通对应服务少数来自模型名称写错导致路由失败。解决登录 Google AI Studio 控制台确认当前项目已经启用 Generative AI 服务重新生成一把 API Key 并立刻复制到 .env注意不要带换行。模型名以控制台开发者文档为准不要照着旧教程写已被替换的型号名。5.2 429 RESOURCE_EXHAUSTED免费额度被打穿批量生成到一半停摆现象脚本单章跑没问题循环批量生成到十几章后开始频繁报 429有时间隔几分钟重试又能过但再过几章又挂。原因API 有每分钟请求次数或每日 token 配额限制免费档额度有限。批量脚本没有做限速一秒钟连发好几个请求直接打穿配额。解决引入指数退避和请求队列。报 429 后等待 30 秒重试还失败就翻倍等待。最省事的实现是给每次调用加上重试装饰器。另一个血泪经验是cache 目录里保存的原始响应绝对不能跳过批量中断后从最后成功一章的序号继续而不是从头再跑一遍。删除已成功的章节重跑既费 token 又可能让前后章节风格不一致。5.3 提示词超长生成章节前突然报 400 INVALID_ARGUMENT现象跑前几章正常跑到某章后build_chapter_prompt 生成的 prompt 被 API 拒绝返回 400。原因最常见的是前情提要无限累积。摘要虽然压到了 200 字但每章都追加跑到上百章后摘要串本身也有两万多字加上角色卡和细纲触到了单次请求的输入长度限制。其次是个别章节文本异常庞大导致 summary 的截断逻辑失效。解决为摘要串设置一个硬上限。每追加新摘要后检查总长度超出 8000 字符时从头到尾再调用一次 Gemini把所有摘要二次压缩成一份新的 2000 字前情提要。这样前情提要永远维持在一个可控规模。注意二次压缩的 prompt 也要用模板否则压缩出来的内容会丢掉基本信息。5.4 章节内容重复几十章后主角行为像平行时空现象同一章细纲换个随机种子生成两次第二次竟然还和第一次某些段落一模一样跨章节时主角在第 21 章已经知道的事第 23 章又重新发现了一遍。原因第一是生成时 temperature 过低导致采样路径单一第二是前情提要没有把“已知信息”单独列出来。模型看到的世界观和人物状态没有更新自然只能复述旧节奏。解决在章节 prompt 里加入“已知信息锁定”区块内容来自角色 JSON 的 current_state 和前情提要中的已解决问题列表。这个区块的作用是告诉模型这些事情发生过不要重复。配合 4.3 节的重复检测器本地指标异常时自动重写。另外random seed 不要固定Gemini API 不承诺同一个 seed 产生同一个结果固定 seed 反而容易让后续章节陷入同一条采样路径。5.5 zip 解压乱码、目录缺失、依赖对不上现象花力气从网上下载了“基于 Gemini 大模型的超长篇小说生成器.zip”在电脑上双击解压结果目录全是乱码或者按 README 运行时报 ModuleNotFoundError。原因这类 zip 多为 UTF-8 编码文件名老版本 Windows 资源管理器默认按本机 ANSI/GBK 解码中文目录名直接显示成乱码。模块找不到则常见于资源打包者把 requirements.txt 里写了一大堆但核心代码用的是另一套版本。解决优先用 7-Zip 或 WinRAR 解压这两个工具对 UTF-8 文件名支持更完整。如果已经解压乱了用 Python 的 zipfile 模块重新解压指定编码为 utf-8。解压后不要急跑主脚本先建虚拟环境再装 requirements.txt。如果遇到 zip 本身带解压密码不要轻信网上所谓的“移除密码”宣称先在新版本发布说明或附带的 txt 文件里找密码暴力破解这类资源不现实也不划算。6. 进阶验证用上一章结尾做续写校验把返工率压到最低批量生成长篇之后的返工一大半来自章节接缝处。上一章停在主角走进古宅下一章却从主角在客栈醒来开始这种断裂感读者一眼就能察觉。我习惯在每次生成下一章正文之前先做一次“接缝校验”把上一章最后的 200 字文本作为硬约束放进一个独立的校验 prompt让 Gemini 判断待生成细纲中的起始事件是否与这段接缝自然衔接。校验通过才调用正文生成。这么做多了一次 API 调用但省掉的返工远大于成本。另一个参数值得固化到脚本里把上一章结尾的物理位置、在场人物、时间线作为 JSON 字段写进 chapter_plan下一章的起始状态全部从这些字段推导而不是让模型自由发挥。人判断接缝是“感觉对不对”生成器接缝是“字段是否连续”两者结合才稳。我自己的习惯是每次批量生成前先在 cache/summaries 目录跑一遍摘要构建确认前情提要链表完整跑完一卷后再把全书大纲拿去对照实际章节事件检查有没有偏离原定走向。一旦发现有偏差就用对应的卷级细纲重写受影响章节而不是从头返工。这算是我的“后悔药”每次翻车之前都能兜底。希望帮到你。本文还有配套的精品资源点击获取