简介本资源是一个面向AI文学创作实践者的长篇小说自动化生成系统专为解决百万字级小说持续写作中情节断裂、人设崩塌、伏笔遗忘等核心痛点而设计。系统基于文件级长期记忆机制与Smart State状态管理模型内置Claude Code Skill中文小说生成引擎可自动分章创作并植入悬念钩子显著提升故事连贯性与读者黏性。压缩包共116个文件含68个Markdown格式的章节元数据与创作日志、35个Python核心脚本涵盖状态流转、记忆检索、章节调度等模块、9个JSON配置与索引文件如story_index.json、entity_chapter_map.json整体仅336KB轻量易部署。目前已有128人学习下载提供完整可运行的本地化AI小说创作框架包含从开篇初始化、章节迭代生成到跨章实体一致性校验的全流程支持目录结构体现清晰的记忆-状态-输出三层架构适合NLP开发者、AI写作工具研究者及数字出版技术实践者深度复用与二次开发。1. 项目概述当AI开始写百万字小说最近在捣鼓一个挺有意思的东西我把它叫做“AI长篇小说创作系统”。这玩意儿不是那种你给个开头它帮你续写几段就完事的玩具。它的目标是真正能驾驭几十万、甚至上百万字的长篇故事让AI从一个“段落写手”变成一个能记住前三百章所有伏笔、人物关系和世界设定的“真正作者”。核心的挑战就一个长期记忆。你肯定有过这种体验让ChatGPT写个长故事写到第五章它可能已经把第一章主角养的那条狗的名字给忘了或者把某个关键的反派设定给吃了。传统的大模型对话就像金鱼一样只有7秒或者说有限的上下文窗口记忆。要写长篇必须解决这个问题。我看到的思路是“基于文件级长期记忆的Smart State模式”。这名字听起来有点唬人但拆开看就明白了。“文件级”意味着记忆的存储和读取不再依赖于脆弱的对话上下文而是落到了实实在在的文件系统里可能是文本文件也可能是向量数据库。“长期”自不必说。“Smart State”则是关键它指的是一种智能的状态管理机制不是把所有的故事内容都一股脑儿塞给模型而是根据当前创作的需要智能地、动态地从海量记忆文件中检索、筛选、组合出最相关的背景信息喂给AI。这就像给AI作者配了一个超级助理这个助理熟读整部小说手稿每当作者要写新一章时助理就能立刻递上相关的笔记“老板这是三百年前那场战争的起因、这三个角色之间的爱恨情仇、以及上一章结尾埋下的那个悬念。”这个系统的价值对于网文作者、编剧、游戏剧情策划甚至是进行大型世界构建的奇幻/科幻作家来说是显而易见的。它能把人从繁琐的“一致性维护”工作中解放出来专注于核心的创意和情节设计。下面我就来详细拆解一下如何从零开始构建这样一个系统。2. 核心架构与Smart State模式深度解析2.1 为什么传统的“上下文窗口”思路会失败在深入我们的方案之前必须彻底理解为什么简单粗暴地增加上下文长度比如使用128K甚至100万token的模型不是解决长篇创作的银弹。首先成本与效率的灾难。即使模型支持超长上下文每次生成都携带整部小说的全文其计算开销Token费用和生成时间将是天文数字且其中99%的信息对生成下一段话是无用的噪音。其次模型性能的衰减。现有研究表明即使是支持长上下文的模型对输入序列中靠前或中间位置的信息其关注度和提取能力也会显著下降。你指望AI从十万字的上下文里精准回忆起第500字提到的一个配角姓氏这很不靠谱。最后缺乏结构化与聚焦。一股脑输入所有文本模型缺乏对信息重要性和相关性的判断。关键伏笔和无关的环境描写拥有相同的权重这反而会干扰模型的创作。因此我们的系统必须超越“长上下文”转向“精准记忆检索”。2.2 Smart State模式智能的状态管理与记忆调度Smart State是整个系统的“大脑”和“调度中心”。它的核心职责是管理故事的当前状态并决定为了推进故事需要从长期记忆中唤醒哪些知识。1. 状态State的构成故事的当前状态不是一个简单的字符串而是一个结构化的数据对象。通常包括当前情节节点故事进行到了哪个关键事件点。活跃角色列表当前场景中出现的角色及其简要情绪状态。核心矛盾与目标本章节或本场景要解决的主要问题。最近的关键事件摘要前几章或前几个场景的浓缩概括。待解决的悬念Chekhovs Guns前面埋下尚未收回的伏笔列表。这个状态对象是动态更新的每完成一个章节或一个重要场景系统就会自动更新它。2. “Smart”体现在何处—— 基于状态的记忆检索这是最核心的智能环节。当需要生成下一段内容时Smart State模块会分析当前状态理解我们正处于“英雄被困地牢正在尝试逃脱”的场景。生成检索查询Query根据状态自动构造多个检索问题。例如“地牢的构造细节和守卫分布”环境记忆“英雄是如何被关进来的关押他的人是谁”情节记忆“英雄身上目前有哪些物品或特殊能力”角色记忆“地牢里是否关押着其他重要角色他们与英雄的关系如何”角色关系记忆检索长期记忆将这些查询发送到我们的文件级记忆库中进行搜索。信息融合与上下文构建将检索到的、高相关性的记忆片段与当前状态摘要、以及最新的几条创作指令作者输入组合在一起形成一段精炼、高度相关、信息量充足的“提示上下文”送给大模型进行生成。这个过程模拟了人类作者的思考在动笔前快速回忆与当前场景相关的所有设定和过往情节。2.3 文件级长期记忆库的设计记忆库是系统的“硬盘”。设计目标是存储海量信息并支持快速、精准的检索。1. 存储格式不止是文本文件纯文本文件如.md或.json易于阅读和备份但检索效率低。因此我们采用混合架构原始文本档案按章节或场景存储完整的创作文本。这是权威数据源。向量数据库核心检索引擎将文本档案分解成更小的片段如段落或场景通过嵌入模型Embedding Model转换为向量一组数字存入向量数据库如ChromaDB, Pinecone, Weaviate。向量检索能根据语义相似度快速找到相关内容。结构化信息库用一个单独的数据库如SQLite或简单的JSON存储高度结构化的信息如“角色属性表”、“地点索引”、“关键事件时间线”、“伏笔追踪表”。这些信息用于快速回答特定类型的查询如“列出所有已知的反派”。2. 记忆的粒度与索引策略粒度记忆不能太粗整章也不能太细每句话。通常以“叙事单元”为粒度例如一个完整的场景、一段重要的对话、一个关键的事件描述。每个单元都附带元数据所属章节、出现的关键角色、涉及的关键地点、核心主题/情感。索引在存入向量数据库时除了文本本身这些元数据也作为过滤条件Metadata Filter一并存储。这样在检索时我们可以进行组合查询例如“查找所有涉及‘角色A’和‘地点B’且主题包含‘背叛’的记忆片段”。3. 系统核心模块实现详解3.1 创作引擎与状态机创作引擎是系统的“执笔人”。它接收来自Smart State模块构建好的上下文提示调用大模型API如GPT-4, Claude, 或本地部署的Llama 3来生成文本。关键实现细节提示工程给模型的提示Prompt是精心设计的模板。它通常包含以下几个部分系统指令定义AI的角色一位资深小说家、写作风格、以及核心规则如“严格遵循提供的故事背景和人物设定”。当前故事状态摘要由Smart State提供的1-2段概括。检索到的相关记忆以清晰标记如[背景记忆]、[人物档案]列出。作者的最新指令例如“写一段主角发现密室日记的紧张场景”。输出格式要求要求模型以纯叙事文本输出并可能要求其同时输出对本段生成的“状态更新建议”如“新出现物品一把生锈的钥匙”。流式输出与交互生成应该是流式的让作者能实时看到文字涌现。同时系统应提供“暂停”、“重写”、“调整”等交互功能。当作者对某段生成不满意时可以点击“重写”系统会保持相同的上下文但要求模型尝试另一种写法。状态机驱动整个创作流程可以看作一个状态机。状态包括“等待指令”、“检索记忆”、“生成文本”、“等待审核”、“更新状态”。Smart State模块负责在“检索记忆”和“更新状态”两个环节工作。3.2 记忆的写入、检索与更新流程这是系统的数据闭环确保记忆随着创作而生长。1. 记忆写入索引化流程新章节文本完成 - 文本分割器按场景/段落分割- 对每个片段 1. 元数据提取器NLP工具分析片段自动提取角色、地点、关键名词、情感倾向。 2. 嵌入模型将“片段文本元数据描述”转换为向量。 3. 将该向量与片段文本、元数据一同存入向量数据库。 4. 同时将高度结构化的信息如新角色的名字、属性更新到“结构化信息库”。2. 记忆检索流程接收到查询如“英雄的佩剑来历”- 1. 将查询文本通过相同的嵌入模型转换为查询向量。 2. 在向量数据库中执行相似性搜索找到最相似的K个片段如Top 5。 3. 可选利用元数据过滤器进行精筛如只查找“角色英雄”相关的记忆。 4. 返回检索到的片段文本。3. 记忆的更新与冲突解决故事创作中存在“吃书”设定前后矛盾的可能。系统需要一定容错但也应提供管理工具。版本管理记忆库可以支持简单的版本当作者明确修改了早期设定时可以手动触发对相关记忆片段的重新索引或标记为“废弃”。冲突检测系统可以定期运行简单的检查例如通过查询“角色A的眼睛颜色”如果检索出“蓝色”和“绿色”两个不同片段可以提示作者进行确认。记忆权重可以为更近期、或经过作者确认的记忆片段赋予更高的权重在检索结果排序时优先。3.3 与外部模型的集成与提示词设计系统本身不包含大模型而是模型的“驾驶舱”。因此与不同模型的兼容性很重要。1. API集成层抽象一个统一的模型调用接口内部适配OpenAI API、Anthropic Claude API、开源模型通过Ollama或vLLM提供的API等。这样可以灵活切换模型根据生成任务需要创意还是需要严谨选择不同的模型。2. 提示词模板库针对不同的创作任务设计不同的提示模板。叙事生成模板用于主线的推进。对话润色模板专注于生成符合角色性格的生动对话。场景描写模板侧重于环境、氛围的渲染。大纲扩展模板根据一个粗略的情节点子扩展出详细的场景列表。设定问答模板让模型基于现有记忆以角色口吻回答关于世界观的问题用于测试设定的一致性。每个模板都预留了插槽由Smart State模块动态填入具体的状态和记忆内容。4. 百万字级创作的工程挑战与应对当项目规模扩展到百万字时会面临一系列工程上的挑战。4.1 向量数据库的规模与性能优化百万字文本假设每200字一个片段会产生约5000个向量片段。这个规模对主流向量数据库如Chroma来说完全在能力范围内但优化仍不可少。分区索引可以按“卷”或“篇章”对记忆进行分区。检索时优先在当前篇章或最近篇章的分区内搜索大幅缩小搜索范围提升速度和相关性。分层记忆系统并非所有记忆都需要同等粒度的向量存储。核心记忆层角色核心设定、关键事件、核心设定。高精度索引随时待命。细节记忆层具体场景描写、次要对话。标准索引。归档记忆层已完成很久、且与当前主线关联度极低的篇章。可以降低索引精度或仅在全文检索时使用。缓存机制对于当前创作章节频繁涉及的角色和地点其核心记忆可以被缓存在内存中避免重复的向量检索。4.2 长期创作中的状态维护与“剧情漂移”防控即使有记忆系统AI在超长周期创作中仍可能逐渐偏离最初的大纲或人物基调即“剧情漂移”。定期“锚点”回顾系统应强制在每完成N个章节如10章后进行一次“锚点回顾”。自动将当前生成的内容与最初的大纲、人物设定文档进行摘要对比并提示作者是否存在重大偏离。关键指标监控定义一些可量化的指标如“主角主动性指数”、“剧情节奏平静/冲突场景比例”、“反派出场频率”。通过简单的文本分析监控这些指标的变化趋势向作者可视化展示。作者反馈闭环最重要的防控手段。系统应提供便捷的标注工具当作者发现某处生成不符合预期时可以即时标注如“此处人物OOC了”。这个反馈不仅用于当前修改更应该被记录并用于优化后续针对该人物的记忆检索权重和提示词。4.3 系统的可扩展性与模块化设计一个好的创作系统应该能适应不同的创作流派和作者习惯。插件化架构将“记忆检索器”、“状态分析器”、“提示词模板”、“输出后处理器”等设计为可插拔的模块。例如一个擅长写武侠的作者可以导入一套“武侠世界常识记忆库”和专用的“武功招式生成模板”。配置驱动通过配置文件或UI作者可以调整各种参数检索返回的记忆片段数量、生成文本的长度、模型的创造性温度Temperature、是否开启“自动伏笔建议”等。支持多人协作为大型项目设计允许设定不同的角色主笔、设定管理员、审阅者并控制其对记忆库和状态机的修改权限。5. 实战操作从零搭建一个最小可行系统5.1 技术栈选择与环境搭建我们以Python为核心搭建一个本地优先的轻量级系统。核心框架使用LangChain或LlamaIndex。它们提供了连接大模型、处理文档、构建向量索引的丰富抽象能极大减少底层代码量。这里我更推荐LlamaIndex它在文档索引和检索方面的设计更贴合我们的需求。向量数据库选择ChromaDB。它轻量、可嵌入式运行、无需服务器非常适合桌面应用。嵌入模型如果网络允许使用OpenAI的text-embedding-3-small性价比极高。若需完全本地化可选用BAAI/bge-small-zh-v1.5或thenlper/gte-small这类开源模型通过HuggingFace Transformers或Sentence-Transformers库调用。大语言模型初期开发调试可使用OpenAI GPT-3.5-Turbo API。正式创作考虑GPT-4、Claude 3或本地部署的Qwen2.5-7B-Instruct、Llama 3.1 8B等性能优秀的开源模型需要一张显存足够的GPU。前端界面为了快速原型可以使用Gradio或Streamlit构建一个简单的Web界面。后期若需更复杂交互可考虑Tkinter(Python桌面) 或Electron(跨平台桌面)。环境准备示例# 创建虚拟环境 python -m venv ai_novel_venv source ai_novel_venv/bin/activate # Linux/Mac # ai_novel_venv\Scripts\activate # Windows # 安装核心库 pip install llama-index llama-index-vector-stores-chroma llama-index-llms-openai pip install chromadb openai tiktoken pip install gradio # 用于构建UI5.2 实现核心闭环一个简单的创作迭代我们实现一个最简化的单次创作循环展示Smart State和记忆检索如何协作。步骤1初始化记忆库首次运行import chromadb from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore from llama_index.embeddings.openai import OpenAIEmbedding from llama_index.llms.openai import OpenAI # 初始化嵌入模型和LLM请替换你的API Key embed_model OpenAIEmbedding(api_keyyour-key) llm OpenAI(modelgpt-3.5-turbo, api_keyyour-key) # 初始化ChromaDB客户端和集合 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(novel_memories) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) # 假设你已有一些前期设定和章节文档在 ./docs 文件夹 documents SimpleDirectoryReader(./docs).load_data() # 创建索引这将自动进行文本分块和向量化 index VectorStoreIndex.from_documents( documents, embed_modelembed_model, storage_contextstorage_context ) # 创建检索器 retriever index.as_retriever(similarity_top_k3) # 每次检索最相关的3个片段步骤2定义Smart State与生成上下文class SimpleSmartState: def __init__(self, retriever, llm): self.retriever retriever self.llm llm self.current_scene_summary 主角林风在古墓深处刚刚发现了一幅神秘的壁画。 self.active_characters [林风主角好奇且谨慎] def build_context(self, author_instruction): # 1. 基于当前状态生成检索查询 retrieval_queries [ f关于角色{self.active_characters[0]}的性格和能力描述, 关于这座古墓的历史和危险设定, 壁画可能揭示的秘密或传说 ] # 2. 执行检索获取相关记忆 relevant_memories [] for query in retrieval_queries: nodes self.retriever.retrieve(query) for node in nodes: # 避免重复添加完全相同的内容 if node.text not in [m[text] for m in relevant_memories]: relevant_memories.append({query: query, text: node.text}) # 3. 构建最终提示 memory_context \n.join([f- {m[text][:150]}... for m in relevant_memories]) # 截断显示 prompt_template f 你是一位资深奇幻小说作家。请根据以下故事背景和相关信息续写接下来的内容。 【当前故事状态】 {self.current_scene_summary} 活跃角色{, .join(self.active_characters)} 【相关背景记忆】 {memory_context} 【作者指令】 {author_instruction} 请生成一段约300字的流畅叙事保持悬疑和探索的氛围。 输出内容 return prompt_template def update_state(self, generated_text): # 这里可以调用一个小的LLM来从生成的文本中提取状态更新 # 例如识别新出现的地点、物品、角色情绪变化等 # 此处简化为手动更新摘要示例 self.current_scene_summary f在古墓中{generated_text[:100]}... print(f状态已更新为{self.current_scene_summary})步骤3执行创作循环# 初始化 smart_state SimpleSmartState(retriever, llm) # 作者输入指令 author_instruction 描写林风仔细研究壁画并从中发现了一个隐藏机关的线索。 # Smart State构建上下文 prompt smart_state.build_context(author_instruction) # 调用LLM生成 response llm.complete(prompt) generated_text response.text print( 生成内容 ) print(generated_text) print() # 更新系统状态 smart_state.update_state(generated_text)这个最小循环展示了从记忆检索到生成再到状态更新的核心流程。在一个完整系统中update_state函数会复杂得多可能需要解析生成文本自动提取实体和关系来更新记忆库本身。5.3 常见问题与调试技巧在实际搭建和运行过程中你肯定会遇到各种问题。以下是一些常见坑点和解决思路1. 检索结果不相关或质量差问题AI生成的内容天马行空完全无视检索到的记忆。排查检查嵌入模型用于生成记忆向量和查询向量的模型是否一致如果是开源模型其语义理解能力是否足够调整分块大小记忆片段Chunk的大小至关重要。太大则包含无关信息太小则失去上下文。对于小说以“一个完整的动作或对话场景”为块约150-400字通常效果较好。优化检索查询让Smart State生成的查询更具体。与其查询“古墓信息”不如查询“古墓第三层的陷阱类型”或“壁画上描述的古代王国名称”。增加元数据过滤在检索时利用之前存储的元数据章节、角色进行过滤能极大提升精度。2. 生成内容风格不稳定或“人设崩塌”问题角色说话方式前后不一致或文风在古典和现代间跳跃。排查强化系统指令在Prompt的“系统指令”部分用更强烈的语气规定写作风格和角色一致性要求。例如“你必须严格模仿《冰与火之歌》的叙事风格和人物对话方式。”提供风格范例在长期记忆库中存入几段你认为最能代表目标风格的原文片段并在检索时赋予更高权重或强制包含。检查温度参数降低LLM的temperature参数如从0.8降至0.3可以减少随机性让输出更可控、更一致。3. 系统响应速度慢问题从输入指令到生成结果等待时间过长。排查向量检索优化确保ChromaDB的持久化路径在SSD上。对于本地嵌入模型考虑使用更轻量的版本。LLM API延迟如果使用云端API网络是主要瓶颈。考虑对生成请求设置合理的超时和重试机制或切换到响应更快的模型如GPT-3.5-Turbo比GPT-4快。缓存检索结果对于同一章节内频繁出现的实体如主角名其基本信息的检索结果可以缓存在内存中避免重复查询向量数据库。4. 如何处理作者的中途修改问题作者对AI生成的一段内容不满意手动进行了修改如何让记忆库同步方案这是文件级记忆的优势。实现一个“重新索引”功能。将修改后的章节文件替换原文件。触发一个后台任务识别出被修改的文档。从向量数据库中删除该文档对应的所有旧片段向量。将修改后的文档重新进行分块、提取元数据、生成向量并入库。这个过程可以设计为半自动在作者保存文件时弹出提示询问是否更新记忆。构建这样一个系统更像是在培育一个数字化的创作伙伴。它不会取代作者而是将作者从记忆和一致性的重负中解放出来让人脑更专注于创意、情感和故事的灵魂。从最小原型开始逐步迭代你会发现AI在长篇叙事上的潜力远超预期。本文还有配套的精品资源点击获取
简介本资源是一个面向AI文学创作实践者的长篇小说自动化生成系统专为解决百万字级小说持续写作中情节断裂、人设崩塌、伏笔遗忘等核心痛点而设计。系统基于文件级长期记忆机制与Smart State状态管理模型内置Claude Code Skill中文小说生成引擎可自动分章创作并植入悬念钩子显著提升故事连贯性与读者黏性。压缩包共116个文件含68个Markdown格式的章节元数据与创作日志、35个Python核心脚本涵盖状态流转、记忆检索、章节调度等模块、9个JSON配置与索引文件如story_index.json、entity_chapter_map.json整体仅336KB轻量易部署。目前已有128人学习下载提供完整可运行的本地化AI小说创作框架包含从开篇初始化、章节迭代生成到跨章实体一致性校验的全流程支持目录结构体现清晰的记忆-状态-输出三层架构适合NLP开发者、AI写作工具研究者及数字出版技术实践者深度复用与二次开发。1. 项目概述当AI开始写百万字小说最近在捣鼓一个挺有意思的东西我把它叫做“AI长篇小说创作系统”。这玩意儿不是那种你给个开头它帮你续写几段就完事的玩具。它的目标是真正能驾驭几十万、甚至上百万字的长篇故事让AI从一个“段落写手”变成一个能记住前三百章所有伏笔、人物关系和世界设定的“真正作者”。核心的挑战就一个长期记忆。你肯定有过这种体验让ChatGPT写个长故事写到第五章它可能已经把第一章主角养的那条狗的名字给忘了或者把某个关键的反派设定给吃了。传统的大模型对话就像金鱼一样只有7秒或者说有限的上下文窗口记忆。要写长篇必须解决这个问题。我看到的思路是“基于文件级长期记忆的Smart State模式”。这名字听起来有点唬人但拆开看就明白了。“文件级”意味着记忆的存储和读取不再依赖于脆弱的对话上下文而是落到了实实在在的文件系统里可能是文本文件也可能是向量数据库。“长期”自不必说。“Smart State”则是关键它指的是一种智能的状态管理机制不是把所有的故事内容都一股脑儿塞给模型而是根据当前创作的需要智能地、动态地从海量记忆文件中检索、筛选、组合出最相关的背景信息喂给AI。这就像给AI作者配了一个超级助理这个助理熟读整部小说手稿每当作者要写新一章时助理就能立刻递上相关的笔记“老板这是三百年前那场战争的起因、这三个角色之间的爱恨情仇、以及上一章结尾埋下的那个悬念。”这个系统的价值对于网文作者、编剧、游戏剧情策划甚至是进行大型世界构建的奇幻/科幻作家来说是显而易见的。它能把人从繁琐的“一致性维护”工作中解放出来专注于核心的创意和情节设计。下面我就来详细拆解一下如何从零开始构建这样一个系统。2. 核心架构与Smart State模式深度解析2.1 为什么传统的“上下文窗口”思路会失败在深入我们的方案之前必须彻底理解为什么简单粗暴地增加上下文长度比如使用128K甚至100万token的模型不是解决长篇创作的银弹。首先成本与效率的灾难。即使模型支持超长上下文每次生成都携带整部小说的全文其计算开销Token费用和生成时间将是天文数字且其中99%的信息对生成下一段话是无用的噪音。其次模型性能的衰减。现有研究表明即使是支持长上下文的模型对输入序列中靠前或中间位置的信息其关注度和提取能力也会显著下降。你指望AI从十万字的上下文里精准回忆起第500字提到的一个配角姓氏这很不靠谱。最后缺乏结构化与聚焦。一股脑输入所有文本模型缺乏对信息重要性和相关性的判断。关键伏笔和无关的环境描写拥有相同的权重这反而会干扰模型的创作。因此我们的系统必须超越“长上下文”转向“精准记忆检索”。2.2 Smart State模式智能的状态管理与记忆调度Smart State是整个系统的“大脑”和“调度中心”。它的核心职责是管理故事的当前状态并决定为了推进故事需要从长期记忆中唤醒哪些知识。1. 状态State的构成故事的当前状态不是一个简单的字符串而是一个结构化的数据对象。通常包括当前情节节点故事进行到了哪个关键事件点。活跃角色列表当前场景中出现的角色及其简要情绪状态。核心矛盾与目标本章节或本场景要解决的主要问题。最近的关键事件摘要前几章或前几个场景的浓缩概括。待解决的悬念Chekhovs Guns前面埋下尚未收回的伏笔列表。这个状态对象是动态更新的每完成一个章节或一个重要场景系统就会自动更新它。2. “Smart”体现在何处—— 基于状态的记忆检索这是最核心的智能环节。当需要生成下一段内容时Smart State模块会分析当前状态理解我们正处于“英雄被困地牢正在尝试逃脱”的场景。生成检索查询Query根据状态自动构造多个检索问题。例如“地牢的构造细节和守卫分布”环境记忆“英雄是如何被关进来的关押他的人是谁”情节记忆“英雄身上目前有哪些物品或特殊能力”角色记忆“地牢里是否关押着其他重要角色他们与英雄的关系如何”角色关系记忆检索长期记忆将这些查询发送到我们的文件级记忆库中进行搜索。信息融合与上下文构建将检索到的、高相关性的记忆片段与当前状态摘要、以及最新的几条创作指令作者输入组合在一起形成一段精炼、高度相关、信息量充足的“提示上下文”送给大模型进行生成。这个过程模拟了人类作者的思考在动笔前快速回忆与当前场景相关的所有设定和过往情节。2.3 文件级长期记忆库的设计记忆库是系统的“硬盘”。设计目标是存储海量信息并支持快速、精准的检索。1. 存储格式不止是文本文件纯文本文件如.md或.json易于阅读和备份但检索效率低。因此我们采用混合架构原始文本档案按章节或场景存储完整的创作文本。这是权威数据源。向量数据库核心检索引擎将文本档案分解成更小的片段如段落或场景通过嵌入模型Embedding Model转换为向量一组数字存入向量数据库如ChromaDB, Pinecone, Weaviate。向量检索能根据语义相似度快速找到相关内容。结构化信息库用一个单独的数据库如SQLite或简单的JSON存储高度结构化的信息如“角色属性表”、“地点索引”、“关键事件时间线”、“伏笔追踪表”。这些信息用于快速回答特定类型的查询如“列出所有已知的反派”。2. 记忆的粒度与索引策略粒度记忆不能太粗整章也不能太细每句话。通常以“叙事单元”为粒度例如一个完整的场景、一段重要的对话、一个关键的事件描述。每个单元都附带元数据所属章节、出现的关键角色、涉及的关键地点、核心主题/情感。索引在存入向量数据库时除了文本本身这些元数据也作为过滤条件Metadata Filter一并存储。这样在检索时我们可以进行组合查询例如“查找所有涉及‘角色A’和‘地点B’且主题包含‘背叛’的记忆片段”。3. 系统核心模块实现详解3.1 创作引擎与状态机创作引擎是系统的“执笔人”。它接收来自Smart State模块构建好的上下文提示调用大模型API如GPT-4, Claude, 或本地部署的Llama 3来生成文本。关键实现细节提示工程给模型的提示Prompt是精心设计的模板。它通常包含以下几个部分系统指令定义AI的角色一位资深小说家、写作风格、以及核心规则如“严格遵循提供的故事背景和人物设定”。当前故事状态摘要由Smart State提供的1-2段概括。检索到的相关记忆以清晰标记如[背景记忆]、[人物档案]列出。作者的最新指令例如“写一段主角发现密室日记的紧张场景”。输出格式要求要求模型以纯叙事文本输出并可能要求其同时输出对本段生成的“状态更新建议”如“新出现物品一把生锈的钥匙”。流式输出与交互生成应该是流式的让作者能实时看到文字涌现。同时系统应提供“暂停”、“重写”、“调整”等交互功能。当作者对某段生成不满意时可以点击“重写”系统会保持相同的上下文但要求模型尝试另一种写法。状态机驱动整个创作流程可以看作一个状态机。状态包括“等待指令”、“检索记忆”、“生成文本”、“等待审核”、“更新状态”。Smart State模块负责在“检索记忆”和“更新状态”两个环节工作。3.2 记忆的写入、检索与更新流程这是系统的数据闭环确保记忆随着创作而生长。1. 记忆写入索引化流程新章节文本完成 - 文本分割器按场景/段落分割- 对每个片段 1. 元数据提取器NLP工具分析片段自动提取角色、地点、关键名词、情感倾向。 2. 嵌入模型将“片段文本元数据描述”转换为向量。 3. 将该向量与片段文本、元数据一同存入向量数据库。 4. 同时将高度结构化的信息如新角色的名字、属性更新到“结构化信息库”。2. 记忆检索流程接收到查询如“英雄的佩剑来历”- 1. 将查询文本通过相同的嵌入模型转换为查询向量。 2. 在向量数据库中执行相似性搜索找到最相似的K个片段如Top 5。 3. 可选利用元数据过滤器进行精筛如只查找“角色英雄”相关的记忆。 4. 返回检索到的片段文本。3. 记忆的更新与冲突解决故事创作中存在“吃书”设定前后矛盾的可能。系统需要一定容错但也应提供管理工具。版本管理记忆库可以支持简单的版本当作者明确修改了早期设定时可以手动触发对相关记忆片段的重新索引或标记为“废弃”。冲突检测系统可以定期运行简单的检查例如通过查询“角色A的眼睛颜色”如果检索出“蓝色”和“绿色”两个不同片段可以提示作者进行确认。记忆权重可以为更近期、或经过作者确认的记忆片段赋予更高的权重在检索结果排序时优先。3.3 与外部模型的集成与提示词设计系统本身不包含大模型而是模型的“驾驶舱”。因此与不同模型的兼容性很重要。1. API集成层抽象一个统一的模型调用接口内部适配OpenAI API、Anthropic Claude API、开源模型通过Ollama或vLLM提供的API等。这样可以灵活切换模型根据生成任务需要创意还是需要严谨选择不同的模型。2. 提示词模板库针对不同的创作任务设计不同的提示模板。叙事生成模板用于主线的推进。对话润色模板专注于生成符合角色性格的生动对话。场景描写模板侧重于环境、氛围的渲染。大纲扩展模板根据一个粗略的情节点子扩展出详细的场景列表。设定问答模板让模型基于现有记忆以角色口吻回答关于世界观的问题用于测试设定的一致性。每个模板都预留了插槽由Smart State模块动态填入具体的状态和记忆内容。4. 百万字级创作的工程挑战与应对当项目规模扩展到百万字时会面临一系列工程上的挑战。4.1 向量数据库的规模与性能优化百万字文本假设每200字一个片段会产生约5000个向量片段。这个规模对主流向量数据库如Chroma来说完全在能力范围内但优化仍不可少。分区索引可以按“卷”或“篇章”对记忆进行分区。检索时优先在当前篇章或最近篇章的分区内搜索大幅缩小搜索范围提升速度和相关性。分层记忆系统并非所有记忆都需要同等粒度的向量存储。核心记忆层角色核心设定、关键事件、核心设定。高精度索引随时待命。细节记忆层具体场景描写、次要对话。标准索引。归档记忆层已完成很久、且与当前主线关联度极低的篇章。可以降低索引精度或仅在全文检索时使用。缓存机制对于当前创作章节频繁涉及的角色和地点其核心记忆可以被缓存在内存中避免重复的向量检索。4.2 长期创作中的状态维护与“剧情漂移”防控即使有记忆系统AI在超长周期创作中仍可能逐渐偏离最初的大纲或人物基调即“剧情漂移”。定期“锚点”回顾系统应强制在每完成N个章节如10章后进行一次“锚点回顾”。自动将当前生成的内容与最初的大纲、人物设定文档进行摘要对比并提示作者是否存在重大偏离。关键指标监控定义一些可量化的指标如“主角主动性指数”、“剧情节奏平静/冲突场景比例”、“反派出场频率”。通过简单的文本分析监控这些指标的变化趋势向作者可视化展示。作者反馈闭环最重要的防控手段。系统应提供便捷的标注工具当作者发现某处生成不符合预期时可以即时标注如“此处人物OOC了”。这个反馈不仅用于当前修改更应该被记录并用于优化后续针对该人物的记忆检索权重和提示词。4.3 系统的可扩展性与模块化设计一个好的创作系统应该能适应不同的创作流派和作者习惯。插件化架构将“记忆检索器”、“状态分析器”、“提示词模板”、“输出后处理器”等设计为可插拔的模块。例如一个擅长写武侠的作者可以导入一套“武侠世界常识记忆库”和专用的“武功招式生成模板”。配置驱动通过配置文件或UI作者可以调整各种参数检索返回的记忆片段数量、生成文本的长度、模型的创造性温度Temperature、是否开启“自动伏笔建议”等。支持多人协作为大型项目设计允许设定不同的角色主笔、设定管理员、审阅者并控制其对记忆库和状态机的修改权限。5. 实战操作从零搭建一个最小可行系统5.1 技术栈选择与环境搭建我们以Python为核心搭建一个本地优先的轻量级系统。核心框架使用LangChain或LlamaIndex。它们提供了连接大模型、处理文档、构建向量索引的丰富抽象能极大减少底层代码量。这里我更推荐LlamaIndex它在文档索引和检索方面的设计更贴合我们的需求。向量数据库选择ChromaDB。它轻量、可嵌入式运行、无需服务器非常适合桌面应用。嵌入模型如果网络允许使用OpenAI的text-embedding-3-small性价比极高。若需完全本地化可选用BAAI/bge-small-zh-v1.5或thenlper/gte-small这类开源模型通过HuggingFace Transformers或Sentence-Transformers库调用。大语言模型初期开发调试可使用OpenAI GPT-3.5-Turbo API。正式创作考虑GPT-4、Claude 3或本地部署的Qwen2.5-7B-Instruct、Llama 3.1 8B等性能优秀的开源模型需要一张显存足够的GPU。前端界面为了快速原型可以使用Gradio或Streamlit构建一个简单的Web界面。后期若需更复杂交互可考虑Tkinter(Python桌面) 或Electron(跨平台桌面)。环境准备示例# 创建虚拟环境 python -m venv ai_novel_venv source ai_novel_venv/bin/activate # Linux/Mac # ai_novel_venv\Scripts\activate # Windows # 安装核心库 pip install llama-index llama-index-vector-stores-chroma llama-index-llms-openai pip install chromadb openai tiktoken pip install gradio # 用于构建UI5.2 实现核心闭环一个简单的创作迭代我们实现一个最简化的单次创作循环展示Smart State和记忆检索如何协作。步骤1初始化记忆库首次运行import chromadb from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore from llama_index.embeddings.openai import OpenAIEmbedding from llama_index.llms.openai import OpenAI # 初始化嵌入模型和LLM请替换你的API Key embed_model OpenAIEmbedding(api_keyyour-key) llm OpenAI(modelgpt-3.5-turbo, api_keyyour-key) # 初始化ChromaDB客户端和集合 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(novel_memories) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) # 假设你已有一些前期设定和章节文档在 ./docs 文件夹 documents SimpleDirectoryReader(./docs).load_data() # 创建索引这将自动进行文本分块和向量化 index VectorStoreIndex.from_documents( documents, embed_modelembed_model, storage_contextstorage_context ) # 创建检索器 retriever index.as_retriever(similarity_top_k3) # 每次检索最相关的3个片段步骤2定义Smart State与生成上下文class SimpleSmartState: def __init__(self, retriever, llm): self.retriever retriever self.llm llm self.current_scene_summary 主角林风在古墓深处刚刚发现了一幅神秘的壁画。 self.active_characters [林风主角好奇且谨慎] def build_context(self, author_instruction): # 1. 基于当前状态生成检索查询 retrieval_queries [ f关于角色{self.active_characters[0]}的性格和能力描述, 关于这座古墓的历史和危险设定, 壁画可能揭示的秘密或传说 ] # 2. 执行检索获取相关记忆 relevant_memories [] for query in retrieval_queries: nodes self.retriever.retrieve(query) for node in nodes: # 避免重复添加完全相同的内容 if node.text not in [m[text] for m in relevant_memories]: relevant_memories.append({query: query, text: node.text}) # 3. 构建最终提示 memory_context \n.join([f- {m[text][:150]}... for m in relevant_memories]) # 截断显示 prompt_template f 你是一位资深奇幻小说作家。请根据以下故事背景和相关信息续写接下来的内容。 【当前故事状态】 {self.current_scene_summary} 活跃角色{, .join(self.active_characters)} 【相关背景记忆】 {memory_context} 【作者指令】 {author_instruction} 请生成一段约300字的流畅叙事保持悬疑和探索的氛围。 输出内容 return prompt_template def update_state(self, generated_text): # 这里可以调用一个小的LLM来从生成的文本中提取状态更新 # 例如识别新出现的地点、物品、角色情绪变化等 # 此处简化为手动更新摘要示例 self.current_scene_summary f在古墓中{generated_text[:100]}... print(f状态已更新为{self.current_scene_summary})步骤3执行创作循环# 初始化 smart_state SimpleSmartState(retriever, llm) # 作者输入指令 author_instruction 描写林风仔细研究壁画并从中发现了一个隐藏机关的线索。 # Smart State构建上下文 prompt smart_state.build_context(author_instruction) # 调用LLM生成 response llm.complete(prompt) generated_text response.text print( 生成内容 ) print(generated_text) print() # 更新系统状态 smart_state.update_state(generated_text)这个最小循环展示了从记忆检索到生成再到状态更新的核心流程。在一个完整系统中update_state函数会复杂得多可能需要解析生成文本自动提取实体和关系来更新记忆库本身。5.3 常见问题与调试技巧在实际搭建和运行过程中你肯定会遇到各种问题。以下是一些常见坑点和解决思路1. 检索结果不相关或质量差问题AI生成的内容天马行空完全无视检索到的记忆。排查检查嵌入模型用于生成记忆向量和查询向量的模型是否一致如果是开源模型其语义理解能力是否足够调整分块大小记忆片段Chunk的大小至关重要。太大则包含无关信息太小则失去上下文。对于小说以“一个完整的动作或对话场景”为块约150-400字通常效果较好。优化检索查询让Smart State生成的查询更具体。与其查询“古墓信息”不如查询“古墓第三层的陷阱类型”或“壁画上描述的古代王国名称”。增加元数据过滤在检索时利用之前存储的元数据章节、角色进行过滤能极大提升精度。2. 生成内容风格不稳定或“人设崩塌”问题角色说话方式前后不一致或文风在古典和现代间跳跃。排查强化系统指令在Prompt的“系统指令”部分用更强烈的语气规定写作风格和角色一致性要求。例如“你必须严格模仿《冰与火之歌》的叙事风格和人物对话方式。”提供风格范例在长期记忆库中存入几段你认为最能代表目标风格的原文片段并在检索时赋予更高权重或强制包含。检查温度参数降低LLM的temperature参数如从0.8降至0.3可以减少随机性让输出更可控、更一致。3. 系统响应速度慢问题从输入指令到生成结果等待时间过长。排查向量检索优化确保ChromaDB的持久化路径在SSD上。对于本地嵌入模型考虑使用更轻量的版本。LLM API延迟如果使用云端API网络是主要瓶颈。考虑对生成请求设置合理的超时和重试机制或切换到响应更快的模型如GPT-3.5-Turbo比GPT-4快。缓存检索结果对于同一章节内频繁出现的实体如主角名其基本信息的检索结果可以缓存在内存中避免重复查询向量数据库。4. 如何处理作者的中途修改问题作者对AI生成的一段内容不满意手动进行了修改如何让记忆库同步方案这是文件级记忆的优势。实现一个“重新索引”功能。将修改后的章节文件替换原文件。触发一个后台任务识别出被修改的文档。从向量数据库中删除该文档对应的所有旧片段向量。将修改后的文档重新进行分块、提取元数据、生成向量并入库。这个过程可以设计为半自动在作者保存文件时弹出提示询问是否更新记忆。构建这样一个系统更像是在培育一个数字化的创作伙伴。它不会取代作者而是将作者从记忆和一致性的重负中解放出来让人脑更专注于创意、情感和故事的灵魂。从最小原型开始逐步迭代你会发现AI在长篇叙事上的潜力远超预期。本文还有配套的精品资源点击获取
