写作这件事最折磨人的往往不是“没有灵感”而是脑子里明明有一个世界落笔时却卡在空白页前。设定写到一半推翻重来人物对话越写越像同一个模板前后章节甚至能把角色名字写错。我试过很多方法最后是 LLM大语言模型真正帮我解决了这些困扰——它没有替我写书而是让我从重复劳动里解脱出来把精力放回更重要的创意判断上。本文会用一套完整可落地的流程讲清楚如何用 LLM 辅助小说创作从环境准备、核心参数理解到世界观设定、人物卡生成、章节增量创作再到常见坑点和工程化建议。无论你是想用技术手段辅助写作的开发者还是想提高产出效率的创作者都可以在本文里找到能直接复制使用的方案。1. 为什么说 LLM 能让小说创作“自由”1.1 创作自由的含义很多人第一次用 LLM 写小说时期待的是“输入一句话输出一整章”。但实际体验往往是模型确实能生成几千字读起来通顺却总觉得不是自己的故事。于是很快得出结论AI 写作不行。这个结论下得太早了。用 LLM 辅助创作的正确姿势不是让它“替你写”而是让它“帮你把脏活累活干完”。小说创作里有一大批高重复、低创意、却极其消耗耐心的工作比如从零搭建世界观设定并把设定整理成结构化的设定文档。根据一句话需求快速生成多个版本的人物卡。把几百字的大纲扩写成完整的章节细纲。在连续创作多章后保持时间线、人物关系、伏笔一致。对已有段落做语气统一、错别字修正、语病润色。这些工作有一个共同点它们不需要太多天才灵感但需要大量时间。LLM 最擅长的恰恰是这种“基于已有规则批量生成文本”的任务。当你把机械劳动交给模型自己只保留判断和审美时创作自由度反而变大了——这就是“LLMs Set My Fiction Free”的真实含义。1.2 LLM 在小说创作中的五个典型角色在实际项目中我习惯把 LLM 当成一个多角色团队来用。不同的提示词Prompt可以激活它不同的能力对应创作流程的不同阶段。角色核心任务典型应用场景设定顾问补全世界观、社会规则、力量体系奇幻、科幻类型的小说设定搭建人物设计师生成性格、背景、说话风格需要快速产出多个候选人设大纲拆解师把大纲拆成章节细纲长篇小说分卷分章规划文字编辑润色句子、统一语气、修正错别字草稿二次打磨陪练读者模拟读者视角反馈剧情问题章节发布前的自检后面我会在第四节演示这些角色的实际用法。需要注意的是这些能力并不是模型天然内置好的“按钮”而是通过提示词工程Prompt Engineering激发出来的。理解这一点是使用 LLM 辅助创作的技术前提。2. 环境准备与版本说明2.1 两种使用方式对比使用 LLM 辅助小说创作有两种主流方式。你应该根据自己的技术水平和创作习惯来选。第一种是直接使用网页端产品例如 ChatGPT、Claude 等对话式产品。这种方式上手最快不需要写代码适合大部分创作者。缺点是上下文管理比较依赖手动复制粘贴批量处理多个章节时效率不高。第二种是通过 API 调用模型把它集成到自己的写作脚本或编辑器插件里。这种方式适合有编程基础的开发者可以实现批量处理、自动化生成、设定库检索等高级功能。缺点是需要一定开发成本也要注意 API 费用。本文会以第二种方式为主来讲解因为它的可定制性和可重复性更强。你不需要一次性搭建完整系统先把核心脚本跑通后面按需扩展即可。2.2 Python 调用环境准备无论你选择哪种模型服务调用逻辑都差不多。这里以 Python 为例推荐使用openaiSDK 或兼容 OpenAI 接口的 SDK。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。# 建议使用 Python 3.9 及以上版本 python3 --version # 创建虚拟环境推荐 python3 -m venv venv source venv/bin/activate # 安装 OpenAI SDK pip install openai安装完成后准备一个配置文件。实际项目中不要把 API Key 直接写进代码里建议通过环境变量读取。export OPENAI_API_KEY你的key这里需要说明一点不同厂商提供的模型接口和版本差异较大调用参数也略有不同。本文示例的代码是通用的接口调用模式如果你使用的是其他模型服务请先阅读对方的 API 文档确认base_url、模型名称等参数。2.3 测试一次模型对话下面来写第一个测试脚本它的作用是验证环境是否配置成功。# 文件路径scripts/test_api.py import os from openai import OpenAI # 创建客户端 client OpenAI( api_keyos.getenv(OPENAI_API_KEY), ) # 发起一次最简单的对话请求 response client.chat.completions.create( modelgpt-4o-mini, # 模型名称以你实际开通的为准 messages[ {role: system, content: 你是一名资深小说编辑。}, {role: user, content: 请用一句话评价这句话的开头雨下了七天七夜城里的人开始忘记太阳的样子。} ] ) print(response.choices[0].message.content)保存后运行python scripts/test_api.py如果你在控制台看到模型返回的点评文字说明环境已经通了。如果报错优先检查 API Key 是否配置正确、模型名称是否可用、网络是否能正常访问服务地址。3. 核心原理拆解LLM 为什么能辅助写作很多人把 LLM 当成“更智能的搜索引擎”这其实是一个误区。理解下面几个核心概念你才能写出更有效的提示词也才知道为什么有些设置会影响创作质量。3.1 Token 与上下文窗口大语言模型并不像人一样逐字阅读它会把文本切分成 Token词元。Token 可以是单词的一部分、一个完整单词甚至一个标点符号。不同模型的 Token 计算方式不同但可以粗略理解为“字数越多消耗的 Token 越多”。模型每次能处理的最大 Token 数量叫做上下文窗口Context Window。上下文窗口决定了模型在一次对话中能“看到”多少内容。这个限制对小说创作非常重要。以长篇小说为例一部 30 万字的作品全部塞进上下文是不现实的。你不可能让模型“记住”所有章节。实战中的做法是每次请求只传当前章节相关的关键信息而不是全文。把世界观、人物卡、前文摘要作为上下文注入。每生成完一章用模型生成该章的摘要作为下一章的上下文。这种“增量式”创作方式是长篇小说能够用 LLM 持续创作的关键。我在第四节会给出具体实现。3.2 temperature 等采样参数LLM 生成文本时并不是每次都选概率最高的词而是从一个概率分布里采样。temperature参数控制随机性temperature接近 0输出更确定、保守适合设定文档、摘要、代码。temperature较高如 0.8~1.0输出更多样、有创造力适合情节发散、对话设计。temperature过高容易逻辑混乱、胡言乱语。在小说创作中不同场景要用不同的参数。比如生成人物卡时我一般用 0.7 左右兼顾稳定和多样性而润色已有文字时用 0.3 以下保持原意不变。response client.chat.completions.create( modelgpt-4o-mini, temperature0.7, # 创作场景调高编辑场景调低 messages[...] )另一个常见参数是max_tokens它限制模型返回的最大 Token 数。生成小说章节时如果发现输出经常在结尾被截断可以检查是否设置了这个参数。3.3 系统提示词与角色设定在 OpenAI 的 Chat 接口中messages列表有三种常见角色system系统提示词定义模型的身份和回答风格。user用户输入代表你的需求。assistant模型的回复在多轮对话中用于提供历史信息。对小说创作来说system是效果最明显的杠杆。你可以把一套完整的创作规范写进系统提示词让模型始终带着这套身份输出。system_prompt 你是一位擅长奇幻小说创作的专业作家。 你的风格是画面感强重视细节但不过度堆砌形容词。 你写的人物对话要符合角色身份和性格不能出现现代网络用语。 你可以自由发挥情节但必须保持世界观设定的内部逻辑一致。 这里的关键是系统提示词要具体、可执行而不是笼统地说“你是一个优秀作家”。描述越具体模型输出的风格越稳定。3.4 幻觉创作中的双刃剑幻觉Hallucination是指模型生成的内容在事实层面不准确。在代码编写等场景中幻觉通常是需要避免的故障但在小说创作中它可能是灵感来源也可能是剧情炸弹。举例来说你要求模型“根据第一章的内容续写”模型可能会凭空捏造一个第一章里从未出现过的角色——这就是幻觉。但如果模型在你只提到“有一座黑暗城堡”时补充了城堡内部的楼梯、烛火和墙壁纹理这种合理扩展反而是有价值的。因此实际创作中要把幻觉分类处理无害扩展符合设定风格可以保留并人工润色。设定冲突与既有设定矛盾需要通过提示词约束或在输出后校验。凭空引入添加了不属于当前范围的角色或事件需要删除或明确标注“待用户确认”。避免设定冲突最有效的方法是把关键设定写进每次请求的上下文中并明确要求模型“只能使用上下文中出现过的信息”。4. 完整实战从设定到章节生成前面讲了原理这一节我们搭建一个最小可用的“LLM 小说创作辅助脚本”。它会包含四个阶段项目结构、世界观设定生成、人物卡生成、章节增量生成。4.1 创建项目结构建议按模块拆分文件方便后续扩展。fiction-assistant/ ├── config.py # 配置参数 ├── prompts/ # 提示词模板 │ ├── world_setting.txt │ ├── character_card.txt │ └── chapter_writing.txt ├── scripts/ │ ├── generate_world.py │ ├── generate_character.py │ └── generate_chapter.py └── output/ # 生成结果存放先创建一个简单的配置模块。# 文件路径config.py import os # 从环境变量读取 API Key API_KEY os.getenv(OPENAI_API_KEY) # 模型名称按你实际开通的模型填写 MODEL_NAME gpt-4o-mini # 默认生成参数 TEMPERATURE_CREATIVE 0.8 TEMPERATURE_EDIT 0.34.2 用提示词生成世界观世界观设定是小说创作中最费神的部分之一。下面这个提示词模板会引导模型按结构化方式输出设定。# 文件路径prompts/world_setting.txt 你是我的世界观设定顾问。 请根据下面这段“核心创意”帮我生成一份结构完整的世界观设定。 要求 1. 包含以下小节世界地理、历史脉络、社会结构、力量体系如果适用、科技水平。 2. 每个小节给出至少 3 条具体设定不能只说空话。 3. 设定之间不允许互相矛盾。 4. 如果原始创意没有提供的信息请用占位符标记为【待补充】。 5. 输出使用 Markdown 格式。 核心创意 {idea}注意这个模板里用了{idea}占位符。实际调用时我们会把用户输入填充到这个位置。下面写一个 Python 脚本来读取模板并调用模型。# 文件路径scripts/generate_world.py from openai import OpenAI import config def read_prompt(path: str) - str: with open(path, r, encodingutf-8) as f: return f.read() def generate_world(idea: str): client OpenAI(api_keyconfig.API_KEY) system_prompt 你是一位专业的世界观架构师擅长搭建逻辑自洽的小说世界。 user_prompt read_prompt(../prompts/world_setting.txt).format(ideaidea) response client.chat.completions.create( modelconfig.MODEL_NAME, temperature0.5, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ] ) return response.choices[0].message.content if __name__ __main__: idea 一个靠记忆交易维持运转的城市人们用珍贵的记忆购买长短不一的寿命。 result generate_world(idea) print(result) # 把结果保存到文件 with open(../output/world_setting.md, w, encodingutf-8) as f: f.write(result)这个脚本做的事很简单读取模板、替换占位符、调用模型、打印结果、保存文件。运行cd scripts python generate_world.py你会在output/world_setting.md得到一份可编辑的世界观草稿。注意这份草稿只作为起点你需要手动调整并加入自己的原创想法。4.3 结构化生成人物卡人物卡是另一个高频需求。我们希望模型输出一个固定的 JSON 结构方便程序后续处理而不是纯文本。# 文件路径prompts/character_card.txt 请为小说角色创建一张人物卡。 要求 1. 输出严格 JSON 格式不要输出其他文字。 2. JSON 字段如下 { name: 角色名, age: 年龄, appearance: 外貌描述, personality: 性格特点, background: 背景故事, speech_style: 说话风格, motivation: 核心动机, flaw: 性格缺陷 } 3. 所有内容必须具体避免“性格开朗”“经历丰富”这类空泛表述。 4. 说话风格要给出一个示例对话方便后续对话生成时参考。 角色需求 {character_requirement}这次我们写一个可以批量生成多张人物卡的脚本。# 文件路径scripts/generate_character.py import json from openai import OpenAI import config def read_prompt(path: str) - str: with open(path, r, encodingutf-8) as f: return f.read() def generate_character(requirement: str): client OpenAI(api_keyconfig.API_KEY) system_prompt 你只输出 JSON不输出任何解释性文字。 user_prompt read_prompt(../prompts/character_card.txt).format( character_requirementrequirement ) response client.chat.completions.create( modelconfig.MODEL_NAME, temperature0.7, response_format{type: json_object}, # 部分模型支持强制 JSON 输出 messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ] ) content response.choices[0].message.content # 解析 JSON return json.loads(content) if __name__ __main__: requirement 主角一名 28 岁的记忆交易所职员外表冷静内心渴望找回自己失去的童年记忆。 character generate_character(requirement) print(json.dumps(character, ensure_asciiFalse, indent2)) with open(../output/character_main.json, w, encodingutf-8) as f: json.dump(character, f, ensure_asciiFalse, indent2)如果你使用的模型不支持response_format{type: json_object}也可以移除该参数然后自己写一段 JSON 解析代码处理返回文本。人物卡的价值在于后续生成章节时我们可以把角色 JSON 作为上下文的一部分传入让模型在对话中保持一致的角色性格。4.4 增量生成章节这是整个流程里最关键的一步。目标是让模型基于“世界观设定 人物卡 前文摘要 当前章节大纲”来生成章节内容而不是让它自由发挥。先创建一个章节提示词模板。# 文件路径prompts/chapter_writing.txt 你是一名小说作者。请根据以下信息创作小说章节。 ## 写作要求 1. 字数约 1500 字。 2. 只写正文不要写章节名不要输出任何解释。 3. 情节必须围绕【本章目标】展开不允许引入新角色或新事件。 4. 对话必须符合人物卡中的说话风格。 5. 可以调用设定库中的信息但不得与之矛盾。 ## 世界观设定 {world_setting} ## 人物卡 {character_card} ## 前文摘要 {previous_summary} ## 本章目标 {chapter_goal}调用脚本如下# 文件路径scripts/generate_chapter.py from openai import OpenAI import config def read_file(path: str) - str: try: with open(path, r, encodingutf-8) as f: return f.read() except FileNotFoundError: return 暂无内容 def generate_chapter(chapter_goal: str): client OpenAI(api_keyconfig.API_KEY) world_setting read_file(../output/world_setting.md) character_card read_file(../output/character_main.json) previous_summary read_file(../output/chapter_summary.md) with open(../prompts/chapter_writing.txt, r, encodingutf-8) as f: template f.read() user_prompt template.format( world_settingworld_setting, character_cardcharacter_card, previous_summaryprevious_summary, chapter_goalchapter_goal ) response client.chat.completions.create( modelconfig.MODEL_NAME, temperatureconfig.TEMPERATURE_CREATIVE, messages[ {role: system, content: 你是一位专业的小说作者。}, {role: user, content: user_prompt} ] ) return response.choices[0].message.content if __name__ __main__: # 示例生成第一章 goal 主角第一次进入记忆交易所目睹一位老人用水晶瓶购买十年寿命感到震撼。 chapter generate_chapter(goal) print(chapter) with open(../output/chapter_001.md, w, encodingutf-8) as f: f.write(chapter)这个脚本的核心思路是“上下文拼接”。每次调用模型时都把创作新章节所需的最小上下文拼在一起而不是依赖多轮对话。这样有两个好处一是 token 消耗可控二是每个章节都基于最新版本的世界观设定和人物卡不会因为对话历史太长导致模型“遗忘”。4.5 运行与验证按照 4.1 到 4.4 的顺序依次执行脚本cd scripts python generate_world.py python generate_character.py python generate_chapter.py第一次运行完整流程后你会得到三个重要的输出文件世界观设定、人物卡、第一章正文。这里有一个需要特别注意的验证步骤生成章节后一定要手动检查是否有与世界观设定矛盾的地方。模型生成的内容可以当作一稿但发布前必须经过人工修改。我的经验是LLM 生成的内容新手如果只用 30 分钟修改可能反而比直接写更费时间。正确的用法是把它当成“无限量供应的草稿”你只负责挑选、修剪、重写关键段落。5. 常见问题与排查思路实践过程中每个人都会遇到类似的问题。这里整理一份高频问题排查表。问题现象常见原因解决思路生成的人物性格前后不一致上下文未注入人物卡或人物卡描述太笼统每次请求都携带完整人物卡并在提示词中强调“严格按照人物卡描述行动”章节经常引入新角色本章目标写得太模糊模型有自由发挥空间在提示词中明确“禁止引入新角色所有出场人物必须在人物卡中列出”文章开始讲空泛套话temperature 过高或系统提示词缺少风格约束降低 temperature并在 system prompt 中明确“不要写空泛的总起句直接进入场景”输出被截断max_tokens 设置过小调大 max_tokens或把章节拆分成更小的生成单元生成结果和设定矛盾上下文没包含关键设定把设定库按需截取注入到 user prompt 中多轮对话后模型“忘记”前文上下文窗口超限或未正确拼接历史改用每次请求完整拼接上下文的方式不用多轮对话JSON 格式经常解析失败模型输出了多余解释文字加强系统提示词或使用 response_format 强制 JSON 格式下面重点展开两个最容易踩坑的场景。5.1 角色性格漂移“角色性格漂移”是指小说写到后面角色行为和开篇完全不像同一个人。原因很直接模型没有稳定的“角色记忆”每次生成都依赖你传入的上下文。如果不传它只能凭概率猜。解决办法是把人物卡写得更细化尤其是“说话风格”和“做出的关键决定”。举个例子一张不好用的人物卡可能是主角是一个勇敢的人。一张好用的卡是这样的主角表面冷静克制但遇到弱者受欺时会不经过思考先冲上去事后才意识到风险但已经来不及收手。他的口头禅是“不就是一条命吗”但其实真的害怕死亡。他的核心弱点是无法开口向别人求助。具体到行为模式的描述模型才能稳定模仿。这就是为什么我在第二节强调人物卡要具体不能空泛。5.2 上下文爆炸长篇小说写到几十章后如果把全文或所有设定都塞进上下文很快会超出模型上下文窗口限制而且费用也会飙升。解决办法是“分层摘要法”每生成一章先让模型输出 200 字以内的章节摘要保存到文件。生成新章时只传入“前文摘要”不传完整前文。当写到“卷”的规模时再为整卷生成一个更高级别的摘要。重要信息如关键伏笔、完整设定单独放在设定库里按需查询。这是一套类似“金字塔”的信息管理结构底层是完整章节中间层是章节摘要顶层是整卷摘要。LLM 每次只读取它需要的层级而不是一次加载全部内容。6. 最佳实践与工程建议6.1 把设定库当作你的“创作地基”小说创作辅助项目的第一步永远是建立一个可检索的设定库。不要依赖模型记住设定而要让模型每次生成前“查阅”设定库。这个设定库可以是一份 Markdown 文档分成世界观、地理、历史、人物、伏笔等小节。一个数据库表每条记录是一个设定项包含关键词和详细内容。一个纯文本目录每个角色或地点单独一个文件。对于个人项目我推荐从 Markdown 文档开始。等设定规模变大后再迁移到带检索的数据库方案。关键是任何新生成的内容都要及时回填到设定库否则下一章生成时又用不上。6.2 提示词模板化提示词不要直接写在代码里而是拆成模板文件这样方便调整和维护。更进一步可以把常用提示词做成一个仓库像管理代码一样用 Git 管理记录每次调整的效果。一个实用的模式是每个提示词模板都包含“角色定位 任务描述 约束条件 输出格式 上下文注入区”。这种模板结构可以直接复用于不同场景。模板写好后建议记录每个模板在什么模型、什么 temperature 下效果最好。经过几次测试你会找到自己最顺手的组合。6.3 人工审校与版权边界LLM 生成的内容本质上是它的模型的统计输出不能直接视为“原创”。实际创作中我的建议是生成内容只能作为起点必须经过人工重写和润色。不要直接把完整的 AI 生成章节发布到商业平台除非你确认平台允许 AI 辅助内容。涉及灵感借鉴、角色设定等核心创意时最终决策权永远在人。如果作品需要获得版权保护建议保留创作过程记录证明人类作者对关键设定和情节走向的控制。这个问题没有绕过的必要LLM 是效率工具不是替代作者身份的机器。把它定位成“创作伙伴”你既能享受效率提升又不至于陷入版权争议。6.4 数据隐私与安全写小说这件事有时很私密尤其是还没公开的作品。使用 API 时要注意下面几点不要把未公开发布的作品全文直接上传到不熟悉的第三方平台。使用 API 时注意阅读服务商的隐私条款了解数据是否会被用于模型训练。对核心创意、商业项目内容建议通过环境变量管理密钥不要提交到代码仓库。尽量使用不保留对话记录的配置或定期清理聊天历史。这个原则对所有 AI 辅助创作工具都适用你交给模型的信息要经过筛选而不是毫无保留地全盘托出。6.5 多模型协作分工不同模型有不同的特长。有的模型逻辑性强适合写设定和大纲有的模型文笔细腻适合写具体段落。如果你有条件接入多个模型可以让它们分工协作。一个可行的框架是用逻辑型模型生成世界观、拆解章节大纲。用文学倾向的模型写正文。再让另一个模型扮演“毒舌编辑”指出逻辑漏洞和重复套路。这种“多模型评审”机制在项目中期尤其有用。把写好的章节发给不同模型分别要求它们从“读者体验”和“逻辑一致性”两个角度评论可以得到不少有价值的修改建议。7. 总结与下一步本文从“创作自由”这个实际痛点出发讲清楚了 LLM 辅助小说创作的核心思路不是让模型替你写而是让它承担设定搭建、人物卡生成、章节扩写这些重复劳动把人解放出来做真正的创意判断。文章覆盖了完整的最小可运行项目包括 Python 环境搭建、提示词模板设计、世界观生成、人物卡 JSON 输出、章节增量生成以及常见问题的排查方案。你可以直接复制代码先跑通第一条链路再根据自己的创作习惯调整提示词和流程。下一步值得深入的方向有三个一是搭建本地设定库检索让模型在生成前自动查询相关设定二是设计章节质量评估脚本用模型对生成章节打分并自动反馈修正三是配合编辑器实现定时批量生成把整套流程工程化。如果你在实践过程中遇到了新的坑不妨动手记录下来总结成自己的提示词模板。创作始终是人的事LLM 只是那支更好用的笔。