【NovWr，开源更新】我放弃全量总结，而是加了个渐进式披露的agent
- 内容介绍
- 文章标签
- 相关推荐
佬友们好，我又回来填坑了
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
NovWr是一个面向长篇小说创作 / 续写的 AI 工具，它的特点是：代码负责组装上下文，LLM 负责维护设定和生成，人负责判断和取舍。
这是全新的主页编辑区：
studio主页1920×1026 267 KB
公开仓库地址：
GitHub - Hurricane0698/novelwriter
通过在 GitHub 上创建帐户来为 Hurricane0698/novelwriter 开发做出贡献。
部署方式：Docker 自部署
- 适合：长篇小说、同人续写、世界观和角色关系较重的创作
如果佬友们觉得项目有用，还请点点star，感谢支持
更新摘要
这次 NovWr 算是做了一波真正意义上的大更新。
Novel Copilot
在上篇文章里，我在最后表达了自己想做agent的想法
我发现现在很多长文本 AI 工具，还是很迷信一件事：超长上下文 + 大模型全量总结。好像只要模型上下文够大，把整本书塞进去，它就能顺便把设定、人物关系、剧情阶段都替你整理明白。
但我自己不相信这条路—我做过 AI 自动化，就知道这事没那么美。首先是单次总结注意力衰减，对长上下文召回率很低，而如果为了解决它引入规划、执行、审计，甚至更复杂一点的 pipeline，听起来都很好，像是什么都能包办，但真落地的时候，问题会一个接一个出现：
自动规划剧情当然听着爽，可去 AI 味怎么办呢？
全量总结也不是不能做，但为了让它总结好，到底要花多少时间和多少 token 去调呢？
就算这些都被解决了，它最后写出来的东西，真的是你想要的吗？真的是读者想看的吗？
我现在越来越觉得，好的 AI 写作工具，不应该把模型当成万能许愿机，它应该把那些繁琐、重复、消耗注意力的活接过去，同时把最关键的判断权留在人手里。
所以我用了 Copilot 这个名字。
副驾驶，不是驾驶员。
它帮你做的是查设定、翻原文、找证据，为你提供更新建议；决定这段到底算不算正式设定的决策权始终在人这里。
说到底，文学和小说终究是给人看的东西。
所以我一直想做的，不是一个万能写作机，而是一个人在 AI 时代真的能长期拿来用的写作工具。
———
灵感的发生地
在构思小说助手的设计时，我思考的是人平时到底是怎么查设定的？你不会真的把一本几十万字的小说从头到尾重读一遍。正常情况都是先回忆一下大概在哪，翻目录、翻设定、翻相关章节，最后再去精读最关键的那几段。
NovWr 的世界模型，本来就是在解决前半段——设定是怎么样的？但麻烦的其实一直是后半段：维护它。
AI 每续写完一章，里面都可能冒出新的变化：
有新角色、新地点、新势力、某个实体状态变了，某条关系从合作变成对立了，某处设定又冲突了
这些如果不及时处理，下次生成的时候，设定就会开始出现漂移。
而LLM的自回归属性往往会加剧这个正反馈，让设定越来越飘
但如果每次都靠人手动翻书、找依据、核对上下文，那也确实太累了。
所以我后来想明白了一件事：AI 不是不能做这部分，而是不能按“全能自动维护器”的思路去做。
我最后把它做成了一个只读 Agent，而且故意只给了它三个工具：
- Find：先找“这个东西大概在哪些地方出现过”
- Open：打开它觉得最可能有用的内容包
- Read：只精读最相关的段落，拿精确信息
整个方案背后，没有很重的向量库，也没有复杂的 RAG 系统。
核心就是文本、世界模型，再加上这三个工具。
这是我能想到的极简抽象。
它旧像是一个人在翻书：先缩小范围，再定位，再细看。
这算是从渐进式披露得到的灵感————不是无脑把所有内容一股脑塞给模型，而是先把原文整理成一份份内容包，让它自己判断哪些可能相关，再一层层往下。
小说助手怎么用？
假如 AI 刚续写完一章，里面让“虚步”从“初步掌握”变成了“可实战使用”，同时又冒出来一个新人物“赵槐”。
这时候 Copilot 不会直接改数据库，也不会上来就重写整份设定。
它会先：
- Find：去找“虚步”之前在哪些章节出现过，比如第 12、45、80 章
- Open：优先打开最可能和能力变化有关的内容包
- Read：精读最关键的段落，判断这次变化到底是临时发挥、误写，还是真的应该进入世界模型
最后它也不会直接拍板，而是只输出结构化 JSON。
后端再把这些整理成建议卡给你看，比如：
- 这个实体的属性可能该更新了
- 这段关系可能已经变了
- 这个新角色可能还没录入
- 这个设定和旧内容之间可能有冲突
然后你自己一条条看，同意就采纳，不同意就忽略。
copilot提建议卡1920×1035 243 KB
———
copilot的局限
架构简化了这么多，不损失有效性是不可能的。我不想回避这些问题。
- 信息筛选会有所损失：渐进式披露意味着 Agent 会跳过它认为不相关的内容包，偶尔会漏掉隐含关联，不过它是可以优化的
- 时间线冲突依赖模型判断：第 10 章还是朋友，第 50 章已经反目，当前哪条设定有效，需要推理，这就要求大模型能力足够强
- 它不是完全自动的维护系统：它降低的是维护摩擦，不是替你消灭维护这件事。工作量降到10%但维护仍然会存在。
但这也是我愿意接受的取舍：我想要速度、成本、可控性和可审计性。
重构前端为双工作区
我觉得因为长篇创作这件事，正文写作和设定治理是分不开的。
你写着写着就会碰到这些情况：
这个角色是不是写跑了？
这段关系是不是已经变了？
刚写出来的新地点和新术语是不是该进世界模型了？
这些都不是写完再说的事，而是写作过程中就会不断打断你的事。
当初设计初版时，我没有考虑过这一点
所以NovWr 之前的 UI，在这点上其实是很割裂和摩擦的：
小说详情页、写作工作台、世界模型编辑器来回切换。
它最大的问题不是切换有点麻烦，而是如果切过去改个设定，再回来，摩擦感很强。
位置丢了，对话丢了，有时候连正在编辑的内容都要重新找。久而久之，人就会下意识地想：算了，回头再维护。
所以我这次干脆把这三块合并成了一个统一的小说工作区：NovelShell。
底下是两个主UI：
- Studio：主工作台，负责章节编辑、续写设置、结果审阅，也能顺手看实体和体系并做轻量编辑
- Atlas：世界模型治理区，负责体系编辑、实体详情、关系管理，还有 Copilot 建议审核
重构后我自己试试，确实觉得舒服了不少。
atlas地图集实体对话展示
1920×1040 136 KB
对大家来说，最直接的收益不只是页面更漂亮了，而是：
位置不丢
从 Studio 跳到 Atlas，再返回时，不是回首页，而是回到你刚才那个精确位置：当前编辑阶段、选中的章节、打开的实体面板、注入摘要的展开状态，都会被恢复。
对话不丢
你在 Studio 和 AI 聊到一半，切去 Atlas 改设定，回来时 Copilot 对话还在。
Agent 会话按小说 ID 绑定，并识别界面实体、体系、全书功能，自动显示相应选项卡——只要还在同一本小说里，上下文就不断线。
内容保存
如果你正在改章节内容时触发跳转，系统会先保存，再导航。
实现细节
我把所有导航状态都做成了 URL-first：
- 刷新页面能恢复
- 复制链接能直达
- 浏览器前进 / 后退能正常工作
- Studio / Atlas 共用同一套路由状态解析逻辑
也就是说，这不是一个换皮重构，而是一次工作流层面的统一。
写作和治理是交替的，不是分离的。
如果切换成本高到让用户放弃维护世界模型，那世界模型的数据结构再漂亮，最后也只是摆设。
这次增强的几个细节
除了双工作区和 Copilot，这一版我还补了几块我自己很在意的能力 / 基建：
一个是风格漂移检测。
这个不是让 AI 再来评审 AI，而是用纯文本统计去看行文密度和风格变化。
如果续写结果已经明显开始不像这本书了，系统会直接提醒。
一个是代码架构的优化
让ai抽象出了很多可复用的逻辑，做了很多代码原子化
另一个是围绕 Copilot 的一些工程兜底。
这个想法看起来好像就三个工具，想法简单，实际上脏活特别多：
- 多对话并存时怎么做状态隔离
- 后台运行的结果怎么回收
- 并发场景下建议卡怎么生成
- 人审流程和自动流程之间边界怎么划
这些东西不太适合拿来当宣传词，但它们决定了这东西到底是不是真能用。
另外，我还顺手做了一些 i18n / 多语言支持的底层准备。
再加上一批导航恢复、编辑保存兜底、状态一致性之类的小修小补。
这些东西像是不显眼的细节，但我觉得对一个设计理念是人人可用的创作工具来说很重要。
为什么我最后决定关停托管版，转向全面开源
上次发帖之后，NovWr 拿到了 200+ 注册。看到注册涨起来那几天，我其实挺兴奋的，真的以为自己可能找对了一条路。
但数据很快就冷下来了：大多数用户只是进来试几次，看看效果，然后就走了。最近连续几天没有任何人使用，我最后还是把托管版关掉了。
对于这个结果刚开始我是很失落的。项目前后做了 3 个月，中间反复重构、反复推翻，也认真想过商业化。直到决定把托管版关掉那一刻，心里会有一种“是不是我从一开始就想偏了”的感觉。
我和ai去探讨，它很好的安慰了我：问题不在于这个方向完全没价值，而在于另我的起项思路和商业化顺序相反，同时我也高估了设定维护作为主痛点的普遍性。
世界模型一直是我最核心的设计。这次做 Copilot，也是为了减少设定维护这件事的摩擦。
但问题在于：
- 愿意写长篇的人，不愿意维护世界模型这样一个陌生理念
- 设定维护，也不会是他们真正的痛点。
后来我在ai建议下去龙空看了一圈，我发现大家讨论最多的是：
- 章纲怎么搭
- 节奏怎么控
- 开头怎么起
- 剧情卡住了怎么办
几乎没人高频讨论“设定集维护”本身。再看竞品，卖点往往也是“实时自动跟踪设定变化”，而不是让用户主动打开一个编辑器手动治理。
这说明我做的很可能不是一个假问题，但它更像一个中后期、偏重度用户、偏工作流优化的问题，而不是一个新用户一上手就会强烈感受到、并且愿意立刻为之付费的问题。
所以我决定与其硬撑着维持一个没人用的 hosted 版本，不如直接开源自部署，它更适合走开源 + 社区共创
有趣的是：这或许才符合人人可用的创作工具发展
对我来说，这不是“项目完了”，反而更像是第一次把商业化方向看清了一点：先找对痛点，再谈分发和商业化；先把真正会长期用它的人找到，再谈增长。
感谢您看到了这里，如果觉得项目有帮助，还请给个star，您的支持是我继续开发的最大动力！GitHub - Hurricane0698/novelwriter · GitHub
致谢
这个项目能更新，离不开很多人的帮助：
感谢 Any Router 公益
感谢 xychatai、xiaviercode提供的稳定中转
感谢 Trellis 开发团队
感谢上个帖子Linuxdo 社区的热心佬友——Star、点赞、反馈，每一条我都看了
--【壹】--：
谢谢佬友
--【贰】--：
我靠，这我真得要试用下，需要的就是设定管理大于写作本身的工具，之前试用过的ai写作工具都不太符合我的工作流
--【叁】--：
把graph说成世界模型…不是一回事吧…
--【肆】--：
太强了，支持！
--【伍】--：
佬友太强啦！
--【陆】--：
太强了，大佬
--【柒】--：
太厉害了 马克
--【捌】--：
谢谢认可，也欢迎佬友提出反馈！
--【玖】--：
不不，世界模型是通过训练多模态让AI理解、模拟并预测物理世界的运作规律的模型，你所说的实体，以及实体之间的关系，就是 graph。您如果能搞出世界模型，那恭喜您，至少估值 10 亿刀
--【拾】--：
原来佬友就是砍掉了80%的作者，怪不得头像看起来眼熟。
我也专注于AI写作这块挺久了，但是我的项目前后推翻了3遍，一直没有达到我认为可以拿出来给大家试用的程度。看到越来越多的开源项目，从中也受到不少启发。相比于看代码和提示词，我还是更喜欢看一些讲建设思路的文章，从而和自己的思路进行比较。有趣的是，渐进式披露也是我在我的项目v3版里引入的，算是和佬不谋而合了，虽然它现在还是达不到我预期的效果，可能是应了佬友的这句话“但这也是我愿意接受的取舍：我想要速度、成本、可控性和可审计性。”。
在停止v3版本继续开发后，我开始在反思一个问题，会不会那些已经取得了商业成功的人们，他们使用的其实是AI的下限呢？
--【拾壹】--：
是的，我讲思路就是想启发更多的人。渐进式披露那里真有缘，佬友的项目开源吗？如果可以的话我点个star（顺便学习一下）。我的效果确实也还有差距，不过反正工程上就是trade-off嘛，坚持信念继续走就好。
商业成功那里，我觉得是个很有意思的想法，我认为不是二元对立的，有可能发挥了ai80%能力的成功（比如claude code），也有发挥了40%的成功（比如各种api套壳），是个连续谱。但我认为不会有人真的发挥完了ai能力上限，不过虽然短期那些只发挥了40%的取得成功，但如果不继续改进长期看还是会失败呢（又得扯到成功和失败的定义了哈哈）
--【拾贰】--：
V1版佬友想法和我一样诶。我也在ai建议下做了溯源系统，发现成本高效果一般，所以我也放弃这条路，自己从0思考怎么写书。在过程中，我发现去类比人类写书过程很有效的：一个作家也不会事无巨细记住每个角色状态，世界事件，尤其是对超长篇网文来说，更像是保留对世界的一个建模抽象，以及高层次的大纲，有需要的时候翻书看。不做大纲是因为，我觉得这种脑暴通用型ai解决的很好了，直接去找sota模型规划大纲。我没必要为了功能更多去实现
我认为在vibecoding时代，理解项目是什么样还是很重要的，不然就像老板被员工架空了。
反正我自己偶尔会去抓关键代码和随机扫描看，不懂的就问ai，过程中就发现ai写东西还是很混乱，清东西容易清不干净，这里留一点兜底那里留一点旧实现，细节执行也不到位。
这些东西如果不处理，下次ai继续写也很可能学到这种风格，代码就很可能坏了。
我也通过这种方式保留了对技术细节的一定掌握，从而保证ai实现不会出现表面实现背地是另一套的状态（这也是踩坑后才学到的，ai说实现了不一定是真的实现，很可能给你用个mock糊弄了，所以很多时候我都不相信，自己去看去问，发现了许多优化点）
有些时候，我也不急着去实现新功能，而是慢下来想这个功能是否真的必要，这个方向有什么问题，less is more吧
佬友想法很有创新性，我学到了很多，也希望自己的一点思考能带给你一些启发吧
--【拾叁】--：
现在还没有开源，因为一直没有打磨成我想要的样子，这中间也经历过几次思想上的重构。可以和佬友做个交流。
v1版本，我想的是给自己打造一个写小说的玩意，当时想的也比较简单，两个大的流程链，一个是创意创作阶段，就是由AI负责把一句话创意细化为结构化的创意，分卷分章分场景。另一个就是内容创作阶段，由AI根据结构化的创意进行内容创作。
v1版本死在了人物状态链和世界状态链功能上了，当时想的是人物和世界都是不断演化的，我把这些演化过程和章节建立可追述的版本链，从而来保证世界和角色的前后一致。但是章节重写、乃至大纲重新，会对版本链造成毁灭性的打击，我一直没有想好解决办法。所以v1版本就弃了。
v2版本，我受L站的一位熊猫头像大佬的影响，决定搞一个技能插槽的玩意。但是我的想法是把不同的写作风格、题材、标签做成不同的技能，然后根据创作需要自由组合技能。
v2版本死在了我到后面根本就分不清楚分类了，比如三幕式、五幕式是结构的技能，黄金开篇法则又是开篇的技能，五维质量检查又是审核的技能，更甚至我连题材和标签都开始渐渐分不清了，“历史”是题材吧，那“穿越”也是题材吧，那“热血”算是标签吧，那“种地”呢？“种地”是题材还是标签呢？如何写一个“五幕式的黄金开篇的穿越历史去种地的热血文”呢。。。直接把我给难住了，所以v2版本最终死在了体系划分不清上。
v3版本，是从skill大兴之后，我突然想到的灵感。既然skill可以渐进式披露，那么我是否可以把v1版本的信息管理和v2版本的技能管理，全部都做成类似skill的形式，由AI来判断是否需要加载呢。当时觉得这个想法还蛮有创造性的，但是实验下来发现，AI很傻X，我自己都想不清楚的东西，交给AI来搞，结果注定还是一团糟糕，AI产出的东西比我预期的还要混乱，我不知道是自己的组织能力出了问题，还是基座模型本身不够聪明。
目前正在尝试v4版本，也就是多Agent版本。虽然从v1版本开始，就是多Agent版本了，但是它是哪种基于固定流程的多Agent版本，也就是说虽然我有10几个Agent，但是每个的权重是一样的，只是分别负责不同的工序而已，本质上还是流水线生产。现在在尝试的v4版本，更像是龙虾那种subagent，让AI自己去决定流水线、自己却决定工序、自己去决定如何组织分工、自己去设计和启动子agent。从目前的进展来看，大概率还是失败的，哈哈哈哈。
从这一路走过来，我最大的感受就是“AI完全没有创造力”，如果是人自己都没想清楚的问题，绝对不能指望AI能帮你解决。可以把AI看作是计算器，首先自己懂得加减乘除，才能用计算器帮你计算来提高效率，如果是自己都不会解的数学题，给个银河计算机当计算器都没用
哦，对了，我的所有版本里还有一个缺陷，就是我从来没有考虑过市场化这个问题，我没有去抓市场数据，做读者画像、故事题材分析等模块，单纯还是建立在自愈自己的基础上。这大概也是为啥我搞了几个版本了，还是觉得AI写的故事达不到我的预期，很有可能是我尝试的是AI的上限，而那些批量化的生产者（已经产生利润的）他们尝试的是AI的下限，这也是两条不同的道路。
--【拾肆】--：
唔……现在的方向看上去好像和我的需求不是太相关，但仔细看好像又能对上我的需求……
--【拾伍】--：
太强了大佬
--【拾陆】--：
佬友可以试试
--【拾柒】--：
不太确定佬友这里说的世界模型具体指的是什么。在 novwr 里，我们说的世界模型指的是对小说世界状态的结构化抽象。我认为一个世界本身就是由规则、实体，以及实体之间的关系构成的，因此世界模型也是据此实现的。
另外，novwr 也不只是 graph，graph 只是其中一种表达和组织方式。佬友如果有兴趣，可以看代码或者直接试用一下，会更直观。
--【拾捌】--：
太强了佬，有空的时候我会试试能不能用这个项目实现我小说的点子的
--【拾玖】--：
先赞后看
佬友们好，我又回来填坑了
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
NovWr是一个面向长篇小说创作 / 续写的 AI 工具，它的特点是：代码负责组装上下文，LLM 负责维护设定和生成，人负责判断和取舍。
这是全新的主页编辑区：
studio主页1920×1026 267 KB
公开仓库地址：
GitHub - Hurricane0698/novelwriter
通过在 GitHub 上创建帐户来为 Hurricane0698/novelwriter 开发做出贡献。
部署方式：Docker 自部署
- 适合：长篇小说、同人续写、世界观和角色关系较重的创作
如果佬友们觉得项目有用，还请点点star，感谢支持
更新摘要
这次 NovWr 算是做了一波真正意义上的大更新。
Novel Copilot
在上篇文章里，我在最后表达了自己想做agent的想法
我发现现在很多长文本 AI 工具，还是很迷信一件事：超长上下文 + 大模型全量总结。好像只要模型上下文够大，把整本书塞进去，它就能顺便把设定、人物关系、剧情阶段都替你整理明白。
但我自己不相信这条路—我做过 AI 自动化，就知道这事没那么美。首先是单次总结注意力衰减，对长上下文召回率很低，而如果为了解决它引入规划、执行、审计，甚至更复杂一点的 pipeline，听起来都很好，像是什么都能包办，但真落地的时候，问题会一个接一个出现：
自动规划剧情当然听着爽，可去 AI 味怎么办呢？
全量总结也不是不能做，但为了让它总结好，到底要花多少时间和多少 token 去调呢？
就算这些都被解决了，它最后写出来的东西，真的是你想要的吗？真的是读者想看的吗？
我现在越来越觉得，好的 AI 写作工具，不应该把模型当成万能许愿机，它应该把那些繁琐、重复、消耗注意力的活接过去，同时把最关键的判断权留在人手里。
所以我用了 Copilot 这个名字。
副驾驶，不是驾驶员。
它帮你做的是查设定、翻原文、找证据，为你提供更新建议；决定这段到底算不算正式设定的决策权始终在人这里。
说到底，文学和小说终究是给人看的东西。
所以我一直想做的，不是一个万能写作机，而是一个人在 AI 时代真的能长期拿来用的写作工具。
———
灵感的发生地
在构思小说助手的设计时，我思考的是人平时到底是怎么查设定的？你不会真的把一本几十万字的小说从头到尾重读一遍。正常情况都是先回忆一下大概在哪，翻目录、翻设定、翻相关章节，最后再去精读最关键的那几段。
NovWr 的世界模型，本来就是在解决前半段——设定是怎么样的？但麻烦的其实一直是后半段：维护它。
AI 每续写完一章，里面都可能冒出新的变化：
有新角色、新地点、新势力、某个实体状态变了，某条关系从合作变成对立了，某处设定又冲突了
这些如果不及时处理，下次生成的时候，设定就会开始出现漂移。
而LLM的自回归属性往往会加剧这个正反馈，让设定越来越飘
但如果每次都靠人手动翻书、找依据、核对上下文，那也确实太累了。
所以我后来想明白了一件事：AI 不是不能做这部分，而是不能按“全能自动维护器”的思路去做。
我最后把它做成了一个只读 Agent，而且故意只给了它三个工具：
- Find：先找“这个东西大概在哪些地方出现过”
- Open：打开它觉得最可能有用的内容包
- Read：只精读最相关的段落，拿精确信息
整个方案背后，没有很重的向量库，也没有复杂的 RAG 系统。
核心就是文本、世界模型，再加上这三个工具。
这是我能想到的极简抽象。
它旧像是一个人在翻书：先缩小范围，再定位，再细看。
这算是从渐进式披露得到的灵感————不是无脑把所有内容一股脑塞给模型，而是先把原文整理成一份份内容包，让它自己判断哪些可能相关，再一层层往下。
小说助手怎么用？
假如 AI 刚续写完一章，里面让“虚步”从“初步掌握”变成了“可实战使用”，同时又冒出来一个新人物“赵槐”。
这时候 Copilot 不会直接改数据库，也不会上来就重写整份设定。
它会先：
- Find：去找“虚步”之前在哪些章节出现过，比如第 12、45、80 章
- Open：优先打开最可能和能力变化有关的内容包
- Read：精读最关键的段落，判断这次变化到底是临时发挥、误写，还是真的应该进入世界模型
最后它也不会直接拍板，而是只输出结构化 JSON。
后端再把这些整理成建议卡给你看，比如：
- 这个实体的属性可能该更新了
- 这段关系可能已经变了
- 这个新角色可能还没录入
- 这个设定和旧内容之间可能有冲突
然后你自己一条条看，同意就采纳，不同意就忽略。
copilot提建议卡1920×1035 243 KB
———
copilot的局限
架构简化了这么多，不损失有效性是不可能的。我不想回避这些问题。
- 信息筛选会有所损失：渐进式披露意味着 Agent 会跳过它认为不相关的内容包，偶尔会漏掉隐含关联，不过它是可以优化的
- 时间线冲突依赖模型判断：第 10 章还是朋友，第 50 章已经反目，当前哪条设定有效，需要推理，这就要求大模型能力足够强
- 它不是完全自动的维护系统：它降低的是维护摩擦，不是替你消灭维护这件事。工作量降到10%但维护仍然会存在。
但这也是我愿意接受的取舍：我想要速度、成本、可控性和可审计性。
重构前端为双工作区
我觉得因为长篇创作这件事，正文写作和设定治理是分不开的。
你写着写着就会碰到这些情况：
这个角色是不是写跑了？
这段关系是不是已经变了？
刚写出来的新地点和新术语是不是该进世界模型了？
这些都不是写完再说的事，而是写作过程中就会不断打断你的事。
当初设计初版时，我没有考虑过这一点
所以NovWr 之前的 UI，在这点上其实是很割裂和摩擦的：
小说详情页、写作工作台、世界模型编辑器来回切换。
它最大的问题不是切换有点麻烦，而是如果切过去改个设定，再回来，摩擦感很强。
位置丢了，对话丢了，有时候连正在编辑的内容都要重新找。久而久之，人就会下意识地想：算了，回头再维护。
所以我这次干脆把这三块合并成了一个统一的小说工作区：NovelShell。
底下是两个主UI：
- Studio：主工作台，负责章节编辑、续写设置、结果审阅，也能顺手看实体和体系并做轻量编辑
- Atlas：世界模型治理区，负责体系编辑、实体详情、关系管理，还有 Copilot 建议审核
重构后我自己试试，确实觉得舒服了不少。
atlas地图集实体对话展示
1920×1040 136 KB
对大家来说，最直接的收益不只是页面更漂亮了，而是：
位置不丢
从 Studio 跳到 Atlas，再返回时，不是回首页，而是回到你刚才那个精确位置：当前编辑阶段、选中的章节、打开的实体面板、注入摘要的展开状态，都会被恢复。
对话不丢
你在 Studio 和 AI 聊到一半，切去 Atlas 改设定，回来时 Copilot 对话还在。
Agent 会话按小说 ID 绑定，并识别界面实体、体系、全书功能，自动显示相应选项卡——只要还在同一本小说里，上下文就不断线。
内容保存
如果你正在改章节内容时触发跳转，系统会先保存，再导航。
实现细节
我把所有导航状态都做成了 URL-first：
- 刷新页面能恢复
- 复制链接能直达
- 浏览器前进 / 后退能正常工作
- Studio / Atlas 共用同一套路由状态解析逻辑
也就是说，这不是一个换皮重构，而是一次工作流层面的统一。
写作和治理是交替的，不是分离的。
如果切换成本高到让用户放弃维护世界模型，那世界模型的数据结构再漂亮，最后也只是摆设。
这次增强的几个细节
除了双工作区和 Copilot，这一版我还补了几块我自己很在意的能力 / 基建：
一个是风格漂移检测。
这个不是让 AI 再来评审 AI，而是用纯文本统计去看行文密度和风格变化。
如果续写结果已经明显开始不像这本书了，系统会直接提醒。
一个是代码架构的优化
让ai抽象出了很多可复用的逻辑，做了很多代码原子化
另一个是围绕 Copilot 的一些工程兜底。
这个想法看起来好像就三个工具，想法简单，实际上脏活特别多：
- 多对话并存时怎么做状态隔离
- 后台运行的结果怎么回收
- 并发场景下建议卡怎么生成
- 人审流程和自动流程之间边界怎么划
这些东西不太适合拿来当宣传词，但它们决定了这东西到底是不是真能用。
另外，我还顺手做了一些 i18n / 多语言支持的底层准备。
再加上一批导航恢复、编辑保存兜底、状态一致性之类的小修小补。
这些东西像是不显眼的细节，但我觉得对一个设计理念是人人可用的创作工具来说很重要。
为什么我最后决定关停托管版，转向全面开源
上次发帖之后，NovWr 拿到了 200+ 注册。看到注册涨起来那几天，我其实挺兴奋的，真的以为自己可能找对了一条路。
但数据很快就冷下来了：大多数用户只是进来试几次，看看效果，然后就走了。最近连续几天没有任何人使用，我最后还是把托管版关掉了。
对于这个结果刚开始我是很失落的。项目前后做了 3 个月，中间反复重构、反复推翻，也认真想过商业化。直到决定把托管版关掉那一刻，心里会有一种“是不是我从一开始就想偏了”的感觉。
我和ai去探讨，它很好的安慰了我：问题不在于这个方向完全没价值，而在于另我的起项思路和商业化顺序相反，同时我也高估了设定维护作为主痛点的普遍性。
世界模型一直是我最核心的设计。这次做 Copilot，也是为了减少设定维护这件事的摩擦。
但问题在于：
- 愿意写长篇的人，不愿意维护世界模型这样一个陌生理念
- 设定维护，也不会是他们真正的痛点。
后来我在ai建议下去龙空看了一圈，我发现大家讨论最多的是：
- 章纲怎么搭
- 节奏怎么控
- 开头怎么起
- 剧情卡住了怎么办
几乎没人高频讨论“设定集维护”本身。再看竞品，卖点往往也是“实时自动跟踪设定变化”，而不是让用户主动打开一个编辑器手动治理。
这说明我做的很可能不是一个假问题，但它更像一个中后期、偏重度用户、偏工作流优化的问题，而不是一个新用户一上手就会强烈感受到、并且愿意立刻为之付费的问题。
所以我决定与其硬撑着维持一个没人用的 hosted 版本，不如直接开源自部署，它更适合走开源 + 社区共创
有趣的是：这或许才符合人人可用的创作工具发展
对我来说，这不是“项目完了”，反而更像是第一次把商业化方向看清了一点：先找对痛点，再谈分发和商业化；先把真正会长期用它的人找到，再谈增长。
感谢您看到了这里，如果觉得项目有帮助，还请给个star，您的支持是我继续开发的最大动力！GitHub - Hurricane0698/novelwriter · GitHub
致谢
这个项目能更新，离不开很多人的帮助：
感谢 Any Router 公益
感谢 xychatai、xiaviercode提供的稳定中转
感谢 Trellis 开发团队
感谢上个帖子Linuxdo 社区的热心佬友——Star、点赞、反馈，每一条我都看了
--【壹】--：
谢谢佬友
--【贰】--：
我靠，这我真得要试用下，需要的就是设定管理大于写作本身的工具，之前试用过的ai写作工具都不太符合我的工作流
--【叁】--：
把graph说成世界模型…不是一回事吧…
--【肆】--：
太强了，支持！
--【伍】--：
佬友太强啦！
--【陆】--：
太强了，大佬
--【柒】--：
太厉害了 马克
--【捌】--：
谢谢认可，也欢迎佬友提出反馈！
--【玖】--：
不不，世界模型是通过训练多模态让AI理解、模拟并预测物理世界的运作规律的模型，你所说的实体，以及实体之间的关系，就是 graph。您如果能搞出世界模型，那恭喜您，至少估值 10 亿刀
--【拾】--：
原来佬友就是砍掉了80%的作者，怪不得头像看起来眼熟。
我也专注于AI写作这块挺久了，但是我的项目前后推翻了3遍，一直没有达到我认为可以拿出来给大家试用的程度。看到越来越多的开源项目，从中也受到不少启发。相比于看代码和提示词，我还是更喜欢看一些讲建设思路的文章，从而和自己的思路进行比较。有趣的是，渐进式披露也是我在我的项目v3版里引入的，算是和佬不谋而合了，虽然它现在还是达不到我预期的效果，可能是应了佬友的这句话“但这也是我愿意接受的取舍：我想要速度、成本、可控性和可审计性。”。
在停止v3版本继续开发后，我开始在反思一个问题，会不会那些已经取得了商业成功的人们，他们使用的其实是AI的下限呢？
--【拾壹】--：
是的，我讲思路就是想启发更多的人。渐进式披露那里真有缘，佬友的项目开源吗？如果可以的话我点个star（顺便学习一下）。我的效果确实也还有差距，不过反正工程上就是trade-off嘛，坚持信念继续走就好。
商业成功那里，我觉得是个很有意思的想法，我认为不是二元对立的，有可能发挥了ai80%能力的成功（比如claude code），也有发挥了40%的成功（比如各种api套壳），是个连续谱。但我认为不会有人真的发挥完了ai能力上限，不过虽然短期那些只发挥了40%的取得成功，但如果不继续改进长期看还是会失败呢（又得扯到成功和失败的定义了哈哈）
--【拾贰】--：
V1版佬友想法和我一样诶。我也在ai建议下做了溯源系统，发现成本高效果一般，所以我也放弃这条路，自己从0思考怎么写书。在过程中，我发现去类比人类写书过程很有效的：一个作家也不会事无巨细记住每个角色状态，世界事件，尤其是对超长篇网文来说，更像是保留对世界的一个建模抽象，以及高层次的大纲，有需要的时候翻书看。不做大纲是因为，我觉得这种脑暴通用型ai解决的很好了，直接去找sota模型规划大纲。我没必要为了功能更多去实现
我认为在vibecoding时代，理解项目是什么样还是很重要的，不然就像老板被员工架空了。
反正我自己偶尔会去抓关键代码和随机扫描看，不懂的就问ai，过程中就发现ai写东西还是很混乱，清东西容易清不干净，这里留一点兜底那里留一点旧实现，细节执行也不到位。
这些东西如果不处理，下次ai继续写也很可能学到这种风格，代码就很可能坏了。
我也通过这种方式保留了对技术细节的一定掌握，从而保证ai实现不会出现表面实现背地是另一套的状态（这也是踩坑后才学到的，ai说实现了不一定是真的实现，很可能给你用个mock糊弄了，所以很多时候我都不相信，自己去看去问，发现了许多优化点）
有些时候，我也不急着去实现新功能，而是慢下来想这个功能是否真的必要，这个方向有什么问题，less is more吧
佬友想法很有创新性，我学到了很多，也希望自己的一点思考能带给你一些启发吧
--【拾叁】--：
现在还没有开源，因为一直没有打磨成我想要的样子，这中间也经历过几次思想上的重构。可以和佬友做个交流。
v1版本，我想的是给自己打造一个写小说的玩意，当时想的也比较简单，两个大的流程链，一个是创意创作阶段，就是由AI负责把一句话创意细化为结构化的创意，分卷分章分场景。另一个就是内容创作阶段，由AI根据结构化的创意进行内容创作。
v1版本死在了人物状态链和世界状态链功能上了，当时想的是人物和世界都是不断演化的，我把这些演化过程和章节建立可追述的版本链，从而来保证世界和角色的前后一致。但是章节重写、乃至大纲重新，会对版本链造成毁灭性的打击，我一直没有想好解决办法。所以v1版本就弃了。
v2版本，我受L站的一位熊猫头像大佬的影响，决定搞一个技能插槽的玩意。但是我的想法是把不同的写作风格、题材、标签做成不同的技能，然后根据创作需要自由组合技能。
v2版本死在了我到后面根本就分不清楚分类了，比如三幕式、五幕式是结构的技能，黄金开篇法则又是开篇的技能，五维质量检查又是审核的技能，更甚至我连题材和标签都开始渐渐分不清了，“历史”是题材吧，那“穿越”也是题材吧，那“热血”算是标签吧，那“种地”呢？“种地”是题材还是标签呢？如何写一个“五幕式的黄金开篇的穿越历史去种地的热血文”呢。。。直接把我给难住了，所以v2版本最终死在了体系划分不清上。
v3版本，是从skill大兴之后，我突然想到的灵感。既然skill可以渐进式披露，那么我是否可以把v1版本的信息管理和v2版本的技能管理，全部都做成类似skill的形式，由AI来判断是否需要加载呢。当时觉得这个想法还蛮有创造性的，但是实验下来发现，AI很傻X，我自己都想不清楚的东西，交给AI来搞，结果注定还是一团糟糕，AI产出的东西比我预期的还要混乱，我不知道是自己的组织能力出了问题，还是基座模型本身不够聪明。
目前正在尝试v4版本，也就是多Agent版本。虽然从v1版本开始，就是多Agent版本了，但是它是哪种基于固定流程的多Agent版本，也就是说虽然我有10几个Agent，但是每个的权重是一样的，只是分别负责不同的工序而已，本质上还是流水线生产。现在在尝试的v4版本，更像是龙虾那种subagent，让AI自己去决定流水线、自己却决定工序、自己去决定如何组织分工、自己去设计和启动子agent。从目前的进展来看，大概率还是失败的，哈哈哈哈。
从这一路走过来，我最大的感受就是“AI完全没有创造力”，如果是人自己都没想清楚的问题，绝对不能指望AI能帮你解决。可以把AI看作是计算器，首先自己懂得加减乘除，才能用计算器帮你计算来提高效率，如果是自己都不会解的数学题，给个银河计算机当计算器都没用
哦，对了，我的所有版本里还有一个缺陷，就是我从来没有考虑过市场化这个问题，我没有去抓市场数据，做读者画像、故事题材分析等模块，单纯还是建立在自愈自己的基础上。这大概也是为啥我搞了几个版本了，还是觉得AI写的故事达不到我的预期，很有可能是我尝试的是AI的上限，而那些批量化的生产者（已经产生利润的）他们尝试的是AI的下限，这也是两条不同的道路。
--【拾肆】--：
唔……现在的方向看上去好像和我的需求不是太相关，但仔细看好像又能对上我的需求……
--【拾伍】--：
太强了大佬
--【拾陆】--：
佬友可以试试
--【拾柒】--：
不太确定佬友这里说的世界模型具体指的是什么。在 novwr 里，我们说的世界模型指的是对小说世界状态的结构化抽象。我认为一个世界本身就是由规则、实体，以及实体之间的关系构成的，因此世界模型也是据此实现的。
另外，novwr 也不只是 graph，graph 只是其中一种表达和组织方式。佬友如果有兴趣，可以看代码或者直接试用一下，会更直观。
--【拾捌】--：
太强了佬，有空的时候我会试试能不能用这个项目实现我小说的点子的
--【拾玖】--：
先赞后看