1. 从“失忆”到“长情”：我为什么需要一个能记住前文的AI小说编辑器

写小说，尤其是长篇，最怕什么？不是卡文，不是灵感枯竭，而是写到第十章，突然想不起第三章里某个配角眼睛的颜色，或者第五章主角随口提过的一个地名。你不得不停下创作的手，在几十个文档里来回翻找，或者依赖那并不靠谱的记忆。这种“上下文割裂”的体验，足以打断任何流畅的创作心流。

我尝试过市面上几乎所有主流的写作软件和笔记工具。它们有的界面精美，有的功能强大，但都有一个共同的短板：它们只是被动的“记录者”，而非主动的“协作者”。当我向内置的AI助手提问：“主角第一次见到反派时，反派说了什么？” 得到的回复往往是：“抱歉，我无法访问您之前的文档内容。” 那一刻，感觉就像雇了一个记忆力只有七秒的助理，每次对话都得从头教起。

这让我意识到，一个真正能辅助创作的AI工具，其核心能力不应该是“生成”，而应该是“理解”。它需要像一个真正的编辑或合著者那样，记住整个故事世界的设定、人物关系、情节脉络。于是，我把目光投向了那些能够处理长文本、具备强大记忆能力的AI Agent框架。在众多选择中，WorkBuddy以其清晰的架构、对Node.js的良好支持以及活跃的社区进入了我的视野。我的目标很明确：不是做一个通用的聊天机器人，而是打造一个专为长篇叙事服务的“记忆中枢”，一个能嵌入到我的写作流程中、真正理解我故事上下文的AI小说编辑器。

2. WorkBuddy：不只是另一个AI套壳，而是可编程的智能体框架

在开始动手之前，我们需要先理解WorkBuddy到底是什么。网络上有很多关于“WorkBuddy使用教程”、“WorkBuddy和CodeBuddy区别”的讨论，容易让人把它看作一个现成的、开箱即用的AI应用。实际上，这是一种误解。WorkBuddy更像是一个 智能体（Agent）的底层开发框架和运行环境 。

你可以把它想象成乐高积木的基础底板和核心连接件。它提供了让AI智能体运行起来所需的基础设施：任务调度、记忆管理、工具调用、状态保持等。但它本身不提供任何具体的“技能”（Skill）。你需要，或者说，你可以基于它来搭建任何你想要的智能应用。这正是它的魅力所在——高度的可编程性和定制性。

与一些封装好的、提供固定问答模式的AI工具相比，WorkBuddy的核心优势在于其 记忆系统 。它原生支持将对话历史、工具执行结果、用户自定义数据等，以一种结构化的方式存储和检索。这对于小说创作场景至关重要。当我在编辑器中输入“将主角的冒险经历总结成时间线”时，WorkBuddy驱动的后台智能体能够去它的记忆库中，检索所有与“主角”、“冒险”相关的片段，然后进行综合分析与生成，而不是基于最后一次对话的只言片语胡编乱造。

它的技术栈基于Node.js，这对于广大JavaScript/TypeScript开发者来说非常友好，意味着你可以用熟悉的语言来扩展它的能力。社区里已有不少“开源项目”展示了如何为WorkBuddy添加各种“Skill”，比如连接数据库、调用外部API、处理特定格式的文件等。这为我构建小说编辑器提供了坚实的技术基础：我不需要从零开始造轮子，而是可以站在一个设计良好的框架上，专注于实现“文学记忆”这个核心功能。

3. 架构蓝图：如何让AI成为你的“故事数据库”

有了WorkBuddy作为引擎，下一步就是设计整个系统的架构。我的目标是一个本地优先、隐私安全、深度集成的写作环境。整个系统可以分为三层：呈现层、智能层和记忆层。

呈现层（编辑器界面） ：我选择了一个轻量级、可嵌入的富文本编辑器作为前端，例如Tiptap或Quill。它的作用是提供一个干净、无干扰的写作区域，同时暴露一些特殊的交互控件，比如“询问AI关于当前段落”、“检索人物设定”、“生成后续情节建议”等按钮。所有用户输入的文字，都会实时或按批次发送到智能层进行处理。

智能层（WorkBuddy智能体） ：这是整个系统的大脑。我创建了一个专有的WorkBuddy Agent，它配备了几个关键技能（Skill）：

