很多 AI 写作工具都能生成一段看起来不错的文字，但一写到长篇，问题就来了：人物性格悄悄变化，前面埋下的伏笔被忘记，时间线互相打架，写到几十章后，模型甚至记不清上一章发生了什么。
我想做的不是一个套着聊天框的"小说生成器"，而是一套真正围绕长篇写作设计的工作台：它要能管理作品、大纲、人物和世界设定；写每一章时自动带上相关上下文；章节完成后整理记忆；还要允许作者随时修改、重写和调整后续方向。
于是，我用 WorkBuddy 把这个想法做成了一个可以本地运行的开源项目：墨线 · 小说工坊。
项目地址：https://cnb.cool/TvTink/xiaoshuo
一、先把"做个小说工具"拆成能执行的需求
我一开始没有直接让 WorkBuddy "帮我做个网站"，而是先讨论真实的写作流程。一个长篇项目至少有四层数据：
- 作品层：书名、类型、主题、篇幅和文风。
- 规划层：世界设定、人物、时间线、总体剧情和逐章大纲。
- 正文层：每一章的标题、内容和完成状态。
- 记忆层：章节摘要、人物状态、伏笔、地点、物品和滚动更新的全局摘要。
我给 WorkBuddy 的第一类指令，大致是这样的：
我想做一个本地运行的网页版 AI 小说编辑器。先不要写代码，请分析长篇小说生成最容易失控的环节，给出数据结构、写作流程和上下文策略。数据需要持久化，大模型通过 OpenAI 兼容接口接入。方案确认后再实现。
这一步很重要。WorkBuddy 先帮我把模糊想法整理成页面、接口、数据表和任务流程，我再逐项确认。最终技术方案保持得很克制：前端使用原生 HTML、CSS 和 JavaScript，后端使用 Node.js、Express 与 SQLite。没有为了"看起来先进"堆叠框架，部署和迁移也更简单。
实际打开 WorkBuddy 的 Plan 模式，它并不会直接动手写代码，而是先把当前工作区扫一遍：Node.js 版本、npm、Playwright 是否就绪，全在第一屏列出来；接着把整套项目要长成什么样子、每个文件负责什么，先用一张目录清单铺出来：
我对照这张图确认"环境 OK、目录结构合理"后，再让它继续往下展开。后面的输出会自动落到一张「阶段计划表」上：P1 基础骨架、P2 模型设置 + 项目 CRUD、P3 大纲生成主流程......一直到 P9 自动化测试，每个阶段都写清楚"做什么"和"预计产出"：
这张表就是后续所有代码动作的"母版"。我对照它决定要不要调整顺序、合并阶段、砍掉功能，确认后再让 WorkBuddy 真正动手。Plan 模式在这里帮我避免了一上来就堆功能、又因为边界不清反复返工的常见问题------把"想要的东西"翻译成"可以执行的事情"这一步，是后续一切顺利的起点。
新建作品时，作者可以输入书名、题材、主题、章节数、每章字数、文风和硬性设定，也可以选择系统内已有作品作为结构或文风参考。
二、真正难的不是生成文字，而是管理上下文
普通的做法是把前文全部塞给模型。短篇还能用，长篇很快就会超过模型窗口，也会带来大量无效 token。只给上一章又不够，早期伏笔、人物关系和世界规则很容易丢失。
我和 WorkBuddy 反复调整后，采用了分层上下文策略：
- 默认注入前 2 章完整正文，作者可以在 1 至 5 章之间调整。
- 更早章节只提供结构化摘要，减少无关文本。
- 同时注入全局摘要、当前章大纲、相关人物、时间线、世界设定和关键记忆。
- 每章完成后，自动提取人物状态、剧情事件、伏笔、地点和物品记忆。
- 长章节先分段摘要，再归并为章节记忆，避免章末内容被截断。
- 上下文总字符预算可在 8000 至 120000 之间配置，超长时优先保留设定开头和当前剧情结尾。
模型连接也没有绑定某一家服务。只要提供 OpenAI Chat Completions 兼容接口，就可以接入 OpenAI、DeepSeek、通义千问、智谱、硅基流动或本地 Ollama。API Key 和作品数据都保存在本机 SQLite 中。
这个阶段最能体现 WorkBuddy 对我效率的提升。它不只给出一段建议，而是可以直接读取现有代码、找到上下文拼装逻辑、修改实现并跑回归测试。我的任务从"亲手改完每一个细节"，变成"说清楚约束、检查方案、验收行为"。尤其在跨前端、接口和数据库的改动中，这种协作方式很实用------改完一处再让 WorkBuddy 跑一遍相关用例，把通过结果贴回来，再讨论下一处。
三、长篇大纲不能一次生成，所以我把它做成可恢复任务
当作品只有十几章时，一次生成大纲问题不大。但如果是 100 章、500 章甚至更长，要求模型一次返回完整 JSON，失败概率会明显增加：响应可能截断、格式可能损坏，重试还会把已经成功的部分全部浪费掉。
我继续向 WorkBuddy 提出约束：
单部作品要支持最多 1000 章。超过 50 章时，不要一次生成全部章节。先规划全书分卷和阶段节奏，再按批次生成逐章大纲；每批成功后立即保存，失败只重试当前批次，服务重启后也要能继续。
最终实现是：长篇先生成全局框架，再按每批 20 章顺序规划；页面显示当前批次和百分比；每个成功批次写入 SQLite；模型 JSON 出现常见错误时先自动修复，仍然失败则只重试当前批次，最多 3 次。
作者也不必一次规划全书。可以先输入某个章节区间和阶段意图，生成后人工审核确认，再继续下一阶段。下一阶段必须承接已经确认的前段，避免 AI 擅自推翻前文。
这一点改变了产品定位：AI 负责提出和执行，作者保留确认权。长篇写作不适合"点击一次，等它写完"，更适合"规划、审核、写作、复盘"的循环。
四、写到一半想改方向，不需要推倒重来
小说创作很少严格按照最初大纲走。写到第十章后，作者可能想更换主线、增加人物，或者发现某一章与上下文衔接不自然。
我让 WorkBuddy 在不破坏已完成内容的前提下增加了几类编辑能力：
- 重规划后续：指定起始章节、新总章数和调整要求；起始章之前的正文、大纲与记忆保持不变，只重新生成后续方向。
- 重写本章：可指定上、下衔接章节，只替换当前章正文，再重建本章记忆和全局摘要。
- 按设定再生：世界、人物、时间线、剧情、全局摘要和未完成大纲可以按需勾选，已完成正文不会被覆盖。
- 连续写作：指定写到第几章自动停止，并强制按章节顺序生成，避免跳章造成状态缺失。
这里我学到一个很实用的 WorkBuddy 协作方法：修改需求时，把"哪些可以改"和"哪些绝对不能动"同时写清楚。例如：
从第 8 章开始重新规划后续。第 1 至 7 章正文、已确认大纲和记忆全部保留；只重建第 8 章之后的标题、大纲、时间线和必要的新人物。请先列出影响范围，再修改代码并补测试。
相比只说"加一个重规划功能"，这种指令能显著减少返工。WorkBuddy 会先定位数据边界，再处理前端交互、后端接口和回归测试。
五、写完一本，还能写续作或复用创作模板
在已有作品顶部，可以直接进入"衍生创作"：
- "写后续"会携带原作全局摘要、人物、世界设定和最近结尾，创建一个独立续作。
- "复用模板"只保留类型、篇幅、文风和自定义约束，不复制原作人物、剧情和正文。
此外，完整作品可以导出为 JSON 或 ZIP。ZIP 中既有包含设定、大纲、正文与记忆的完整包，也有按章节拆分的 TXT，方便备份、迁移和后续编辑。导入时会先校验数据，不会因为一个损坏文件直接污染现有项目。
六、让 WorkBuddy 不只"写代码"，还负责验证结果
开发过程中，我没有把"页面能打开"当成完成。每次涉及核心数据行为，我都会要求 WorkBuddy 同步补测试，例如：
请为这次改动补自动化测试，覆盖正常流程、错误输入和数据保留边界。运行完整测试，确认没有破坏导入导出、长篇规划与已完成章节。
目前仓库有 16 次提交 ，测试覆盖长篇分批生成、失败重试、异常 JSON 修复、上下文窗口、选择性再生、章节重写、续作和完整包迁移等核心行为。本文发布前，我重新运行了测试，结果为 18 项全部通过。
整个"跑测试、读报错、决定继续修还是先讨论"的小循环，都是在 WorkBuddy 的集成终端里完成的。如果哪一项失败，它会先把错误原文贴回对话窗口，再和我决定是直接修复、还是要先讨论方案。这条"测试出问题就停下讨论"的原则，让它从"我说它写"变成"我和它一起写"。
项目也配置了 CNB 自动构建：推送到 main 后会安装依赖、执行测试、启动健康检查并发布容器镜像。需要部署时，一条 Docker 命令即可启动，并通过数据卷持久化 SQLite。而这一切的入口，其实是 WorkBuddy 左边的「专家·技能·连接器」面板------CNB、福帮手、金山文档、企查查、网易邮箱、GitHub、Notion 等几十个常用平台都在里面，我这次用到的就是 CNB：
加完连接器之后，WorkBuddy 不只是能写代码，还能在授权范围内直接帮我读写仓库、提 PR、查 Issue、同步文档，把"开发"和"上线"之间的工具切换也省掉了。
https://cloud.tencent.com/developer/article/2695673
七、我的真实感受：WorkBuddy 更像一个能落地的开发搭档
这次实践里，WorkBuddy 对我最有价值的地方，不是一次生成了多少代码，而是它能参与完整工程循环：理解需求、阅读仓库、制定修改方案、跨文件实现、运行命令、根据报错继续修复，最后用测试证明结果。
当然，它也不是一句话就能把产品做完。需求过大或边界模糊时，生成结果同样可能偏离预期。我的经验是：
- 复杂功能先用 Plan 模式对齐数据边界和验收条件。
- 一次只解决一个完整问题，例如先做上下文策略，再做长篇任务恢复。
- 明确不能被修改的数据，尤其是已有正文和已确认大纲。
- 每次完成后让 WorkBuddy 自己运行测试，而不是只听它说"已经完成"。
- 重复出现的约束写进项目文档，减少后续对话的重复说明。
对我来说，WorkBuddy 把"我有一个产品想法"推进到了"仓库可以运行、功能可以验证、项目可以部署"。它没有取代我的判断，但显著降低了把需求翻译成工程实现的成本。对于个人开发者，尤其是需要同时处理产品、前端、后端、数据和部署的人，这种端到端协作非常实用。
墨线仍会继续迭代，但它已经能够完成一条完整的长篇创作链路：设定故事边界，分阶段规划，逐章写作，管理上下文，按需重写，衍生续作，最后导出和迁移作品。
八、把 WorkBuddy 的"工作现场"拼在一起
聊了这么多规划、测试和工程细节，最后把 WorkBuddy 这次的关键工作现场拼在一起来看：
- 起点是 Plan 模式------它先核对工作区环境（Node.js、npm、Playwright 是否就绪），再把整个项目拆成 P1--P9 阶段，每个阶段都列好"做什么"和"预计产出"，是后续所有代码动作的"母版"。
- 中间是代码与测试循环------WorkBuddy 跨文件读懂现有实现，写完后立刻自跑回归，把错误原文贴回对话，决定继续修还是先和我对齐。
- 收尾是连接器------左下角的「专家·技能·连接器」面板一打开，CNB、福帮手、金山文档、企查查、网易邮箱、GitHub、Notion 等几十个常用平台都内置可用。我这次用红线高亮的 CNB 让 WorkBuddy 直接把仓库、PR、Issue 串起来，免掉了开发与上线之间来回切换工具的麻烦。
如果把上面三件事串起来，WorkBuddy 在我的开发循环里其实扮演了四个角色：
- 方案对齐：Plan 模式先出结构、阶段表和验收点，避免"一句话大而空"的指令。
- 代码落地：跨文件读懂现有实现，把新逻辑写进正确的位置，我看着确认。
- 测试与修复：自己跑测试、读报错，再决定继续修还是先和我对齐方案。
- 连接与发布：用内置连接器直连 CNB，从对话窗口完成"代码 → 仓库 → 自动构建"。
最后再放一次项目地址，欢迎体验和交流：