1. 项目缘起当AI写作遇上“健忘症”作为一个常年混迹于各种写作工具和代码编辑器之间的老鸟我最近被一个痛点折磨得够呛市面上那些所谓的AI辅助写作工具聪明是聪明但它们的“记性”实在太差了。你写了几千字的小说想让AI帮你润色一下第三章里某个角色的对话让它符合第一章里埋下的性格伏笔。结果呢你不得不把前面几章的内容一股脑儿复制粘贴进提示词里或者指望AI能自己从上下文中“猜”出来。这就像你请了个才华横溢但患有严重短期失忆的编辑每改一句话你都得把整本书的梗概再给他讲一遍效率低得令人抓狂。这正是我动手折腾这个项目的核心驱动力。我想要一个真正能“记住前文”的AI小说编辑器不是那种简单粗暴的聊天记录式记忆而是能理解故事脉络、角色关系、世界观设定的深度记忆。它应该像一个真正的写作伙伴WorkBuddy静静地待在编辑器侧边栏通读你的整个文稿在你需要的时候基于完整的上下文给出精准的建议、续写或修改。我选择围绕“WorkBuddy”这个概念来构建是因为它精准地描述了我想要的协作关系——不是一个高高在上的“AI大师”而是一个踏实、可靠、懂你项目的伙伴。这个伙伴需要深度集成到写作环境中拥有持续学习项目上下文的能力。经过一番调研和折腾我最终用Node.js生态里的一些强力工具把这个想法变成了现实。下面我就把这套方案的思路、踩过的坑和最终实现细节毫无保留地分享出来。2. 核心设计如何让AI拥有“长时记忆”实现一个能记住前文的编辑器听起来像是要造一个通用人工智能但其实我们可以把问题拆解成几个工程上可实现的模块。关键在于我们不需要AI“理解”一切而是需要一套机制能高效地存储、检索和注入相关的上下文信息给AI模型。2.1 架构总览从文档到提示词的智能管道整个系统的核心工作流可以概括为监听文档变化 - 智能切片与向量化 - 存储到向量数据库 - 用户提问时进行相关性检索 - 构建包含上下文的提示词 - 调用AI模型获取结果。这听起来是一长串步骤但每一个环节都有成熟的开源方案可供选择。我的设计目标是轻量、快速、可离线至少核心流程可离线毕竟写作是个需要专注的过程网络延迟和API费用都是干扰项。为什么选择向量检索这条路早期我尝试过最简单的方法每次都把整个文档作为上下文传给AI。这对于短篇尚可一旦字数上万不仅会急剧增加API调用成本按Token计费还可能触及模型本身的上下文长度限制比如GPT-4 Turbo的128K听起来很长但装下一部百万字的小说也够呛。更糟糕的是过长的无关上下文会干扰AI的判断导致其输出偏离当前焦点这就是所谓的“中间丢失”现象。向量检索的核心思想是“按需索取”。我们将文档切分成一个个有意义的片段比如按段落或场景把这些片段转换成数学向量这个过程叫“嵌入”存储起来。当用户针对某个位置提问时系统将问题也转换成向量然后在向量数据库里快速找出与问题向量最相似的几个文档片段。最后只把这些最相关的片段连同当前正在编辑的段落一起送给AI。这极大地提高了效率、降低了成本并提升了回答的相关性。2.2 技术栈选型为什么是它们选型直接决定了项目的可行性和开发体验。下面是我权衡后的选择运行时Node.js这是整个项目的基础。选择Node.js首先是因为我需要一个能快速构建跨平台桌面应用的环境。其次整个AI处理流程涉及大量的异步操作文件I/O、网络请求、计算密集型嵌入Node.js的事件驱动、非阻塞I/O模型非常适合。最后其庞大的npm生态几乎提供了我所需的一切工具从向量数据库客户端到各种AI模型的SDK。编辑器核心CodeMirror 或 Monaco Editor这是一个关键选择。我需要一个功能强大、可扩展性极强的代码编辑器组件来作为文字处理的核心。CodeMirror轻量、高度可定制是许多现代编辑器的基石如VSCode的早期版本。Monaco Editor则是VSCode编辑器的直接开源版本功能极其强大开箱即用但体积也更大。对于小说编辑器CodeMirror通常足够且更容易集成和定制样式。我最终选择了CodeMirror因为它能让我从更底层控制编辑器的行为比如实现语法高亮针对小说可以高亮角色名、地点等、自定义侧边栏等。向量数据库LanceDB 或 Chroma向量数据库是“记忆”的仓库。我需要一个能够快速进行相似性搜索的数据库。Chroma是一个流行的开源向量数据库易于使用有很好的JavaScript/TypeScript支持。LanceDB是另一个新兴选择它基于Apache Arrow列式内存格式性能非常出色尤其适合嵌入到桌面应用中因为它可以以单文件形式存在无需运行单独的数据库服务。考虑到项目的离线友好性和部署简便性我选择了LanceDB。它就像一个本地的、专门为向量优化过的“智能笔记本”。嵌入模型本地 vs. 云端这是另一个需要权衡的点。嵌入模型负责将文本转换成向量。云端API如OpenAI的text-embedding-3-small优点是质量高、稳定、省心。缺点是会产生持续的费用且必须联网。本地模型如通过TensorFlow.js或Transformers.js运行的all-MiniLM-L6-v2优点是完全离线、零成本、隐私性好。缺点是需要一定的客户端算力但现代电脑完全能胜任且模型体积和初始化需要时间。 为了追求极致的离线体验和隐私保护我决定挑战一下本地嵌入。我选择了Transformers.js库它可以直接在浏览器或Node.js环境中运行经过优化的Hugging Face模型。all-MiniLM-L6-v2是一个在通用语义相似度任务上表现很好的轻量级模型生成的向量维度是384在精度和速度之间取得了很好的平衡。大语言模型LLM接口OpenAI API 兼容层对于最终生成文本的LLM我选择了兼容OpenAI API的方案。这给了我最大的灵活性在开发调试时我可以使用OpenAI的GPT系列需要联网而在追求离线时我可以无缝切换到本地部署的、同样提供OpenAI兼容API的开源模型如Ollama管理的Llama 3、Qwen或DeepSeek等。通过一个统一的API客户端比如openainpm包我只需要切换baseURL和apiKey就能在不同模型间切换代码无需改动。注意本地运行LLM对硬件有一定要求主要是内存和显存。对于小说创作这种需要较长上下文和一定逻辑性的任务建议至少准备16GB内存并考虑使用量化后的模型如4-bit或5-bit量化来降低资源消耗。Ollama极大地简化了本地模型的下载和管理是入门首选。2.3 整体工作流设计确定了技术栈整个应用的工作流就清晰了初始化与加载用户打开一个小说文档或新建。编辑器组件加载文本。后台索引系统在后台自动将整个文档进行分块例如按“## 章节标题”或空行分割调用本地嵌入模型为每一块文本生成向量并存入本地的LanceDB表中。这个过程在首次打开文件或文件有重大修改后触发。交互与检索用户在编辑器中选中一段文字或光标停留在某处然后通过侧边栏的WorkBuddy面板输入问题如“帮我把这段对话改得更紧张些”或“根据前文这个角色此时应该是什么心情”。智能上下文构建系统将用户的问题和光标附近的文本合并生成一个查询向量。用这个向量在LanceDB中进行相似性搜索找出前文中最相关的3-5个文本块。提示词工程系统组装一个结构化的提示词Prompt你是一个专业的小说编辑助手。请根据以下提供的小说上下文回答用户的问题或完成指令。 【相关前文上下文】 这里插入从向量数据库检索到的相关文本块 【当前编辑段落】 这里插入用户选中或光标所在的段落 【用户指令】 用户输入的问题或要求 请基于以上信息进行回应。调用与呈现将组装好的提示词发送给配置好的LLM本地或云端。将返回的流式结果实时显示在WorkBuddy面板中用户可以一键采纳或修改后插入编辑器。这个设计使得AI的每次回应都牢牢地扎根于你已创作的故事土壤中避免了天马行空的偏离。3. 关键实现细节与踩坑实录把设计图变成代码每一步都有需要注意的细节。这里我分享几个最关键的实现环节和遇到的典型问题。3.1 文档分块Chunking的艺术分块是向量检索效果的基础。分得太细比如每句话一块会丢失上下文信息分得太大比如整章一块检索精度会下降且依然可能包含无关信息。我采用的策略是“重叠式语义分块”首先按明显的结构分割如“## 第一章”这样的Markdown标题或连续的两个换行符。这保证了基本的场景或章节完整性。对于每个大块如果长度超过预设值例如400个字符再按句子边界。等进行进一步分割。关键技巧重叠。在分割时让相邻的两个块有少量重叠比如50-100个字符。这能有效防止一个完整的语义单元如一段重要的描述性对话被硬生生割裂在两个块边界导致检索时只找到一半上下文丢失。// 一个简化的分块函数示例 function chunkText(text, chunkSize 400, overlap 50) { const chunks []; // 首先按双换行符分大段 const segments text.split(/\n\s*\n/); for (const segment of segments) { if (segment.length chunkSize) { chunks.push(segment); } else { // 按句子分割 const sentences segment.split(/(?[。])/); let currentChunk ; for (let i 0; i sentences.length; i) { // 如果加上下一句就超长且当前块不为空则保存当前块 if ((currentChunk sentences[i]).length chunkSize currentChunk) { chunks.push(currentChunk); // 重叠处理回溯一部分句子作为下一个块的开始 currentChunk currentChunk.slice(-overlap) sentences[i]; } else { currentChunk sentences[i]; } } if (currentChunk) chunks.push(currentChunk); } } return chunks; }踩坑一标点符号与语言模型。最初我用的句子分割正则表达式比较简单对中文标点支持不好导致很多段落没有被正确分割。后来改用了更健壮的分词库如nodejieba辅助判断句子边界但考虑到轻量性最终优化了正则表达式/(?[。\.\?!])/来兼顾中英文。3.2 本地嵌入模型集成在浏览器或Node.js中运行Transformer模型听起来很复杂但Transformers.js让它变得简单。主要步骤是安装与引入npm install xenova/transformers加载模型指定模型名称库会自动从Hugging Face Hub下载并缓存模型文件。生成嵌入将文本块传递给模型得到浮点数数组向量。import { pipeline } from xenova/transformers; // 注意首次运行会下载模型需要一定时间 const extractor await pipeline(feature-extraction, Xenova/all-MiniLM-L6-v2); async function generateEmbedding(text) { const output await extractor(text, { pooling: mean, normalize: true }); // output.data 是一个Float32Array即我们的向量 return Array.from(output.data); }踩坑二模型加载与性能。模型文件有几十MB首次加载需要时间。在桌面应用中我选择在应用启动时异步加载模型并显示加载进度。另外嵌入计算是CPU密集型任务对于超长文档索引过程可能会暂时阻塞UI。解决方案是将索引任务放入Web Worker浏览器环境或worker_threadsNode.js环境中避免界面卡顿。实测下来在M1 Mac上处理一个10万字的小说生成所有向量大概需要2-3分钟后续增量更新就很快了。3.3 向量数据库LanceDB的集成LanceDB的使用非常直观。在Node.js环境中可以将其视为一个本地的、基于文件的数据库。const lancedb require(lancedb/lancedb); const { connect } lancedb; async function setupVectorDB(dbPath) { const db await connect(dbPath); let table; try { table await db.openTable(novel_chunks); console.log(已存在表直接打开); } catch { // 表不存在创建它 const schema { id: new lancedb.Field(id, new lancedb.Int32()), text: new lancedb.Field(text, new lancedb.Utf8()), vector: new lancedb.Field(vector, new lancedb.FixedSizeList(384, new lancedb.Float32())), // 384维向量 startPos: new lancedb.Field(startPos, new lancedb.Int32()), // 在原文中的起始位置用于快速定位 }; table await db.createTable(novel_chunks, schema); console.log(创建新表); } return { db, table }; } // 插入数据 async function addChunkToTable(table, chunk, embedding, startPos) { const data { id: Date.now(), // 简单生成ID text: chunk, vector: embedding, startPos: startPos }; await table.add([data]); } // 搜索 async function searchSimilarChunks(table, queryEmbedding, limit 5) { const results await table .search(queryEmbedding) .limit(limit) .execute(); return results.map(r ({ text: r.text, score: r._distance, startPos: r.startPos })); }踩坑三向量维度对齐。嵌入模型all-MiniLM-L6-v2输出384维向量在定义LanceDB表结构时FixedSizeList的大小必须严格指定为384。如果用了其他维度的模型如text-embedding-3-small是1536维这里必须同步修改否则会报错。3.4 编辑器与WorkBuddy面板的交互这是用户体验的核心。我使用CodeMirror作为编辑器并在其DOM容器旁边创建一个绝对定位的侧边栏div作为WorkBuddy面板。关键交互逻辑上下文感知监听编辑器的光标位置cursorActivity事件和选中文本变化。当用户没有明确选中文本时默认以光标所在段落通过查找最近的换行符确定边界作为“当前编辑段落”。流式输出调用LLM API时使用流式响应stream: true。这样AI的回复可以像打字一样逐字显示在面板中体验更佳。对于本地Ollama同样支持流式输出。一键应用在WorkBuddy面板的AI回复区域提供一个“插入到光标处”或“替换选中文本”的按钮。点击后将AI生成的内容插入编辑器相应位置。// 伪代码展示思路 const editor new CodeMirror(document.getElementById(editor), { /* 配置 */ }); const workbuddyPanel document.getElementById(workbuddy-panel); const askButton document.getElementById(ask-button); const questionInput document.getElementById(question-input); askButton.addEventListener(click, async () { const question questionInput.value; const cursor editor.getCursor(); const currentLine editor.getLine(cursor.line); // 更智能地获取当前段落向前向后查找空行 const currentParagraph getParagraphAroundCursor(editor, cursor); // 1. 为 (问题 当前段落) 生成查询向量 const queryVector await generateEmbedding(question \n currentParagraph); // 2. 从向量数据库搜索 const relevantChunks await searchSimilarChunks(table, queryVector); // 3. 构建提示词 const prompt buildPrompt(relevantChunks, currentParagraph, question); // 4. 调用LLM流式 const response await fetch(/api/chat, { // 本地或远程代理接口 method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages: [{ role: user, content: prompt }] }), }); const reader response.body.getReader(); const decoder new TextDecoder(); let fullReply ; workbuddyPanel.innerHTML ; // 清空面板 while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value); // 假设chunk是SSE格式或简单文本 fullReply chunk; workbuddyPanel.innerText fullReply; // 实时更新显示 } // 5. 显示“应用”按钮 showApplyButton(fullReply, editor); });4. 部署、优化与扩展思考一个可用的原型出来后下一步是让它更健壮、更实用。4.1 本地化部署与打包为了让其他写作者也能用上我需要把它打包成一个真正的桌面应用。Electron或Tauri是自然的选择。Electron更成熟生态丰富但打包体积较大。Tauri使用Rust编写核心打包体积极小性能更好安全性更高是当前的新兴热门选择。我选择了Tauri因为它能更好地与我的Rust后端如果需要集成并且最终生成的安装包可以小到几MB加上本地模型文件除外。Tauri应用的前端部分就是一个Web应用我的编辑器界面后端Rust逻辑可以处理更复杂的文件操作或本地模型调度。打包注意事项需要将Transformers.js的模型文件.bin和.json等一并打包进应用资源或者提供首次启动时下载的机制。LanceDB的数据库文件则直接存储在用户的应用数据目录下。4.2 性能优化点增量更新索引每次用户保存文档时全量重新索引是低效的。可以实现一个简单的差异分析比较新旧文档只对新增或修改的段落进行重新嵌入和更新数据库操作删除已移除段落对应的向量。嵌入模型缓存对已嵌入的文本块进行哈希如MD5将哈希值和向量一起存储。下次遇到相同文本时直接使用缓存避免重复计算。向量索引加速LanceDB内部支持多种索引如IVF_PQ对于非常大的文档库比如系列小说全集创建索引可以大幅提升检索速度。可以在后台空闲时或文档数量达到阈值后自动创建索引。LLM上下文管理即使经过检索有时相关的上下文块加起来还是可能很长。需要设计一个“精炼”层当总Token数接近模型上限时自动对检索到的上下文进行摘要或进一步筛选确保提示词不会超长。4.3 功能扩展方向这个基础框架的潜力很大角色知识库单独维护一个“角色设定”的向量库。当AI处理涉及特定角色的内容时同时检索小说正文和角色设定库使AI对角色的把握更精准。风格模仿让用户提供几段范文提取其风格特征通过嵌入或专门的分析在生成时要求AI模仿此风格。情节一致性检查定期自动扫描全文让AI基于向量检索找出可能存在矛盾的时间线、人物特征或事件描述并给出提示。多模态扩展结合本地图像生成模型如Stable Diffusion根据小说片段自动生成场景概念图或角色立绘为创作提供视觉灵感。5. 常见问题与排查指南在实际开发和试用中我遇到了一些具有代表性的问题这里整理出来供参考。问题现象可能原因排查与解决思路向量检索结果完全不相关1. 嵌入模型未正确加载或运行。2. 文本分块不合理破坏了语义。3. 向量数据库搜索函数使用错误。1. 检查嵌入模型pipeline是否成功创建尝试对一句简单文本生成嵌入看输出是否为固定长度的浮点数数组。2. 检查分块函数打印出前几个块的内容看是否符合预期。调整分块大小和重叠度。3. 确认search函数调用正确查询向量维度与数据库存储维度一致。AI回复似乎未使用前文1. 检索到的相关片段未正确拼接到提示词中。2. 提示词Prompt模板设计不佳AI忽略了上下文。1. 在发送请求前将组装好的完整提示词打印到控制台检查【相关前文上下文】部分是否包含有效内容。2. 强化提示词指令。例如在开头明确强调“你必须严格依据以下上下文回答如果上下文未提供相关信息请直接说明无法回答”。可以尝试在上下文中加入明显的标记如 上下文开始 。应用运行缓慢界面卡顿1. 在主线程进行大量同步计算如嵌入生成。2. 向量数据库操作阻塞了事件循环。3. 文档过大索引耗时过长。1.必须将嵌入计算、数据库索引等重型任务放入Web Worker或独立进程。2. 确保所有数据库操作尤其是初始全量插入是异步的。3. 实现进度提示并考虑将全量索引改为在后台空闲时进行。对于超长文档可以提示用户先索引部分章节。本地LLMOllama回复质量差1. 模型选择不当能力不足。2. 提示词未针对本地模型优化。3. 上下文长度超出模型处理能力。1. 尝试更强大的模型如llama3:8b、qwen2:7b等。7B参数以上的模型在理解长指令和复杂上下文上表现更好。2. 本地模型可能对指令的遵循能力不如GPT-4。需要编写更直接、更结构化的提示词避免过于复杂或含蓄的表述。3. 检查并严格控制送入模型的总Token数。使用transformers的Tokenizer预先计算Token数量。LanceDB表无法打开或写入失败1. 数据库文件被占用如另一个进程正在使用。2. 表结构Schema与现有数据不匹配。3. 文件路径权限问题。1. 确保应用是单实例运行或实现了正确的数据库连接池/锁机制。2. 如果修改了表结构如向量维度可能需要删除旧的数据库文件重新创建。3. 检查应用是否有对目标目录的读写权限。在打包应用中应使用app.getPath(userData)这类API来获取合适的可写目录。最后一点心得这个项目的核心价值不在于用了多炫酷的模型而在于通过工程化的思路将“记忆”这个抽象需求拆解成了可落地的数据流水线。它证明了即使不依赖庞大的云端服务和复杂的算法利用开源工具和清晰的架构我们也能在本地打造出智能、实用的创作工具。最大的成就感来自于当它真正“读懂”了你前文埋下的伏笔并给出一个严丝合缝的续写建议时那种与机器协同创作的奇妙感觉。