本地AI叙事生成工作流：用开源大模型实现连续剧集式故事创作

上一次让 AI 续写奇幻冒险，最怕就是前后人设崩塌、地名乱飞。这次我们来看一个本地 AI 叙事生成工作流，专门解决“连续剧集式故事生成”的问题。它不追求单次输出一个惊艳片段，而是让你用开源大模型，在一套固定世界观里稳定产出长篇小说、跑团剧情、互动小说内容。项目标题里那句“穿越暗影森林，遇到狼人，精灵差点把我送走”，就是这套流程在设定约束下生成的一集样例。

这套工作流最有价值的地方是：角色状态可追踪、场景设定可复用、章节之间有人物关系约束，并且支持批量生成多条剧情走向。你可以把它理解为给本地 LLM 加了一套“编剧缓存”，而不是让模型自由发挥。它会先生成世界观、角色卡、剧情大纲，再按章节推进。生成完的内容直接输出为 Markdown 文件，可以导入主流写作软件或直接二次编辑。

本文会从实际搭建流程出发，讲清楚三件事：怎么在本地把这套叙事生成服务跑起来，怎么通过 API 做批量章节生成，以及怎么处理角色一致性、剧情重复、上下文超长这类常见问题。如果你是做小说辅助创作、游戏剧情策划，或者想给跑团群做一个自动主持人，这套思路可以直接参考。

1. 核心能力速览

先把这套工作流的核心能力列出来，方便你判断要不要往下看。

从材料看，这套流程不依赖单一模型，而是“提示词工程 + 状态缓存 + 推理服务”的组合。它的上限由你选择的基座模型决定，稳定性则由工作流设计决定。

2. 适用场景与使用边界

2.1 适合谁用

第一类用户是网文作者和小说创作者。每天需要更新连载内容时，最耗时间的不是“写出来”，而是“保持前后一致”。这套工作流会在每次生成前把角色状态、位置、当前目标塞进提示词，让模型续写时不会把剑客突然写成法师。

第二类用户是游戏团队的剧情策划。做 NPC 对话、支线任务、多结局剧情时，需要在短时间内产出大量文本变体。批量生成功能可以一次跑 5 到 10 条分支，策划只需要筛选和润色。

第三类用户是跑团玩家。跑团过程中主持人需要即兴描述场景、安排 NPC、推进剧情。如果有一个本地生成的“剧情保险”，既能减少现场临时编内容的压力，又能保证世界观规则不被打破。

2.2 不适合什么场景

不要把这套工作流当成“一键出版机器”。AI 生成的叙事文本会有幻觉、重复、节奏拖沓的问题，直接商用需要大量人工审核。尤其是涉及血腥、暴力、恋童等内容时，模型可能生成不适合发布的内容，必须在输出层加过滤器，并在公序良俗和平台规则范围内使用。

也不适合用来做“真人真事改编”。涉及真实人物、真实事件的叙述，必须获得当事人授权。生成的虚拟角色如果意外与现实人物相似，发布前需要重点排查。

2.3 安全与合规边界

如果你要把生成内容发布到公开平台，请确认：

• 不涉及侵权素材。不要直接把某位知名作家的角色名、世界观、标志性情节喂给模型继续写。
• 不虚构真实人物。政治人物、公众人物出现在冒险故事里，可能构成名誉侵权或不当使用。
• 不用于误导。不要把虚构内容伪装成新闻或真实经历发布。
• 不进行未经同意的肖像与声音使用。如果生成内容附带配音或角色立绘，需要确保素材授权完整。

3. 环境准备与前置条件

搭建这套本地 AI 叙事生成服务，需要准备三部分环境：Python 运行时、推理服务、模型文件。

3.1 操作系统与硬件

• 操作系统：Windows 10/11、Ubuntu 20.04 及以上、macOS 均可。
• GPU：NVIDIA 显卡优先，显存建议从 8GB 起步。如果跑 7B 量化模型，6GB 显存也有机会，但要控制上下文长度。
• CPU：仅做 CPU 推理时，建议 16GB 以上内存，生成速度会明显慢于 GPU。
• 磁盘空间：模型文件加依赖环境，预留 10GB 到 30GB 比较稳妥。

