这次我们直接拿一个真实的小说开篇标题来当演示素材“旧爱荒芜我怀孕了肚子疼得厉害。电话接通时我声音都在抖。”。很多写作者拿到这样一个情感浓度很高的开局面临的实际问题是开篇有了接下来情节怎么推人物情绪怎么保持连贯几十万字的长篇怎么管理时间线和伏笔如果手动硬写效率低还容易在情绪描写上重复。这篇文章不会讨论“灵感”这种玄学而是给一套可以落地的 AI 辅助小说创作工作流。我们选择当前主流的本地大模型或云端 API 作为推理后端把题材拆解、章节续写、情绪描写增强、批量草稿生成、审校和导出整合成一条流水线。看完这篇你可以自己搭一套用于现代言情、都市情感类长篇小说的辅助创作环境并用批量任务一次性生成多个分章草稿再逐个修改定稿。1. 核心能力速览先说清楚这套工作流能做什么、不能做什么能力项说明项目定位AI 辅助长篇小说创作与批量草稿生成工作流基础模型选用支持中文长文本生成的大语言模型通过 API 或本地部署接入核心功能剧情大纲生成、章节续写、情绪描写增强、人物一致性检查、伏笔管理、批量章节草稿硬件门槛云端 API 几乎无门槛本地部署根据模型大小需要 6G 到 24G 显存不等也支持纯 CPU 推理但速度明显下降批量任务支持可一次生成多个章节草稿输出 Markdown 或纯文本文件接口能力有模型服务以 OpenAI 兼容接口或原生接口暴露便于对接脚本适合场景网文作者、出版作者、编剧、新媒体短篇写手、研究 AI 写作的开发者不适合场景需要完全替代人工创作的场景、对文风有极端个性化要求的场景从材料看这套工作流并不绑定某一个固定软件更像是一组“提示词模板 调用脚本 文件管理规范”的组合。你可以用本地开源的 Qwen 系列、GLM 系列也可以用云端 Claude、GPT、文心、DeepSeek 等支持长文本的模型。具体用哪个取决于你的预算、隐私要求和硬件条件。2. 适用场景与使用边界2.1 适用场景长篇连载作者需要每天产出固定字数的章节用 AI 先生成初稿再人工修改润色。写作瓶颈期不知道下一章写什么让 AI 基于大纲给出 3 到 5 个后续方向。情绪戏增强AI 生成“试探版本”的情绪描写作者再从几个方案里挑选或融合。批量整理素材把零散的剧情碎片、人物设定、时间线丢给模型让它整理成结构化文档。团队协作工作室接多个渠道的创作任务时用脚本批量跑章节草稿再分配给不同作者修改。2.2 使用边界必须明确一点AI 辅助创作不等于 AI 代替创作。它的价值是降低“从零到初稿”的时间成本但最终的人物弧光、语言风格、价值表达仍然需要作者来定。如果作品要出版或用于商业平台需要确认平台对 AI 生成内容的披露政策。小说角色如果使用真实人物形象、声音或个人信息必须获得授权。生成的文本可能包含来源不明的语料残留不要直接署名为纯人工创作至少在内部保留修改记录。涉及医疗、法律、心理等专业情节时AI 给出的描述只能当草稿专业准确性需要人工核对。比如本开篇提到“怀孕腹痛”不能只依赖 AI 判断医学细节。3. 环境准备与前置条件3.1 确定接入方式先选推理后端两条路线二选一接入方式优点缺点云端 API无需本地 GPU注册后拿到 Key 即可调用部署成本低长文本费用较高敏感内容需要经过第三方服务本地部署开源模型隐私可控、不用按 token 付费适合大量生成需要显卡显存、模型下载时间、手动配置依赖推荐顺序第一次尝试建议先走云端 API把工作流跑通再考虑本地部署。因为创作类任务需要反复调整提示词云端调试成本更低。3.2 通用检查清单无论哪种方式先确认以下项目操作系统Windows 10/11、Ubuntu 20.04 或 macOS 12 均可 Python 版本3.10 或 3.11 依赖管理pip 或 conda 模型服务地址云端 API 地址或本地 http://127.0.0.1:8000/v1 API Key从模型服务商控制台获取或本地服务无需 Key 磁盘空间存放生成的小说章节、素材库、日志建议预留 5G 以上3.3 安装 Python 依赖创建一个独立虚拟环境避免污染系统 Pythonpython -m venv novel_env source novel_env/bin/activate # Windows 下用 novel_env\Scripts\activate pip install openai requests pandas tiktokenopenai库用于调用兼容 OpenAI 格式的接口requests用来写简单的 HTTP 调用pandas可选用于后续统计生成字数tiktoken用于估算 token 消耗。4. 搭建本地模型服务可选如果你选择本地部署这里给出一套通用启动流程。具体模型名称和端口以实际使用的框架为准。4.1 下载模型以开源的中文长文本模型为例需要到模型托管平台下载对照的模型权重通常会得到多个文件包含配置文件、分词器、权重文件等。建议单独建一个models目录存放models/ └── qwen-ish/ ├── config.json ├── tokenizer.json └── model.safetensors下载后确认文件完整性主要看是否有config.json和分词器文件缺少任何一个都会导致服务启动失败。4.2 启动推理服务使用常见的推理框架启动下面是一段典型命令需要按你的实际安装路径和模型路径替换python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen-ish \ --served-model-name novel-assistant \ --port 8000启动成功的标志是控制台出现Starting vLLM API server或类似输出同时http://127.0.0.1:8000/v1/models可以被访问。如果遇到显存不足可以降低并发参数、改用 4-bit 量化版本或者干脆换用云端 API。4.3 验证本地服务用curl快速验证接口是否可用curl http://127.0.0.1:8000/v1/models如果返回一段包含模型名称的 JSON说明服务已经正常。此时可以继续后面的脚本调用。5. 设计小说创作提示词提示词是这套工作流的核心。同样一个模型提示词写得清楚输出质量能差出几倍。5.1 基础创作提示词模板以下是一个可用于“章节续写”的通用模板以本项目的开头段落为示例输入你是一名擅长现代情感题材的中文小说作者。 请续写以下开篇要求 1. 保持第一人称视角。 2. 情绪上突出“焦虑、无助、害怕失去” 3. 字数控制在 800 字左右 4. 结尾留一个悬念和下一章的冲突点呼应。 开篇如下 “旧爱荒芜我怀孕了肚子疼得厉害。电话接通时我声音都在抖。” 只输出正文内容不要输出任何解释或说明。这里的关键是“角色设定 写作要求 输入素材 输出约束”四段式结构。你可以把它保存成一个文本文件方便后续脚本读取。5.2 情绪描写增强模板当某段情绪描写不够强烈时可以让 AI 输出多个备选版本下面是一段情节描述请用三种不同的写法改写要求分别侧重 1. 动作细节 2. 生理感受 3. 内心独白。 情节怀孕三个月独自在家突然腹痛给前任打电话求助但对方没有立刻接听。 每种写法 150 字左右用编号分隔。这样得到的多个版本作者可以选取或融合而不是直接抄 AI 的唯一输出。5.3 大纲生成模板写长篇之前先让 AI 生成一个分卷大纲请根据以下故事核心冲突生成一个 30 章的小说大纲。 故事核心怀孕的女主角因为意外腹痛向旧爱求助却发现旧爱身边已有新的人两人被迫重新面对过去未解决的情感问题。 要求 - 每章用一句话概括核心事件 - 每 10 章为一个转折点 - 标注主要人物关系和情感走向。大纲生成的输出质量取决于你给的“故事核心”是否明确。建议把人物名单、人物目标、核心冲突、故事结局倾向都写清楚再让模型生成。6. 编写 Python 调用脚本6.1 通用 API 调用脚本下面是一个兼容 OpenAI 格式的调用脚本支持云端和本地服务。你只需要修改BASE_URL和API_KEY两个变量。import requests import json import time # 云端 API 填写服务商地址本地 vLLM 服务通常填 http://127.0.0.1:8000/v1 BASE_URL http://127.0.0.1:8000/v1 # 云端填真实 Key本地服务可留空 API_KEY sk-your-key def chat(prompt, modelnovel-assistant, temperature0.8, max_tokens1500): url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: model, messages: [ {role: system, content: 你是一名中文情感小说创作助手。}, {role: user, content: prompt} ], temperature: temperature, max_tokens: max_tokens } response requests.post(url, headersheaders, jsonpayload, timeout180) response.raise_for_status() data response.json() return data[choices][0][message][content] if __name__ __main__: prompt 续写以下情节字数 800 字第一人称情感基调为紧张与无助 我怀孕了肚子疼得厉害。电话接通时我声音都在抖。 result chat(prompt) print(result)说明temperature控制随机性情感创作建议设到 0.7 到 0.9太低会显得死板太高容易跑题。max_tokens根据需要的字数估算一般 1000 个汉字大约对应 1500 到 2000 tokens不同模型的 tokenizer 有差异。超时时间设长一点长文本生成通常需要几十秒。6.2 批量生成章节脚本单次调用只解决一章长篇连载需要批量生成。下面是一个批量脚本读取一个chapters.json文件每个章节包含标题和提示词循环调用模型并保存到outputs目录import requests import json import time import os BASE_URL http://127.0.0.1:8000/v1 API_KEY sk-your-key MODEL novel-assistant def generate(prompt, max_tokens2000): url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: MODEL, messages: [ {role: system, content: 你是一名中文情感小说创作助手输出连贯、细腻、符合人物设定。}, {role: user, content: prompt} ], temperature: 0.8, max_tokens: max_tokens } for attempt in range(3): try: response requests.post(url, headersheaders, jsonpayload, timeout300) response.raise_for_status() data response.json() return data[choices][0][message][content] except Exception as e: print(f第 {attempt 1} 次失败{e}) time.sleep(5) return def load_chapters(path): with open(path, r, encodingutf-8) as f: return json.load(f) def save_chapter(idx, title, content): os.makedirs(outputs, exist_okTrue) safe_title title.replace(/, _).replace(\\, _) filename foutputs/{idx:02d}_{safe_title}.md with open(filename, w, encodingutf-8) as f: f.write(f# {title}\n\n{content}\n) if __name__ __main__: chapters load_chapters(chapters.json) for item in chapters: print(f正在生成关章节{item[title]}) result generate(item[prompt]) save_chapter(item[index], item[title], result) time.sleep(2) # 避免请求过于密集 print(批量生成完成结果保存在 outputs 目录)对应的chapters.json示例[ { index: 1, title: 旧爱荒芜第一章 电话, prompt: 续写开篇我怀孕了肚子疼得厉害。电话接通时我声音都在抖。要求突出紧张氛围800字。 }, { index: 2, title: 旧爱荒芜第二章 医院, prompt: 上一章结尾是救护车赶到。续写去医院后的情节引入医生和旧爱身边的女性角色800字。 } ]批量任务建议先跑 2 个章节验证输出效果确认风格稳定后再放大批次。一次生成 20 章以上时要加入断点续跑逻辑也就是失败后从上次成功的位置继续避免全部重来。7. 功能测试与效果验证7.1 测试维度不管用什么模型先用固定的 5 个维度评估输出测试维度判断标准情节连贯性人物行为是否符合前文设定是否出现突然失忆、性格反转情绪一致性紧张场景是否始终维持紧张而不是中途变成轻松搞笑文风稳定性视角是否统一用词习惯是否一致是否混入古文或翻译腔人物一致性角色的称呼、性格、口头禅、家庭背景没有前后矛盾结构完整性章节是否有开头、发展、结尾是否留下章末钩子7.2 测试用例示例以下是一组可以直接运行的测试提示词测试 1视角一致性 请判断下面这段文字是否始终使用第一人称视角指出所有视角混淆的句子。 粘贴生成的章节正文 测试 2时间线核查 下面是小说的章节事件列表请按时间顺序重排并指出矛盾之处。 粘贴事件列表 测试 3情绪强度评估 请用 1 到 10 分评估这段文字的情绪紧张程度并说明哪些段落削弱了紧张感。 粘贴章节正文把这三个测试结果记录下来每次调整提示词后对比就能知道改动是否有效。7.3 判断成功与否的标准生成的章节可以“读得下去”没有明显语法错误和人物逻辑崩塌。至少保留一个可以作为章末悬念的句子。情绪描写的词汇没有大量重复。如果连续三章都出现“心脏像被什么东西攥住”说明模型已经在偷懒需要补充禁用词汇表。8. 资源占用与性能观察8.1 云端 API 场景使用云端 API 时重点观察的是单次调用耗时长章节生成通常需要 30 到 120 秒。Token 消耗如果一次生成 1500 字的正文加上提示词通常消耗 2500 到 3500 tokens。频率限制多数服务商对每分钟请求数有限制批量脚本里要加time.sleep()来控制请求频率。8.2 本地部署场景本地部署的观察重点不同显存占用通过 nvidia-smi 实时查看 生成速度记录单次请求耗时 并发请求一次处理一个请求时最稳定并发容易导致显存溢出观察命令nvidia-smi -l 2如果显存占用超过显卡总容量的 90%建议降低生成的max_tokens上限使用量化版本模型一次只跑一个请求关闭浏览器中多余的标签页因为浏览器也会占用显存。8.3 长文本生成的性能瓶颈长篇小说创作中最消耗资源的不是单次生成而是“上下文累积”。随着前文内容越来越长模型每次生成都要重新处理一遍前文耗时成倍上升。解决办法不要每次都把全文塞进上下文只选择与本章节相关的摘要和人物卡。定期让模型“总结前文摘要”下一章基于摘要续写而不是基于全文续写。下面是我前 20 章的剧情摘要请基于摘要续写第 21 章。 摘要 粘贴 500 字以内的摘要 第 21 章要求 粘贴本章要求这个方法的缺点是可能丢失细节但能显著降低 token 消耗和生成耗时。9. 常见问题与排查方法问题现象可能原因排查方式解决方案请求返回 401 错误API Key 错误或已过期检查服务商控制台中的 Key 状态重新生成 Key并确认没有多余空格本地服务启动失败模型文件缺失或路径错误检查启动日志中的文件读取信息对照模型仓库确认目录结构完整显存不足OOM模型过大或并发请求过多运行nvidia-smi查看显存占用换小模型、启用量化、减少并发生成内容重复temperature 过低或提示词模板太简单对比多次输出结果调高 temperature 到 0.9并在提示词中增加“避免重复使用相同比喻”生成速度越来越慢上下文太长检查请求体中的 token 数启用摘要机制精简上下文批量任务中断网络超时或服务端限流查看脚本输出的失败日志增加失败重试和断点续跑逻辑输出内容跑题提示词缺少约束对比输入提示词与实际输出增加“只输出正文”“不要解释”等约束人物性格前后矛盾没有建立人物卡让模型生成人物卡并每次附带维护characters.json在提示词中附带关键人物设定10. 最佳实践与使用建议10.1 建立素材目录结构推荐用下面的结构管理创作素材novel_project/ ├── chapters.json # 章节列表与提示词配置 ├── characters.json # 人物设定卡 ├── outline.md # 分卷大纲 ├── prompts/ │ ├── system.txt # 系统提示词 │ ├── continue.txt # 续写模板 │ └── emotion_boost.txt # 情绪增强模板 ├── inputs/ │ └── opening.txt # 小说开篇素材 ├── outputs/ # 批量生成结果 └── logs/ # 调用日志与失败记录人物卡是长篇创作的命脉。以本项目为例characters.json可以这样写{ characters: [ { name: 女主角, age: 28, 身份: 自由职业者, 性格: 外表坚强内心缺乏安全感, 核心目标: 保住孩子独立生活不再依赖旧爱, 关系: 与男主角是前男女朋友分手后意外怀孕 }, { name: 男主角, age: 30, 身份: 创业者, 性格: 理性、克制但内心有未解开的情感结, 核心目标: 处理公司危机同时面对过去的情感债务, 关系: 女主角的旧爱身边已有新的人出现 } ] }10.2 分批迭代不要一口气生成全书第一次批量生成建议只跑第 1 章到第 3 章。人工修改把风格校准到自己的要求。把修改后的版本回填到提示词示例里再生成后面章节。很多作者犯的错误是让 AI 一口气生成 20 章然后发现第 5 章开始人物性格漂移最后全部返工。先小批量试错比大规模返工省时间。10.3 记录每一次有效提示词如果你发现某个提示词组合输出的效果很好立刻保存。可以按“输入素材 模型参数 输出效果”三列维护一张提示词效果表提示词版本模型参数输出质量使用场景continue_v1temp0.8中空洞较多章节续写continue_v2temp0.85附人物卡好人物一致章节续写emotion_v1temp0.9好情绪细腻情绪戏增强10.4 合规使用提醒如果作品用于商业出版建议保留完整的修改记录区分 AI 初稿和作者修改内容。不要用真实人物姓名、照片、声音生成小说情节或对外发布。涉及医生、律师、警察等专业角色的情节发布前请专业人士核验避免错误专业信息传播。AI 生成内容可能存在版权归属争议不同平台和渠道的规定不同签约前确认清楚。11. 总结与下一步这套工作流最值得尝试的点是把情绪密度很高的开篇素材通过“提示词模板 批量调用脚本 人物卡管理”变成持续产出的章节草稿。它对硬件要求不苛刻云端 API 方式几分钟就能跑通本地部署则适合对隐私和数据安全有更高要求的作者。拿到这套方案后最先应该验证的是“章节续写”这一个功能。用本项目开篇的 50 字素材加上第 5 节给的模板跑 3 次对比输出结果就能判断当前模型和提示词的水平不必急着写长脚本或搭完整目录结构。最容易踩的坑有三个一是没有维护人物卡导致配角性格越写越飘二是上下文物料越堆越长生成速度逐渐不可接受三是直接照搬 AI 生成内容用于商业发布踩到平台政策风险。后续可以继续扩展的方向包括从单章续写扩展到自动生成“前情提要”并把它放在每一章的开头建立“伏笔管理表”让模型定期检查哪些线索还没回收把生成结果接入文档数据库自动生成全书人物关系图谱。先把第 1 章到第 3 章跑通你就能理解所有这些扩展方向的实际成本在哪里。建议把这套流程收藏等到需要写长篇时再拿出来对照搭建。