news 2026/9/8 9:52:12

基于大语言模型的小说生成器:如何用RAG根治长篇设定崩塌与逻辑漂移

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
基于大语言模型的小说生成器:如何用RAG根治长篇设定崩塌与逻辑漂移

简介:这是一款基于大语言模型的多功能小说生成器,面向希望提升长篇创作效率的写作者与AI应用爱好者,帮助解决故事连贯性、角色一致性和情节合理性等常见难题。压缩包共48个文件,约498KB,以Python源码为主,包含主程序、一致性检查器、大模型适配器、配置管理等模块,辅以说明文档和配置文件,结构清晰,便于二次开发。已有276人学习下载。读者可借助其模块化设计快速搭建本地运行环境,按提示设定故事类型、风格与角色背景,即可生成初稿,并利用内置检查机制维护世界观统一,适合从构思到成稿的多种创作场景,是探索AI辅助文学创作的高性价比工具。 写长篇小说最崩溃的瞬间是什么?不是卡文,不是灵感枯竭,而是写到第三十万字的时候,突然发现自己把主角左手的伤疤写到了右手,或者第一卷就死掉的配角,在第五卷又活生生地出现帮着主角打架。这种设定崩塌的问题,几乎是每个长篇写作者的噩梦。

我做这款“基于大语言模型的多功能小说生成器”,初衷就是为了治这个病。它不是那种你输入一句话就给你瞎编三千字的“自动写文机”,而是一套帮你在动笔之前就把世界观、人物关系、时间线、能力体系全部固化下来的创作辅助系统,核心解决三个问题:逻辑严谨、设定统一、长篇可维护。这篇博文我会把整个项目的设计思路、功能拆解、实操流程和踩坑记录全部摊开来讲,适合正在写长篇网文、准备做互动叙事游戏,或者对LLM应用开发感兴趣的读者。

1. 整体设计思路:为什么大模型写长文总是“越写越崩”

在动手做这个生成器之前,我先花了两周时间调研市面上已有的AI写作工具,发现一个通病:它们都只擅长“短平快”,你让它写个五百字的小短文、写个朋友圈文案、写个短视频脚本,效果都不错。但一旦让它写几十万字的长篇小说,基本到第三四万字就开始崩——前后人名对不上、时间线混乱、角色性格漂移、设定说变就变。

1.1 大模型写长文的“记忆天花板”

这个问题的根源在于大语言模型的注意力机制存在天然的“上下文窗口”限制。通俗点说,模型每次生成文本时,只能“看到”你喂给它的那么长一段内容,超出窗口范围的信息就会彻底消失。你不可能把五十万字的草稿一次性塞进上下文窗口让它“记住”,就算是最新的长上下文模型,塞进去之后生成质量也会断崖式下降,注意力被稀释,模型反而抓不住重点。

这就好比让一个记忆力极好但只能记住最近半小时谈话内容的人来做你的编辑,你跟他聊前三十章的情节,他认真听完了,但聊到第五十章的时候,他已经把前三十章忘干净了。这跟模型本身的智商无关,纯粹是架构机制决定的。

1.2 我的解法:给大模型配一个“设定外挂”

既然模型记不住,那就不让它“硬记”。我的核心设计思路是:把需要长期记忆的内容从上下文窗口中剥离出来,单独建立一个结构化设定库,在每次生成前动态检索并注入当前章节所需的设定片段。

这个思路其实借鉴了RAG(检索增强生成)的做法。小说生成器维护一个专门的“设定数据库”,里面存放世界观设定、人物卡、势力关系、时间线事件、伏笔清单等结构化信息。每次写新章节时,系统先分析本章涉及哪些人物、哪些地点、哪些伏笔,然后从设定库里检索出相关条目,拼装成一段“当前章节提示词”,再交给模型生成正文。

这样一来,模型永远不需要记住整本书,它只需要专注于当前章节的创作,而全局的一致性和逻辑性由设定库来保障。这就像给一个天赋型但健忘的写手配了个满分助理,助理负责查资料递素材,写手负责发挥文采,各司其职。

1.3 技术选型:API调用为主,本地部署兜底