3.2 推理框架选择

这里给出两种常见方案，你可以按自己的使用习惯选一种。

方案一：llama.cpp 风格服务。适合显存不大的环境，支持 GGUF 量化模型，启动简单，占资源少。

此方案没有提供固定安装命令，按常规流程操作时，先克隆项目仓库，再执行编译或安装即装包操作。以 llama.cpp 为例：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUBLAS=ON cmake --build . --config Release

注意：LLAMA_CUBLAS只对 NVIDIA GPU 生效；如果你的显卡是 AMD 或 Intel，需要更换为对应的后端参数。

方案二：transformers + vLLM 风格服务。适合显存充裕、追求更大上下文和更高吞吐量的用户。

pip install transformers torch vllm

Hugging Face 格式模型加载时，可以这样启动一个本地 OpenAI 兼容服务：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name local-story \ --port 8000

具体模型名称和路径需要在你本机可访问的前提下替换。之前下载好的模型，可以直接替换为本地路径。

3.3 Python 依赖

无论选哪个推理后端，你都需要一个 Python 环境来跑工作流脚本。建议用虚拟环境隔离：

python -m venv story-env source story-env/bin/activate # Windows 下执行 story-env\Scripts\activate pip install openai pydantic pyyaml

openai库是因为本地推理服务大多提供 OpenAI 兼容接口，调用方式统一，之后切换模型不用改业务代码。

4. 安装部署与启动方式

这一部分直接从“生成一个完整的系列故事”这个目标倒推，按顺序启动推理服务、初始化世界观、生成长篇章节。

4.1 启动推理服务

以 OpenAI 兼容接口为例，启动后本地会有一个http://127.0.0.1:8000/v1的端点。启动成功标志是控制台出现类似Uvicorn running on http://127.0.0.1:8000的日志。

如果端口被占用，改端口再起：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-7b-instruct \ --served-model-name local-story \ --port 8010

启动后先测一下接口连通性：

curl http://127.0.0.1:8010/v1/models

能返回模型列表，说明推理服务正常。

4.2 初始化世界观与角色卡

这是整套工作流里最关键的一步。直接让模型“写一个暗影森林的冒险故事”，输出大概率是废稿。正确做法是先建立一个结构化的设定文件。

创建一个world_setting.yaml：

world: name: 暗影森林周边区域 geography: - 暗影森林：常年被灰雾笼罩，树木高大，阳光难以直达 - 狼人领地：位于森林北侧，与精灵聚居地隔河相望 power_system: - 自然魔法：精灵族掌握，使用时会发出淡绿色微光 - 月蚀之力：狼人在满月期间获得强化，但会失去部分理性 characters: - name: 主角 race: 人类 class: 游侠 current_status: 受伤，左肩有狼人抓伤，背包剩余5天口粮 motivation: 穿越暗影森林，寻找失落的精灵圣物 - name: 精灵向导 race: 精灵 class: 法师 current_status: 对主角的 狼人身份 背景存疑 motivation: 希望利用主角引出森林深处的狼人首领 story_state: current_location: 暗影森林东部边缘 current_chapter: 第8集 recent_events: - 主角在夜间营地遭到狼人突袭 - 精灵向导用范围魔法迟滞狼人，但导致森林起火

这个 YAML 文件的核心作用是让模型在续写前“重新加载状态”。每次生成本节内容之前，把 YAML 的关键内容渲染成系统提示词，再让模型输出下一集。

4.3 章节续写脚本

写一个 Python 脚本调用推理服务。为了避免每次手动拼接提示词，脚本里把世界观和对话历史拼接好，再发给模型，然后把结果追加到 Markdown。

