• 打开输出token选项，设置接近顶格的max_output_tokens:65000 • 检查客户端具体参数（如果可以），确保stopSequences为空数组 • 指定清晰、具体、长提纲，为每个Part指定具体的、尽可能长的Tokens数 • 指示AI在达到输出上限时只需持续输出至极限停止，不做任何收束与总结 • 打开流式输出 • 长思维链预算 • 排除AI输出Markdown等特殊格式的可能；降低AI输出敏感词的几率，防止触发敏感词截断 • 高温度、高创意（直接关系不大，保守起见可以中 比如0.7，希望尽可能增加字数和创造性可以开高 例如1） • 递归续写法，或许可超过65535tokens限制（尚未经充分测试）
我们以Gemini 2.5 Pro近期版本0506或0605进行举例。
Gemini 2.5 Pro API 的硬指标很“豪横”——官方在 Vertex AI 与 Google AI Studio 的型号页都写得很清楚：单次输入可达 1 048 576 tokens，单次输出上限 65 535 tokens。
折算一下：六万五千余个 token 至少约等于 250 000 – 260 000 汉字，一口气能写出一部中等篇幅的网络小说章节。
为什么你常见的大模型的实际输出远没这么长？
1. 前端／SDK 保护阀——Gemini 网页版和不少第三方客户端为了避免浏览器死锁，把响应硬砍在几千词左右；社区里已有多次提问确认这一点。 2. 安全与预算策略——Gemini 2.5 Pro 新增了“configurable thinking budgets”（可配置思考预算），Google 会根据负载与安全策略在内部截断生成，哪怕你把 maxOutputTokens 设置到最大，也可能在触发安全或预算阈值时提前收尾。 3. finish_reason=MAX_TOKENS——当模型触顶或被 stop_sequences 拦截，返回值里的 finish_reason 会注明，它不会像早期模型那样直接报错，而是给出一个合法但被截断的候选文本。
决定“单次输出长度”的直接变量
Tips：temperature、topP、topK只影响选词随机度，与篇幅长短关系比较小。
让 Gemini 持续吐出长文的三步法
第一步：打开流式输出接口
改用streamGenerateContent（或 SDK 中的stream=True）。长文时边收边写能绕开 HTTP 超时，也不会占用巨大内存。
在Cherry studio中的流式输出选项：
如图所示
在 generation_config 里直接拉满：
{ "maxOutputTokens": 65000, "stopSequences": [], "temperature": 0.9 }
若你的项目开启了 “thinking budget（思考链长度）”，同时把 budget 调到 large，避免内部提前收束。
如图所示
第二步，：结构化指示输出，禁止收束，持续写作
Gemini 2.5 Pro 的官方上限是 65 535 tokens；把stopSequences设成空数组即可完全取消软性截断。
剩下就交给提示词：用系统角色给模型一道“死命令”——沉浸写作，直到撞到硬上限才准收笔。
{
"contents": [
{
"role": "system",
"parts": [
{
"text": "你正在编写一部长篇幻想小说的第一卷。保持同一叙事视角与文风，专注场景与细节描写，不要总结，不要提前收束。除非输出达到模型最大限制，否则绝不结束。"
}
]
},
{
"role": "user",
"parts": [
{
"text": "第一卷大纲如下：\n——王都春祭，少年侍卫莱昂意外拾得封印之剑；\n——祭典爆发混战，王女被掳，莱昂被迫踏上追踪之旅；\n——沿途遭遇盗贼同盟、隐士炼金术师、古代遗迹；\n——终章在黑曜塔顶与掳走王女的白银龙骑士决战。\n请以沉浸镜头，从春祭清晨的市集喧嚣写起，完整展开第一卷全部剧情。"
}
]
}
],
"generationConfig": {
"maxOutputTokens": 65000,
"stopSequences": [],
"temperature": 0.7
}
}设计提示词的要点：
1. 只说一件事——不停写。排除总结概括；禁止在章节终点收束。 2. 用户指令给出清晰、线性的大纲。大纲越具体，模型越少兜圈子，token 更容易被剧情填满而不是自我重复。 3. 场景化开门。从“春祭清晨的市集喧嚣”这类具体画面切入，模型会自然沿时间线推进，持续消耗 token。 4. 参数配合。 stopSequences置空，temperature任意，可中等或高；streamGenerateContent流式输出。
上边是AI生成的一段完整提示词，使用Markdown格式也是可以的。
还是以上边那段提示词为例，你可尽可能丰富提示词每一章具体章纲，并明确、清晰、段落收尾有明确场景、情节可供AI展开的原则来进行优化。
理想状态下，照此格式调用，Gemini 会从市集的炊烟一直写到黑曜塔顶的龙翼，没有任何“继续？”的询问，直到 65 000 token 触顶后以 finish_reason = "MAX_TOKENS" 自动断句。
第三步(探索进一步提升可能）：详细提纲控制+“接力提示词”确保不中断
接下来，是结合OpenAI和Gemini Deepresearch所得的一个新的方法，未经测试，可以听一听，或许有用。
首先确保一个详细的大纲，为AI指定尽可能长的分块写作内容。
用下面的提示词模板驱动模型写分块文本，每块恰巧到 60 K+ token 触顶，自动出现 finish_reason="MAX_TOKENS" 时立即续写：
<system>
你正在为一部长篇网络小说生成正文。保持统一文风，并在每段末尾输出
“【PART_END】”。当你到达输出上限时停止在句末，不要写总结。
</system>
<user>
小说大纲如下……
现在从 Chapter 1 开始，尽情展开，不要省略细节。
</user>代码侧逻辑示例（伪码）：
while True:
response = model.stream_generate_content(messages, max_output_tokens=65000)
save(response.text)
if response.candidates[0].finish_reason != "MAX_TOKENS":
break
messages.append({"role": "user", "content": "继续。"})这种“检测 finish_reason→追加 继续”的对话递归可以无缝拼接多段 65 K token 输出，理论上只受账号的 每日 tokens 配额 和 账单 约束，
经验小结
• 前期设置方面、最大输出token参数 max_output_tokens、高思维链预算、流式输出、是可以调整的关键• 内容越具体，指令却清晰，敏感内容越少，越不易触发Gemini安全截断。 • 把结构清晰、内容明确的长篇大纲、人物表、世界观提前塞进提升词，能减少模型“兜圈子”导致的无谓 token 消耗。 • 若担心单回合 65 K 仍不够，先让模型输出完整分章目录，然后逐章调用，可避免在中间被安全策略中断后找不到续写位置。 • 遇到突然空白或 HTML blob，大概率是 Markdown 代码块或表格被过滤，尝试在提示词里禁用 Markdown 并改用纯文本。
在做好这些设置之后，Gemini 2.5 Pro 在实践中完全可以稳定输出 20000 甚至 100000 token 级别的长篇文本，而停止点只取决于你何时说“到此为止可以了”。
最后，说一下船板本人的经验。
由于Gemini等诸多主流大模型都是大语言模型，大语言模型输出的本质是概率计算和对人类语言形态的模拟，换句话说，当AI“俺寻思该这样”的时候，它就会按照自己“寻思”出来的模糊形象去输出内容。而不是像计算机程序一样，接到什么就执行什么。
对于大模型而言，要求其输出具体的8000tokens或者9000tokens这样具体到要求是没有意义的，对于大模型而言，他充其量能够根据训练，得知这是一段较长的文字。我们要求其输出多少，其实是一个“大概意思”的传递。
因此，如果我们要尽可能长的一次性输出，不仅应该将指定的输出tokens说的尽量高，也应该兼顾合理性。只有提示词准确、清晰、具体、合理，结合长tokens的指令，才能更容易确保长输出。
大模型的输出，其实很多时候就是一个让它觉得“气氛到位了”的技巧。
例如，我们要求AI以王小明早晨起来给自己做了煎鸡蛋，这段剧情，一次输出60000tokens的小说。这样一个要求，显然是不合理的。
AI也很难输出这样一段超长的文字的。
而如果我们将王小明从小到大的人生经历，以及他的人物关系，雄心壮志，吃了煎鸡蛋之后他就要上战场去拯救世界……这样丰富的剧情以蒙太奇形式插入到早晨做煎鸡蛋到剧情中，当我们告诉AI，王小明今天早晨煎鸡蛋实际只是他人生中最关键的那一天中一个最具有象征意义的片段……那么我们就实际将提纲扩写到了足以支撑十万字中篇小说的地步。
这样一来，气氛就到位了，AI就很容易生成长文本了。