模型层面我踩了不少坑。最开始想全部用本地部署的开源模型,省成本还能保护数据隐私,但试下来发现,开源模型在长篇叙事的连贯性和文笔细腻度上,跟商业API模型确实还有差距。特别是描写人物微表情、环境氛围渲染这类需要“笔力”的活儿,开源模型写出来总差点意思。

最终我采用的是“双轨制”架构:默认走商业大模型API(比如通义千问、智谱、DeepSeek等国内平台),保证生成质量;同时预留了本地部署接口,用ChatGLM或千问开源版做兜底,处理不需要太高文笔的章节大纲、设定整理等工作。这里友情提示一下,新手配置API的时候一定要看清楚平台给的“代理地址”到底是指什么——有的平台要求填的是网关地址,有的是模型服务地址,填错一个字母就全部报错,我刚开始调试的时候在这上面白白耗了一个下午。

2. 核心功能拆解与实操要点

整套系统我分了四个核心模块:世界观设定模块、人物管理模块、章节大纲模块、正文生成与润色模块。每个模块解决一个层面的问题,合起来才能支撑起长篇创作的完整闭环。

2.1 世界观设定模块:把“规则”写进系统里

这个模块是整套系统的地基。很多写手在动笔前脑子里其实有完整的世界观,但就是没落在纸面上,写到后面全靠记忆,不崩才怪。我的做法是设计了一套结构化字段模板,强制用户把设定填进去,包括但不限于:世界背景、力量体系、种族/阵营、地理区域、科技/魔法水平、社会制度、禁忌与限制。

最核心的一个字段叫“硬性规则”,专门记录这个世界里绝对不能违背的物理法则或运行规律。比如你设定“这个世界魔法需要消耗生命力”,那这条规则会被系统标注为“全局锁定”,无论生成哪一章,模型都会被明确提示不得写出“无代价使用大型魔法”的情节。

这里有一个实操要点值得强调:设定不是写得越多越好。一个常见误区是新手恨不得把世界观写成十万字百科全书,结果模型每次都要携带超长设定,反而冲淡了正文的创作上下文。我建议设定库的总字数控制在单次生成允许的上下文中占到三分之一以内,宁缺毋滥,只留核心规则和与当前剧情强相关的设定。

2.2 人物管理模块:深度人设卡与OOC控制

人物写崩是最影响读者弃书的原因。角色前期冷静理智,后期突然无脑冲动,这种“OOC(Out Of Character,不符合原人设)”问题是AI写作的重灾区。

我设计的“深度人设卡”不只记录姓名年龄外貌这些表层信息,更关键的是三层内容:性格标签、行为准则、说话风格特征。性格标签用来约束角色的决策倾向,比如一个“谨慎多疑”的角色,系统会避免让他在没有充分证据的情况下做出冒险行动;行为准则记录角色的底线和禁忌,比如“从不伤害儿童”、“极度厌恶背叛”,这些是角色行为的红线;说话风格特征则存储角色的惯用句式、口头禅、语速倾向,甚至用词偏好,确保对话读起来“像这个人说出来的话”。

操作上,我做了个“同场景重写”功能——如果你发现某段对话角色语气不对,可以单独选中这段文字,系统会基于该角色的人设卡重新生成,而不是整章推倒重来。实测下来这个功能最能节省修改时间,原来AI写完一章,我要花半小时改人物对白,现在基本几分钟就能过一遍。

2.3 章节大纲模块:让模型当“拉片编辑”

写长篇最忌讳的就是“脚踩西瓜皮,滑到哪里是哪里”。但我发现,让大模型直接生成完整细纲,往往会结构松散,因为它缺乏“全书观”。我建议的处理思路是“两步走”:

第一步,让模型基于设定库生成“三幕式总纲”——开头、高潮、结局。这个阶段不需要细节,只定大方向,比如主角的初始状态、核心矛盾、终极目标、关键转折点。

第二步,每一卷开始时,基于总纲和当前状态生成“卷纲”,再基于卷纲拆解“章节纲”。每次拆解时,模型都会从设定库中检索这个时间点已经发生的事件、角色当前的状态、待回收的伏笔清单,确保大纲之间逻辑衔接紧密。

