真正能够完成的百页文档

今年早些时候，我们写过关于生成数百页文档和演示文稿的文章。能够要求生成一份 100 页的报告是一回事。但每次都完整获取全部 100 页，且让第 87 页的质量与第 3 页一样好，事实证明这是一个更难解决的问题，也是导致我们今年收到最令人沮丧的 Bug 报告的原因：一份看起来已经完成的文档，却在第 14 页戛然而止。

本文将解释长文档生成的工作原理、我们在 v1.11.1 中做出的改变，以及在需要超长文档时如何获得最佳效果。

长文档是如何制作出来的

NextDocs 不会要求单个模型一口气写完 100 页。而是由三个角色分工合作：

路由模型 (Router) 读取您的请求，并决定文档的类型、长度、结构以及使用哪条通道。
生成模型 (Create model) 逐章节撰写文档，并实时流式传输到画布上，以便您可以边写边看。
更新模型 (Update model) 负责处理您随后要求的修改，一次只修改一个章节，而无需重新生成其余内容。

每个角色都运行在最适合它的模型上。路由模型体量小且速度快。生成模型则根据您的方案和模式进行选择：极速通道（fast lane）使用 GPT-5.6 Luna，质量通道（quality lane）使用 Gemini 3.8 Flash，高级通道（premium lane）使用 Claude Sonnet 4.6。阶梯模型文章详细解释了这些选择。

以前哪里容易出错

模型在撰写长文档时是有时间预算的：NextDocs 允许单次创建耗时约 11 分钟，单次更新耗时约 6 分钟。有些模型从第一页到最后一页都能保持稳定的速度。而另一些模型则是起步很快，随着文档变长而逐渐变慢。在生成长文档时，变慢的模型会耗尽预算，流式传输随之结束。而以前的 Bug 就在于：这份半成品的文档会被保存下来，就好像它已经全部完成了一样。没有错误提示，没有警告，只有一份在句子中间戛然而止的报告。

我们通过在使用的每个模型上重放一个来自生产环境的真实 22 页请求，发现了这个问题。一旦看清了这种模式，它就变得显而易见，现在它已成为我们测试的首要项目。有五个模型参与了那次重放测试；其中两个模型因此未能获得通道分配。

v1.11.1 中做出了哪些改变

共有三项改变。

提前结束的流式传输现在会被判定为失败，而不是生成一份文档。 如果模型在完成之前停止，NextDocs 将拒绝保存被截断的结果，并告知您发生了什么，以便您可以重新尝试，而不是在开会时才发现问题。

中断的运行会保留已完成的部分。 这是硬币的另一面：如果在长文档生成过程中您的网络连接断开或关闭了标签页，已完成的页面将被保留，您可以从那里继续，而无需重新开始。静默截断是失败，但刻意中止则不是。

阶梯上的每个模型都通过了长文档关卡的检验。 任何模型，无论多新、基准测试成绩多好，在预算内完成 22 页的重放测试之前，都无法获得通道分配。Gemini 3.8 Flash 在发布后一天内就通过了测试，并于 9 月 3 日获得晋升。而 Claude Sonnet 5 在第 16 页时停止了，因此未能通过。

如何在超长文档上获得最佳效果

使用质量（Quality）或高级（Premium）模式。 极速通道虽然快速且可靠，但对于需要保持章节一致性的 60 页文档，质量通道的模型能更好地把握结构。高级模式撰写的文档在所有模式中最详尽、也最长，因此请给它充足的时间。
提供明确的结构。 “十二个章节，每个章节包含摘要、发现和建议表”所生成的文档，要比仅输入“一份长报告”均匀得多。如果把文档的形态完全交由运气决定，长文档的内容往往会偏离主题。
先生成大纲，再生成文档。 对于超过 40 页的任何内容，先要求将大纲生成为一个独立的简短文档，修改好之后，再将其粘贴到实际的提示词中。这是您能做到的成本最低的修改。
附加源文件。 在提示词中附加 PDF、Word 文件和电子表格，可以使长文档紧扣事实，避免内容偏离。
修改章节，而不是整份文档。 生成后，通过名称要求修改特定章节。更新模型将仅对该章节进行修改，这样速度很快，且能保持其余部分完全不变。