1. 文本摄取与分块技能 ：负责接收编辑器传来的文本，按照章节、场景或固定长度进行智能分块。分块时不仅看字数，还会尝试识别段落边界、对话切换等语义边界，以保证上下文片段的完整性。
2. 向量化与存储技能 ：将分块后的文本，通过嵌入模型（Embedding Model）转换为高维向量。这个向量就像是这段文字的“数学指纹”，包含了其语义信息。随后，这个向量和对应的原始文本，被一起存储到本地的向量数据库（如ChromaDB或LanceDB）中。这就是记忆层的核心。
3. 检索与推理技能 ：当用户在编辑器中提出一个问题（如“主角的导师叫什么？”），该技能会将问题也转化为向量，然后在向量数据库中进行相似性搜索，找出与问题最相关的几个文本片段（记忆）。WorkBuddy Agent会将这些片段作为“上下文”，连同用户的问题，一起发送给大语言模型（如GPT-4、Claude或本地部署的Ollama模型），请求模型基于这些确切的记忆来生成答案。

记忆层（向量数据库） ：这是一个独立于大模型的外部记忆系统。它持久化地存储着你所有创作内容的向量和原文。即使你关闭了编辑器，甚至更换了底层的大语言模型，你的“故事记忆”依然完好无损。你可以把它想象成小说的“第二大脑”，专门负责海量、结构化信息的存储和快速关联检索。

这个架构的关键在于 解耦 ：写作界面、AI推理能力、长期记忆被分离成独立的模块。这样，我可以单独升级其中任何一部分，比如换一个更强大的本地模型，或者优化检索算法，而不会影响其他部分。这也保证了数据完全掌握在自己手中，所有创作内容无需上传至云端，满足了创作者对隐私和版权的基本要求。

4. 核心实现：构建“记忆”的三大关键技术环节

理论架构清晰后，真正的挑战在于实现。让AI记住前文，涉及三个环环相扣的技术环节：怎么存、怎么找、怎么用。

4.1 记忆的存入：文本分块与向量化策略

存，不是把整部小说扔进去那么简单。一股脑存入整本书，检索时可能会带回大量无关信息，干扰AI的判断。因此，需要智能分块。

我的策略是 多级分块结合 ：

• 第一级：章节分块 。以自然章节为边界，这是最粗的粒度，适合检索宏观结构，如“故事第三部分讲了什么”。
• 第二级：场景分块 。利用空行、时间地点变化、POV（视点人物）转换等信号，将一章切分为多个场景。这是最常用的粒度，能精准定位到具体事件。
• 第三级：滑动窗口分块 。对于特别长的描述性或论述性段落，采用固定长度（如500字）重叠滑动窗口进行分块，重叠部分（如100字）能保证上下文连贯，避免在段落中间被切断语义。

分块后的文本，通过嵌入模型转化为向量。这里有一个关键选择：使用 专用嵌入模型 还是 大语言模型本身的嵌入能力 ？早期我直接使用OpenAI的 text-embedding-ada-002 ，效果不错但依赖网络。后来转向本地部署的模型，如 BAAI/bge-small-zh-v1.5 ，这个针对中文优化的模型在语义捕捉上表现非常出色，且完全离线。在WorkBuddy的Skill里，调用Hugging Face Transformers库或通过Ollama来运行这些嵌入模型，流程非常顺畅。

注意 ：分块策略需要根据你的写作风格调整。如果你擅长写大段心理描写，可能需要增大滑动窗口；如果你的小说场景切换频繁，那么场景分块会更有效。这是一个需要结合内容反复调试的过程。

4.2 记忆的检索：从关键词到语义搜索

当用户提问“那个红头发的女巫后来怎么样了？”，传统的关键词搜索可能因为用户记不清“女巫”这个词而失效。而向量检索的核心是 语义搜索 。

系统的工作流程如下：

1. 问题向量化 ：将用户的自然语言问题，使用与存入时 相同的嵌入模型 ，转化为一个向量。
2. 相似度计算 ：在向量数据库中，计算问题向量与所有存储的记忆向量之间的余弦相似度。这个值在-1到1之间，越接近1表示语义越相似。
3. Top-K召回 ：取出相似度最高的K个记忆片段（例如Top-5）。这K个片段就是AI回答问题的“参考依据”。

为了提高检索精度，我引入了 混合检索 策略：

• 语义检索为主 ：如上所述，保证能找到语义相关但关键词不匹配的内容。
• 关键词元数据过滤为辅 ：在存入向量时，同时为每个记忆块提取关键实体（人物、地点、组织）作为元数据标签。检索时，可以先通过“人物：红发女巫”这类过滤器缩小范围，再进行语义搜索，大幅提升准确率。

在WorkBuddy中，这可以通过在Skill里组合调用向量数据库的查询接口和元数据过滤功能来实现。例如，使用ChromaDB时，它的 query 方法可以直接接受 where 条件进行过滤。

4.3 记忆的使用：设计精准的提示词工程

检索到的记忆片段，不会自动变成答案。如何将这些“记忆”有效地“喂”给大语言模型，决定了最终回答的质量。这里就是提示词（Prompt）工程的用武之地。

我设计的核心提示词模板如下：

你是一位专业的小说创作助手，拥有关于以下故事片段的完整记忆。请严格根据提供的记忆来回答问题，不要编造记忆中没有的信息。

