尧图网页设计 
简介基于文件级长期记忆与Smart State模式的AI长篇小说创作系统面向AI创作者、文学爱好者和大模型应用开发者旨在解决长篇故事持续创作、情节连贯和记忆管理等核心痛点。整个资源包共116个文件其中68个Markdown文档承担小说章节、角色设定与记忆记录35个Python脚本实现核心创作逻辑与调用流程9个JSON文件保存索引、实体映射和流程指标另含Shell脚本、文本说明与YAML配置文件压缩包整体仅336KB轻量高效。当前已有136人学习下载。系统内置了专门用于中文分章节小说创作的功能可自动生成章节并设置悬念钩子配合文件级长期记忆能够支持百万字级长篇并快速产出超过20章的完整文稿保持故事前后呼应。对于想尝试AI长篇创作、研究长期记忆机制或二次开发小说生成管线的读者这套资源提供了可直接运行的代码、模块清晰的目录结构以及从故事索引到创作监控的完整参考。1. 百万字小说创作卡在3万字文件级长期记忆与Smart State模式怎么破局我见过太多AI长篇小说创作项目死在同一个地方用常规对话方式写完前几万字后彻底失控。人物说话腔调逐渐趋同、伏笔回收时记不清埋在了哪一章、时间线悄悄错位——这些不是模型能力不够而是记忆没有跟着故事一起增长。AI长篇小说创作系统里最核心的设计不是某句神奇提示词而是怎么管理记忆。文件级长期记忆的思路很朴素把人物档案、世界观、时间线、伏笔这类关键信息以文件形式落盘管理再配合Smart State模式在准备、写作、反思、压缩四个状态间自动流转按需读取记忆。这样上下文窗口永远只放当前需要的部分理论上可以支撑百万字级的持续创作。这篇笔记从选型原因讲到最小可复现代码再给你一套避坑清单照着搭就能跑。2. 先想清楚再写代码文件级长期记忆的选型对比与Smart State状态机设计2.1 三种记忆方案的取舍上下文窗口、向量库、文件系统做技术选型时记忆放哪决定了整个系统的上限。我见过不少人在上下文窗口、向量数据库、文件系统之间反复横跳最后选错了载体整个管线推倒重来。先看一张对比表后面展开说为什么文件在这类场景里是下限最高的选择。记忆方案优势短板适合场景上下文窗口接入简单模型天然支持成本随长度非线性上涨窗口有限历史重复发送导致有效信息密度低短篇、单场景写作向量数据库支持全库语义检索召回相关段落检索有模糊性关键设定可能被近似结果带偏需要额外维护Embedding与库本身人工修正不直观知识库问答、检索增强文件级长期记忆精确透明、可人工修订、可版本控制、按需挑选加载读写策略要自己设计做不好容易堆成碎片长篇小说这种每个细节都可能是伏笔的创作场景先排除纯上下文窗口。你以为把前几十章全文塞进Prompt里就解决了只要故事超过五万字每次调用都要把所有历史重复发一遍Token成本按字数平方上涨而且模型对塞在最后面的指令记忆反而更差。更麻烦的是你无法单独修正某一段记忆——改一个人设得重新把全文拼一遍再发。向量数据库看起来高级实际用在长篇小说创作里很别扭。创作需要的是精确一致性林远在第一卷左手中指戴过一枚黑色戒指这个事实必须百分百准确。向量检索给的答案是与查询最相似的段落哪怕相似度达到0.95那缺失的5%也会让设定漂移。我做过测试让同一个模型基于向量检索写五十章到第三十掌时戒指的颜色已经开始互换了。这不是模型笨是检索层引入了不确定性。文件级长期记忆是确定性最强的方案一个人物一个文件一个伏笔一条JSON记录读取时明确指定路径修改时直接编辑文件。模型看到的记忆内容完全可控人工介入也容易。代价是你要自己设计一套读写规则——这正是Smart State模式存在的意义。2.2 Smart State的四种状态与转换规则Smart State模式本质是一个极简的创作Agent状态机比市面上鼓吹的通用AI Agent聚焦得多。核心是管理什么时候加载记忆、什么时候写入记忆、什么时候整理记忆。四个状态定义如下PREPARE准备态在写每一章之前根据当前章节的计划决定加载哪些记忆块拼装写作Prompt。WRITE写作态调用大模型生成正文上下文只包含准备态装配好的内容。REFLECT反思态每章写完后把本章发生的关键信息人物变化、时间推进、新伏笔、已回收伏笔更新进对应的记忆文件。COMPACT压缩态每隔固定章节数把已经写过的一段情节做成更粗粒度的摘要腾出记忆空间的保质期。转换规则不是简单轮转而是带条件判断当前状态触发事件下一状态PREPARE记忆装配完成WRITEWRITE正文生成完成且未到压缩间隔REFLECTWRITE正文生成完成且章节数是压缩间隔的整数倍COMPACTREFLECT记忆更新完成PREPARECOMPACT压缩完成REFLECT这里有个细节我踩过坑压缩态结束后不要直接回到PREPARE而是先补一次REFLECT。因为压缩过程会重写旧摘要可能影响最近一章的记忆一致性。先把当前章的动态记忆固化下来再进入下一轮准备。2.3 为什么这套设计能扛住百万字关键在于把记忆分成了三层静态记忆、动态记忆、归档记忆。静态记忆是世界观和人物基线几乎不随情节变化写好后就固定在那里。动态记忆是最近几章的摘要和当前状态的快照每次写作要加载。归档记忆是更早的情节浓缩只在需要跨越引用时按需抽取。这三层对应文件系统的不同目录读取策略完全不同。静态记忆每次必读动态记忆滚动加载最近三章归档记忆平时不碰。有了这个分层每一轮写作的Token消耗稳定在一个固定区间不会随着小说篇幅增长而膨胀。我验证过这个结构在十万字、三十万字、六十万字三个节点上单章生成的Prompt长度波动不超过5%。一句话总结文件级长期记忆给了系统记住什么的答案Smart State模式给了什么时候记、什么时候取的节拍器。3. 搭建最小可运行的创作系统目录规范、记忆装配与写作循环代码3.1 项目目录与文件级记忆的落盘规范拿到zip包解压后项目目录结构一般会包含下面这些核心路径。目录规范是整个系统的地基我建议你直接沿用不要自己临场发挥改命名——等写到了第五十万字再回来调整目录那灾难就大了。# 解压 zip 后的推荐目录布局 novel-system/ ├── config.yaml # 全局配置 ├── memory/ # 文件级长期记忆的唯一根目录 │ ├── core/ # 静态记忆不变或低频变化 │ │ ├── world.md # 世界观与力量体系 │ │ ├── characters/ # 每个角色一个 md 文件 │ │ │ ├── 001_林远.md │ │ │ └── 002_苏晴.md │ │ └── timeline.json # 全局时间线 │ ├── scenes/ # 已写章节的动态摘要滚动保留 │ │ └── arc_001/ │ │ ├── chapter_001_summary.md │ │ ├── chapter_002_summary.md │ │ └── ... │ ├── plots/ # 伏笔与情节线 │ │ └── foreshadows.json │ └── status.json # 当前状态快照写到了第几章、活跃角色是谁 ├── output/ # 生成的正文全文 ├── prompts/ # 提示词模板 └── scripts/ # Python 脚本有一个关键原则core目录的文件只能手动修改或者由REFLECT状态精准更新绝不能让模型自由落盘。动态角色状态这个人现在心情如何、和谁的关系变了通常我放在单独的characters_state目录里和核心性格基线分开。基线是设定状态是进展混在一起会导致模型写着写着把临时情绪改成了永久性格。我一般会在memory目录下放一个.meta.json记录每次重要记忆变更的时间和触发章节方便回溯问题。这在后面第6章会展开。3.2 核心代码Smart State状态机实现状态机的实现不复杂但要保证转换条件符合业务直觉。以下代码是核心骨架生产环境我会加上事件落盘和异常兜底这里先给你看主干。# scripts/smart_state.py from enum import Enum class State(Enum): PREPARE prepare # 准备态装配本次写作所需记忆 WRITE write # 写作态调用大模型生成正文 REFLECT reflect # 反思态把本段故事压缩成记忆 COMPACT compact # 压缩态对旧记忆做摘要合并 class SmartStateMachine: 控制创作流程的状态机核心是决定下一步干什么。 def __init__(self, config: dict): self.config config self.current State.PREPARE self.serial 0 # 当前章节序号 self.last_event None def transition(self, event: dict) - State: 根据事件决定下一个状态。 event 至少带 kind 字段finish_prepare / finish_write / finish_reflect / finish_compact。 kind event.get(kind, ) interval self.config[memory][compact_interval] if self.current State.PREPARE and kind finish_prepare: self.current State.WRITE elif self.current State.WRITE and kind finish_write: if self.serial 0 and self.serial % interval 0: self.current State.COMPACT # 写满整卷先压缩旧记忆 else: self.current State.REFLECT # 平时写完立刻反思更新记忆 elif self.current State.REFLECT and kind finish_reflect: self.current State.PREPARE elif self.current State.COMPACT and kind finish_compact: self.current State.REFLECT # 压缩完成补一次最近章节反思 return self.current逻辑说明状态机的每一次转换都由外部事件驱动而不是靠定时器。event字典里的kind字段标记了上一动作是否完成。关键判断在WRITE结束的分岔章节数是压缩间隔的整数倍就先做COMPACT否则直接进REFLECT。这个设计保证大情节节点前后记忆不会被零散的章节摘要淹没。参数说明compact_interval是压缩间隔一般在config.yaml里配成 10 或 12。间隔太小压缩太频繁影响创作连续性间隔太大动态记忆文件会累积到失控。对百万字级别的小说我按整卷边界约 8 到 12 章一卷来配这个值。3.3 核心代码记忆装配与章节生成管线状态机只是节拍器真正干活的是记忆装配模块。装配的关键原则是按需加载、控制总数、缓存静态内容。# scripts/memory_loader.py import json from pathlib import Path class MemoryLoader: 从文件系统按需读取记忆所有读取都带缓存避免重复读盘。 def __init__(self, root: str): self.root Path(root) self._cache {} def load_core(self) - str: # 静态记忆世界观 当前卷大纲每次写作必读 if core not in self._cache: world (self.root / core/world.md).read_text(encodingutf-8) self._cache[core] world return self._cache[core] def load_recent_summaries(self, serial: int, keep: int 3) - list: # 动态记忆最近 keep 章的摘要太多会稀释当前注意力 base self.root / scenes summaries [] for i in range(max(1, serial - keep), serial): f base / farc_001/chapter_{i:03d}_summary.md if f.exists(): summaries.append(f.read_text(encodingutf-8)) return summaries def load_characters(self, active_ids: list) - str: # 只加载当前出场角色几百个角色全塞进去必炸 texts [] for cid in active_ids: f self.root / core/characters / f{cid}.md if f.exists(): texts.append(f.read_text(encodingutf-8)) return \n\n.join(texts)逻辑说明load_core使用缓存是刻意的——世界观文件可能几千字读取解析一次就够了每章都重新读盘纯属浪费。load_recent_summaries的keep参数是关键调优点它控制动态记忆窗口的宽度。我试过keep5上下文太长反而让模型分不清主次keep2会在跨章节情节上丢线索。最终常见的稳妥值是 3。参数说明active_ids列表从哪里来这是 PREPARE 态的核心产出。我的做法是让模型在上一次 REFLECT 结束时用固定格式输出下一章的预计出场角色ID同时把上一章实际出现的角色ID写入status.json。装配时取两者的并集防止角色突然闯入却没带档案。接下来是写作管线把上面两个模块串起来# scripts/write_pipeline.py from smart_state import State, SmartStateMachine from memory_loader import MemoryLoader def build_prompt(state: State, loader: MemoryLoader, serial: int, active_roles: list, outline: dict) - str: # 提示词由“记忆块 本次写作指令”组装 blocks [ loader.load_core(), loader.load_characters(active_roles), # recent summaries 属于动态记忆避免在 PREPARE 阶段读太多次 *loader.load_recent_summaries(serial, keep3), f本章目标{outline.get(goal, )}, f小说内时间{outline.get(in_story_time, 未知)}, ] return \n\n.join(blocks) def run_chapter(config, serial: int, outline: dict) - str: loader MemoryLoader(config[memory_root]) sm SmartStateMachine(config) sm.serial serial sm.transition({kind: finish_prepare}) # 进入写作态 prompt build_prompt(sm.current, loader, serial, outline.get(roles, []), outline) # 调用兼容 OpenAI 协议的接口用最大文本长度兜底 text llm_generate(prompt, max_tokensconfig[model][max_tokens_paragraph]) sm.transition({kind: finish_write}) # 进入反思态或压缩态 # REFLECT把本段内容浓缩成摘要写回 memory/scenes if sm.current State.REFLECT: summary summarize(text) write_summary(serial, summary) sm.transition({kind: finish_reflect}) return text逻辑说明llm_generate和summarize是示意函数落地时分别替换成你的模型调用和摘要Prompt。整个循环的节奏是准备 → 写作 → 反思三步推进。这里有个隐含设计finish_prepare事件是在build_prompt之前触发的所以状态机的 WRITE 态已经就位装配函数内部不再需要判断状态代码路径更短。参数说明config[model][max_tokens_paragraph]建议从 2000 到 3000 之间取值。小于 2000生成内容容易在情节半途切断SUMMARY 被迫频繁写本章尚未完结大于 3000单次生成的叙事节奏容易松散而且模型在长生成末尾的记忆回溯能力会明显下降。4. 从零跑通到十万字初始化、参数设置与记忆归档节奏4.1 初始化创作世界观、人物档案与大纲的写入格式很多项目死在第一步直接把一大段世界观文字丢给模型让它边写边自己整理。结果写到第十章模型把力量体系的规则给改了。初始化阶段要做的不是告诉模型故事设定而是建立后续记忆更新的锚点。人物档案的文件格式要区分基线与动态状态两部分。基线是铁律REFLECT 时禁止触碰动态状态允许更新。# 角色档案林远 ## 基础信息 - 年龄24故事时间第4章时 - 身份青云宗外门弟子 - 外貌左眉有一道旧疤惯用左手 ## 性格基线REFLECT时不可突破 - 底色隐忍重情义怀疑心重 - 说话习惯短句很少用感叹号 - 行为模式先做后说吃了亏先记下 ## 动态状态REFLECT时按情节更新 - 当前目标寻找妹妹失踪的线索 - 近期情绪焦虑但不动声色 - 与苏晴的关系互不信任的搭档参数说明基础信息里的故事时间一定要写清楚是哪一章时点否则REFELCT把几章前的外貌更新覆盖掉时间线就乱了。“性格基线”块我用特殊标记不可突破并在写作Prompt里明确告诉模型如果情节需要偏离基线必须先写一段内心冲突来铺垫而不是悄无声息地改变人设。世界观文件同理。我会在里面用章节号标记变更点比如天道规则补充第37章出现跨境界战斗余波规则如下……。这样后续REFLECT更新时能知道哪条规则是在什么情节下新增的。大纲建议按卷拆分每卷一个md文件内含本卷核心冲突和高潮节点。所有初始化文件都建好后跑一遍脚本生成初始status.json里面的current_serial设为0active_roles设为第一卷前三章必然出场的角色ID列表。4.2 章节生成的参数设置温度、目标Token与惩罚系数的配合模型参数不是万能药但调错了确实会放大记忆管理的压力。这是我在不同状态下的经验值可以参考后根据自己的模型风格微调。# config.yaml 关键参数 model: temperature: 0.8 # 写作态0.7-0.9太低会复读记忆太高会脱离设定 max_tokens_paragraph: 2500 # 单章正文上限 presence_penalty: 0.2 # 对重复提到同一概念做轻微抑制 memory: recent_summary_keep: 3 # PREPARE 时加载最近几章摘要 reflect_interval: 1 # 每1章做一次REFLECT compact_interval: 10 # 每10章做一次COMPACT参数说明temperature的取值逻辑源于一个现象——当上下文里混入了三个章节摘要时模型倾向于把摘要里的词原样复述导致新章节读起来像旧章扩写。设置 0.8 左右的温度能压制这种复读倾向但调到 0.9 以上又会让人物对话失控。presence_penalty我试过调到 0.5结果模型开始刻意回避人名用那个人指代主角带来新问题。reflect_interval我固定为 1每章都做反思。有人嫌它浪费Token我也试过每三章做一次反思结果第二章的记忆细节被第三章覆盖到第四章节时第一二章的信息已经出现混淆。省下的Token远不及修复bug的成本。4.3 REFLECT的写入规范与COMPACT的执行时机REFLECT不是把整章交给大模型让它总结一下就完事。要给它一个固定的输出结构才能写入文件后还能被下一次PREPARE方便读取。我常用的REFLECT Prompt要求模型输出四段本段情节摘要200字内、角色状态变更按角色ID列出、时间线推进明确小说内过去了几天、伏笔记录新增哪些未回收线索回收了哪条旧的。输出是JSON格式然后由脚本写入对应文件# scripts/reflect_writer.py import json from datetime import datetime def apply_reflect(result: dict, serial: int, root: str): # result 来自大模型按固定JSON结构输出的反思结果 # 1. 更新时间的推进 timeline_path f{root}/core/timeline.json with open(timeline_path, encodingutf-8) as f: timeline json.load(f) timeline[events].append({ chapter: serial, advance_days: result.get(days_advanced, 0), note: result.get(summary, )[:100] }) # 2. 更新角色状态文件不是核心档案而是动态状态 for change in result.get(character_changes, []): state_path f{root}/core/characters_state/{change[id]}.json with open(state_path, w, encodingutf-8) as f: json.dump(change[state], f, ensure_asciiFalse, indent2) # 3. 记录伏笔 f_path f{root}/plots/foreshadows.json # ... 类似更新逻辑逻辑说明apply_reflect把大模型的JSON反思结果拆开分别更新时间线、角色状态、伏笔三个文件而不是写进同一个大文件。这样做的目的是让每个记忆文件保持单一职责后续要调某一个角色的状态直接读对应文件即可。COMPACT的执行时机是第10章、第20章这类整卷节点。我会把旧章节摘要合并成一个卷摘要放在scenes/arc_001/下文件名从chapter_001_summary.md改成arc_001_summary.md。注意不要删除原章节正文output/目录保留全文只是记忆层做压缩。5. 百万字级持续创作避坑五个高频翻车现场与排查方法这一章是血泪经验集中区。我在多个长篇小说项目里排过雷下面五个问题出现频率最高每条按现象→原因→解决的顺序写方便你直接照着排查。5.1 人物性格悄悄漂移基线档案和动态状态没有隔离现象主角写到第四十章时从惜字如金变成了话痨读者反馈人设崩了。排查记忆文件发现人物档案里的说话习惯字段不知何时被改成了善于表达。原因REFLECT更新记忆时模型把动态状态比如这一章他情绪激动所以多说了几句话写进了基线字段。两类信息混在同一个文件里模型无法区分哪些可改、哪些不可改。解决严格分离基线档案与动态状态分别放在characters/和characters_state/两个目录。REFLECT的更新逻辑只允许写动态状态目录。在写作Prompt里增加约束角色性格基线如无重大情节铺垫必须保持稳定任何临时情绪波动写入角色状态文件。同时初始化脚本里对基线文件做只读标记业务代码禁止往该目录写内容。5.2 时间线错乱只记章号不记小说内时间现象第二章写三日后第四章直接写第二天清晨读者以为主角学会了瞬移。排查发现时间线文件里只有章节号没有记录每章推进了几天。原因生成正文时模型只知道自己刚写到第四章不知道故事内已经过了多少天。大纲文件里写了本卷时间跨度三个月但模型不会自动去换算当前日期。解决在outline数据结构里增加in_story_time字段每个章节计划都明确标注开始日期如大周历七月十二。REFLECT的输出结构里增加days_advanced字段每次写完后累加时间线。PREPARE装配Prompt时把当前时间点作为必填上下文。排查问题时先看timeline.json的事件列表比对章节号与日期是否匹配。5.3 记忆文件无限膨胀没有滚动窗口清理机制现象写到三十万字时单章的Prompt从原来的2千Token涨到4千Token生成一次的成本翻倍速度也明显变慢。查看scenes/目录发现所有章节摘要都堆在那里。原因REFLECT每章都写入新摘要但没有任何机制淘汰旧摘要。load_recent_summaries(keep3)只控制了读取条数没控制文件的累积写入磁盘上的记忆文件越来越多迟早会拖累文件系统浏览和后续压缩操作。解决COMPACT阶段除了合并卷摘要还要执行归档策略超过当前卷范围的单章摘要统一移动到memory/archive/从主加载路径中移除。我通常保留最近两卷的单章摘要更早的全部归档为卷摘要。同时写一个脚本定时扫描scenes/目录单文件超过2KB的摘要会被提示重写压缩。5.4 状态切换过于频繁章节节奏碎成了一段段说明文现象写到十几章时剧情推进很慢每章开头都是大段的设定复述读者反馈像在看设定集。实际上单章生成质量正常但每章都在重复世界观和角色背景。原因PREPARE装配记忆时load_core()每次都读入完整世界观文件而世界观这章根本没变化。模型接到信息后会习惯性在正文开头铺垫一遍导致叙事节奏被拖垮。解决给load_core()增加版本号比对逻辑world.md的文件头记录一个version字段每次REFLECT如果世界观没有变更就不重新写入修改时间PREPARE读取时会检查版本号若与上次读取相同则用缓存副本。更重要的是Prompt里明确要求只有当世界观信息与本章情节直接相关时才复述否则不要提及。5.5 系统重启后失忆status.json没有兜底恢复机制现象服务进程崩溃后重启系统从第一章开始重新写或者从前几章的状态继续写但角色动态状态全部丢失。排查发现status.json里只存了current_serial没有存上一次REFLECT完成的摘要ID。原因写作流程是生成正文→写摘要→更新记忆→更新状态如果进程在第3步和第4步之间崩溃status.json里已经更新了章节号但角色状态文件没来得及写系统认为写过了其实记忆没存上。解决给status.json加一个last_committed_reflect_serial字段每次REFLECT完全写入后才更新。启动时对比current_serial和last_committed_reflect_serial如果前者大于后者说明上一章的记忆没有落盘自动回滚到上一章状态重新执行REFLECT。这个兜底逻辑大概二十行代码能省掉大量排障时间。6. 进阶给记忆文件加版本标记实现创作可回滚6.1 用脚本记录每次记忆变更的版本快照长篇小说创作中改错了后悔最让人头疼。比如你把一个男主的亲密关系从恋人改成仇敌写了五章后发现节奏不对想回到改之前的状态。如果在文件层没有版本概念就只能靠手动CtrlZ而这在几十个记忆文件之间根本不可靠。我建议在系统里集成一个极简的版本标记脚本每次REFLECT成功落盘后调用一次# scripts/version_mark.py import json import datetime import subprocess MEMORY_META memory/.meta.json def stamp(message: str): 给当前记忆快照打一个可回滚的版本标记。 record { time: datetime.datetime.now().isoformat(), message: message, git_commit: subprocess.getoutput(git rev-parse --short HEAD), } with open(MEMORY_META, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)逻辑说明这个脚本依赖git rev-parse获取当前提交的短哈希。前提是你把memory/目录纳入Git仓库并在每次REFLECT完成后执行一次git commit。这样memory/.meta.json就记录了每次记忆变更对应的Git提交想要回滚时看一眼.meta.json找到那次变更的哈希直接git checkout hash -- memory/就能恢复当时的记忆状态。参数说明message字段建议用结构化描述第42章REFLECT林远与苏晴关系改变新增伏笔-黑色令牌。这样排查问题时即使你不想回滚也能从时间线看到哪一步操作改变了记忆。6.2 一套可执行的自检脚本思路光有版本标记还不够我习惯在每次写作会话开始时跑一次自检检查三类问题记忆文件是否完整、状态快照是否一致、未回收伏笔数量是否异常膨胀。自检脚本不复杂就是对几个JSON文件做字段存在性校验再统计foreshadows.json里recovered: false的条目数。如果未回收伏笔超过20条我会主动触发一次COMPACT让模型把伏笔按照重要程度重新排列必要时合并相近线索。这套系统的核心价值在于你把模型能力和记忆管理解耦了。模型可以随时换——今天用闭源大模型明天换开源模型记忆文件依然是那些创作连续性不会断。我从第一个百万字项目里学到的最大教训是别高估模型对长文的自我管理能力也别低估文件系统作为记忆容器的潜力。先把状态机、目录规范、版本标记这三样搭扎实后续换模型、加新功能都只是在这个骨架上添肉。希望帮到你。本文还有配套的精品资源点击获取 文件级长期记忆与Smart State双引擎：破解AI长篇创作记忆失控难题
简介基于文件级长期记忆与Smart State模式的AI长篇小说创作系统面向AI创作者、文学爱好者和大模型应用开发者旨在解决长篇故事持续创作、情节连贯和记忆管理等核心痛点。整个资源包共116个文件其中68个Markdown文档承担小说章节、角色设定与记忆记录35个Python脚本实现核心创作逻辑与调用流程9个JSON文件保存索引、实体映射和流程指标另含Shell脚本、文本说明与YAML配置文件压缩包整体仅336KB轻量高效。当前已有136人学习下载。系统内置了专门用于中文分章节小说创作的功能可自动生成章节并设置悬念钩子配合文件级长期记忆能够支持百万字级长篇并快速产出超过20章的完整文稿保持故事前后呼应。对于想尝试AI长篇创作、研究长期记忆机制或二次开发小说生成管线的读者这套资源提供了可直接运行的代码、模块清晰的目录结构以及从故事索引到创作监控的完整参考。1. 百万字小说创作卡在3万字文件级长期记忆与Smart State模式怎么破局我见过太多AI长篇小说创作项目死在同一个地方用常规对话方式写完前几万字后彻底失控。人物说话腔调逐渐趋同、伏笔回收时记不清埋在了哪一章、时间线悄悄错位——这些不是模型能力不够而是记忆没有跟着故事一起增长。AI长篇小说创作系统里最核心的设计不是某句神奇提示词而是怎么管理记忆。文件级长期记忆的思路很朴素把人物档案、世界观、时间线、伏笔这类关键信息以文件形式落盘管理再配合Smart State模式在准备、写作、反思、压缩四个状态间自动流转按需读取记忆。这样上下文窗口永远只放当前需要的部分理论上可以支撑百万字级的持续创作。这篇笔记从选型原因讲到最小可复现代码再给你一套避坑清单照着搭就能跑。2. 先想清楚再写代码文件级长期记忆的选型对比与Smart State状态机设计2.1 三种记忆方案的取舍上下文窗口、向量库、文件系统做技术选型时记忆放哪决定了整个系统的上限。我见过不少人在上下文窗口、向量数据库、文件系统之间反复横跳最后选错了载体整个管线推倒重来。先看一张对比表后面展开说为什么文件在这类场景里是下限最高的选择。记忆方案优势短板适合场景上下文窗口接入简单模型天然支持成本随长度非线性上涨窗口有限历史重复发送导致有效信息密度低短篇、单场景写作向量数据库支持全库语义检索召回相关段落检索有模糊性关键设定可能被近似结果带偏需要额外维护Embedding与库本身人工修正不直观知识库问答、检索增强文件级长期记忆精确透明、可人工修订、可版本控制、按需挑选加载读写策略要自己设计做不好容易堆成碎片长篇小说这种每个细节都可能是伏笔的创作场景先排除纯上下文窗口。你以为把前几十章全文塞进Prompt里就解决了只要故事超过五万字每次调用都要把所有历史重复发一遍Token成本按字数平方上涨而且模型对塞在最后面的指令记忆反而更差。更麻烦的是你无法单独修正某一段记忆——改一个人设得重新把全文拼一遍再发。向量数据库看起来高级实际用在长篇小说创作里很别扭。创作需要的是精确一致性林远在第一卷左手中指戴过一枚黑色戒指这个事实必须百分百准确。向量检索给的答案是与查询最相似的段落哪怕相似度达到0.95那缺失的5%也会让设定漂移。我做过测试让同一个模型基于向量检索写五十章到第三十掌时戒指的颜色已经开始互换了。这不是模型笨是检索层引入了不确定性。文件级长期记忆是确定性最强的方案一个人物一个文件一个伏笔一条JSON记录读取时明确指定路径修改时直接编辑文件。模型看到的记忆内容完全可控人工介入也容易。代价是你要自己设计一套读写规则——这正是Smart State模式存在的意义。2.2 Smart State的四种状态与转换规则Smart State模式本质是一个极简的创作Agent状态机比市面上鼓吹的通用AI Agent聚焦得多。核心是管理什么时候加载记忆、什么时候写入记忆、什么时候整理记忆。四个状态定义如下PREPARE准备态在写每一章之前根据当前章节的计划决定加载哪些记忆块拼装写作Prompt。WRITE写作态调用大模型生成正文上下文只包含准备态装配好的内容。REFLECT反思态每章写完后把本章发生的关键信息人物变化、时间推进、新伏笔、已回收伏笔更新进对应的记忆文件。COMPACT压缩态每隔固定章节数把已经写过的一段情节做成更粗粒度的摘要腾出记忆空间的保质期。转换规则不是简单轮转而是带条件判断当前状态触发事件下一状态PREPARE记忆装配完成WRITEWRITE正文生成完成且未到压缩间隔REFLECTWRITE正文生成完成且章节数是压缩间隔的整数倍COMPACTREFLECT记忆更新完成PREPARECOMPACT压缩完成REFLECT这里有个细节我踩过坑压缩态结束后不要直接回到PREPARE而是先补一次REFLECT。因为压缩过程会重写旧摘要可能影响最近一章的记忆一致性。先把当前章的动态记忆固化下来再进入下一轮准备。2.3 为什么这套设计能扛住百万字关键在于把记忆分成了三层静态记忆、动态记忆、归档记忆。静态记忆是世界观和人物基线几乎不随情节变化写好后就固定在那里。动态记忆是最近几章的摘要和当前状态的快照每次写作要加载。归档记忆是更早的情节浓缩只在需要跨越引用时按需抽取。这三层对应文件系统的不同目录读取策略完全不同。静态记忆每次必读动态记忆滚动加载最近三章归档记忆平时不碰。有了这个分层每一轮写作的Token消耗稳定在一个固定区间不会随着小说篇幅增长而膨胀。我验证过这个结构在十万字、三十万字、六十万字三个节点上单章生成的Prompt长度波动不超过5%。一句话总结文件级长期记忆给了系统记住什么的答案Smart State模式给了什么时候记、什么时候取的节拍器。3. 搭建最小可运行的创作系统目录规范、记忆装配与写作循环代码3.1 项目目录与文件级记忆的落盘规范拿到zip包解压后项目目录结构一般会包含下面这些核心路径。目录规范是整个系统的地基我建议你直接沿用不要自己临场发挥改命名——等写到了第五十万字再回来调整目录那灾难就大了。# 解压 zip 后的推荐目录布局 novel-system/ ├── config.yaml # 全局配置 ├── memory/ # 文件级长期记忆的唯一根目录 │ ├── core/ # 静态记忆不变或低频变化 │ │ ├── world.md # 世界观与力量体系 │ │ ├── characters/ # 每个角色一个 md 文件 │ │ │ ├── 001_林远.md │ │ │ └── 002_苏晴.md │ │ └── timeline.json # 全局时间线 │ ├── scenes/ # 已写章节的动态摘要滚动保留 │ │ └── arc_001/ │ │ ├── chapter_001_summary.md │ │ ├── chapter_002_summary.md │ │ └── ... │ ├── plots/ # 伏笔与情节线 │ │ └── foreshadows.json │ └── status.json # 当前状态快照写到了第几章、活跃角色是谁 ├── output/ # 生成的正文全文 ├── prompts/ # 提示词模板 └── scripts/ # Python 脚本有一个关键原则core目录的文件只能手动修改或者由REFLECT状态精准更新绝不能让模型自由落盘。动态角色状态这个人现在心情如何、和谁的关系变了通常我放在单独的characters_state目录里和核心性格基线分开。基线是设定状态是进展混在一起会导致模型写着写着把临时情绪改成了永久性格。我一般会在memory目录下放一个.meta.json记录每次重要记忆变更的时间和触发章节方便回溯问题。这在后面第6章会展开。3.2 核心代码Smart State状态机实现状态机的实现不复杂但要保证转换条件符合业务直觉。以下代码是核心骨架生产环境我会加上事件落盘和异常兜底这里先给你看主干。# scripts/smart_state.py from enum import Enum class State(Enum): PREPARE prepare # 准备态装配本次写作所需记忆 WRITE write # 写作态调用大模型生成正文 REFLECT reflect # 反思态把本段故事压缩成记忆 COMPACT compact # 压缩态对旧记忆做摘要合并 class SmartStateMachine: 控制创作流程的状态机核心是决定下一步干什么。 def __init__(self, config: dict): self.config config self.current State.PREPARE self.serial 0 # 当前章节序号 self.last_event None def transition(self, event: dict) - State: 根据事件决定下一个状态。 event 至少带 kind 字段finish_prepare / finish_write / finish_reflect / finish_compact。 kind event.get(kind, ) interval self.config[memory][compact_interval] if self.current State.PREPARE and kind finish_prepare: self.current State.WRITE elif self.current State.WRITE and kind finish_write: if self.serial 0 and self.serial % interval 0: self.current State.COMPACT # 写满整卷先压缩旧记忆 else: self.current State.REFLECT # 平时写完立刻反思更新记忆 elif self.current State.REFLECT and kind finish_reflect: self.current State.PREPARE elif self.current State.COMPACT and kind finish_compact: self.current State.REFLECT # 压缩完成补一次最近章节反思 return self.current逻辑说明状态机的每一次转换都由外部事件驱动而不是靠定时器。event字典里的kind字段标记了上一动作是否完成。关键判断在WRITE结束的分岔章节数是压缩间隔的整数倍就先做COMPACT否则直接进REFLECT。这个设计保证大情节节点前后记忆不会被零散的章节摘要淹没。参数说明compact_interval是压缩间隔一般在config.yaml里配成 10 或 12。间隔太小压缩太频繁影响创作连续性间隔太大动态记忆文件会累积到失控。对百万字级别的小说我按整卷边界约 8 到 12 章一卷来配这个值。3.3 核心代码记忆装配与章节生成管线状态机只是节拍器真正干活的是记忆装配模块。装配的关键原则是按需加载、控制总数、缓存静态内容。# scripts/memory_loader.py import json from pathlib import Path class MemoryLoader: 从文件系统按需读取记忆所有读取都带缓存避免重复读盘。 def __init__(self, root: str): self.root Path(root) self._cache {} def load_core(self) - str: # 静态记忆世界观 当前卷大纲每次写作必读 if core not in self._cache: world (self.root / core/world.md).read_text(encodingutf-8) self._cache[core] world return self._cache[core] def load_recent_summaries(self, serial: int, keep: int 3) - list: # 动态记忆最近 keep 章的摘要太多会稀释当前注意力 base self.root / scenes summaries [] for i in range(max(1, serial - keep), serial): f base / farc_001/chapter_{i:03d}_summary.md if f.exists(): summaries.append(f.read_text(encodingutf-8)) return summaries def load_characters(self, active_ids: list) - str: # 只加载当前出场角色几百个角色全塞进去必炸 texts [] for cid in active_ids: f self.root / core/characters / f{cid}.md if f.exists(): texts.append(f.read_text(encodingutf-8)) return \n\n.join(texts)逻辑说明load_core使用缓存是刻意的——世界观文件可能几千字读取解析一次就够了每章都重新读盘纯属浪费。load_recent_summaries的keep参数是关键调优点它控制动态记忆窗口的宽度。我试过keep5上下文太长反而让模型分不清主次keep2会在跨章节情节上丢线索。最终常见的稳妥值是 3。参数说明active_ids列表从哪里来这是 PREPARE 态的核心产出。我的做法是让模型在上一次 REFLECT 结束时用固定格式输出下一章的预计出场角色ID同时把上一章实际出现的角色ID写入status.json。装配时取两者的并集防止角色突然闯入却没带档案。接下来是写作管线把上面两个模块串起来# scripts/write_pipeline.py from smart_state import State, SmartStateMachine from memory_loader import MemoryLoader def build_prompt(state: State, loader: MemoryLoader, serial: int, active_roles: list, outline: dict) - str: # 提示词由“记忆块 本次写作指令”组装 blocks [ loader.load_core(), loader.load_characters(active_roles), # recent summaries 属于动态记忆避免在 PREPARE 阶段读太多次 *loader.load_recent_summaries(serial, keep3), f本章目标{outline.get(goal, )}, f小说内时间{outline.get(in_story_time, 未知)}, ] return \n\n.join(blocks) def run_chapter(config, serial: int, outline: dict) - str: loader MemoryLoader(config[memory_root]) sm SmartStateMachine(config) sm.serial serial sm.transition({kind: finish_prepare}) # 进入写作态 prompt build_prompt(sm.current, loader, serial, outline.get(roles, []), outline) # 调用兼容 OpenAI 协议的接口用最大文本长度兜底 text llm_generate(prompt, max_tokensconfig[model][max_tokens_paragraph]) sm.transition({kind: finish_write}) # 进入反思态或压缩态 # REFLECT把本段内容浓缩成摘要写回 memory/scenes if sm.current State.REFLECT: summary summarize(text) write_summary(serial, summary) sm.transition({kind: finish_reflect}) return text逻辑说明llm_generate和summarize是示意函数落地时分别替换成你的模型调用和摘要Prompt。整个循环的节奏是准备 → 写作 → 反思三步推进。这里有个隐含设计finish_prepare事件是在build_prompt之前触发的所以状态机的 WRITE 态已经就位装配函数内部不再需要判断状态代码路径更短。参数说明config[model][max_tokens_paragraph]建议从 2000 到 3000 之间取值。小于 2000生成内容容易在情节半途切断SUMMARY 被迫频繁写本章尚未完结大于 3000单次生成的叙事节奏容易松散而且模型在长生成末尾的记忆回溯能力会明显下降。4. 从零跑通到十万字初始化、参数设置与记忆归档节奏4.1 初始化创作世界观、人物档案与大纲的写入格式很多项目死在第一步直接把一大段世界观文字丢给模型让它边写边自己整理。结果写到第十章模型把力量体系的规则给改了。初始化阶段要做的不是告诉模型故事设定而是建立后续记忆更新的锚点。人物档案的文件格式要区分基线与动态状态两部分。基线是铁律REFLECT 时禁止触碰动态状态允许更新。# 角色档案林远 ## 基础信息 - 年龄24故事时间第4章时 - 身份青云宗外门弟子 - 外貌左眉有一道旧疤惯用左手 ## 性格基线REFLECT时不可突破 - 底色隐忍重情义怀疑心重 - 说话习惯短句很少用感叹号 - 行为模式先做后说吃了亏先记下 ## 动态状态REFLECT时按情节更新 - 当前目标寻找妹妹失踪的线索 - 近期情绪焦虑但不动声色 - 与苏晴的关系互不信任的搭档参数说明基础信息里的故事时间一定要写清楚是哪一章时点否则REFELCT把几章前的外貌更新覆盖掉时间线就乱了。“性格基线”块我用特殊标记不可突破并在写作Prompt里明确告诉模型如果情节需要偏离基线必须先写一段内心冲突来铺垫而不是悄无声息地改变人设。世界观文件同理。我会在里面用章节号标记变更点比如天道规则补充第37章出现跨境界战斗余波规则如下……。这样后续REFLECT更新时能知道哪条规则是在什么情节下新增的。大纲建议按卷拆分每卷一个md文件内含本卷核心冲突和高潮节点。所有初始化文件都建好后跑一遍脚本生成初始status.json里面的current_serial设为0active_roles设为第一卷前三章必然出场的角色ID列表。4.2 章节生成的参数设置温度、目标Token与惩罚系数的配合模型参数不是万能药但调错了确实会放大记忆管理的压力。这是我在不同状态下的经验值可以参考后根据自己的模型风格微调。# config.yaml 关键参数 model: temperature: 0.8 # 写作态0.7-0.9太低会复读记忆太高会脱离设定 max_tokens_paragraph: 2500 # 单章正文上限 presence_penalty: 0.2 # 对重复提到同一概念做轻微抑制 memory: recent_summary_keep: 3 # PREPARE 时加载最近几章摘要 reflect_interval: 1 # 每1章做一次REFLECT compact_interval: 10 # 每10章做一次COMPACT参数说明temperature的取值逻辑源于一个现象——当上下文里混入了三个章节摘要时模型倾向于把摘要里的词原样复述导致新章节读起来像旧章扩写。设置 0.8 左右的温度能压制这种复读倾向但调到 0.9 以上又会让人物对话失控。presence_penalty我试过调到 0.5结果模型开始刻意回避人名用那个人指代主角带来新问题。reflect_interval我固定为 1每章都做反思。有人嫌它浪费Token我也试过每三章做一次反思结果第二章的记忆细节被第三章覆盖到第四章节时第一二章的信息已经出现混淆。省下的Token远不及修复bug的成本。4.3 REFLECT的写入规范与COMPACT的执行时机REFLECT不是把整章交给大模型让它总结一下就完事。要给它一个固定的输出结构才能写入文件后还能被下一次PREPARE方便读取。我常用的REFLECT Prompt要求模型输出四段本段情节摘要200字内、角色状态变更按角色ID列出、时间线推进明确小说内过去了几天、伏笔记录新增哪些未回收线索回收了哪条旧的。输出是JSON格式然后由脚本写入对应文件# scripts/reflect_writer.py import json from datetime import datetime def apply_reflect(result: dict, serial: int, root: str): # result 来自大模型按固定JSON结构输出的反思结果 # 1. 更新时间的推进 timeline_path f{root}/core/timeline.json with open(timeline_path, encodingutf-8) as f: timeline json.load(f) timeline[events].append({ chapter: serial, advance_days: result.get(days_advanced, 0), note: result.get(summary, )[:100] }) # 2. 更新角色状态文件不是核心档案而是动态状态 for change in result.get(character_changes, []): state_path f{root}/core/characters_state/{change[id]}.json with open(state_path, w, encodingutf-8) as f: json.dump(change[state], f, ensure_asciiFalse, indent2) # 3. 记录伏笔 f_path f{root}/plots/foreshadows.json # ... 类似更新逻辑逻辑说明apply_reflect把大模型的JSON反思结果拆开分别更新时间线、角色状态、伏笔三个文件而不是写进同一个大文件。这样做的目的是让每个记忆文件保持单一职责后续要调某一个角色的状态直接读对应文件即可。COMPACT的执行时机是第10章、第20章这类整卷节点。我会把旧章节摘要合并成一个卷摘要放在scenes/arc_001/下文件名从chapter_001_summary.md改成arc_001_summary.md。注意不要删除原章节正文output/目录保留全文只是记忆层做压缩。5. 百万字级持续创作避坑五个高频翻车现场与排查方法这一章是血泪经验集中区。我在多个长篇小说项目里排过雷下面五个问题出现频率最高每条按现象→原因→解决的顺序写方便你直接照着排查。5.1 人物性格悄悄漂移基线档案和动态状态没有隔离现象主角写到第四十章时从惜字如金变成了话痨读者反馈人设崩了。排查记忆文件发现人物档案里的说话习惯字段不知何时被改成了善于表达。原因REFLECT更新记忆时模型把动态状态比如这一章他情绪激动所以多说了几句话写进了基线字段。两类信息混在同一个文件里模型无法区分哪些可改、哪些不可改。解决严格分离基线档案与动态状态分别放在characters/和characters_state/两个目录。REFLECT的更新逻辑只允许写动态状态目录。在写作Prompt里增加约束角色性格基线如无重大情节铺垫必须保持稳定任何临时情绪波动写入角色状态文件。同时初始化脚本里对基线文件做只读标记业务代码禁止往该目录写内容。5.2 时间线错乱只记章号不记小说内时间现象第二章写三日后第四章直接写第二天清晨读者以为主角学会了瞬移。排查发现时间线文件里只有章节号没有记录每章推进了几天。原因生成正文时模型只知道自己刚写到第四章不知道故事内已经过了多少天。大纲文件里写了本卷时间跨度三个月但模型不会自动去换算当前日期。解决在outline数据结构里增加in_story_time字段每个章节计划都明确标注开始日期如大周历七月十二。REFLECT的输出结构里增加days_advanced字段每次写完后累加时间线。PREPARE装配Prompt时把当前时间点作为必填上下文。排查问题时先看timeline.json的事件列表比对章节号与日期是否匹配。5.3 记忆文件无限膨胀没有滚动窗口清理机制现象写到三十万字时单章的Prompt从原来的2千Token涨到4千Token生成一次的成本翻倍速度也明显变慢。查看scenes/目录发现所有章节摘要都堆在那里。原因REFLECT每章都写入新摘要但没有任何机制淘汰旧摘要。load_recent_summaries(keep3)只控制了读取条数没控制文件的累积写入磁盘上的记忆文件越来越多迟早会拖累文件系统浏览和后续压缩操作。解决COMPACT阶段除了合并卷摘要还要执行归档策略超过当前卷范围的单章摘要统一移动到memory/archive/从主加载路径中移除。我通常保留最近两卷的单章摘要更早的全部归档为卷摘要。同时写一个脚本定时扫描scenes/目录单文件超过2KB的摘要会被提示重写压缩。5.4 状态切换过于频繁章节节奏碎成了一段段说明文现象写到十几章时剧情推进很慢每章开头都是大段的设定复述读者反馈像在看设定集。实际上单章生成质量正常但每章都在重复世界观和角色背景。原因PREPARE装配记忆时load_core()每次都读入完整世界观文件而世界观这章根本没变化。模型接到信息后会习惯性在正文开头铺垫一遍导致叙事节奏被拖垮。解决给load_core()增加版本号比对逻辑world.md的文件头记录一个version字段每次REFLECT如果世界观没有变更就不重新写入修改时间PREPARE读取时会检查版本号若与上次读取相同则用缓存副本。更重要的是Prompt里明确要求只有当世界观信息与本章情节直接相关时才复述否则不要提及。5.5 系统重启后失忆status.json没有兜底恢复机制现象服务进程崩溃后重启系统从第一章开始重新写或者从前几章的状态继续写但角色动态状态全部丢失。排查发现status.json里只存了current_serial没有存上一次REFLECT完成的摘要ID。原因写作流程是生成正文→写摘要→更新记忆→更新状态如果进程在第3步和第4步之间崩溃status.json里已经更新了章节号但角色状态文件没来得及写系统认为写过了其实记忆没存上。解决给status.json加一个last_committed_reflect_serial字段每次REFLECT完全写入后才更新。启动时对比current_serial和last_committed_reflect_serial如果前者大于后者说明上一章的记忆没有落盘自动回滚到上一章状态重新执行REFLECT。这个兜底逻辑大概二十行代码能省掉大量排障时间。6. 进阶给记忆文件加版本标记实现创作可回滚6.1 用脚本记录每次记忆变更的版本快照长篇小说创作中改错了后悔最让人头疼。比如你把一个男主的亲密关系从恋人改成仇敌写了五章后发现节奏不对想回到改之前的状态。如果在文件层没有版本概念就只能靠手动CtrlZ而这在几十个记忆文件之间根本不可靠。我建议在系统里集成一个极简的版本标记脚本每次REFLECT成功落盘后调用一次# scripts/version_mark.py import json import datetime import subprocess MEMORY_META memory/.meta.json def stamp(message: str): 给当前记忆快照打一个可回滚的版本标记。 record { time: datetime.datetime.now().isoformat(), message: message, git_commit: subprocess.getoutput(git rev-parse --short HEAD), } with open(MEMORY_META, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)逻辑说明这个脚本依赖git rev-parse获取当前提交的短哈希。前提是你把memory/目录纳入Git仓库并在每次REFLECT完成后执行一次git commit。这样memory/.meta.json就记录了每次记忆变更对应的Git提交想要回滚时看一眼.meta.json找到那次变更的哈希直接git checkout hash -- memory/就能恢复当时的记忆状态。参数说明message字段建议用结构化描述第42章REFLECT林远与苏晴关系改变新增伏笔-黑色令牌。这样排查问题时即使你不想回滚也能从时间线看到哪一步操作改变了记忆。6.2 一套可执行的自检脚本思路光有版本标记还不够我习惯在每次写作会话开始时跑一次自检检查三类问题记忆文件是否完整、状态快照是否一致、未回收伏笔数量是否异常膨胀。自检脚本不复杂就是对几个JSON文件做字段存在性校验再统计foreshadows.json里recovered: false的条目数。如果未回收伏笔超过20条我会主动触发一次COMPACT让模型把伏笔按照重要程度重新排列必要时合并相近线索。这套系统的核心价值在于你把模型能力和记忆管理解耦了。模型可以随时换——今天用闭源大模型明天换开源模型记忆文件依然是那些创作连续性不会断。我从第一个百万字项目里学到的最大教训是别高估模型对长文的自我管理能力也别低估文件系统作为记忆容器的潜力。先把状态机、目录规范、版本标记这三样搭扎实后续换模型、加新功能都只是在这个骨架上添肉。希望帮到你。本文还有配套的精品资源点击获取