这里面的设计密码是“倒退式校验”——每一章大纲生成后,系统会把它和之前的章节摘要做一次逻辑比对,专门检查时间线冲突、地点跳转异常、人物“凭空出现”等问题。这个环节特别重要,我在测试时发现,即使设定库做得再好,模型在生成大纲时还是偶尔会“不小心”让一个早该死掉的角色复活,倒退式校验能把这个bug在生成正文之前就拦下来。

3. 实操过程:搭建并跑通完整创作流程

理论说再多,不如直接上手跑一遍。下面我以一个具体的太空悬疑题材为例,完整演示这套小说生成器从零到一的工作流程,包括提示词设计、参数选择和过程记录,你可以直接照着复现。

3.1 初始化设定库:以“深空孤舟”项目为例

第一个实操动作永远是建设定库,而不是急着写正文。我在系统里新建了一个名为“深空孤舟”的项目,填写了以下核心设定:

  • 世界观背景:公元2387年,地球资源枯竭,人类派出“孤舟号”殖民飞船前往14光年外的开普勒-442b,航程耗时152年,船上采取冷冻休眠制度,每10年轮换一组船员值班。
  • 硬性规则:飞船内重力模拟系统覆盖全船,若关闭则进入微重力环境;超光速通信不可用,与地球存在最长11年的信号延迟;舰载AI“忒弥斯”拥有船内最高控制权但不能直接伤害船员。
  • 故事核心冲突:在一次例行轮换中,发现本该处于休眠状态的第三批船员中有一人提前苏醒且死亡,死状蹊跷,主角临时接任安全官展开调查。

这组设定的妙处在于:每一条规则都预设了叙事张力。信号延迟意味着孤立无援的绝境,休眠制度让每个人都有嫌疑,AI权限的限制则埋下了“AI是否在其中做了手脚”的悬念线。填写完设定后,系统会自动把规则转换为约束指令,在后续所有生成请求中附加传送给模型。

3.2 构建人物卡:让角色立得住

设定库建好之后,我建了三个初始人物。以主角为例,深度人设卡如下:

她叫林昭,27岁,原飞船工程部技术员,临危受命接任安全官。性格标签填的是“高敏感、低信任、高执行力”——她对周围人的情绪变化极度敏感,但表面上冷静克制,只有在压力临界点才会爆发。行为准则栏填了三条:绝不在没有把握的情况下公开指责他人;对自己认定的真相执拗到底,不惧与权威对抗;尽可能避免不必要的牺牲。

说话风格特征我备注了“短句多、疑问句多、习惯性重复对方话语的末尾两个字”。这个细节很有意思,实际操作中我发现,这种语言学层面的特征描述,比单纯写“她说话很冷漠”有效得多。模型能根据“重复对方末尾词”这种具体模式,生成了非常有辨识度的对话节奏。写作时读者即使遮住人名,也能从台词风格猜到是谁在说话。

3.3 生成章节大纲:从卷纲到章纲的层层落体

设定和人物卡就绪后,我先让系统生成了第一卷卷纲,标题为“第八十七天的异常”。模型根据总纲和当前状态,给出了四个关键章节节点:发现异常死亡、初步调查引出矛盾、查案触碰舰规禁忌、卷末发现第二具尸体且凶手似乎“不可能”作案。

然后我让系统把第二章“初步调查引出矛盾”拆解成段落级别的大纲。这里要讲解一下参数调节的技巧。大模型生成有一个temperature参数,控制随机性,取值范围一般是0到2。数值越低,输出越发散度小、更加保守可控;数值越高,越发有创意但容易跑偏。我的经验是:

生成场景推荐temperature原因
卷纲、章纲等结构性内容0.5-0.7既要逻辑稳定,又要保留一点意外转折
人物对话0.8-0.9稍高随机性让对话不那么“样板戏”
动作场景、战斗场面0.7-0.8保持节奏感,避免啰嗦
情节推理、解密桥段0.4-0.5逻辑严谨优先,避免逻辑崩坏

第二章的大纲生成时我设了temperature=0.6,生成结果里有个细节让我很满意:模型主动建议“让林昭在调查时发现前任安全官留下的日志,但日志最后一页被撕掉”——这既制造了悬念,又自然带出了支线线索,还不需要额外引入新角色。这说明设定库里的“前任安全官”虽然只填了简单信息,但足够模型在这个框架内发挥创造力了。

