用AI写长篇这件事我身边越来越多人尝试过。小说写手拿来写网文连载自媒体拿来写系列科普产品经理拿来写万字PRD大家几乎都会撞上同一堵墙开头惊艳越长越崩。你让AI写第1章它像模像样人物鲜活得能蹦出来写到第7章它忘了主角是个左撇子把第3章埋的伏笔丢得一干二净剧情在同一个困境里绕了三圈最后还能在结尾突然赶火车一样把所有矛盾草草收掉。问题不是你不会提问也不是AI太笨而是长篇写作本质上是一个状态管理问题。AI大模型的生成方式是逐词预测它并没有一个真正长期存在的记忆。写第10章的时候模型只能看到当前上下文窗口里的内容第1到第5章的细节早就被挤出了窗口。它不是忘了是压根儿没看见。我在反复踩坑之后把遇到的每种崩法都做成了对应的代码。这里的代码有两层含义一层是可复用的提示词模板我叫它写作代码块另一层是真正用来管理章节状态和伏笔追踪的小脚本。两种合起来就是我这套解决长篇写崩问题的方法。这篇东西不是理论全是我自己写连载、写系列长文时一步步试出来的适合正在用AI写长篇的人直接抄作业。1. 先说清楚AI长篇写作到底是怎么写崩的1.1 我从翻车现场里总结出的五大通病我前前后后写了十几个长篇项目每崩一次就记录一次症状最后发现所有翻车现场其实都可以归成五类。通病表现根本原因上下文失忆设定、人名、伏笔大面积丢失核心细节被挤出了上下文窗口人物漂移主角性格前后不一致行为逻辑断裂缺少可注入的人物状态约束剧情回环反复描写相似冲突故事没有推进缺少事件发生清单和状态锁空洞注水句子语法正确但信息量为零缺少具体化指令和细节密度要求结尾烂尾高潮被压缩伏笔被硬收缺少全局结局锚点与收束规划这五个问题不是独立出现的。实际情况通常是上下文失忆诱发人物漂移人物漂移导致情节推进不下去AI只好靠注水填空最后收不住就烂尾。一条完整的崩坏链。1.2 底层原因模型眼里没有50章之前聊解决方案之前得先弄明白模型为什么会有这些通病。Transformer架构的生成原理是根据前面所有的token预测下一个token的出现概率。所以它每一句话都是合格的每一段都是通顺的但它的规划范围只限于当前窗口。上下文窗口就是模型一次性能看到的内容上限常见的是几千到十几万个token。如果你把一部20万字的长篇全部扔进去后面的token会把前面的内容冲掉相当于你的第10章是在不知道第1章写了什么的情况下生成的。这个特性决定了AI天然适合写片段不适合写长卷。它像一个记忆力很差的天才写手单看任何一段都才华横溢但你让它写完一整本书它记不住自己前面埋了什么雷。1.3 解决思路把记忆从模型内部搬到外部既然模型内部没有稳定记忆那就不要在模型内部找答案而是把记忆外置到你自己可控的文件、模板和脚本里。这就是我做代码的出发点人物状态卡负责记录人物每次生成前重新加载。事件状态追踪表负责锁死剧情防止AI无中生有或绕圈。细节密度清单负责防止注水。结局锚点负责防止烂尾。上下文注入脚本负责把这些东西自动拼装塞进每一条生成请求。这套方法本质上是把一个不擅长长程记忆的模型改造成一个每章都带着完整备忘录开工的写手。你不用提升模型的记忆力只要每次开工前把备忘录摆在它面前就行。2. 通病一设定与人物见光死我用人物状态卡治它2.1 症状与根因写网文最怕人物崩。第1章那个冷静克制、外冷内热的刑警到第9章突然变成了话痨暖男读者第一个炸。但你怎么怪AI你每次对话都是从零开始的它根本不知道主角在第1章说过什么话、做过什么事。很多人的第一反应是把人设写进第一句提示词比如你是一个冷酷的刑警。但冷酷这个词太抽象AI生成出来的冷酷只有一种模板话少、眼神冷、动作干脆。等你写到第20章这个脸谱化角色已经没有任何新意了。真正的角色是具体的他左手习惯还是右手习惯他遇到危险时先保护谁他有什么绝对不能触碰的底线。2.2 对症代码人物状态卡模板我做的第一个人物状态卡长这样【人物状态卡】角色名林澈 【基本属性】年龄29性别男职业刑警 【性格基线】冷静、克制、不轻易表达情绪外冷内热 【行为规则】遇到威胁时优先保护无关人员不抽烟左撇子 【当前状态】第7章结束时右手受伤住处被人侵入 【禁忌】绝不可能背叛搭档 【已用伏笔】第3章提到父亲留下的怀表尚未揭晓看起来像普通笔记核心是注入时机。每次生成新章节之前把这份状态卡连同上一章末尾一起喂给模型让它先吸收设定再开始写。我把这个动作叫作重新加载上下文。这跟写代码之前先看一遍需求文档是一个道理。2.3 实操把人物状态卡做成自动注入手贴状态卡能做但很烦。我现在靠一段脚本自动加载把人物卡、世界观和上一章结尾拼成一个提示词直接丢给模型。import json def load_context(character_file, world_file, last_chapter): with open(character_file, r, encodingutf-8) as f: characters json.load(f) with open(world_file, r, encodingutf-8) as f: world f.read() character_text json.dumps(characters, ensure_asciiFalse, indent2) context ( 【世界观设定】\n world \n\n 【人物状态】\n character_text \n\n 【上一章结尾】\n last_chapter \n\n 请严格依据以上信息续写下一章。 不允许出现与人物状态卡矛盾的行为、对话和习惯。 ) return context这段脚本本身没什么高深的重点在于它逼迫你维护好characters.json。每次章节更新之后你都要打开这个JSON把人物当前状态改掉。比如林澈右手受伤这件事如果第8章没写他康复那第9章他就不能徒手跟人搏斗。状态卡记一笔模型就老实一笔。这里有一个特别容易踩的坑JSON字段不要贪多。我一开始把角色的童年经历、家庭关系、喜欢吃什么全塞进去结果发现上下文被无关信息占满反而把真正重要的当前状态挤掉了。人物状态卡只保留三个部分不会变的基本设定、当前会影响剧情的动态状态、绝对不能违背的禁忌。什么童年阴影、星座血型等写到相关情节再单独补。3. 通病二剧情逻辑断裂与无限绕圈用事件状态追踪表锁死进度3.1 症状与根因AI写长篇写到中期会出现一种我称之为伪进展的现象。看起来每章都有新情节但整体上故事一步都没往前走。主角刚到A地又被传送回B地反派死了一次下一章又活了同一个悬念每次翻章都重新抛出来。为什么会这样因为模型在生成每一章时只追求单章内部的自洽它没有能力核对已经发生的事件清单。这是长篇写作最难治的一个病。人物漂移你还能靠状态卡约束剧情逻辑问题则需要一套更复杂的机制——事件锁。3.2 对症代码事件状态追踪表事件状态追踪表是我最先完善的工具核心思想是把已经发生的事实记录下来并且明确告诉模型这些事实不可推翻。【事件状态追踪表】 - 事件编号E-01 章节第3章 人物林澈、苏薇 关键动作取得怀表 结果怀表在苏薇手里 后续影响苏薇身份存疑 - 事件编号E-02 章节第5章 人物苏薇 关键动作苏薇谎称怀表丢失 结果林澈暂时相信 后续影响苏薇的谎言是后期关键爆点3.3 实操把事件锁写进提示词生成新章节之前把事件追踪表整理成一段铁律直接放在提示词最上方【铁律】以下事件已经发生不得推翻、不得遗忘、不得重复发生 1. 林澈在第3章取得了怀表。 2. 怀表目前由苏薇保管。 3. 苏薇在第5章向林澈谎称怀表丢失。 4. 林澈右手在第7章受伤尚未痊愈。 请续写下一章。新章节可以创造新事件但必须与以上事件保持一致。我试过很多复杂prompt最后发现最有效的反而是这种简单直白的条件约束。模型写崩往往不是因为它不知道怎么写而是因为没人告诉它哪些是记忆里必须存在的东西。你把事件清单摊开它就不会自己脑补出一个新的怀表去向。分享一个实操细节事件追踪表每章都要更新更新的动作最好固定在写完之后马上做。我一开始是写三五章才回头补一次结果刚补完上一章下一章又写了一章新冲突旧事件彻底对不上号了。后来我每章生成完第一件事就是打开events.md追加新事件同步修改旧事件的后续影响。坚持了大概十章整个剧情线的连贯性明显上了一个台阶。4. 通病三内容空洞、套话连篇用细节密度清单逼它写具体4.1 症状与根因AI写的长篇里水是最常见的现象。它太会写那种正确但没有信息量的句子了他感到一丝不安仿佛有什么事情即将发生她的眼神里透着复杂的光芒。这种句子连写十段剧情还是原地踏步。根因在于模型生成文本时倾向输出概率最高的表达而概率最高的表达往往是概括性的、模糊的、放之四海而皆准的。这个问题本职工作叫注水放在长篇写作里是致命的。读者可以容忍一章的过渡但容忍不了连续五章都是这种内容。4.2 对症代码五感写作卡我给每章生成写了一个细节密度清单要求生成的文本必须覆盖以下要素具体动作不是情绪概括而是身体行为。比如他攥紧拳头而不是他愤怒。实物细节场景里有具体物品有气味、声音、光影不只是房间很暗。对话潜台词两个人的对话不能是简单的一问一答必须有弦外之音。时间与空间锚点读者能清楚知道现在是几点、在哪个城市哪个房间。把它做成提示词放在章节生成指令里【写作要求】 本段要求使用细节密度清单 - 每个角色至少有1个具体的身体动作 - 场景至少包含2个可感知的实物细节 - 对话中至少有1处潜台词 - 每章开头100字内交代时间和空间锚点4.3 实操空洞写法与细节写法的现场对比同样一个情节直接让AI写和加了细节清单的AI写差距非常直观。空洞版林澈走进了房间看到苏薇坐在窗边。他心里很复杂不知道该不该相信眼前这个女人。空气里弥漫着紧张的气氛他总觉得有什么事情要发生了。细节版林澈推门时门轴发出一声尖锐的吱呀。房间里的白炽灯闪了一下窗边坐着的苏薇手里握着一只已经凉透的茶杯茶水表面浮着一层细小的白色泡沫。他把右手藏进风衣口袋指尖碰到绷带粗糙的布面。苏薇没有抬头只说了一句你来得真晚。她面前的窗台上那只怀表不见了。很明显第二版的信息密度完全不同。读者能从右手藏进口袋看到林澈的伤从怀表不见了看到剧情冲突从凉透的茶杯看到等待时间。细节不是装饰细节就是剧情的容器。4.4 补充技巧图层展开法我在写长篇时还有一个习惯叫图层展开。把每一段文本拆成动作层、环境层、心理层三个维度。动作层负责推进情节环境层负责氛围渲染心理层负责角色情绪。跟AI说清楚这个分层逻辑之后提示词长这样请按图层展开本段 1. 先写动作层主角做了什么怎么做的。 2. 再写环境层周围有什么光线、声音、气味。 3. 最后穿插心理层角色此刻的判断和怀疑。 要求三层交替分布禁止写成整段心理独白。这招直接治住了AI爱写大段情绪独白的毛病。因为如果你不指挥它模型会自然地沉溺在他感到他觉得他意识到里面整页纸没有一个人做事情。5. 通病四结局烂尾或突然加速用逆提纲和收束检查兜底5.1 症状与根因长篇最怕烂尾AI尤其容易烂尾。写到后半段时上下文压力越来越大模型判断尽快结束反而是概率最高的选择于是主角突然大爆发打败反派伏笔什么都还没解释整本书就戛然而止。这种体验就像追了三个月的小说最后两章签约作家跑路了。5.2 对症代码逆提纲法我解决烂尾的方法是在动笔之前就先想好结局这个动作叫逆提纲。不是从第1章往后推而是先把最后一章的关键事件写出来再往回倒推每一章该往哪个方向走。实际操作时我把结局锚点写成一个固定字段注入每一次章节生成【结局锚点】 最终结局设定 林澈最终发现苏薇才是幕后黑手但在关键时刻选择保护她。 所有伏笔必须在最后一章收束 - 怀表的真正用途 - 林澈父亲死亡的真相 - 苏薇的真实身份 请确保本章情节向结局锚点推进不得写出与结局方向完全无关的章节。这个锚点相当于给AI的导航终点。它不是规定每一章必须发生什么而是保证每章都在朝同一个方向走不会迷路。5.3 实操收束条件自查清单光有锚点还不够我还做了一张收束条件自查清单每写两三章就跑一遍【收束检查】 请检查当前章节是否满足以下条件 - 怀表伏笔是否已经解释其用途 - 父亲之死是否已经揭晓真相 - 苏薇身份是否已经揭示 - 未满足的部分后续章节中是否已有潜在安排 如果没有请给出下一章可以铺垫的方向建议。这个检查单独作为一轮对话不要和章节生成混在一起。它的作用不是让AI改稿而是让你自己看清当前离结局还差几步哪些伏笔在悄悄流失。5.4 代码化伏笔闭环检测脚本如果项目够长纯靠人脑记伏笔也不靠谱。我写了一个很简单的伏笔检测脚本逻辑就是维护一张伏笔清单每章标注状态最后自动列出未闭环的项。def check_plot_hooks(hooks_file): with open(hooks_file, r, encodingutf-8) as f: hooks json.load(f) unresolved [] for hook in hooks: if hook[status] ! closed: unresolved.append(hook[name] | 涉及章节: hook[opened_chapter]) if unresolved: print(以下伏笔尚未闭环) for item in unresolved: print(- item) else: print(所有伏笔均已闭环可以安心收尾。)脚本很简单但跑起来很爽。每次写完一章更新伏笔状态扫一眼输出结果哪条线没跟上立刻一目了然。6. 通病五多线并行时全线失控用主支线矩阵理顺脉络6.1 症状与根因写长篇只要稍微有点规模几乎逃不开支线。主角查案是主线反派视角是副线配角的感情线偶尔也要出来透口气。AI最怕这种多线程任务它没有能力同时维护几条线的因果关系经常把支线写成独立短篇主角在主线里下一步要干什么等回到主线的时候已经完全接不上了。6.2 对症代码主线支线矩阵我建了一个主线支线矩阵表把所有进行中的线索都放在一张表里管理。线名类型目标涉及人物下一场关键戏优先级怀表谜案主线查明怀表与父亲死亡真相林澈、苏薇苏薇谎称怀表丢失被识破P0警察局内鬼支线A找出泄露消息的内鬼林澈、老周林澈发现老周深夜进入档案室P1苏薇的救赎支线B揭示苏薇真心并推动她反转苏薇、林澈苏薇与幕后黑手通话被林澈撞见P1这张表的最重要作用是让AI知道当前主战场在哪。我在每次生成之前会加一段线序说明【当前线序】 当前主线怀表谜案。本章围绕主线推进。 支线A警察局内鬼。本章如涉及描写不超过500字。 支线B苏薇的救赎。本章场景控制在对话内不触发大冲突。 支线场景结束后必须回到主线不允许连续两章只写支线。6.3 实操把支线显式化很多人写长篇会犯一个隐性错误默认AI知道哪条线是主线。实际上模型根本不知道你不在提示词里标明线序它每一章都会随机抽取一条线写。有时候写了一整章配角的感情戏主角的案子一点没推进你还得回头删稿重写。后来我强制自己每章开头标注本章归属线这样AI才不会跑偏。把支线显式化还有一个好处就是你自己也更容易控制节奏。主线写得太紧了就安排一章支线缓冲主线松了就把支线停掉专心推主线。这个节奏感是在线序矩阵里直接体现出来的。7. 把五套代码打包成一套可用的长篇写作流水线7.1 目录设计与文件规范以上五套方案分开用各自都能解决一个问题但真正好用是把它们组装成一个系统。我用了一个非常简单的文件夹结构来管理所有写作项目直接分享出来novel_system/ ├─ 00_config/ │ ├─ world.md # 世界观、基本规则、地理气候 │ ├─ characters.md # 人物状态卡汇总 │ ├─ timeline.md # 时间线记录每章经过的时间 │ ├─ plot_hooks.md # 伏笔清单 │ └─ events.md # 事件状态追踪表 ├─ 01_templates/ │ ├─ chapter_gen.md # 章节生成模板 │ ├─ state_update.md # 状态更新模板 │ ├─ plot_check.md # 剧情一致性检查模板 │ └─ ending_check.md # 收束检测模板 ├─ 02_scripts/ │ ├─ context_injector.py # 上下文注入脚本 │ └─ hook_checker.py # 伏笔闭环检测脚本 └─ 03_output/ ├─ chapters/ # 每章正文 └─ state_backup/ # 状态备份这套目录本身没什么技术含量但它解决了一个很现实的问题写作状态到底是放在脑子里还是放在文件里。你每写十章状态文件就是你的记忆外挂。哪怕隔了一个月再回来写只要把config目录打开全貌立刻恢复。7.2 操作流水线七步工作法有了目录和脚本我每章的实际操作流程固定为七个步骤。第一步定主线与结局。新项目动笔前先用逆提纲法写出结局锚点和主线方向写进world.md。第二步建人物状态卡。给主要角色建卡填基本属性、行为规则、禁忌暂空当前状态。第三步每章先写大纲。一小段就好100字左右说清楚本章发生在哪里、由谁推动、解决什么问题、朝结局推进多少。第四步注入上下文生成。用context_injector.py把世界观、人物卡、事件表、上一章结尾、本章大纲拼装成完整提示词喂给模型生成正文。第五步更新状态。打开events.md追加本章新事件同步修改人物当前状态和伏笔表。第六步一致性巡检。用plot_check.md做一轮快速检查确认没有出现矛盾设定。第七步伏笔闭环扫描。运行hook_checker.py看哪些伏笔未闭环及时在下一章安排收束。这套流程看起来繁琐实际上跑熟之后一章只需要十分钟左右。其中第四步生成占大头第五和第七步加起来三分钟。但就是这三分钟的固定动作把我原来写到第20章必崩的魔咒破掉了。7.3 几条保住性命的实操经验这些经验全部来自翻车之后每一条都是真金白银换来的。第一不要一次性把整个世界观全扔给模型。我第一版把world.md写了两千字注入进去之后把上下文塞得满满当当模型反而不知道该关注什么生成的章节既没重点也没风格。后来只保留当前剧情真正相关的规则状态瘦身之后效果立竿见影。第二每章的大纲阶段不能省。你要让AI写的是一章有明确目标的章节而不是故事自然发展。没有目标的章节模型就会用自己最喜欢的套路写三章之后所有章节结构全部雷同。第三跑偏了立刻打断不要将错就错。如果生成到一半发现人物说了一句完全不符合设定的话直接停止重新调整提示词再生成。你让它把整章写完再改这个错误可能已经渗透进后面的文本里了。第四定期备份状态文件。state_backup目录里的备份我是每五章做一次全项目打包压缩。AI生成的文本本身不贵但状态文件里的设定和事件表积累起来之后非常值钱丢一次心态直接崩。8. 写在最后别指望AI记住你要替它记住这套方法我自己用了将近半年最大的收获不是让AI写的每一章都完美而是让崩坏变得可控。以前写到20章只能扔掉重来现在写到20章还能清晰地指出是第几章开始发飘具体是哪个角色出了问题哪条事件链断了。这种掌控感比任何prompt技巧都重要。这五套代码不是什么黑科技本质上是把写作这件事工程化了。人物状态卡是实时更新的人设表事件追踪表是剧情的事实数据库细节清单是防注水规范结局锚点是导航终点注入脚本是每天开工前的例行检查。它们合在一起解决了AI最不擅长的问题把散装文本变成一条贯穿始终的长线。最后再分享一个小技巧。每次写完一章花三十秒问AI一个问题本章如果全部删掉后面的故事是否还能成立如果答案是能那这就是一章水章下一章必须大幅推进。这个问题我试过很多次比任何复杂的结构分析都直观。AI写长篇不崩的秘诀说到底就一句话别指望模型拥有好记性你要做那个把备忘录一直摊在它面前的导演。