import openai import yaml client = openai.OpenAI( base_url="http://127.0.0.1:8010/v1", api_key="EMPTY" ) with open("world_setting.yaml", "r", encoding="utf-8") as f: setting = yaml.safe_load(f) system_prompt = f""" 你是一个奇幻冒险小说续写助手。请基于以下世界观、角色状态和最近事件， 续写第 {setting['story_state']['current_chapter']} 集。 要求： 1. 不要改变角色基本设定。 2. 情节推进集中在当前场景：暗影森林东部边缘。 3. 对话占比不超过40%。 4. 结尾留下一个悬念。 5. 输出用 Markdown 标题。 """ user_prompt = "继续写下一段冒险故事，主角和精灵向导在森林中遭遇狼人追踪。" response = client.chat.completions.create( model="local-story", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], temperature=0.8, top_p=0.95, max_tokens=1500 ) chapter_text = response.choices[0].message.content with open(f"chapters/{setting['story_state']['current_chapter']}.md", "w", encoding="utf-8") as f: f.write(f"# 第八集：穿越暗影森林，遇到狼人，精灵差点把我送走\n\n") f.write(chapter_text) print("生成完成，输出至 chapters/")

脚本中的model="local-story"要与启动推理服务时--served-model-name保持一致。生成的 Markdown 文件里，模型可能会直接写一级标题，所以脚本先写入固定标题，再追加正文，避免内容里出现重复的一级标题。

4.4 剧情状态自动更新

生成完第八集后，状态文件不能停留在“第 8 集”的旧值。手动更新很麻烦，应该让脚本自动做一次状态摘要。

新增一步：让模型先把上一节内容压缩成三行状态摘要，然后写进world_setting.yaml。这一步可以和章节生成同时调用：

summary_response = client.chat.completions.create( model="local-story", messages=[ {"role": "system", "content": "你是一个剧情状态压缩器。把用户输入压缩成 JSON，包含 current_location、current_chapter、recent_events 三个字段，recent_events 为最多3条列表。"}, {"role": "user", "content": chapter_text} ], temperature=0.2, max_tokens=300 ) print(summary_response.choices[0].message.content)

拿到 JSON 之后，写回 YAML 文件：

import json import re text = summary_response.choices[0].message.content match = re.search(r"\{.*\}", text, re.S) if match: new_state = json.loads(match.group(0)) setting["story_state"] = new_state with open("world_setting.yaml", "w", encoding="utf-8") as f: yaml.dump(setting, f, allow_unicode=True)

注意，模型输出 JSON 时经常夹杂解释文字，所以用正则先提取花括号部分。如果你的基座模型可靠，也可以去掉re.match直接json.loads。

4.5 目录结构规划

整套工作流建议按以下目录组织，避免章节、设定、中间结果混在一起：

story-project/ ├── world_setting.yaml ├── characters.yaml ├── chapters/ │ ├── 第1集.md │ ├── 第2集.md │ └── 第8集.md ├── outputs/ │ ├── branches/ │ └── summaries/ ├── scripts/ │ ├── generate_chapter.py │ ├── update_state.py │ └── batch_generate.py └── logs/

chapters放正文，outputs/branches放多分支剧情，scripts放调用脚本，logs记录每次生成的请求参数和响应状态，方便排查问题。

5. 功能测试与效果验证

正式开写之前，先用三组测试确认工作流是否正常。每组测试只改一个变量，避免同时调整多个参数导致无法定位问题。

5.1 基础生成能力测试

测试目的：确认推理服务能正常返回文本，且输出格式符合 Markdown 要求。

操作步骤：

1. 清空chapters目录，临时在脚本里把temperature设为 0.7。
2. 运行generate_chapter.py。
3. 打开生成的 Markdown 文件，检查标题、段落、对话格式。

预期结果：生成文本在 800 到 1500 字之间，包含##或###小标题，有对话和动作描写。

判断成功标准：服务响应时间正常，生成结果没有大段重复内容，文件名正确。

失败排查：

• 如果脚本报ConnectionError，说明推理服务没启动或端口不一致。
• 如果返回大量空白，可能是max_tokens太小，调大到 2000。
• 如果输出突然中断，检查top_p是否设置过低。

5.2 剧情连续性测试

测试目的：验证“主角左肩受伤”这个状态不会在续写时被遗忘。

操作步骤：

1. 在world_setting.yaml中把current_status改为“左肩有狼人抓伤，行动不便”。
2. 连续生成三集，每集都使用同一个状态文件。
3. 检测三集内容里是否出现了与“左肩受伤”矛盾的行为描述，例如“主角单手用剑劈开石门”这种明显矛盾。

