【征求意见】webnovel-writer v7 设计公示：架构重写，发布前征集意见 #118
Replies: 7 comments 19 replies
-
|
接了claude opus4.8 大纲还没读完，先破产了。token烧的有点厉害，其他都是棒棒的。用deepseek v4 pro不能看 |
Beta Was this translation helpful? Give feedback.
-
|
deepseekv4pro有严重的不遵守指令的问题不好搞 |
Beta Was this translation helpful? Give feedback.
-
|
写东西用Sonnet就差不多了，只有非常复杂的高难度章节细纲才需要出动Opus 4.6 |
Beta Was this translation helpful? Give feedback.
-
当前的流程其实已经十分强大了，但是ai在节奏控制这一块还是太差了，特别是plan流程的时候它自己闷着头生成几百章章纲，你打开一看发现十张章纲才差不多能写半章正文。而且在写玄幻仙侠类的网文的时候，ai经常没法理解这些超自然的能力，写着写着就变成金丹高手贴身肉搏，还有从十米高处摔断腿的筑基高手。每次看到这些内容我都差点两眼一黑昏古七 |
Beta Was this translation helpful? Give feedback.
-
恐怕需要引入战力系统了，单纯的力量体系不够ai用，得明确什么等级能做到什么事，并且还得确保ai能严格按照这东西执行才行 |
Beta Was this translation helpful? Give feedback.
-
|
V6 版本的 /webnovel-plan 环节会同步生成卷纲与章纲，二者生成流程相互绑定。用户无法先调整优化卷纲，再单独生成章纲。 |
Beta Was this translation helpful? Give feedback.
-
|
本身没有章纲这个文件，但是卷纲相当于是整个卷的章纲组成的，主要问题其实是v6的整个流程没有做好人与ai的交互，除了创意阶段其他阶段基本输入个命令就跑到结束压根不会请求作者意见，v7会着重优化这一点 |
Beta Was this translation helpful? Give feedback.
-
|
对对对，这个特别重要。 功能性特别强大。 但是缺少了部分人的交互。我始终认为，AI永远替代不了人的。 因为人是具有灵魂的。所以一本好的小说，一定是需要人工交互赋予情绪的。全自动不重要，如果一个agent可以把繁琐复杂单一的任务给完成，就已经是一个特别牛B的agent了。总有人做躺平的梦。这不现实。 |
Beta Was this translation helpful? Give feedback.
-
|
另外作者大哥，你这边用的模型是claude吗？我买了100刀的token。一个小时烧完了。我准备订阅pro了，但是又怕不够用。能咨询一下你如果用claude，订阅的是pro还是max |
Beta Was this translation helpful? Give feedback.
-
|
我都是用的l站上面的各种白嫖渠道没有订阅，如果你要你自己订阅要考虑封号问题 |
Beta Was this translation helpful? Give feedback.
-
|
大佬，还有个问题想请教。你之前列出的评判维度：伏笔、悬念、感情线、细纲、审稿、吃书、全书近况，麻烦帮忙看看其中有没有表述生硬、不合适的地方。 |
Beta Was this translation helpful? Give feedback.
-
|
这些不是评判维度只是之前ai生成的prd里面有很多不属于小说领域的词，我让他做了替换，你说的那个是属于审查的一部分 |
Beta Was this translation helpful? Give feedback.
-
|
完整的prd可以在这儿看 |
Beta Was this translation helpful? Give feedback.
-
|
你换个模型就好了。 用claude 4.6sonet 会强太多。其他更强的模型别用，不然MAX*20都不够用。 这是大脑的问题不是设定的问题。 |
Beta Was this translation helpful? Give feedback.
-
|
好的谢谢，我去尝试看看 |
Beta Was this translation helpful? Give feedback.
-
|
大佬你好，我最近在做自己的个人写作agent。 文风对齐方法核心思路：不靠禁令约束 AI，而是从作者样文中提取可执行的写作模式，让 AI 逐段照着做。 一句话总结：把文风从模糊感觉翻译为一套从样文中逆向提取、精确描述、且可被 AI 逐段执行的程序化操作。它的可靠性来自作者本人的成功经验 × 跨文本重复验证 × 外部理论锚定这三者的三角支撑。 一、提取风格指纹从作者自有样文中计算 7 个维度的特征——句长分布、词汇偏好、句式模式、对话引语处理、叙事距离、标点习惯、段落节奏。这是客观可量化的基线。 二、拆解为原子模式从样文中找出反复出现的最小叙事操作，每个命名、定义、配样文出处。例如：
十几个这样的原子操作，每个都来自作者的实际文本。 三、组合为复合语群单个原子只覆盖一句或几句，不足以约束一整段文字的推进节奏。例如"锚点引入"只负责开头那一句，之后怎么写它不管。因此从样文中提取原子模式的常用组合，打包为结构骨架——比如 S1 物象锚定（锚点→收敛→感知→转折→递进→收束）覆盖了从开头到收尾的完整弧线，B1 预期反转（铺垫→短句转折→反转→收尾）定义了反转类段落的推进方向。 四、逐段约束而非全局套模板每个场景细纲中的节拍（一个叙事单元，通常对应一个具体事件）独立标注要用的语群和手法标签。例如： 渲染时只执行该行标注的几件事——{S1截断} 指定结构骨架，[意象, 陌生化] 指定文学技巧。不同节拍标注不同，不共用一套全局配置。这相当于配置驱动的渲染管线：约束是局部且精确的。 五、从修改中学习每次作者调整产出后，系统对比原版和改版，归纳节奏偏好，经确认后存档。不手动写规则，从操作中归纳。 这套模式的可靠性从何而来原子模式并非凭空制定，可靠性由三个独立维度共同支撑： 样文自证。 这些模式不是从写作教材里抄来的，也不是靠模型"审美"挑出来的——它们来自作者已经写完、认可的三篇样文。这是当事人的经验证据，不是第三方判断。 跨文本交叉验证。 每个模式至少在 3 篇样文中的 2 篇里同时出现才被收录（2/3 阈值），不是单篇的偶然写法。状态标记（◉已确认/◇可选用/⚠谨慎）进一步区分了哪些是稳定习惯、哪些只是可用选项。 外部理论锚定。 每个原子模式都映射到 Wikipedia 叙事技巧框架中的已知概念——"锚点引入"对应 In Medias Res 和 Narrative Hook，"链式收敛"对应 Amplification 和 Convergence Rhythm，"感知判断"对应 Defamiliarization 和 Imagery，"短句转折"对应 Peripety。这意味着每个操作都有文学理论的命名和讨论历史，不是黑盒产物。 外部理论锚定的额外价值锚定外部理论不仅是"自证合理"，还有三个工程层面的好处： 第一，差异就是风格。 作者习惯的某个写法与 Wikipedia 标准定义不一致的地方，恰好就是个人特色所在。例如"感知判断"对应 Defamiliarization，但样文中它的实现比标准定义更克制——不给结论，只给感官。这个偏离定义了作者风格的边界。外部理论相当于标准基线，偏离它的地方就是个人方言。 第二，给风格库提供可扩展的骨架。 当前原子模式仅从三篇样文中提取，覆盖有限。当作者尝试新手法时，不需要从零归纳——可以在 Wikipedia 框架内先定位目标技巧条目，对比自己和标准定义的差距，快速确定新模式的形态。 第三，降低协作成本。 如果另一位作者、编辑或研究者参与项目，说"用 Peripety"比说"我管这叫短句转折"更容易建立共同理解。 |
Beta Was this translation helpful? Give feedback.
-
|
外部理论的引用：https://en.wikipedia.org/wiki/List_of_narrative_techniques 这里，我希望通过现有的外部知识库，为作者写作风格提供理论支撑，并为作家间交流建立共同的语言规范。这个思路同样可以拓展到其他写作理论甚至其他领域的理论上。也适合作者根据自己需要制定。即使两个作者采用不同的语言规范，也可以通过agent去自主识别和对接。 以上是我的一点想法。这个feature我觉得还不值得整合进整个体系（它更像是通用研究agent的能力，和网文写作不一定适配），但这个潜在用法或许可以纳入到教程中来。 |
Beta Was this translation helpful? Give feedback.
-
|
我认为ai了解几乎所有的写作手法以及各种写作风格，但是这些知识在没有提示情况下只会使用最保守或者说固定的手法，如何在合适的时候引导ai使用某种手法来写这是个问题 |
Beta Was this translation helpful? Give feedback.
-
|
这种能通过总结作者以往的作品，或者给AI一些作者感觉写的好的内容，让AI来总结形成作者喜欢的写作手法，再让它根据这种手法来创作是不是可以，写的越来越多，这种写作手法应该也能更贴合作者本身，就是感觉每次都带着写作手法估计会很耗token，不带的话，怎么引导AI在合适的时候用又是个大问题 😂 |
Beta Was this translation helpful? Give feedback.
-
“合适的时候用”比较好解决，只要确定好阶段，然后把这部分写进代码里就好。 |
Beta Was this translation helpful? Give feedback.
-
还有个人的文风呀，写作风格提取这个环节还是有必要的，能适应更多场景。还有，关于写作偏移，用多个视角的审核 agent 来审核文章质量 |
Beta Was this translation helpful? Give feedback.
-
|
是的，而且我为了便宜用dsv4，它文风不稳定，比其他模型更需要显式约束进行引导。
考虑到文风只能在草稿层面落实，最合适的做法应该是在草稿上一层，也就是规划每一个场景的节奏时确定。
我不太熟悉网文写作，但这看起来对应网文中的章纲？在这一阶段需要确定核心冲突，冲突的解决过程，制定故事节拍。
目前我是在节拍引入风格标记，告诉模型应该采用哪些手法来落实这部分内容。这样模型可以结合当前的故事节奏、涉及的意象和伏笔等一系列信息，来分析什么写法最合适，并写到细纲里。
|
Beta Was this translation helpful? Give feedback.
-
|
我感觉不如尝试用glm，会比dsv4更遵循指令 |
Beta Was this translation helpful? Give feedback.
-
|
很喜欢这个项目，也试着将其迁移到codex上运行。个人感觉最优的方式还是让一个主控ai来调控负责阶段推进、ready payload、验收和阻断，小白也能轻松创作。附件是我在codex用的提示词，不是很专业比较乱 hh |
Beta Was this translation helpful? Give feedback.
-
|
你这个想法也挺好的的可以吸收进去，有个问题就是子代理开多了token消耗会显著增加有很多上下文都要重复读取，好处是上下文隔离更专注于某个事不容易被上下文的噪音干扰 |
Beta Was this translation helpful? Give feedback.
-
|
用过这个项目，十分强大，很佩服作者能力。 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
大家好。v6 发布以来收到了大量反馈，其中一部分问题经过多轮修补仍无法根治——原因在底层架构，不在某个具体功能。因此 v7 决定重写整个系统。在动工之前，把完整设计公示出来征集意见：格式层一旦定稿就要长期保持稳定，现在是影响设计的最佳时机。
v6 的主要问题与 v7 的对应解法
v7 中一本书的形态
一本书就是一个文件夹，目录全中文，内容全部是 Markdown 文档，任何编辑器都能直接打开：
没有数据库，没有隐藏状态。直接修改任何文件都是合法操作——下次启动时系统会识别改动并提议补登，不会报错阻拦。
写一章的流程
定稿权始终在作者手里——系统不存在任何不经作者确认就写入定稿区的路径。
伏笔、悬念、感情线
每条线索一份独立档案：何时埋下、推进到哪、计划何时收尾。搁置过久时系统会提示"悬了太久"——这是提醒，不是错误。允许有收不回的伏笔，系统不强制清账。
挂机连写
确认当卷卷纲后，可让 AI 连写一个批次（默认 8 章，可配置）。批次结束后作者统一审稿：整批接受、修改其中几章、或从某章起打回重写。质量防线：每批次做一次体检，体检不过线或连续数章无剧情推进会自动停下。
修改与"吃书"
导出发布
一键导出纯净正文（单章 / 章节范围 / 全书），可直接发布到内容平台。
安装方式的变化
v7 不再通过插件市场分发，统一为：
运行环境要求 Node.js 22 或更高版本。v6 项目提供一次性迁移命令：正文与全部记录（伏笔、剧情线、设定）完整迁移，失败可整体回退。市场版 v6 停留在最后一个版本，并附新安装方式的指引。
首发支持 Claude Code 与 Codex（维护者亲测）；Gemini CLI、Cursor 等待社区验证后纳入支持列表。
7.0 明确不做的事
征集意见
后续节奏
v6 不会下线：master 分支长期保留，致命问题继续修复。
期待大家的意见。设计阶段的修改成本最低，正式发布后格式将保持长期稳定。
Beta Was this translation helpful? Give feedback.
All reactions