NovelStudio（小说连载工作台）产品系统

长文和连载小说写作有一个用 AI 很难绕过的问题:模型的上下文有限,而一本书动辄几十万字。直接让模型「一次生成整本书」的结果通常是——写到第十章人设已经漂移,前面埋的伏笔没人回收,时间线自相矛盾。市面上多数 AI 写作工具面向的是碎片化短文和营销文案,并不解决长周期写作的连续性问题。

NovelStudio 就是为这个场景立项的:把长文写作拆成可重复、可检查、可持续维护的工程流程。核心思路是「项目目录驱动」——世界观、人物设定、关系表、章节大纲、伏笔清单、时间线全部以 Markdown 文件沉淀在项目目录里,每一次生成都从这些文件里按需组装上下文,每写完一章再由模型把新增伏笔和时间线事件回写进去。用户是网文作者、连载写作者和需要产出长篇结构化内容的创作者。项目由我独立开发,已可本地运行使用。

产品由「本地网页工作台 + CLI 执行内核」两层组成,网页是日常主入口,CLI 是底层引擎,共八个模块:

1)项目初始化:一键创建长文项目,自动生成标准目录骨架与写作模板、总纲、章节大纲、世界观、人物设定等基础文件。
2)章节管理:章节列表展示编号、字数与两行预览,章节状态(未开始 / 草稿中 / 已摘要 / 已检查)由文件存在情况自动推断,无需人工维护。
3)生成与续写:按当前章节、所选模型、附加要求与投喂清单组装 prompt 调用模型,结果写回章节文件;续写模式会要求模型在已有草稿上推进而非重写。
4)结构化摘要:模型返回本章摘要、全局压缩摘要、新增伏笔、已兑现伏笔、时间线事件五个字段,并自动追加写入 memory 文件,追加语义不覆盖人工内容。
5)一致性检查:结合世界观、人设与禁忌材料生成检查报告,渲染为 Markdown 存档。
6)投喂清单:13 项上下文材料可逐项勾选控制是否参与本次模型调用,勾选状态按项目持久化;配套材料抽屉可直接读写原文件。
7)多模型切换:UI 注册四个模型目标,支持深浅主题、运行浮层与快捷键操作。
8)CLI 与集成:提供 init / plan / generate / continue / summarize / check 六条命令,并已接入桌面总控,通过健康检查接口判断服务状态。

独立开发项目,产品设计、架构、前后端实现与提示词工程全部由我一人完成,代码开源在 GitHub(Whos12Jackson/NovelStudio)。

技术栈与架构:Node.js 后端 + 原生 HTML/CSS/JS 前端,采用「网页工作台 + CLI 执行内核 + 项目目录驱动」三层结构。网页层不重复实现任何生成逻辑,只做读目录、提供本地 HTTP API、把操作转发给 CLI 三件事,保证同一套业务逻辑在图形界面和命令行下行为一致。

实现亮点:① 不用数据库,用文件系统做真相源——章节、摘要、伏笔、时间线全部是人类可读可手改的 Markdown,作者随时能脱离工具直接编辑,避免数据被锁死在工具里;② 投喂开关是端到端真实生效的,前端勾选经接口编码成参数传给 CLI,上下文加载层把未勾选材料置空,拼接层只拼非空材料,不是前端隐藏而是后端真的不喂,既可控成本也便于排查模型为什么这么写;③ 长程一致性靠状态回灌——写完一章由模型抽出新增伏笔与时间线事件追加回 memory,下一章再作为上下文喂回去,用有限上下文撑住长篇连续性;④ 模型调用统一抽象成目标注册表,四个目标可随时切换并带重试,密钥只存本机 .env,仓库只提交无密钥模板。

踩过的坑:上下文预算与生成质量的取舍(靠摘要压缩 + 材料分项开关解决)、结构化 JSON 返回不稳定需要容错、Windows 环境下中文写入链路存在编码污染风险(网页文案改用 HTML 实体与转义规避)。