预期结果：模型会持续识别到左肩伤势，至少不会出现“主角双手举重物”这种严重冲突。

判断成功标准：三集内容中，角色状态与环境描述的基本事实保持一致。

失败排查：如果模型持续忘记状态，把系统提示词里的角色状态部分加重，增加一条“你必须在动作描写中体现上述状态”。

5.3 分支剧情测试

测试目的：验证在同一个剧情节点上，能否生成多方向分支。

操作步骤：

1. 固定用户提示词为“精灵向导提出要用范围魔法烧开森林通道，主角可以选择同意或拒绝。写两个分支。”
2. 将n参数设为 2，一次请求返回两条补全。
3. 如果服务端不支持n参数，就循环调用两次，每次温度设置为 0.9。

branches = [] for i in range(2): resp = client.chat.completions.create( model="local-story", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], temperature=0.9, max_tokens=1200 ) branches.append(resp.choices[0].message.content) for idx, branch in enumerate(branches, 1): with open(f"outputs/branches/第8集-分支{idx}.md", "w", encoding="utf-8") as f: f.write(branch)

预期结果：两个分支的开头相同，后续走向明显不同，且都能自洽。

失败排查：如果两个分支几乎一致，提高temperature到 1.0 或 1.1；如果分支内容混乱，降低到 0.8 并增加角色约束信息。

5.4 长文本稳定性测试

测试目的：验证 2000 字以上的章节输出是否会出现重复或逻辑断裂。

操作步骤：

1. 将max_tokens调大到 3000。
2. 生成一集完整章节。
3. 重点检查中间段落是否有“复读机现象”或突然换场景。

预期结果：章节的前后场景衔接连贯，不存在完全重复的句子。

判断成功标准：全文无明显重复语句，事件时间线清晰。

失败排查：如果长文本生成质量下降，最直接的办法是降低单次输出上限，改为分段生成。先写“前半段”，再在脚本里把前半段作为上下文，续写“后半段”。

6. 接口 API 与批量任务

工作流跑通之后，可以进入批量章节生成阶段。批量生成并不等于“无限生成”，你需要先想清楚每一批要出多少集、每集之间的状态如何衔接。

6.1 API 调用示例

上面脚本里已经展示了openai.OpenAI的调用方式。如果你不用 Python，也可以用 curl 直接测试接口：

curl http://127.0.0.1:8010/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "local-story", "messages": [ {"role": "system", "content": "你是奇幻小说续写助手，保持角色设定不变。"}, {"role": "user", "content": "主角穿过暗影森林时遇到了狼人，请续写这一段遭遇。"} ], "max_tokens": 800, "temperature": 0.8 }'

返回结果示例：

{ "choices": [ { "message": { "role": "assistant", "content": "雾气在树干之间涌动，一双赤红色的眼睛从阴影里亮了起来。" } } ] }

6.2 批量章节队列设计

批量任务的前提是“每一集的状态输入来自上一集的摘要输出”。所以不能简单地开 10 个线程同时生成 10 集，否则角色状态会乱。更稳妥的做法是串行批处理：