3.4 逐段生成正文与即时校验

大纲定稿后,进入逐段生成流程。我的做法不是让系统一次性输出完整章节,而是按章节内部段落切分成若干个“创作单元”,每个单元控制在800到1500字左右,生成后立刻做一次设定校验,通过后再生成下一段。

这个操作背后的原因是:分段生成可以大幅降低上下文携带量,让模型专注于当前场景的描写,同时每次生成前系统都能重新注入与当前段落相关的最新状态信息——比如角色在上一段刚发现关键物证,这一段她的心理状态标注就会调整为“警觉、紧张、怀疑对象锁定为二副”。

第一次完整生成“林昭询问二副不在场证明”这个单元的正文后,系统返回的文本里出现了一个逻辑裂缝:二副的台词里提到了“两周前的事”,但时间线上这艘船上的“周”概念早就被改成了“轮换周期”,用“周”来算时间在这个世界里根本不符合设定。这正是倒退式校验发挥作用的地方——校验模块比对了时间线设定库,检测到用词与世界观矛盾,自动标注了警告,并给出了修正建议:“轮换周期第12天”或“距上次轮换过去三天”。

我把这些校验提醒汇总成了一个“逻辑勘误记录”文件,积累到目前已经有几十条。回头看,这正是这套系统和普通AI写作软件拉开差距的地方:普通软件给你生成一段好看的文字,但这套系统在生成的同时还在盯着逻辑漏洞,相当于每一章都配备了一个较真的逻辑编辑。

4. 常见问题与排查技巧实录

系统虽然好用,但踩坑的地方也不少。我把实际使用中频率最高的问题和排查方法整理成一份速查手册,基本都是常规文档里不会写的经验,每一条都是我实实在在调试过的。

4.1 上下文遗忘问题:前文设定“突然消失”

现象:设定库里明明写了某个配角是左撇子,后续章节里他却“右手持枪射击”。原因排查下来,往往不是设定库失效了,而是生成某一段时检索模块没有把“左撇子”这个设定标签作为关键词命中。我做的最关键修复是把人物卡的“关键视觉特征”字段单独提炼出来,作为全局注入信息,不依赖检索命中——凡是填进这个字段的内容,每次生成必带。

这个修复虽然只改了一行注入逻辑,但效果立竿见影。我后来把这个经验推广到所有“高频硬设定”上,比如主角的外貌、飞船的名字、核心科技的运作法则,全部走全局注入通道,不再依赖语义检索。

4.2 角色说话“A像B”:人设卡生效范围不足

现象:对话生成时,两个性格差异很大的角色说出来的话几乎一个调调,看台词根本分不清是谁。排查后发现是提示词里的人物风格指导写得太过笼统——“说话有个性”这种描述等于没说。解决思路是分两步走:第一步,缩窄风格描述到句式层面,比如“习惯用三到五个字的短句提问”、“爱用比喻来描述技术概念”;第二步,生成对话前额外注入一段“人物关系动态”——比如当前正在对话的两人上次交流时发生过争执,这次对话语气会带着一丝防备。

我强烈建议不要指望一次设置永久生效。长篇创作过程中人物会成长、关系会变化,我每周会花十分钟回顾本周生成的章节,把手动修正过的人物描写特征记录回人设卡里,让人设卡“跟着故事一起长”。

4.3 “AI味”太重:四字成语堆砌、排比句泛滥

这是几乎所有人用大模型写小说都躲不开的毛病。生成的文字读起来华丽但空洞,一段话连续三个排比,形容词堆得比内容还多。我试过很多方法,最有用的有两个:第一个是在提示词里明确约束“多用具体名词,少用抽象形容词”,比如不要写“她感到深深的绝望”,而要写“她盯着舷窗外无尽的黑,手指在控制台上轻轻敲了十七下”;第二个方法是把temperature调低,同时把重复惩罚参数(frequency penalty)调高试试,这个参数会抑制模型重复使用同样的词汇,能让行文不再那么“复读机”。

配合这个方法,我在系统里增加了一个“风格种子样例”功能——把自己欣赏的名家片段作为风格参考放入提示词中,让模型模仿那种句子的节奏和用词密度。实测下来,配合使用之后AI味能减轻大半。

