长篇写作真正难的地方不是文笔，而是记账。写到几百章之后，设定、伏笔、人物关系都会变成需要逐条核对的事实。lingfengQAQ/webnovel-writer 的思路就是把这件事交给一条可检查的流水线：它是一套跑在 Agent 上的长篇网文创作插件，官方定位为一致性系统而非一次性生成器，宣称支持 200 万字量级连载，Star 7164，许可 GPL v3，站点分类为工具 / 效率，已提供中文文档。下面不重复安装步骤，只讲怎么把它当成一个长期项目来管。
先把唯一事实源立起来
这套系统的核心约定只有一句：.story-system/ 是唯一的事实源头，动笔前要签的「合同」和写完后要交的「提交」都放在这里。每章写完后，新的事实以 accepted CHAPTER_COMMIT 的形式入账；而 .webnovel/state.json、index.db、summaries/、memory_scratchpad.json 都是从主链派生的只读视图。
工程化的第一条纪律就来自这里：要改就改主链与提交记录，不要去手工编辑那些派生视图。视图对不上时，正确动作是重新投影，而不是就地把数字改到看起来一致。把这条守住，后面所有的检查才有意义。
写前查资料，写后登记事实
流程里前后各有一道关口。动笔之前，由 context-agent 生成写作任务书，正文按任务书起草，避免模型凭印象发挥；写完之后，由 data-agent 提取本章事实，再生成 CHAPTER_COMMIT 去驱动 state index summary memory vector 五路投影。
把它压缩成一句可执行的口径：写前查资料，写后登记事实。没被登记的事实等于没发生，下一章的上下文里不会出现它；而临时决定又不登记，恰恰是长篇最容易埋雷的地方。内置的 37 个中文网文题材模板与复合题材支持，解决的是开题阶段的套路问题，解决不了这条记账纪律，两者要分开看。
每章必须过 write-gate
一章想被系统承认为「已完成」，得先过 write-gate。多维审查中一旦出现 blocking issue，流程会直接阻断，不允许带着硬伤进入下一章。这条规则看起来严苛，实际是在保护后面的章节：伏笔可以埋伏笔，但错误不能带错误。
配合 /webnovel-review 使用，闸门的意义会很清楚——它不是给文笔打分，而是把「事实是否自洽、设定是否冲突」这类可判定的问题先拦下来，把创作判断留给作者。
投影失败要能定位，也要能重放
.webnovel/projection_log.jsonl 是这套系统里最该被重视的文件之一：它是投影执行日志，用来回答「state index summary memory vector 这五路里，究竟是哪一路没同步」。
推荐的排查顺序是固定的：先看 doctor 给出的 projection_status 是否全部为 done 或 skipped，再从投影日志定位到具体那一路，最后用 projections 子命令重放，而不是重建整本书的索引。视图是派生的，所以重放永远比重做便宜。
章节级备份与可回滚
写章流程的最后一步就是章节级备份，这是回滚的基本盘。配合它可以少做很多无用功：重复执行同一条 /webnovel-write 章号 时，系统会先检查可信断点，尽量从失败点继续，不重写已经可信完成的正文、审查、提交或备份。
最终报告会给出四种总状态：已完成 部分完成 需要你处理 / 未完成。只有不可恢复的故障才会提示去查 .webnovel/logs/run_last.log。看到「部分完成」先别急着重跑，先确认断点位置，往往能从断点接着走完。
让这本书自己长出经验
写完几十章之后，真正值得沉淀的不是正文，而是这本书的有效写法。/webnovel-learn 负责项目学习，长期记忆闭环负责把这些结论留下来，追读力系统则提供另一个视角的数据。
Dashboard 是只读面板，适合定期看一遍：项目状态、实体关系图、章节内容、伏笔与追读力数据都在上面。伏笔那条线尤其值得盯——长篇出问题，十有八九是伏笔埋了没收。
放到云上长期跑：把体检做成例行公事
在 ECS 上长期运行，doctor 应该是每周都会跑一次的东西。它是阶段感知检查，会依次核对目录、文件、数据库、RAG、依赖、Dashboard 产物这几类状态；配合 preflight 与 project-status，主链是否就绪、断点停在哪里、派生视图是否同步，一次就能看全。
云上还要额外管三件事。备份用云盘快照按周期打，优先级最高的仍然是 .story-system/，回滚时先回主链、再重放派生视图。出网方面，把模型与 RAG 服务放在同地域内网访问，既省公网带宽也把延迟压下来，再用白名单把出网域名收敛到少数几个。常驻方面，进程交给 systemd 一类的方式拉起，日志交给 logrotate，别让日志把云盘写满——run_last.log 是故障时才需要翻的东西，不是日常读物。安全组同样保持最小放行，管理端口不对全网开放。
顺带一提，这些运维能力是逐步补齐的：v6.1.0 新增了 doctor project-status write-gate projection 重放 hooks，v5.5.5 收口长期记忆闭环，v5.3 引入追读力系统。也就是说，定期升级并不只是为了修 bug。
总结
把长篇连载当工程项目管，落点其实是三件小事：主链只认 .story-system/、每章都过闸门、投影出问题能定位能重放；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：正在写或准备写长篇连载、设定量已经超出个人记忆的作者；愿意把「写前查、写后记」变成习惯的人；需要多章并行推进、且每章都要可追溯的团队；已经在云上跑着其它自动化任务、顺手把写作也挂上去的人。
不适合：更愿意凭感觉写、不想被流程记录约束的作者，这套约束会一直硌着你；只想快速产出短篇或试稿的人，逐章走完流水线的代价远高于收益；手上是旧版本书仓、期待无损升级到 v8 的人——官方明确尚无经过验证的旧书仓直接迁移方案，换版本基本等于换工作流。
标签：webnovel-writer、DeepSeek Harness、工程化实践、连载一致性、云上运维
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