【相关记忆上下文】
{在此插入检索到的Top-K个记忆片段，用分隔符隔开}

【用户当前问题】
{用户的问题}

【回答要求】
1. 答案必须完全基于上述【相关记忆上下文】。
2. 如果上下文中有明确信息，请直接引用并说明出处（如：出自第X章）。
3. 如果上下文中信息不足或模糊，请如实告知“根据现有记忆，无法确定”，并可以指出可能需要查阅的大致方向。
4. 语言风格保持与小说原文一致。

这个提示词做了几件关键事：

1. 设定角色 ：明确AI的职责是“创作助手”，而非万能知识库。
2. 划定边界 ：强调“严格根据记忆”，抑制其幻觉（Hallucination）倾向。
3. 提供结构化上下文 ：清晰地将记忆与问题分开，便于模型理解。
4. 给出具体指令 ：规定了回答的格式和底线，尤其是“无法确定”这一条，这比胡编乱造有价值得多。

在WorkBuddy Agent中，我将这个提示词模板固化在一个专用的“问答技能”里。该技能的工作流是：接收问题 -> 触发检索技能获取记忆 -> 组装提示词 -> 调用大语言模型API -> 将回答返回给编辑器界面。

5. 实战演练：在写作流程中与“记忆AI”协作

光有技术不够，必须融入真实的写作流程。我来分享几个日常使用中的典型场景，看看这个系统如何具体工作。

场景一：连续性检查与细节补全 我正在写第十五章，主角需要回想起他七岁时父亲送他的一把匕首。我记不清具体描述了。我只需在编辑器侧边栏输入：“查找主角父亲赠送匕首的详细描述”。 后台智能体迅速在记忆库中检索，几秒后返回：“根据记忆，该情节出现在第三章第12段。原文描述为：‘一柄镶着暗蓝色珐琅的短匕，刀柄上刻着缠绕的藤蔓，那是他七岁生日时，父亲在边塞集市用三张上好的狐皮换来的。’” 我不仅得到了答案，还知道了出处，可以快速跳转回去查看上下文，保证了细节的绝对连贯。

场景二：人物关系梳理 故事线复杂，配角众多。我可以直接命令：“生成一份截至目前所有出场人物及其相互关系的图谱摘要。” 智能体会检索所有包含人物介绍和互动的记忆片段，进行综合、去重、归纳，最终生成一份清晰的人物关系清单，甚至能以Markdown表格的形式返回，让我对全局人物网络一目了然。

场景三：情节发展建议 写到一个关键转折点，我有些犹豫。我输入：“基于主角目前‘身负重伤’且‘被朝廷通缉’的处境，以及他‘性格倔强’、‘重视朋友’的特点，请分析他接下来可能做出的三种选择，并评估每种选择对故事走向的影响。” 这时，AI不再是凭空想象。它会检索所有关于主角受伤程度、通缉令详情、性格刻画以及过往重要抉择的记忆，在此基础上进行逻辑推演，给出有上下文支撑的、符合人设的情节建议。这种建议的参考价值远高于天马行空的随机生成。

场景四：风格一致性维护 我的小说是古典武侠风格，但写着写着，偶尔会冒出一些现代词汇。我可以定期让AI进行检查：“扫描最近新增的5000字内容，找出其中可能不符合古典武侠语言风格的词汇或句式，并给出修改建议。” AI基于之前已被我认可的、风格纯正的章节作为“风格记忆”，来比对和审视新内容，充当了一位不知疲倦的“风格校对员”。

6. 避坑指南：那些我趟过的雷和收获的经验

在开发和使用这个编辑器的过程中，我踩过不少坑，也总结出一些让系统更可靠、更高效的经验。

坑一：向量数据库的“遗忘”与“污染” 最初，我采用“追加式”存储，每写一段就存一段。很快发现两个问题：1. 当我修改了之前章节的某个段落，数据库里存在的是旧版本的向量，导致检索到过期信息。2. 同一内容被反复存储（如稍作修改后保存），造成冗余和检索结果重复。 解决方案 ：建立 版本管理与去重机制 。我为每个文档块设计唯一ID，包含章节号和段落哈希。每次保存时，先检查该ID是否已存在，若存在则用新向量覆盖旧向量。同时，定期运行简单的文本相似度去重脚本，清理高度重复的记忆片段。

坑二：检索结果的相关性陷阱 有时，AI的回答看似引经据典，实则答非所问。排查发现，是语义检索找到了“语义相似”但“主题无关”的记忆。例如，提问“A角色的武功招式”，却检索到了描写“B角色练功场景”的段落，因为两段都大量出现“内力”、“经脉”等词。 解决方案 ：优化 检索查询的构造 。不要简单地将原始问题直接向量化。而是先让一个小模型（或通过规则）对问题进行意图解析和关键词增强。例如，将“A角色的武功招式”重写为“关于角色A使用的特定武功招式的名称、特点和描述”，再将其向量化用于检索，能显著提升主题相关性。

