写到第 200 章还不崩设定，webnovel-writer 靠什么做到
AI 写长篇，前三十章通常很顺。真正的麻烦从第八十章之后才开始出现：主角的行事风格悄悄换了一个人，上一卷宣布要闭关三年的角色提前出场，前文郑重埋下的信物再也没有被提起。这些问题的根源往往不是模型不够强，而是没有任何东西替它记住已经写下的内容——每次生成的上下文窗口都是一次性的，写完即忘。
lingfengQAQ/webnovel-writer 瞄准的正是这一段。它是一套跑在 Agent 上的长篇网文创作插件，把自己定位成一致性系统而不是一次性生成器，宣称可支撑 200 万字量级的连载创作。仓库目前 7164 Star，站点综合分 72.2，GPL v3 许可，最近一次上游提交是 2026/9/22。想先看它在同类插件里被归到哪一类，可以从 DeepSeek Harness Hub 插件清单 入手。
它为什么存在：三个典型的崩坏点
第一个是角色动机漂移。写到第 200 章，一个人的说话方式、底线、称呼习惯本该是稳定的，但模型每一章都是从零推理一遍，很容易给出一个"平均而言合理"、却和前面接不上的人物。
第二个是战力与时间线打架。谁在第几层境界、上一个事件过去了几天，这些信息分散在几十万字里，模型没法可靠地回溯。
第三个是伏笔无人回收。前文埋了钩子，而后面没有任何一层机制提醒作者"这个还没收"，于是它就一直悬在那里。
这三件事的共同点在于：它们不属于"这一章写得好不好"，而属于"这一章和前面所有章对不对得上"。这正是它要解决的问题。
Story System：一处事实源，若干只读视图
从 v6.0.0 起，这个插件默认走一条叫 Story System 的主链。理解它只需要抓住一个原则：只有一处是事实，其余都是投影。
.story-system/是唯一的事实源头。动笔之前写的"合同"、写完之后做的"提交"，都存在这里。- 一章写完，新事实从 accepted 的
CHAPTER_COMMIT入账；在确认提交之前，这一章带来的变化都不算数。 .webnovel/state.json、index.db、summaries/、memory_scratchpad.json这几个全部是派生出来的只读视图，不是独立数据源。它们存在的意义是让检索、面板、上下文拼装更快，而不是让人去手工改动。.webnovel/projection_log.jsonl是投影执行日志，它的作用是回答"state / index / summary / memory / vector 这五路里，究竟哪一路没同步"。
这样划分的好处很直接：面板显示的内容和正文对不上时，不必猜数据错在哪一层。
一次 /webnovel-write 的九个步骤
真正写一章时，流程比"把大纲丢给模型"长得多。/webnovel-write 一条龙里串了九个步骤：
1. 预检项目根目录、占位符以及 Story System 的健康状态
2. 刷新这一章的 runtime contract
3. 调用 context-agent 生成写作任务书
4. 按任务书起草正文
5. 调用 reviewer 做多维审查，blocking issue 不通过就阻断
6. 润色、排版、Anti-AI 终检
7. 调用 data-agent 提取事实
8. 生成 CHAPTER_COMMIT，驱动 state / index / summary / memory / vector 投影
9. 执行章节级备份
读成一条流水线就很清楚：前三步决定"该写什么"，中间三步决定"写得好不好"，后三步决定"写的东西有没有真的进入记忆"。第 5 步的阻断是有实体的——审查不过，这一章就不会继续往下走。
中途崩了怎么办：可信断点与四种总状态
长跑任务最怕的是跑到一半断掉，然后重跑把已经写好的正文覆盖掉。它对此的处理叫可信断点：重复执行同一条 /webnovel-write 章号 时，系统会先检查已有记录，尽量从失败点继续，不重写已经可信完成的正文、审查、提交或备份。
这里有个边界需要留意：断点机制只在"已有可信完成记录"时生效。所以实践中的正确顺序是先看状态再重跑，而不是手工去删 COMMIT 文件求一个"干净重来"。
一次执行结束后的总状态有四种：已完成 / 部分完成 / 需要你处理 / 未完成。只有遇到不可恢复故障时，它才会提示你去看 .webnovel/logs/run_last.log。换句话说，"需要你处理"和"未完成"是要区别对待的两件事，前者通常补一个输入就能接着跑。
排查顺序官方也给了：先跑 preflight 与 doctor --format text，重点看三样东西——story_runtime.mainline_ready 是否为 true、.story-system/commits/chapter_XXX.commit.json 是否存在且 accepted、projection_status 是否全部为 done 或 skipped。第三条如果卡住，.webnovel/projection_log.jsonl 会直接告诉你是哪一路掉队，必要时用 projections 子命令补跑。
版本选择与题材覆盖
插件内置 37 个中文网文题材模板，支持复合题材，玄幻修仙、都市现代、言情以及一些特殊题材都有对应起点。
版本这一块需要留心：master 分支的 v6 是 Claude Code 插件，仍在维护但只修致命 bug，Claude Code 用户应当用这一版；v7 已冻结、未发布，只作开发档案；v8 是基于 DeepSeek Harness 的写作工作台，处于源码预览阶段。官方明确说明 v6 与 v8 安装方式不同，且尚无经过验证的旧书仓直接迁移方案。
由此有两个实践结论。想在一个宿主里开箱就用的人，要先接受"v8 拿到的是预览版"这个前提；而如果你手里已经有一本写了几十万字的书，换版本等于换整套工作流——稳妥做法是新书用 v8、老书留在 v6，并且在任何迁移尝试之前先自行备份书项目目录。
总结
写到几百章还不崩设定，靠的不是更强的模型，而是把"事实登记、过审、存档"变成一条有合同、有提交、有投影的流水线；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：准备开写百万字量级连载、痛点在设定漂移而非文笔的作者；被"伏笔埋了收不回"反复折磨、需要强制回收机制的长篇作者；愿意接受"每章走完整流水线"、把一致性看得比单章产出速度更重的团队；已经用 Claude Code 并想先跑通 v6 的人。
不适合：只想写短篇或先试稿几千字的人——每章都要走任务书、起草、审查、事实提取、投影的完整链路，比让模型直接写一章慢得多、也更耗 token，RAG 还要自备 Embedding 与 Rerank 的 Key，不填就只能落到 BM25 关键词检索；想在 DeepSeek Harness 里开箱即用的人——v6 主链是 Claude Code 插件，DSH 形态的 v8 目前仍只是源码预览；手里有旧书仓、又不接受换工作流的人——官方明说没有经过验证的迁移方案，换版本约等于换流程。
标签：webnovel-writer、DeepSeek Harness、长篇网文一致性、Story System
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。