先说结论用 AI 写小说大多数人纠结的是“提示词怎么写”“哪个模型更强”但真正拉开差距的是把小说创作拆成一条可执行、可复用、可批量处理的生产流水线。模型只是发动机你缺的是整车结构。这篇文章不打算只给几句“AI 小说写作技巧”而是把 AI 写网文这件事当成一个本地部署 接口调用 批量任务的技术问题来处理。你会看到一套完整工作流从世界观设定、人物卡、章节大纲到逐章生成、去 AI 味、上下文管理再到最后的批量校验和人工润色。同时给出提示词模板、Python 调用示例、批量任务脚本框架以及常见问题排查清单。想认真用 AI 做长篇连载、短篇量产、或者自己搭一套写作工具的读者这篇文章可以直接收藏。1. 核心能力速览能力项说明核心目标用 AI 稳定产出小说章节而非随机生成一段文字关键环节设定管理、大纲规划、章节生成、上下文记忆、去 AI 味、一致性校验主流方式通用大模型 API / 本地部署开源模型 / AI 小说助手工具硬件门槛用 API 基本无门槛本地部署需按模型参数量准备显卡和显存批量能力支持按章节批量生成、批量润色、批量一致性扫描接口能力可封装为写作 API接入自有编辑器和自动化流程核心难点长文本上下文丢失、文风不稳定、AI 味过重、情节前后矛盾适合读者网文作者、短篇创作者、AI 工具开发者、自媒体内容团队这里要清醒一点AI 不能替代创作但能替代大量“方案和初稿”。真正值得投入时间的是把创作经验固化成一套模型看得懂、能执行的流程。2. AI 写小说的最大误区把它当“生成器”而不是“生产线”很多人第一次用 AI 写小说操作方式是这样的打开对话框输入“帮我写一章玄幻小说主角是废柴逆袭”然后等结果。结果通常很糟糕——设定老套、节奏拖沓、对话僵硬、前后设定打架。问题不在模型在于你把 AI 当成了一次性的“文字生成器”。生成器只负责输出一段看起来像小说的文本它不会替你维护世界观、不会记得第三章埋的伏笔、也不会主动控制这一章的情绪节奏。真正有效的 AI 小说写作必须解决五个问题设定的一致性主角名字、技能体系、势力分布、时间线不能写着写着就变。风格的连续性第一章是冷峻文风不能第三章变成轻松搞笑风。情节的可控性这一章要完成什么剧情任务AI 需要提前知道而不是自由发挥。上下文的记忆长篇小说动辄几十万字模型上下文窗口有限必须设计记忆机制。质量的稳定性AI 输出质量波动大需要一套校验和重写流程。这五个问题本质上都是工程问题。提示词能解决一部分但解决不了全部。你需要的是给 AI 搭一套“生产流程”先写设定文档再拆章节大纲然后逐段生成最后统一去 AI 味。每一步都有输入、有输出、有校验标准。这也是本文想要强调的核心观点用 AI 写小说大多数人忽略的并不是“某个厉害的提示词”而是一个完整的内容生产系统。你不需要每次从零开始和 AI 对话你需要一批可复用的模板、脚本和校验工具把创作经验沉淀下来。3. 一套可落地的 AI 小说生产流程把 AI 写小说拆成流水线具体可以分六个环节。下面按顺序展开每一步都说明输入、输出和操作方式。3.1 世界观与设定生成第一个环节是“世界设定”。不管是玄幻、都市、科幻还是悬疑AI 都需要一个明确的设定文档作为后续所有生成的基础。设定文档要包含世界背景时代、地域、力量体系、科技水平。主角信息姓名、性格、目标、缺陷、成长弧线。配角信息与主角的关系、立场、作用。核心冲突主线矛盾、阶段性对手、终极目标。规则限制例如“魔法不能复活死者”“科技不能超出现代水平”。这一步可以用一个大模型会话完成也可以直接写一份结构化的 Markdown 文档。关键是要分模块不要写成大段散文。示例设定模板# 小说设定暗潮 ## 世界背景 近未来东方都市表面科技繁荣暗处存在“潮汐”组织控制信息流。 力量体系记忆移植技术等级从 D 到 S。 ## 主角 姓名林昭 身份潮汐组织前信息分析师 性格谨慎、多疑、有底线 缺陷无法信任他人 目标查明搭档失踪真相 ## 核心冲突 主线林昭逃离组织后发现搭档失踪与城市记忆网络有关。 阶段性对手潮汐组织追查小队。有了这个文件后面所有章节生成都把它作为“全局上下文”的一部分输入。这就是设定一致性的基础。3.2 章节大纲拆解第二步是拆章节大纲。建议每 5 到 10 章为一个“卷”每章用一两句话描述剧情目标明确本章的起承转合。示例章节大纲## 第 1 章大纲 目标林昭发现搭档的加密档案被清除。 关键事件 1. 开场林昭在安全屋检查遗留数据。 2. 转折发现档案被远程清除仅剩一段加密语音。 3. 结尾语音提示“不要查下去”林昭决定反追。 情绪节奏冷静→紧张→决意。这一章要完成什么、在哪里转折、结尾停在哪个悬念上全部提前定好。AI 生成时只需要负责把大纲扩写成具体场景和对话不需要它自己编剧情主线。这能极大减少情节跑偏的概率。3.3 分段生成正文章节大纲确定后进入正文生成阶段。这里不建议一次生成整章三千字而是分段生成每段 500 到 800 字。原因有两个一是单次输出过长质量会下降二是分段生成让每一段都有机会被检查和修正。生成正文时提示词需要同时包含四个部分全局设定摘要。本章大纲。当前段落要完成的具体事件。上一段正文用于衔接。3.4 去 AI 味处理AI 生成的初稿通常有几类通病句式单一、堆砌形容词、段落节奏均匀、缺乏人物语气差异。去 AI 味不是简单地说“写得更自然”而是要用明确的改写指令针对具体问题做修改。常见指令示例改写以下段落 1. 删除所有“仿佛”“宛如”“犹如”类比喻。 2. 每个段落不超过三句话。 3. 对话要体现角色身份林昭说话简短克制。 4. 增加一个环境细节但不直接说明人物情绪。3.5 一致性校验章节完成后需要检查与之前设定的冲突。这一步可以用 AI 自动完成把设定文档、前文摘要和当前章节一起输入让模型列出所有矛盾点。3.6 人工审校与发布最后一步必须有真人参与。AI 可以完成初稿、润色、检查但最终的作品风格、情感深度、版权责任都在作者身上。发布前至少通读一遍修改生硬的对话和不合理的情节。4. 提示词工程小说写作的“可复用资产”很多人把提示词当成一次性对话用完就丢。但小说写作的场景提示词应该被当成代码一样管理有版本、有模块、可复用。4.1 角色设定系统提示词下面是一个通用的小说写作系统提示词模板可复制调整你是一名网文小说作者擅长{题材}。你的任务是根据设定、大纲和前文续写小说正文。 在写作时严格遵循以下规则 1. 严格保持世界观设定中的人物性格、力量体系和势力关系。 2. 每段字数控制在{字数}字左右。 3. 优先使用短句避免排比和重复句式。 4. 对话要体现人物身份和性格差异。 5. 每章结尾要保留悬念或情绪钩子。 6. 不输出任何解释性文字只输出小说正文。 当前设定 {setting_text} 当前章节大纲 {chapter_outline} 前文 {previous_text}这里的{setting_text}、{chapter_outline}、{previous_text}是你从设定文档、大纲文件和前文目录中读取的内容。这才是 AI 小说写作的正确用法提示词不是一段写死的咒语而是一个从资料库动态填充的模板。4.2 人物对话风格控制网文中读者通常能通过对话认出角色。这需要给 AI 定义一个“人物说话规则表”。林昭句子短少用形容词常用反问句。气场偏冷。 老周话多口头禅“要我说啊”习惯性劝人稳妥。 安宁语速快喜欢用网络流行词情绪外放。生成章节时将这段规则加入提示词能明显改善角色辨识度。4.3 节奏控制指令网文章节常见节奏问题开头平淡、中间拖沓、结尾乏力。可以在提示词中增加节奏指令本章节奏要求 1. 开场 150 字内进入事件。 2. 中段包含一次小冲突或信息反转。 3. 结尾停在悬念处不要解决所有问题。 4. 战斗/追逐场景使用短段落每段不超过 2 句话。这类指令模板可以积累成你自己的“提示词库”。写都市悬疑用一套写玄幻升级用另一套。长时间使用后会发现输出稳定性明显提高。5. 长篇小说上下文管理与记忆方案长篇小说最大的技术难点不是生成质量而是上下文管理。模型一次能处理几千到几万字但一本书几十万字不可能全塞进去。必须在每次生成前从资料库中检索最相关的信息组装成一条精简的“前文摘要”。这里有三种方案按项目复杂度从低到高排列。5.1 手动维护摘要文件每写 5 章就人工更新一份章节摘要记录重要事件、当前地点、已出场人物、未解决的线索。生成新章节时把这份摘要塞进提示词。成本最低适合个人作者。摘要文件示例## 第 1-10 章摘要 - 林昭在安全屋发现搭档档案被清除。 - 潜入潮汐组织数据中心获取一段加密语音。 - 与老周碰面确认组织内部有内鬼。 - 未解决线索加密语音中的女声身份。5.2 向量数据库 检索式记忆第二个方案是把每章正文切块嵌入到向量数据库如 Chroma、Milvus生成下一章前用“当前剧情关键词”检索最相关的历史片段作为上下文补充。适合章节多、需要处理长线伏笔的场景。补充说明这个方案需要你熟悉 Python 和向量数据库的基本操作且要按实际需求搭建没有通用开箱即用的一键方案。对于几十万字的长篇是更稳妥的技术路线。5.3 模型上下文扩展部分模型支持很长的上下文窗口可以直接把前文摘要和关键章节塞进提示词。但长上下文不等于高质量模型对长文本中细节的注意力会下降也存在显存或 API 限额问题。更稳妥的组合是“摘要 检索片段 当前章节大纲”这个组合会让输出信息密度更高。6. 批量任务与接口 API 接入如果只是偶尔写几章手动复制粘贴提示词就够用了。但如果你在写长篇连载或者团队需要批量生产章节就应该把整个流程脚本化、接口化。6.1 批量生成的工程思路批量生成章节不建议一次性调用模型生成全部章节。错误做法是“给定所有大纲让 AI 直接写完整本书”。正确做法是逐章串联生成先把第 1 章的设定和大纲传给模型生成第 1 章再把第 1 章摘要 第 2 章大纲传给模型生成第 2 章。这样上下文是连续递进的而不是完全割裂的。用 Python 写一个批量生成脚本时大致结构如下import json import time import requests # 以 OpenAI 兼容接口为例实际接口地址和密钥请按你的服务调整 API_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key def generate_chapter(setting_text, outline_text, previous_summary): payload { model: your-model-name, messages: [ {role: system, content: 你是一名网文小说作者严格遵循设定和大纲。}, {role: user, content: f设定\n{setting_text}\n\n大纲\n{outline_text}\n\n前文摘要\n{previous_summary}\n\n请生成本章正文。} ], temperature: 0.8, max_tokens: 2000 } headers { Content-Type: application/json, Authorization: fBearer {API_KEY} } response requests.post(API_URL, jsonpayload, headersheaders, timeout120) response.raise_for_status() return response.json()[choices][0][message][content] def main(): chapters [ {chapter: 1, outline: 第 1 章大纲, file: chapter_001.md}, {chapter: 2, outline: 第 2 章大纲, file: chapter_002.md}, ] previous_summary 故事开始前的背景设定。 for item in chapters: content generate_chapter(世界观设定, item[outline], previous_summary) with open(item[file], w, encodingutf-8) as f: f.write(content) # 这里可以加一个简单的摘要提取函数更新 previous_summary previous_summary f第{item[chapter]}章完成{content[:80]}... time.sleep(2) # 避免请求过快被限流 print(f完成第 {item[chapter]} 章) if __name__ __main__: main()注意以上代码是通用模板。实际的 API 地址、模型名、鉴权方式、参数名都要按你所用的服务商修改不要直接复制运行。6.2 批量润色流程正文生成后还需要批量去 AI 味。润色脚本的思路是读取章节文件调用同一模型的“改写”接口把原文拆成段落逐段提交改写最后合并回文件。拆分的原因是单次改写过长容易丢细节。def polish_text(text, style_rules): prompt f请按以下规则改写小说段落\n{style_rules}\n\n原文\n{text} payload { model: your-model-name, messages: [ {role: user, content: prompt} ], temperature: 0.5, max_tokens: 1500 } # 发送请求逻辑与 generate_chapter 类似此处省略 return response_text6.3 批量一致性扫描更高级的用法是让模型扫描全文找出剧情前后矛盾。操作方式把设定文档和章节摘要发送给模型让它列出每个疑点。请根据设定检查以下章节摘要找出所有前后矛盾之处 1. 人物称呼不一致。 2. 时间线错误。 3. 设定规则被打破。 4. 已死亡角色再次出现。 设定 {setting_text} 章节摘要 {chapters_summary}这个流程虽然不能 100% 发现所有问题但能覆盖大部分明显的低级错误省下大量人工审校时间。7. AI 写作常见的“坑”与排查方法AI 写小说不像部署服务报错了会有日志输出。写作问题通常表现为“输出内容不符合预期”原因藏在提示词、上下文和模型选择里。下面整理了一份排查清单。问题现象可能原因排查方向解决方案章节内容与大纲无关大纲不够具体模型只能自由发挥检查大纲是否包含关键事件和结尾状态将大纲细化到“事件 转折 结尾”三段式角色说话风格雷同提示词中缺少人物语言特征确认人物设定中是否包含说话习惯增加角色对话规则表前后设定矛盾设定文档未进入每次生成上下文检查 API 调用是否传入全局设定写一个合并设定摘要的函数每次生成前注入文本读起来像 AI 写的缺少去 AI 味改写步骤检查初稿是否直接发布增加批量润色流程专项消除套话批量生成越到后面质量越差前文摘要太长模型注意力分散观察摘要长度和输出长度的比例精简摘要只保留关键事件和未解决线索模型拒绝生成某些情节内容安全策略误判检查触发原因是否与暴力、敏感词有关调整措辞表达减少敏感触发词务必基于合法合规内容创作生成速度慢或 API 超时单次请求生成字数过多检查请求的 max_tokens 设置改成分段生成每段几百字8. AI 写作的合规与版权边界用 AI 写小说必须明确几个边界问题这比提示词更重要。第一AI 生成内容的版权归属在不同平台有不同的规则发布前要确认目标平台的 AI 内容政策尤其是签约网文平台是否有“AI 生成内容需声明”的要求。第二让 AI 模仿某位在世作者、未经授权模仿特定作品风格用于商业发布时存在法律风险。更稳妥的做法是只使用通用风格描述词比如“冷峻都市风”“快节奏悬疑风”而不是“模仿某作者”。第三如果使用真实人物作为小说角色必须获得授权。涉及真实事件的改编也需要注意名誉权和隐私权问题。第四本地部署开源模型时要注意模型本身的许可证允许的用途。个别模型明确限制商用或限制特定内容生成商用前先确认协议。这些内容不复杂但容易忽略。可以在自己的写作流程文档里加一个“合规检查清单”每本书开写前过一遍。9. 一套实用的 AI 小说写作最佳实践综合前面的流程这里给出一套可以直接照搬的实践清单。9.1 第一次先从短篇开始不要第一次就用 AI 写百万字长篇。先用一到三章的短篇把流程跑通设定文档 → 大纲 → 生成 → 润色 → 校验。流程顺畅后再扩展到长篇连载。9.2 把提示词模板版本化建议把常用的系统提示词保存为独立文件用 Git 管理。每次调整后记录效果差异慢慢积累出自己的一套“写作风格包”。# 提示词目录结构示例 prompts/ ├── base/ │ ├── system.md │ └── style_rules.md ├── genres/ │ ├── xuanhuan.md │ └── mystery.md └── workflow/ ├── outline.md ├── generate.md └── polish.md9.3 建立输入输出目录规范把设定、大纲、章节、润色稿分成四个目录管理。AI 生成的中间产物和最终定稿分开避免污染最终文件。novel_project/ ├── setting.md ├── outline/ │ ├── volume_01.md │ └── volume_02.md ├── drafts/ │ ├── chapter_001_raw.md │ └── chapter_002_raw.md └── final/ ├── chapter_001.md └── chapter_002.md9.4 每次 AI 输出都要有人工复核AI 写小说适合用来“把上限拉高”但它不负责“守住下限”。发布前通读全文、修改不合理的对话和情绪转变这一步骤不能省。批量生成时尤其要注意章节之间的衔接处最容易出现断裂。9.5 先想清楚商业化路径如果目标是写网文签约AI 辅助的投稿策略和纯人工写作不同。建议先研究目标平台的 AI 创作规范再决定用 AI 做到哪一步。如果目标是做自媒体短篇故事那重点就是保持更新频率和内容一致性这时候批量流程就特别有价值。10. 下一步从“会写一章”到“建一条小说生产线”回到开头的观点用 AI 写小说大多数人忽略的不是某个技巧而是把创作流程工程化的能力。当你开始把设定、大纲、生成、润色、校验拆成独立模块再用脚本和接口把它们串起来时AI 小说写作才真正变成一件可以稳定复用的生产力工具。最先值得验证的是“设定 → 大纲 → 生成”这条最短链路。花一天时间把第 1 章流程跑通记录生成效果和需要调整的提示词。最容易踩的坑是忽略上下文管理一开始就要给每章准备“前文摘要”不要等到第三十章才发现设定已经乱了。再往后可以根据需求扩展本地模型部署、向量数据库记忆、批量章节生成脚本、甚至做一个简单的 Web 编辑器把提示词、资料库和生成接口都集成进去。到这一步你就不再是“用 AI 写小说”而是在搭建一套属于自己的小说内容生产系统。这才是 AI 写作真正值得投入的方向。
AI写小说别只纠结提示词，构建小说生产流水线才是关键
先说结论用 AI 写小说大多数人纠结的是“提示词怎么写”“哪个模型更强”但真正拉开差距的是把小说创作拆成一条可执行、可复用、可批量处理的生产流水线。模型只是发动机你缺的是整车结构。这篇文章不打算只给几句“AI 小说写作技巧”而是把 AI 写网文这件事当成一个本地部署 接口调用 批量任务的技术问题来处理。你会看到一套完整工作流从世界观设定、人物卡、章节大纲到逐章生成、去 AI 味、上下文管理再到最后的批量校验和人工润色。同时给出提示词模板、Python 调用示例、批量任务脚本框架以及常见问题排查清单。想认真用 AI 做长篇连载、短篇量产、或者自己搭一套写作工具的读者这篇文章可以直接收藏。1. 核心能力速览能力项说明核心目标用 AI 稳定产出小说章节而非随机生成一段文字关键环节设定管理、大纲规划、章节生成、上下文记忆、去 AI 味、一致性校验主流方式通用大模型 API / 本地部署开源模型 / AI 小说助手工具硬件门槛用 API 基本无门槛本地部署需按模型参数量准备显卡和显存批量能力支持按章节批量生成、批量润色、批量一致性扫描接口能力可封装为写作 API接入自有编辑器和自动化流程核心难点长文本上下文丢失、文风不稳定、AI 味过重、情节前后矛盾适合读者网文作者、短篇创作者、AI 工具开发者、自媒体内容团队这里要清醒一点AI 不能替代创作但能替代大量“方案和初稿”。真正值得投入时间的是把创作经验固化成一套模型看得懂、能执行的流程。2. AI 写小说的最大误区把它当“生成器”而不是“生产线”很多人第一次用 AI 写小说操作方式是这样的打开对话框输入“帮我写一章玄幻小说主角是废柴逆袭”然后等结果。结果通常很糟糕——设定老套、节奏拖沓、对话僵硬、前后设定打架。问题不在模型在于你把 AI 当成了一次性的“文字生成器”。生成器只负责输出一段看起来像小说的文本它不会替你维护世界观、不会记得第三章埋的伏笔、也不会主动控制这一章的情绪节奏。真正有效的 AI 小说写作必须解决五个问题设定的一致性主角名字、技能体系、势力分布、时间线不能写着写着就变。风格的连续性第一章是冷峻文风不能第三章变成轻松搞笑风。情节的可控性这一章要完成什么剧情任务AI 需要提前知道而不是自由发挥。上下文的记忆长篇小说动辄几十万字模型上下文窗口有限必须设计记忆机制。质量的稳定性AI 输出质量波动大需要一套校验和重写流程。这五个问题本质上都是工程问题。提示词能解决一部分但解决不了全部。你需要的是给 AI 搭一套“生产流程”先写设定文档再拆章节大纲然后逐段生成最后统一去 AI 味。每一步都有输入、有输出、有校验标准。这也是本文想要强调的核心观点用 AI 写小说大多数人忽略的并不是“某个厉害的提示词”而是一个完整的内容生产系统。你不需要每次从零开始和 AI 对话你需要一批可复用的模板、脚本和校验工具把创作经验沉淀下来。3. 一套可落地的 AI 小说生产流程把 AI 写小说拆成流水线具体可以分六个环节。下面按顺序展开每一步都说明输入、输出和操作方式。3.1 世界观与设定生成第一个环节是“世界设定”。不管是玄幻、都市、科幻还是悬疑AI 都需要一个明确的设定文档作为后续所有生成的基础。设定文档要包含世界背景时代、地域、力量体系、科技水平。主角信息姓名、性格、目标、缺陷、成长弧线。配角信息与主角的关系、立场、作用。核心冲突主线矛盾、阶段性对手、终极目标。规则限制例如“魔法不能复活死者”“科技不能超出现代水平”。这一步可以用一个大模型会话完成也可以直接写一份结构化的 Markdown 文档。关键是要分模块不要写成大段散文。示例设定模板# 小说设定暗潮 ## 世界背景 近未来东方都市表面科技繁荣暗处存在“潮汐”组织控制信息流。 力量体系记忆移植技术等级从 D 到 S。 ## 主角 姓名林昭 身份潮汐组织前信息分析师 性格谨慎、多疑、有底线 缺陷无法信任他人 目标查明搭档失踪真相 ## 核心冲突 主线林昭逃离组织后发现搭档失踪与城市记忆网络有关。 阶段性对手潮汐组织追查小队。有了这个文件后面所有章节生成都把它作为“全局上下文”的一部分输入。这就是设定一致性的基础。3.2 章节大纲拆解第二步是拆章节大纲。建议每 5 到 10 章为一个“卷”每章用一两句话描述剧情目标明确本章的起承转合。示例章节大纲## 第 1 章大纲 目标林昭发现搭档的加密档案被清除。 关键事件 1. 开场林昭在安全屋检查遗留数据。 2. 转折发现档案被远程清除仅剩一段加密语音。 3. 结尾语音提示“不要查下去”林昭决定反追。 情绪节奏冷静→紧张→决意。这一章要完成什么、在哪里转折、结尾停在哪个悬念上全部提前定好。AI 生成时只需要负责把大纲扩写成具体场景和对话不需要它自己编剧情主线。这能极大减少情节跑偏的概率。3.3 分段生成正文章节大纲确定后进入正文生成阶段。这里不建议一次生成整章三千字而是分段生成每段 500 到 800 字。原因有两个一是单次输出过长质量会下降二是分段生成让每一段都有机会被检查和修正。生成正文时提示词需要同时包含四个部分全局设定摘要。本章大纲。当前段落要完成的具体事件。上一段正文用于衔接。3.4 去 AI 味处理AI 生成的初稿通常有几类通病句式单一、堆砌形容词、段落节奏均匀、缺乏人物语气差异。去 AI 味不是简单地说“写得更自然”而是要用明确的改写指令针对具体问题做修改。常见指令示例改写以下段落 1. 删除所有“仿佛”“宛如”“犹如”类比喻。 2. 每个段落不超过三句话。 3. 对话要体现角色身份林昭说话简短克制。 4. 增加一个环境细节但不直接说明人物情绪。3.5 一致性校验章节完成后需要检查与之前设定的冲突。这一步可以用 AI 自动完成把设定文档、前文摘要和当前章节一起输入让模型列出所有矛盾点。3.6 人工审校与发布最后一步必须有真人参与。AI 可以完成初稿、润色、检查但最终的作品风格、情感深度、版权责任都在作者身上。发布前至少通读一遍修改生硬的对话和不合理的情节。4. 提示词工程小说写作的“可复用资产”很多人把提示词当成一次性对话用完就丢。但小说写作的场景提示词应该被当成代码一样管理有版本、有模块、可复用。4.1 角色设定系统提示词下面是一个通用的小说写作系统提示词模板可复制调整你是一名网文小说作者擅长{题材}。你的任务是根据设定、大纲和前文续写小说正文。 在写作时严格遵循以下规则 1. 严格保持世界观设定中的人物性格、力量体系和势力关系。 2. 每段字数控制在{字数}字左右。 3. 优先使用短句避免排比和重复句式。 4. 对话要体现人物身份和性格差异。 5. 每章结尾要保留悬念或情绪钩子。 6. 不输出任何解释性文字只输出小说正文。 当前设定 {setting_text} 当前章节大纲 {chapter_outline} 前文 {previous_text}这里的{setting_text}、{chapter_outline}、{previous_text}是你从设定文档、大纲文件和前文目录中读取的内容。这才是 AI 小说写作的正确用法提示词不是一段写死的咒语而是一个从资料库动态填充的模板。4.2 人物对话风格控制网文中读者通常能通过对话认出角色。这需要给 AI 定义一个“人物说话规则表”。林昭句子短少用形容词常用反问句。气场偏冷。 老周话多口头禅“要我说啊”习惯性劝人稳妥。 安宁语速快喜欢用网络流行词情绪外放。生成章节时将这段规则加入提示词能明显改善角色辨识度。4.3 节奏控制指令网文章节常见节奏问题开头平淡、中间拖沓、结尾乏力。可以在提示词中增加节奏指令本章节奏要求 1. 开场 150 字内进入事件。 2. 中段包含一次小冲突或信息反转。 3. 结尾停在悬念处不要解决所有问题。 4. 战斗/追逐场景使用短段落每段不超过 2 句话。这类指令模板可以积累成你自己的“提示词库”。写都市悬疑用一套写玄幻升级用另一套。长时间使用后会发现输出稳定性明显提高。5. 长篇小说上下文管理与记忆方案长篇小说最大的技术难点不是生成质量而是上下文管理。模型一次能处理几千到几万字但一本书几十万字不可能全塞进去。必须在每次生成前从资料库中检索最相关的信息组装成一条精简的“前文摘要”。这里有三种方案按项目复杂度从低到高排列。5.1 手动维护摘要文件每写 5 章就人工更新一份章节摘要记录重要事件、当前地点、已出场人物、未解决的线索。生成新章节时把这份摘要塞进提示词。成本最低适合个人作者。摘要文件示例## 第 1-10 章摘要 - 林昭在安全屋发现搭档档案被清除。 - 潜入潮汐组织数据中心获取一段加密语音。 - 与老周碰面确认组织内部有内鬼。 - 未解决线索加密语音中的女声身份。5.2 向量数据库 检索式记忆第二个方案是把每章正文切块嵌入到向量数据库如 Chroma、Milvus生成下一章前用“当前剧情关键词”检索最相关的历史片段作为上下文补充。适合章节多、需要处理长线伏笔的场景。补充说明这个方案需要你熟悉 Python 和向量数据库的基本操作且要按实际需求搭建没有通用开箱即用的一键方案。对于几十万字的长篇是更稳妥的技术路线。5.3 模型上下文扩展部分模型支持很长的上下文窗口可以直接把前文摘要和关键章节塞进提示词。但长上下文不等于高质量模型对长文本中细节的注意力会下降也存在显存或 API 限额问题。更稳妥的组合是“摘要 检索片段 当前章节大纲”这个组合会让输出信息密度更高。6. 批量任务与接口 API 接入如果只是偶尔写几章手动复制粘贴提示词就够用了。但如果你在写长篇连载或者团队需要批量生产章节就应该把整个流程脚本化、接口化。6.1 批量生成的工程思路批量生成章节不建议一次性调用模型生成全部章节。错误做法是“给定所有大纲让 AI 直接写完整本书”。正确做法是逐章串联生成先把第 1 章的设定和大纲传给模型生成第 1 章再把第 1 章摘要 第 2 章大纲传给模型生成第 2 章。这样上下文是连续递进的而不是完全割裂的。用 Python 写一个批量生成脚本时大致结构如下import json import time import requests # 以 OpenAI 兼容接口为例实际接口地址和密钥请按你的服务调整 API_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key def generate_chapter(setting_text, outline_text, previous_summary): payload { model: your-model-name, messages: [ {role: system, content: 你是一名网文小说作者严格遵循设定和大纲。}, {role: user, content: f设定\n{setting_text}\n\n大纲\n{outline_text}\n\n前文摘要\n{previous_summary}\n\n请生成本章正文。} ], temperature: 0.8, max_tokens: 2000 } headers { Content-Type: application/json, Authorization: fBearer {API_KEY} } response requests.post(API_URL, jsonpayload, headersheaders, timeout120) response.raise_for_status() return response.json()[choices][0][message][content] def main(): chapters [ {chapter: 1, outline: 第 1 章大纲, file: chapter_001.md}, {chapter: 2, outline: 第 2 章大纲, file: chapter_002.md}, ] previous_summary 故事开始前的背景设定。 for item in chapters: content generate_chapter(世界观设定, item[outline], previous_summary) with open(item[file], w, encodingutf-8) as f: f.write(content) # 这里可以加一个简单的摘要提取函数更新 previous_summary previous_summary f第{item[chapter]}章完成{content[:80]}... time.sleep(2) # 避免请求过快被限流 print(f完成第 {item[chapter]} 章) if __name__ __main__: main()注意以上代码是通用模板。实际的 API 地址、模型名、鉴权方式、参数名都要按你所用的服务商修改不要直接复制运行。6.2 批量润色流程正文生成后还需要批量去 AI 味。润色脚本的思路是读取章节文件调用同一模型的“改写”接口把原文拆成段落逐段提交改写最后合并回文件。拆分的原因是单次改写过长容易丢细节。def polish_text(text, style_rules): prompt f请按以下规则改写小说段落\n{style_rules}\n\n原文\n{text} payload { model: your-model-name, messages: [ {role: user, content: prompt} ], temperature: 0.5, max_tokens: 1500 } # 发送请求逻辑与 generate_chapter 类似此处省略 return response_text6.3 批量一致性扫描更高级的用法是让模型扫描全文找出剧情前后矛盾。操作方式把设定文档和章节摘要发送给模型让它列出每个疑点。请根据设定检查以下章节摘要找出所有前后矛盾之处 1. 人物称呼不一致。 2. 时间线错误。 3. 设定规则被打破。 4. 已死亡角色再次出现。 设定 {setting_text} 章节摘要 {chapters_summary}这个流程虽然不能 100% 发现所有问题但能覆盖大部分明显的低级错误省下大量人工审校时间。7. AI 写作常见的“坑”与排查方法AI 写小说不像部署服务报错了会有日志输出。写作问题通常表现为“输出内容不符合预期”原因藏在提示词、上下文和模型选择里。下面整理了一份排查清单。问题现象可能原因排查方向解决方案章节内容与大纲无关大纲不够具体模型只能自由发挥检查大纲是否包含关键事件和结尾状态将大纲细化到“事件 转折 结尾”三段式角色说话风格雷同提示词中缺少人物语言特征确认人物设定中是否包含说话习惯增加角色对话规则表前后设定矛盾设定文档未进入每次生成上下文检查 API 调用是否传入全局设定写一个合并设定摘要的函数每次生成前注入文本读起来像 AI 写的缺少去 AI 味改写步骤检查初稿是否直接发布增加批量润色流程专项消除套话批量生成越到后面质量越差前文摘要太长模型注意力分散观察摘要长度和输出长度的比例精简摘要只保留关键事件和未解决线索模型拒绝生成某些情节内容安全策略误判检查触发原因是否与暴力、敏感词有关调整措辞表达减少敏感触发词务必基于合法合规内容创作生成速度慢或 API 超时单次请求生成字数过多检查请求的 max_tokens 设置改成分段生成每段几百字8. AI 写作的合规与版权边界用 AI 写小说必须明确几个边界问题这比提示词更重要。第一AI 生成内容的版权归属在不同平台有不同的规则发布前要确认目标平台的 AI 内容政策尤其是签约网文平台是否有“AI 生成内容需声明”的要求。第二让 AI 模仿某位在世作者、未经授权模仿特定作品风格用于商业发布时存在法律风险。更稳妥的做法是只使用通用风格描述词比如“冷峻都市风”“快节奏悬疑风”而不是“模仿某作者”。第三如果使用真实人物作为小说角色必须获得授权。涉及真实事件的改编也需要注意名誉权和隐私权问题。第四本地部署开源模型时要注意模型本身的许可证允许的用途。个别模型明确限制商用或限制特定内容生成商用前先确认协议。这些内容不复杂但容易忽略。可以在自己的写作流程文档里加一个“合规检查清单”每本书开写前过一遍。9. 一套实用的 AI 小说写作最佳实践综合前面的流程这里给出一套可以直接照搬的实践清单。9.1 第一次先从短篇开始不要第一次就用 AI 写百万字长篇。先用一到三章的短篇把流程跑通设定文档 → 大纲 → 生成 → 润色 → 校验。流程顺畅后再扩展到长篇连载。9.2 把提示词模板版本化建议把常用的系统提示词保存为独立文件用 Git 管理。每次调整后记录效果差异慢慢积累出自己的一套“写作风格包”。# 提示词目录结构示例 prompts/ ├── base/ │ ├── system.md │ └── style_rules.md ├── genres/ │ ├── xuanhuan.md │ └── mystery.md └── workflow/ ├── outline.md ├── generate.md └── polish.md9.3 建立输入输出目录规范把设定、大纲、章节、润色稿分成四个目录管理。AI 生成的中间产物和最终定稿分开避免污染最终文件。novel_project/ ├── setting.md ├── outline/ │ ├── volume_01.md │ └── volume_02.md ├── drafts/ │ ├── chapter_001_raw.md │ └── chapter_002_raw.md └── final/ ├── chapter_001.md └── chapter_002.md9.4 每次 AI 输出都要有人工复核AI 写小说适合用来“把上限拉高”但它不负责“守住下限”。发布前通读全文、修改不合理的对话和情绪转变这一步骤不能省。批量生成时尤其要注意章节之间的衔接处最容易出现断裂。9.5 先想清楚商业化路径如果目标是写网文签约AI 辅助的投稿策略和纯人工写作不同。建议先研究目标平台的 AI 创作规范再决定用 AI 做到哪一步。如果目标是做自媒体短篇故事那重点就是保持更新频率和内容一致性这时候批量流程就特别有价值。10. 下一步从“会写一章”到“建一条小说生产线”回到开头的观点用 AI 写小说大多数人忽略的不是某个技巧而是把创作流程工程化的能力。当你开始把设定、大纲、生成、润色、校验拆成独立模块再用脚本和接口把它们串起来时AI 小说写作才真正变成一件可以稳定复用的生产力工具。最先值得验证的是“设定 → 大纲 → 生成”这条最短链路。花一天时间把第 1 章流程跑通记录生成效果和需要调整的提示词。最容易踩的坑是忽略上下文管理一开始就要给每章准备“前文摘要”不要等到第三十章才发现设定已经乱了。再往后可以根据需求扩展本地模型部署、向量数据库记忆、批量章节生成脚本、甚至做一个简单的 Web 编辑器把提示词、资料库和生成接口都集成进去。到这一步你就不再是“用 AI 写小说”而是在搭建一套属于自己的小说内容生产系统。这才是 AI 写作真正值得投入的方向。