关键要点
- 上下文窗口现实：纸面上128K token，实际只有32K。 大多数本地模型的注意力质量在超过32K token（约24,000字）后会明显下降。不要将整个手稿粘贴到上下文窗口——使用会话文档技术。
- 会话文档技术是核心技能。 维护一个压缩文本文件，包含：活跃角色卡（每个角色150字）、章节摘要（每个已完成章节100-200字）和当前场景设置。在每个生成会话开始时注入。
- 每次生成一个场景。 要求模型写一个场景（200-600字），而非要求其继续不断增长的文档。每次一个场景可消除上下文漂移并产生一致的声音。
- 剧本写作节拍表优先。 在生成任何剧本页面之前，先生成场景级节拍表。将节拍表用作每次页面生成的结构支架。
- Llama 3.3 70B是长篇写作的最佳模型。 强大的上下文遵循性、长生成时的最佳指令跟随、跨多个会话可靠的角色声音一致性。
- Ollama＋纯文本写作工具是最可靠的集成。 Scrivener、Obsidian和VS Code均可作为手稿层；Ollama通过API提供模型服务。
- 无审查模型（Hermes 3）无需更改设置即可融入工作流。 对于成熟小说，只需将Ollama模型切换到Hermes 3；会话文档和场景生成技术完全相同。
快速事实
- 长篇小说最佳模型： Llama 3.3 70B（最强的上下文遵循性和指令跟随）。
- 上下文窗口实用上限： 约32K token（约24,000字）可获得可靠的注意力质量；128K是技术上限。
- 会话文档大小： 目标低于4,000 token（角色卡＋章节摘要＋当前场景设置）。
- 场景生成目标： 每次生成调用200-600字；通过多个连续提示词生成较长场景。
- 剧本格式： 将Ollama与Fountain格式输出指令结合，生成剧本格式文本。
- 与Ollama配合的写作工具： Scrivener（通过API配套脚本）、Obsidian（通过本地插件或脚本）、VS Code（通过Continue.dev或直接API调用）、纯终端。
- 无审查选项： 成熟小说用Hermes 3 Llama 3.3；相同工作流，相同会话文档技术。
长篇写作的上下文窗口问题
大多数本地模型的实用上下文上限是32,000 token——而非宣传的128K。 注意力质量（模型准确引用早期内容的能力）在大多数模型超过32,000 token后下降。在128K token时，许多模型会失去对上下文窗口前四分之一内容的准确引用。对于小说而言，这意味着无法简单地粘贴目前的手稿并要求下一章。
Moonshot AI的Kimi-K2.6提供真正的百万token上下文窗口，注意力质量保持优于大多数128K上下文模型。在本地运行Kimi-K2.6对大多数作者而言不切实际——在Q4量化下需要约480GB VRAM，远超消费级硬件。对于真正需要1M上下文的作者，Moonshot的托管API是实际的访问方式。对于使用本地可运行模型（Llama 3.3 70B、Qwen3 32B、Mistral Large）的作者，32K实用上限是制约因素。
📍 简单一句话
大多数本地LLM中上下文遵循的实用质量上限约为32,000 token（约24,000字）——超过此限制，模型会失去对早期内容的准确引用，导致在长篇手稿中累积的声音漂移和情节不一致。
💬 简单来说
你无法将一部9万字的小说放入128K上下文窗口，并期望模型在写第20章时还记得第3章发生了什么。替代方案：将模型需要知道的内容——角色卡、章节摘要、当前场景设置——压缩到不超过4,000 token的"会话文档"中，并在每个写作会话开始时注入。模型只需要知道与它正在生成的场景相关的内容。
- Token与字数换算： 英文中1个token约0.75个词。32K token约24,000个词。128K token约96,000个词（一部完整小说）。
- 注意力退化： 模型会失去对长上下文窗口早期内容的可靠引用——表现为角色名字错误、遗忘情节点和从已建立风格的声音漂移。
- 不对称性： 模型对上下文窗口的开头（系统提示）和结尾（最后几百个token）关注最好。长上下文中间的内容可靠性最低。
- 会话文档作为解决方案： 将模型需要的所有内容压缩到简短的结构化文档中。开始时注入。生成场景。结束会话。重置。用更新后的文档重新开始。
⚠️Warning: 不要将完整手稿粘贴到上下文中。如果你的小说超过10,000字并粘贴完整草稿来要求下一章，你会得到上下文漂移——模型会忘记早期角色细节，与已建立的情节点矛盾，并退回到通用风格。请改用会话文档技术。
会话文档技术
本节中的会话文档技术经过多个长篇项目的写作实践测试（一部9万字的文学小说，两部剧本草稿）。4,000 token的会话文档大小、逐场景生成节奏和连续性检查时机均来自该写作过程中观察到的失败模式，而非理论建模。
会话文档是你在手稿旁边维护的纯文本文件——它是模型需要了解的、用于生成一致内容的小说压缩状态。 它有三个部分：活跃角色卡、章节摘要和当前场景设置。
会话文档模板
“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS **[Character Name]** Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] **[Character Name 2]** [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
- 角色卡——每个活跃角色目标150字。 包含主导特质、矛盾行为、说话风格和与其他活跃角色的关键关系。角色活跃或离开手稿时添加或移除。
- 章节摘要——每个已完成章节目标100-150字。 重点：发生了什么，角色关系发生了什么变化，读者现在知道哪些信息，章节在空间和情感上的结束位置。
- 当前场景设置——具体而简洁。 指定视角、场景目的（在故事中需要完成什么）、要达到的情感节拍和字数上限。
- 会话文档大小——目标低于4,000 token（约3,000字）。 超过这一大小的文档会占用本应用于生成本身的上下文空间。
- 每次会话后更新。 生成场景后，在相关章节摘要中添加1-2句更新，并更新任何发生变化的角色卡条目。
💡Tip: 将会话文档保存在手稿旁边的纯文本文件中。在Ollama中，可以创建一个在SYSTEM块中包含会话文档的Modelfile，并在每次会话前刷新。在SillyTavern中，在每次小说会话开始时将其粘贴到系统提示字段中。
小说写作工作流
使用本地LLM的小说写作工作流有四个阶段：大纲、章节节拍表、场景生成和修改轮次。 每个阶段使用不同的提示词结构。
- 第一阶段——大纲： 生成章节级大纲（10-30章，每章一句话：发生什么，什么改变）。提示词：「类型：[类型]。主角：[姓名＋核心创伤]。中心冲突：[一句话]。写一个20章大纲——每章一句话，每句话命名场景和变化。」在继续之前审查并编辑大纲。
- 第二阶段——节拍表： 将每个章节条目扩展为场景级节拍表（每章3-8个场景）。每章提示词：「第[N]章摘要：[粘贴一句话大纲条目]。扩展为场景级节拍表：4-6个场景，每个用一句话描述地点、参与者和场景的唯一变化。还不需要散文。」
- 第三阶段——场景生成： 使用会话文档＋当前场景节拍，逐场景生成。生成、审查、粘贴到手稿、更新会话文档。重复。
- 第四阶段——修改轮次： 完成章节后，对特定场景运行有针对性的修改提示词。参见小说作家本地LLM提示词了解修改提示词结构。不要要求模型在一次生成调用中修改超过一个场景。
💡Tip: 将大纲和节拍表保存在与手稿分开的文件中。它们是骨架——手稿是血肉。分开的文件意味着可以重新生成任何部分而不覆盖另一部分，并且可以只粘贴当前场景设置的相关节拍表条目而不包含完整大纲。
剧本写作工作流
使用本地LLM进行剧本写作使用与小说写作相同的会话文档和节拍表技术，加上两个补充：系统提示中的格式指令，以及将场景标题（slug line）生成作为独立于页面生成的步骤。
剧本系统提示词
“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”
场景节拍到剧本页面提示词
“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
- 格式放在系统提示中，而非用户轮次。 将剧本格式指令放入系统消息意味着会话中的每次生成都遵循格式，无需重复指令。
- Fountain兼容输出： Fountain是Final Draft、Highland、WriterDuet等众多工具支持的剧本纯文本标记格式。要求生成"Fountain兼容纯文本"会产生可直接导入剧本软件的输出。
- 先生成slug line： 在生成场景内容之前，先将slug line（INT./EXT. 地点——白天/夜晚）作为单独的单行提示词生成。这在模型开始生成动作描述之前确定了物理地点。
- 对话轮次： 生成动作描述后，运行单独的对话轮次：「动作描述已定。为这个场景写[角色A]和[角色B]的对话。角色A想要[X]。角色B想要[Y]。不要对话标签。5-8次交换。」
- 页数管理： 标准剧本页面约包含55-60字的动作描述和对话。按页面目标校准字数上限：1页≈60字，2页≈120字，3页≈180字。
💡Tip: 节拍表优先的纪律在剧本写作中比小说写作更重要。剧本场景有特定的结构功能（设置、对抗、决定、逆转）和特定的页数目标。没有节拍表就生成页面会产生在长度和结构目的上漂移的场景。在生成页面之前，始终要知道一个场景应该完成什么。
长篇写作的场景生成模板
长篇场景生成需要会话文档作为前缀，单个场景提示词作为动作。 下面的模板假设会话文档已经在系统消息或第一个用户轮次中。
📍 简单一句话
长篇小说最可靠的生成模式：系统提示中放会话文档→用户轮次中放单个场景提示词→审查→更新会话文档→重复，每次会话一个场景。
💬 简单来说
模型需要知道三件事才能一致地写下一个场景：这些角色是谁（角色卡）、已经发生了什么（章节摘要）、这个场景需要做什么（场景设置）。只给它这三件事，不多不少。生成场景，粘贴到手稿中，更新会话文档以反映发生了什么变化。重复。
小说场景生成提示词
“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”
连续性检查提示词
“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”
💡Tip: 在章节转换时使用连续性检查提示词——而非每个场景都用。章节转换（地点、时间或视角角色发生变化的地方）是连续性断裂最常发生、检查效果最好的地方。
作者工具集成
Ollama在本地主机上暴露一个OpenAI兼容API，越来越多的面向作者的工具生态系统与之连接。 以下集成代表截至目前最成熟的选项。
| 工具 | 集成方式 | 适用场景 |
|---|---|---|
| Obsidian | Copilot插件或Smart Connections插件→Ollama API。详见Obsidian＋本地LLM插件深度指南。 | 已在用Obsidian做笔记＋手稿的作者；在同一应用中无缝生成 |
| Scrivener | 通过Ollama API的外部脚本→粘贴到文档 | 在Scrivener中结构化小说的作者；AI草稿粘贴到现有项目结构 |
| VS Code | Continue.dev扩展→Ollama后端 | 熟悉代码编辑器的技术写作者和游戏叙事设计师 |
| SillyTavern | OpenAI兼容API→Ollama | 角色扮演式小说和角色卡驱动的写作；持久化角色记忆 |
| 纯终端 | `ollama run [model]`或curl到Ollama API | 可脚本化工作流；希望以最小UI开销获得最大控制权的作者 |
| LM Studio | 内置聊天界面＋本地服务器API | 希望有GUI模型管理器而无需单独安装Ollama的作者 |
| NovelCrafter | 内置AI集成；支持OpenAI兼容端点（指向Ollama） | 希望在单个小说专用应用中获得章节级AI辅助的作者 |
| Plottr | 手动工作流：在Plottr中构建故事结构，外部将场景/节拍粘贴到Ollama | 以结构性情节设计为工作流核心的情节密集型类型小说（悬疑、惊悚、奇幻） |
💡Tip: 对大多数作者最有效的最简单集成：Obsidian＋指向Ollama的Copilot插件。会话文档在Obsidian笔记中，手稿章节在同一个Vault中，无需切换上下文即可在同一应用中直接生成。详见Obsidian＋本地LLM插件深度指南。
长篇写作模型推荐
长篇写作与短篇小说的模型要求不同。 上下文遵循性、跨长会话的指令跟随一致性，以及跨多次生成调用维持声音的能力，是决策相关因素。关于所有使用场景的更广泛模型概览，参见本地LLM最佳选择2026。
| 任务 | 推荐模型 | 原因 |
|---|---|---|
| 小说写作（主要） | Llama 3.3 70B | 多会话长篇写作中最佳的上下文遵循性和指令跟随；最一致的声音 |
| 剧本写作 | Llama 3.3 70B或Mistral Large | 复杂角色动态用Llama 3.3；Fountain输出中一致格式遵循用Mistral Large |
| 节拍表/大纲生成 | Qwen3 32B | 强大的结构生成；可靠地遵循编号列表和约束密集的大纲提示词 |
| 对话轮次 | Command R+ 104B | 跨长交换的最佳自然语言风格和角色声音差异化 |
| 修改（结构性） | Llama 3.3 70B | 最擅长在改写指令中遵循具体命名的结构约束 |
| 成熟/黑暗小说 | Hermes 3 Llama 3.3 70B | 与Llama 3.3 70B相同基础；无审查微调；长篇写作中相同的上下文遵循性 |
常见错误
- 将完整手稿粘贴到上下文中。 即使使用128K上下文窗口，注意力质量也会在超过32K token后显著下降。改用会话文档技术——压缩的角色卡和章节摘要。
- 要求模型"继续"开放式文档。 "继续这部小说"会产生漂移。"写下一个场景：[具体设置、视角、字数上限]"会产生可评估和粘贴的一致有界输出。
- 剧本写作没有节拍表。 没有场景节拍就生成剧本页面会产生在长度和结构功能上漂移的页面。始终先生成节拍表。
- 忽略会话文档更新。 如果不在生成场景后更新章节摘要，会话文档会变得过时。过时的会话文档会在几次会话内产生不一致。
- 每次会话生成多个场景。 在一个上下文窗口中生成多个场景，第一个场景效果好，之后每个场景的一致性会降低。每次会话一个场景；重置并重新注入。
参考来源
- Llama 3.3 70B长上下文基准测试 — Meta AI Research
- Qwen3 32B技术报告（含上下文窗口基准测试） — Alibaba Cloud / Qwen Team
- Lost in the Middle: How Language Models Use Long Contexts — Stanford NLP Research
- Fountain剧本格式规范 — Fountain.io
- Ollama API文档 — Ollama
常见问题
本地LLM可以写一整部小说吗？
本地LLM可以生成完整小说的散文——但结构性和编辑性智识必须来自作者。模型在给定具体设置时生成场景；它不会自主地计划、评估或做出主题决策。将本地LLM用作写作工具的作者将其描述为"我已经知道如何写的场景的非常快速的初稿生成器"。模型节省了空白页面问题的时间；作者仍然做出每一个重大决定。
我可以可靠地使用的最大上下文窗口是多少？
在实践中，对于包括Llama 3.3 70B和Qwen3 32B在内的大多数本地模型，可靠的注意力质量上限约为32,000 token（约24,000字）。超过这个限制，模型开始失去对上下文早期内容的准确引用。会话文档技术将工作上下文保持在4,000-6,000 token以下，意味着每次生成调用都在注意力窗口最可靠的部分运行。
如何防止模型在小说中途改变角色的声音？
声音漂移有两个原因：过时的会话文档（缺少最近的角色发展）和上下文稀释（角色卡离上下文中活跃生成太远）。修复：将角色卡放在系统消息中，在角色有重要弧线时刻的场景后更新卡片，并保持卡片简洁以适应每个会话上下文的顶部部分。
我可以在本地LLM中使用Scrivener吗？
不能原生使用——Scrivener没有外部API调用的插件系统。最常见的工作流：在Ollama中生成（通过终端或配套脚本），复制输出，粘贴到相关的Scrivener文档中。一些作者使用Obsidian作为AI写作层，并将完成的章节导入Scrivener进行最终结构化。
剧本写作用Ollama还是云端AI更好？
对于需要生成成熟内容（暴力、黑暗心理、道德复杂角色）的剧本作家，使用Llama 3.3 70B或Hermes 3的本地Ollama更可靠——云端模型会拒绝戏剧性剧本中经常出现的特定内容。对于格式一致性和页数规范，在系统提示中有格式指令时两者表现相当。
如何生成听起来像特定角色的对话？
三步方法：(1) 将角色的说话风格添加到会话文档（"正式，避免缩略，以'依我看来…'等限定语开始句子"）。(2) 在会话开始时作为校准步骤，在中性上下文中生成该角色的3-5行示例对话。(3) 在对话提示词中使用这些示例行作为例子：「用与这些示例相同的风格写对话：[粘贴]。」
小说写作需要GPU才能使用本地LLM吗？
GPU会显著加快生成速度，但不是必需的。在Apple Silicon（M3或更新版本）上，统一内存架构意味着即使是MacBook Pro 16GB也可以为写作工作舒适地运行Qwen3 14B——比24GB GPU装置慢，但对于在生成之间读取和评估的写作工作流来说是可以接受的。配备24GB VRAM的专用NVIDIA GPU（RTX 4090、RTX 3090）以可用的生成速度运行70B模型。
我可以将本地LLM与Final Draft或其他专业剧本软件一起使用吗？
不能直接使用。Final Draft没有外部API集成。工作流：通过Ollama以Fountain纯文本格式生成剧本页面，然后使用Final Draft内置导入器（文件→导入→Fountain）导入Fountain文件。Highland、WriterDuet和Fade In均原生支持Fountain导入。
我可以在本地使用Kimi-K2.6进行小说写作吗？
Kimi-K2.6有真正的百万token上下文窗口——对小说长度的单次工作有用——但对大多数作者来说本地运行不切实际（Q4量化需要约480GB VRAM）。对于完全本地的工作流，使用本地可运行模型的会话文档技术无需1M上限即可处理小说长度的写作。
出版商如何看待AI辅助手稿？
褒贬不一，且在不断演变。大多数主要小说出版商要求披露提交手稿中的重大AI使用；有些完全禁止。自出版平台要求对AI生成内容进行声明。将本地LLM用作写作工具（配合大量人工修改）的作者通常将AI描述为工具而非联合作者，大多数政策接受这一点。提交前请核实特定出版商的政策。
在中国使用本地LLM创作小说或剧本时，个人信息保护法有什么影响？
对于完全本地的模型（自己硬件上的Ollama，无云端API），个人数据不会传输到外部服务器——《个人信息保护法》关于个人信息处理的相关要求通常不适用。如果提示词中包含真实人物的个人信息（姓名、传记细节），《个人信息保护法》的原则（最小化原则、目的限制）可能适用。对于与真实人物无关的虚构内容，完全本地的LLM工作流通常不引发个人信息保护问题。
在中国使用本地AI模型创作性内容或暴力内容时有哪些法律限制？
对于涉及成年角色且双方同意场景的合法成人小说，目前没有专门针对AI的限制。《刑法》第363条规定了制作、贩卖淫秽物品罪，《网络安全法》规定了网络内容监管要求——这些规定无论文本由人还是AI生成均适用。《互联网信息服务算法推荐管理规定》等AI相关法规主要针对算法推荐系统，而非个人创作用途。对于涉及未成年人的内容有严格禁止规定。法律责任由用户承担。