4.4 Token消耗失控:长篇小说越写越贵

写长篇必然要面对成本问题。我刚开始测试时,光一个十章的生成流程就烧掉了几十万token,换算成钱确实肉疼。后来做了三个优化:

第一是缓存历史章节的摘要,而不是直接把全文塞进上下文。系统每章结束后会把该章缩写成300字左右的“章节记忆”,后续生成只携带记忆,不携带全文,这能让上下文占用减少60%以上,费用自然就下来了。

第二是对小节级别设置上下文裁剪,只携带与本场景相关的设定和记忆。因为有些章节省略了大量角色出场,没必要携带他们的全部信息。

第三是把大量格式化整理工作切到本地部署的小模型执行,比如从原文提取时间线、更新伏笔状态这类轻量任务,放在本地跑,既快又近乎免费。商业API只用来撑正文创作这种高价值环节。

5. 写在最后:大模型写小说的正确打开方式

这套系统从构思到现在已经迭代了三个多月,最大的感触是:大模型写长篇小说的核心挑战从来不是“文笔不够好”,而是“记忆不够长、逻辑不够稳”。文笔粗糙可以通过多轮润色解决,但逻辑崩坏和设定漂移是硬伤,一旦发生,轻则读者吐槽,重则整本书结构崩塌无法完本。

目前这套小说生成器已经帮我稳定产出了两部完整的中长篇故事,一部是文首提到的太空悬疑题材,另一部是东方玄幻,前者测试它在硬设定约束下的严谨度,后者测试世界观自由创造空间。两部作品都做到了“无前后矛盾、无角色漂移、伏笔均可回收”,这在没有系统辅助的时代,几乎是不可能的任务。

有一点想与各位读者分享的是:不要指望大模型完全替代你的创作,它更像是团队里的“文字助理+逻辑校对+设定记忆库”三合一的工具。你的审美、你的选题、你对生活和人性的洞察,这些依然是无法被模型替代的核心竞争力。工具负责让你不犯错,而负责让故事发光的人,仍然是你自己。

如果你也在试用同类工具,建议从一个小短篇或者短篇集开始练手,把设定库的结构建立起来,感受一下“设定先行、生成紧随”的创作节奏。这套思路的精髓在于:把创作中机械重复的部分交给机器,把创意和情感表达留给自己。路还长,但方向我已经帮你验证过了,可以放心走。

本文还有配套的精品资源,点击获取

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/8 9:51:44

OpenAI都柏林欧盟总部设立:AI合规、API优化与开发者机遇分析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/8 9:49:42

用Go从零实现短视频推荐算法:开源项目的核心架构与工程实践

简介:一套基于Go语言实现的dy算法完整开源工程,面向希望研究算法实现细节、学习Go后端项目布局,或在此基础上做二次开发的开发者。项目采用清晰的模块化分层结构,控制器、工具集、路由注册与协议文件各司其职,配合主程…

作者头像 李华
网站建设 2026/9/8 9:48:12

AI辅助不等于作者身份:人机协作写作的边界与合规实践

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/8 9:48:07

一文搞懂LLM三大核心:Token、上下文窗口与采样参数

开头经常有读者在后台问我:LLM 到底是怎么“读懂”我输入的那段话的?为什么我多问几句,它的回答就变飘了?为什么有人说“上下文塞太满会爆”,背后到底爆的是什么?我一般会把问题拆成三件事讲:To…

作者头像 李华
网站建设 2026/9/8 9:48:04

YOLO火焰目标检测数据集实战:三种标注格式与训练全流程

简介:面向YOLO目标检测实战的火灾火焰数据集,包含10000张真实场景高质量图片,覆盖白天、夜晚、室内外等多种环境,可用于消防预警、智能安监等场景。资源包内共计2000个文件,以1986个XML标注文件为主(对应VO…

作者头像 李华
网站建设 2026/9/8 9:47:20

Python图像处理入门:用Pillow从像素操作到图形学实战

开篇先问个问题:你接触Python后的第一张图片处理代码,是不是这样写的?from PIL import Imageimg Image.open("test.jpg") img.show()如果是,那你其实已经踩在了计算机图形学的门槛上。Pillow这个库,前身叫P…

作者头像 李华