chapters = [ {"chapter": 9, "user_prompt": "主角在精灵向导的帮助下逃出狼人领地"}, {"chapter": 10, "user_prompt": "主角回头寻找失落在暗影森林深处的圣物"}, {"chapter": 11, "user_prompt": "精灵向导的真实意图开始暴露"} ] for item in chapters: response = client.chat.completions.create( model="local-story", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": item["user_prompt"]} ], temperature=0.8, max_tokens=1800 ) text = response.choices[0].message.content with open(f"chapters/第{item['chapter']}集.md", "w", encoding="utf-8") as f: f.write(text) update_state_from_summary(text)

这里每一步都调用update_state_from_summary，把上一集的摘要写回状态文件，再进入下一集。这样能最大程度降低长程生成时的遗忘问题。

6.3 失败重试建议

批量任务经常会遇到这几个问题：

• 请求超时：模型生成时间超过客户端超时设置。处理方式是增加timeout=300。
• 输出格式错误：模型没有返回完整 JSON 或 Markdown。处理方式是重试一次，第二次概率会显著下降。
• 服务端连接重置：显存不足或并发过高时常见。处理方式是降低并发数，改成逐条调用。
• 内容重复：同一集反复生成相似的句子。处理方式是随机化temperature，在 0.7 到 0.9 之间波动。

重试时可以设置一个简易重试计数：

for attempt in range(3): try: response = client.chat.completions.create(..., timeout=300) break except Exception as e: print(f"第{attempt+1}次调用失败: {e}") time.sleep(5)

6.4 批量场景示例

如果你要给游戏做多个 NPC 的支线任务剧情，可以把“任务目标”“NPC 情绪”“场景地点”作为批量请求变量，循环提交：

tasks = [ {"npc": "铁匠", "mission": "找回被盗的锻造锤", "location": "暗影森林北侧营地"}, {"npc": "酒馆老板", "mission": "调查森林边缘的怪声", "location": "酒馆后巷"}, {"npc": "精灵守卫", "mission": "拦截狼人侦查小队", "location": "精灵聚居地边界"} ] for t in tasks: prompt = f"为NPC {t['npc']} 写一段支线任务开场剧情，任务目标：{t['mission']}，场景：{t['location']}。" ...

这种方式下，同一套工作流可以从“写一本小说”扩展到“批量生成游戏内任务文本”。

7. 资源占用与性能观察

本地跑叙事生成时，最直观的瓶颈不是显存，而是“上下文长度”。这一步说明观察重点。

7.1 显存占用如何观察

Windows 下打开任务管理器，查看 GPU 的“专用 GPU 内存”；Linux 下使用：

nvidia-smi

需要观察的指标包括：

• Memory-Usage：当前显存占用。模型加载后，即使没有请求也会占一块基础显存。
• GPU-Util：生成过程中的显存使用率。推理时通常不会持续满负荷，因为自回归生成是逐 token 计算的。
• Power：功耗。可以辅助判断是否存在降频问题。

不同量化级别模型在生成速度上差别很大。从常见实践看，7B Q4 量化模型在 8GB 显存环境可以尝试，13B Q4 量化模型在 12GB 到 16GB 显存环境更稳妥。但最终占用要以你实际加载的模型为准。

7.2 CPU 推理与 GPU 推理差异

• GPU 推理：生成速度快，适合频繁试验提示词和批量生成。
• CPU 推理：显存压力小，但生成速度可能慢 5 到 10 倍。1 万字章节可能要等很久，不建议在中低端 CPU 上跑大模型做长文生成。
• 混合方案：用llama.cpp的--n-gpu-layers参数把部分层加载到 GPU，其余层留在 CPU。这适合显存不足但还想有一定速度的环境。

./llama-server -m /models/story-model.gguf \ --n-gpu-layers 20 \ --ctx-size 8192 \ --host 127.0.0.1 \ --port 8010

这里--ctx-size是指上下文长度，过大会显著增加 KV Cache 占用。别以为把上下文调到 32768 就一定有提升，模型能不能在长上下文下保持注意力稳定，取决于底座模型质量。

7.3 影响生成速度的主要参数

• max_tokens：单次生成越长，耗时越长，这是最主要的影响因素。
• temperature：本身不影响速度，但影响生成质量和是否出现重复。
• ctx_size：上下文越长，每一轮计算量越大。如果你把整本小说都塞进去，请求会明显变慢。
• batch_size：批量请求并发数。并发越高，单条响应速度可能下降，但整体吞吐量上升。

7.4 降低占用的操作

• 使用 GGUF 量化版本模型，8 比特以下能有效降低显存占用。
• 控制ctx_size，不要太贪长。叙事续写场景下，上下文保留最近 3000 token 通常比一次性塞入三万字更稳定。
• 关闭多余服务。如果同时开了多个模型服务，显存会叠占。
• 生成结束后，不要一下子发几十个并发请求。先两个并发测试，再逐步增加。
• 定期重启服务。长时间运行的 API 服务可能积累内存碎片，导致显存占用缓慢上升。

8. 常见问题与排查方法

8.1 启动类问题

8.2 生成质量类问题

8.3 批量任务类问题

9. 最佳实践与使用建议

如果你决定把这套工作流长期用在自己的写作或游戏项目里，下面这几条建议可以直接落地。

9.1 第一次先小参数测试

不要一上来就生成三万字。先用小模型、低 token 数跑通，确认“启动推理服务、加载世界观、生成章节、更新状态”这条链路完整，再逐步加到正式模型。

建议顺序：

1. 用 1k token 生成一段短章节，验证接口通。
2. 把world_setting.yaml设定完整，生成 2 到 3 集，验证连续性。
3. 调大max_tokens，测试长文本稳定性。
4. 最后再跑批量任务。

9.2 保留一套最小可运行配置

好用的工作流需要版本化。把world_setting.yaml、脚本、模型版本说明一起提交到 git 仓库。如果后面改乱了，可以快速回退。

在脚本目录里放一个README.md，记录：

• 启动推理服务的完整命令。
• 模型文件路径。
• 每次生成时的温度与 token 设置。
• 状态文件存放位置。

9.3 模型文件、输入素材、输出结果分目录管理

这一步能避免很多低级错误。models目录只放模型文件；chapters目录只放最终正文；inputs目录放角色设定、剧情大纲等输入素材。脚本不要把中间摘要写到chapters目录里，否则会混入纯文本状态信息。

9.4 批量任务要加日志和失败重试

批量生成时，脚本要记录每次请求的入参、出参、耗时和错误。日志格式建议包含时间戳、章节号、是否成功。有一个简单的日志样本：

2025-06-01 10:12:33 | 第9集 | 成功 | 耗时58s | tokens: 1450 2025-06-01 10:13:52 | 第10集 | 失败 | timeout | tokens: 0

9.5 接口服务要限制访问范围

API 服务默认绑定127.0.0.1时，只允许本机访问。如果你需要局域网内访问，绑定0.0.0.0，但要注意网络环境是否可信。不要在公网裸奔，至少要加一层密钥校验或使用反向代理。

python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-7b-instruct \ --host 0.0.0.0 \ --port 8010 \ --api-key your-local-key

9.6 涉及人脸、声音、版权素材时必须确认授权

这套工作流如果接入 TTS 配音或角色立绘生成，即使模型跑在本地，只要使用了他人肖像、声音或受版权保护的图片，依然可能侵权。商业项目上线前，必须走授权流程。

9.7 生成内容发布前要做效果复核

本地模型生成的剧情不一定适合直接发布。建议建立一条复核流程：先自动检测敏感词，再由人工通读，确认没有碰到底线内容，然后再发布。对于需要高度一致性的设定，例如“精灵的魔法不能是火系”，应额外检查全文是否出现设定外内容。

10. 总结与下一步

这套本地 AI 叙事生成工作流最值得尝试的点，不是“让 AI 写一段小说”，而是把“剧情状态管理”从人工维护变成了自动化流程。状态文件加系统提示词的组合，能让基座模型在长程续写时不那么快遗忘角色背景。

建议你最先验证三个功能：第一，基础续写链路是否跑通；第二，状态文件更新后，角色设定是否稳定；第三，批量生成三集后，章节之间是否有连贯性。这三个点都通过了，这套流程就可以进入你的日常创作工作台。

最容易踩的坑有两个：一个是启动服务时端口和模型名对不上，另一个是生成后忘了更新状态文件，导致下一集莫名其妙换了个世界观。前者用日志能查到，后者需要你在脚本里强制加入状态更新。

后续可以继续扩展的方向包括：把生成的 Markdown 章节自动转成 EPUB 或 PDF；接入本地 TTS 让章节自动生成有声版本；把剧情分支做成树状结构，用于游戏剧情编辑器；还可以用向量数据库保存角色状态，作为替换YAML状态文件的更高量级方案。

把这套链路稳定下来之后，你手里的就不仅是“一个能写小说的模型”，而是一个可以持续产出连载内容的本地剧情流水线。建议收藏备用，下次写长篇小说或者做游戏剧情时直接套用。