坑三：大模型的“过度发挥” 即使提供了精确记忆，某些大模型（特别是早期版本）仍会忍不住“炫技”，添加一些记忆中不存在但看似合理的细节。 解决方案 ： 强化提示词约束与后处理 。除了在提示词中严厉警告，我还在WorkBuddy的Skill里增加了一个“事实核对”步骤。AI生成初步答案后，系统会自动提取答案中的关键事实断言（如时间、地点、人物动作），再次用这些断言作为查询去检索记忆库，验证是否存在支持证据。如果某个断言找不到足够支撑，则在最终答案里将其标记为“推测”或直接要求AI重新生成该部分。

坑四：系统性能与响应速度 随着小说字数增长到几十万，记忆向量可能达到数万个。每次检索都进行全量计算，速度会变慢。 解决方案 ：引入 分级索引与缓存 。

1. 分级索引 ：除了全量向量库，我为“人物”、“地点”、“关键物品”建立了专门的索引。当问题明显属于某一类别时，优先搜索子索引，大幅缩小搜索范围。
2. 查询缓存 ：对于频繁被问到的、或者近期问过的相似问题（通过问题向量相似度判断），将其答案缓存一段时间。例如，“主角是谁”这种问题，答案在很长一段时间内是不会变的。
3. 增量更新 ：每次只对新写入或修改的文本进行向量化和索引，避免全量重建。

这些优化使得即便在处理长篇作品时，大多数查询也能在1-3秒内得到响应，保证了写作过程的流畅性。

7. 超越编辑器：WorkBuddy智能体的更多可能性

将这个基于记忆的AI能力封装成一个小说编辑器，只是第一个应用场景。WorkBuddy框架的灵活性，使得这套“记忆中枢”可以演变为更通用的“创作大脑”。

可能性一：多作品世界管理 我可以为不同的长篇系列、不同的世界观，创建不同的WorkBuddy Agent实例和对应的向量数据库。一个Agent专门服务“东方玄幻世界A”，记忆库里全是它的设定和文稿；另一个Agent服务“科幻末世世界B”。在写作台上，我可以轻松切换，而不会发生世界观和设定的串扰。这相当于为每个宏大的创作项目配备了一个专属的、知识渊博的“世界管理员”。

可能性二：从辅助写作到辅助构思 当前系统主要服务于“写作中”的查证和连贯性维护。下一步，我可以为Agent添加“构思技能”。例如，输入一个高概念“如果恐龙没有灭绝，并且进化出了文明”，Agent可以调用它的记忆库（此时可能接入一个更通用的知识库，如维基百科向量化数据），结合我以往作品的风格记忆，生成一份初步的世界观设定、种族分类、社会结构草图，为我的新书提供灵感起点。

可能性三：个性化风格迁移与模仿 通过大量学习某位作家特定作品集的记忆，Agent可以深度理解其文风、句式偏好、修辞手法。当我创作新故事时，可以要求Agent以“XX作家的风格”来润色某一段落，或者对我写的段落进行风格符合度评估。这对于系列作品的续写，或者进行特定风格的创作练习，有极大的帮助。

可能性四：跨模态内容关联 记忆库里不仅可以存储文本，还可以存储与故事相关的图片（概念图、地图）、音频（氛围音乐、角色语音参考）、甚至视频片段。通过多模态模型，将这些非文本内容也转化为向量，与文本向量存在同一个空间。这样，当我看到一张场景概念图时，可以问Agent：“根据这幅图的氛围，匹配小说中哪个场景最合适？” 或者，写一段雨夜打斗戏时，让Agent推荐几段存储在记忆库中的、情绪匹配的背景音乐。这将创作从纯文本扩展到了全方位的感官体验构建。

实现这些扩展，本质上都是在WorkBuddy框架下开发新的Skill。它的插件化架构让增加新功能变得模块化。例如，开发一个“风格分析Skill”，专门负责提取和比对文本风格特征；开发一个“多模态存储Skill”，负责处理图像和音频的嵌入与关联。这正是WorkBuddy作为智能体框架而非单一工具的价值所在——它提供了一个可持续进化、按需定制的能力平台。

回看整个项目，从被“失忆”的AI助手困扰，到亲手打造一个“长情”的创作伙伴，最大的收获不是技术本身，而是对“人机协作”模式的重新思考。最好的工具不是替代你，而是深刻理解你，并在你需要的时刻，提供恰到好处的支持。这个能记住前文的编辑器，记住的不仅仅是文字，更是你构建那个虚构世界的点点滴滴，它让AI从“聪明的陌生人”，变成了你创作之旅中一位可靠的“同行者”。