Webnovel Writer 系统架构解析真源划分、防幻觉三定律与合同驱动的 Story System【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer本文基于 Webnovel Writerwebnovel-writer仓库中的 系统架构与模块设计文档完整拆解这套长篇网文辅助创作系统的核心理念真源划分、防幻觉三定律、Strand Weave 节奏红线、Agent 分工与合同驱动的 Story System。读完后你将理解AI 写到几百章不遗忘、不幻觉在工程上是如何落地的——从写前合同、写中审查到写后投影的完整调用链并能对照仓库源码定位每个设计决策的实现位置。核心理念先划分谁说了算长篇连载系统最容易出的问题不是写不出来而是状态漂移多份文件互相矛盾模型不知道该信谁。Webnovel Writer 的第一步设计因此不是加功能而是真源划分——明确规定哪些文件是事实源头哪些只是派生视图。真源划分按照 架构文档 的定义整个书项目目录中的文件分为四个角色类别文件/目录角色写前真源.story-system/MASTER_SETTING.json、volumes/、chapters/、reviews/动笔前的合同约束这一章能写什么写后真源accepted 状态的CHAPTER_COMMIT即.story-system/commits/chapter_XXX.commit.json一章写完新事实从这里入账投影 / read-model.webnovel/state.json、index.db、summaries/、memory_scratchpad.json只读派生视图供查询、展示和检索不是事实源头fallback-onlyreferences/genre-profiles.md仅在合同缺失时降级使用这个划分在代码中有直接印证。ChapterCommitService.build_commit() 构造提交载荷时会显式写入一个provenance字段provenance: { write_fact_role: chapter_commit, # 写事实的角色是 commit projection_role: derived_read_models, # 投影只是派生视图 legacy_state_role: projection_only, # 旧 state.json 仅投影 },也就是说state.json 降级为投影不只是一句文档口号而是被固化在每一章提交文件的元数据里。当旧投影损坏时系统可以依据 accepted commit 重放投影恢复而不需要反向抢救 state.json。防幻觉三定律真源解决信谁三定律解决怎么写。它们是贯穿写前、写中、写后全流程的硬约束定律说明执行方式大纲即法律遵循大纲不擅自发挥Context Agent 强制加载章节大纲设定即物理遵守设定不自相矛盾Reviewer Agent 内置一致性审查发明需识别新实体必须入库管理Data Agent 自动提取并消歧三定律与三个 Agent 一一对应每一律都有明确的执行者和执行环节而不是泛泛的提示词叮嘱。具体到 Context Agent 定义 中第一条定律被翻译成数据权重排序——用户要求 章纲原文 / chapter_directive.goal MASTER_SETTING reasoning 裁决 CHAPTER_COMMIT CSV 检索——章纲原文始终压在检索结果之上第二条定律体现为任务书红线校验中的能力有来源能力 ≤ 已有记录第三条定律则明确新实体由>{ strand_tracker: { last_quest_chapter: 45, last_fire_chapter: 43, last_constellation_chapter: 40, current_dominant: quest, chapters_since_switch: 3, history: [{chapter: 46, dominant: quest}] } }判断逻辑是纯算术的chapters_since_switch 5触发 Quest 连击警告current - last_fire 10触发感情线断档警告current - last_constellation 15触发世界观线断档警告。每章提交时由dominant_strand字段Data Agent 可选输出驱动更新Reviewer 的 Pacing Checker 则据此产出节奏问题。这也解释了架构图中 Reviewer 维度表里Pacing CheckerStrand 比例与断档的存在——红线是写前约束Pacing 审查是写后兜底两端都有防线。总体架构架构文档给出的分层视图如下┌─────────────────────────────────────────────────────────────┐ │ Claude Code │ ├─────────────────────────────────────────────────────────────┤ │ Skills (7个): │ │ init / plan / write / review / query / learn / dashboard │ ├─────────────────────────────────────────────────────────────┤ │ Agents (3个): │ │ Context Agent / Data Agent / Reviewer (含六维审查) │ ├─────────────────────────────────────────────────────────────┤ │ Data Layer: │ │ state.json / index.db (SQLite) / vectors.db │ ├─────────────────────────────────────────────────────────────┤ │ Story System: │ │ .story-system/ (合同·提交·事件) │ └─────────────────────────────────────────────────────────────┘自上而下读这张图Skill 层是作者可见的/webnovel-*命令面Agent 层是三个各司其职的子代理Data Layer 是被派生的只读数据视图最底层的.story-system/才是事实主链——图是自上而下读命令流事实是自下而上定义的。这种方向分离正是真源划分思想的体现所有面向用户的面Skills、Dashboard、查询都跑在投影之上而事实变更只能从 Story System 这一条链进入。Agent 分工读、写、审三权分立Context Agent读文件agents/context-agent.md职责写作前构建创作任务书提供本章上下文、约束和追读力策略。它的定位是上下文压缩器先 research再输出一份五段写作任务书开篇委托、这章的故事、这章的人物、怎么写更顺、收在哪里给起草阶段不落盘、不暴露系统术语。基础上下文通过一条命令一次拿全python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} \ memory-contract load-context --chapter {NNNN}load-context的返回已包含story_contractsMASTER/volume/chapter/review 四层合同、recent_summaries、urgent_loops紧急伏笔、active_rules、protagonist、memory_pack追读力、genre_profile_excerpt等字段只有返回空 contracts 时才降级直接读.story-system/*.json。伏笔处理有一条量化规则remaining ≤ 5章或已超期的伏笔必须处理可选伏笔最多 5 条——这条强制消化机制直接服务于接得住伏笔的目标。Data Agent写文件agents/data-agent.md职责从正文提取accepted_events / state_deltas / entity_deltas / summary_text等 commit artifacts交给chapter-commit驱动 projection writers 更新state.json、index.db、摘要与长期记忆。Data Agent 是发明需识别定律的执行者。它的边界设计值得注意只生成三份 tmp artifactfulfillment_result.json、disambiguation_result.json、extraction_result.json到.webnovel/tmp/绝不直接写 state/index/summaries/memory/vectors——这些落盘动作全部由 chapter-commit 的投影链完成。实体消歧采用置信度分级0.8 自动采用0.5-0.8 采用并附 warning0.5 标记待人工避免把模型的不确定性直接写进事实库。extraction_result.json的顶层字段就是架构文档里点名的那几个accepted_events每条必含event_id、chapter、event_type、subject、payloadevent_type 覆盖power_breakthrough、open_loop_created、promise_paid_off、world_rule_revealed等 10 种枚举、state_deltasentity_id field old new嵌套字段用点号、entity_deltas、entities_appeared、scenes、summary_text。伏笔还有一条闭环规则摘要中每条埋设必须同步一条open_loop_created事件回收则用promise_paid_off或对应闭合事件——伏笔的有登记、有推进、有回收靠的就是这个事件枚举。Reviewer审文件agents/reviewer.md职责章节质量审查内部包含六个审查维度审查维度检查重点High-point Checker爽点密度与质量Consistency Checker设定一致性战力/地点/时间线Pacing CheckerStrand 比例与断档OOC Checker人物行为是否偏离人设Continuity Checker场景与叙事连贯性Reader-pull Checker钩子强度、期待管理、追读力从 reviewer.md 的实现约定看六维是逻辑维度而 Reviewer 实际逐项执行的是 5 个事实维度setting设定一致性能力与境界匹配、地点与世界观一致、timeline时间线跨章衔接、倒计时推进、角色不可同时出现在两地、continuity叙事连贯上章钩子回应、场景过渡、情绪弧连续、character角色一致性对话风格、知识边界、logic因果、动机、力量对比且每个维度必须输出显式结论无问题也要写 pass。它的禁区同样明确不评分、不评价文笔、不建议情节改动只报有 evidence原文引用或数据对比的可验证问题。结构化结果由 review_pipeline.py 复核并覆盖写回标准 artifact其中blockingtrue的问题会直接阻断写章流水线——这就是设定即物理从提示词变成关卡的机制。Story System合同驱动体系Story System 是整个架构的中枢以.story-system/为独立运行面由四部分组成合同种子MASTER_SETTING.json 章节合同 反模式配置合同优先运行时卷合同volumes/ 审查合同reviews/ 写前校验章节提交链commits/chapter_XXX.commit.json state/index/summary/memory 投影事件审计链events/chapter_XXX.events.json 修订提案 覆写账本当前版本默认即 contract-first commit-first.story-system/是主链真源旧的.webnovel/*降级为投影 / read-modelpreflight与 dashboard 会暴露 runtime health。核心链路如下story-system --persist - 写入合同种子MASTER_SETTING.json 等 story-system --emit-runtime-contracts --chapter N - 生成运行时合同 写前校验 chapter-commit --chapter N - 提交 accepted commit 执行各投影写入 story-events --chapter N / --health - 事件审计与健康检查 preflight / dashboard - story runtime health / fallback 状态 / latest commit 状态这些子命令统一从 scripts/webnovel.py 进入例如python -X utf8 webnovel.py --project-root ROOT preflight用于校验插件路径、项目根和 Story System 健康状态。源码级印证提交与投影只有一条执行入口架构文档特别强调了一句话事件审计链不另起第二套投影循环事件路由仅负责声明式激活 writer实际执行入口仍是ChapterCommitService.apply_projections()。在 chapter_commit_service.py 中可以逐句对应提交判定build_commit() 用 Pydantic 校验四类结果后判定status——存在 blocking 问题、漏覆盖的大纲节点或待人工消歧项即rejected否则accepted。提交文件落到.story-system/commits/chapter_NNN.commit.json携带contract_refsmaster/volume/chapter/review 四份合同引用与初始全pending的projection_status。事件入库apply_projections() 对 accepted 的提交先把accepted_events归一化后写入事件日志EventLogStore.write_events再由修订提案触发器检查是否需要落覆写账本——这正是修订提案 覆写账本部分的执行点。投影激活随后进入 apply_projection_writers()用EventProjectionRouter().required_writers(payload)声明本次需要哪些 writer五路投影 writerStateProjectionWriter/IndexProjectionWriter/SummaryProjectionWriter/MemoryProjectionWriter/VectorProjectionWriter按需执行未激活的标记skipped成功的记done异常的记failed:原因全部写回 commit 的projection_status并通过append_projection_run追加到.webnovel/projection_log.jsonl。这条链的工程意义在于单一执行入口事件链story-events只读审计与触发声明不直接写投影因此不会出现事件循环和提交循环各改一份 state的双写竞争。排查某个投影没同步时只需看 commit 文件里的projection_status和 projection log失败后可用projections子命令基于已有 commit 补跑或重放而不用重写章节。运维出口健康即产品的一部分真源与投影分离的代价是多了一个可能失步的层系统用两个出口对冲这个风险preflight在每次写章前暴露 story runtime health、fallback 状态和 latest commit 状态doctordoctor.py做阶段感知体检Dashboard 作为只读面板把story_runtime.mainline_ready、.story-system/commits/chapter_XXX.commit.json是否 accepted、各投影是否done/skipped直接摆给作者。README 给出的排查清单——mainline_ready是否为 true、commit 是否存在且 accepted、projection_status是否全绿——本质上就是按本文的真源划分逐层核对。小结Webnovel Writer 的架构可以用三句话概括事实只在.story-system/一处产生合同 accepted commit一切查询面都是可重放的投影防幻觉约束被拆到写前Context Agent 加载大纲、写中Reviewer 六维审查、写后Data Agent 事件提取三个可执行环节。这种单一事实源 派生视图 全程可审计的设计与数据库领域权威表 物化视图 事件溯源的思路同构也是它能支撑 200 万字量级连载时保持状态一致性的工程基础。更完整的演进细节合同优先运行时的分阶段设计可继续参考 story-system-phase5.md 与 docs/ 下的命令详解。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Webnovel Writer 系统架构解析：真源划分、防幻觉三定律与合同驱动的 Story System
Webnovel Writer 系统架构解析真源划分、防幻觉三定律与合同驱动的 Story System【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer本文基于 Webnovel Writerwebnovel-writer仓库中的 系统架构与模块设计文档完整拆解这套长篇网文辅助创作系统的核心理念真源划分、防幻觉三定律、Strand Weave 节奏红线、Agent 分工与合同驱动的 Story System。读完后你将理解AI 写到几百章不遗忘、不幻觉在工程上是如何落地的——从写前合同、写中审查到写后投影的完整调用链并能对照仓库源码定位每个设计决策的实现位置。核心理念先划分谁说了算长篇连载系统最容易出的问题不是写不出来而是状态漂移多份文件互相矛盾模型不知道该信谁。Webnovel Writer 的第一步设计因此不是加功能而是真源划分——明确规定哪些文件是事实源头哪些只是派生视图。真源划分按照 架构文档 的定义整个书项目目录中的文件分为四个角色类别文件/目录角色写前真源.story-system/MASTER_SETTING.json、volumes/、chapters/、reviews/动笔前的合同约束这一章能写什么写后真源accepted 状态的CHAPTER_COMMIT即.story-system/commits/chapter_XXX.commit.json一章写完新事实从这里入账投影 / read-model.webnovel/state.json、index.db、summaries/、memory_scratchpad.json只读派生视图供查询、展示和检索不是事实源头fallback-onlyreferences/genre-profiles.md仅在合同缺失时降级使用这个划分在代码中有直接印证。ChapterCommitService.build_commit() 构造提交载荷时会显式写入一个provenance字段provenance: { write_fact_role: chapter_commit, # 写事实的角色是 commit projection_role: derived_read_models, # 投影只是派生视图 legacy_state_role: projection_only, # 旧 state.json 仅投影 },也就是说state.json 降级为投影不只是一句文档口号而是被固化在每一章提交文件的元数据里。当旧投影损坏时系统可以依据 accepted commit 重放投影恢复而不需要反向抢救 state.json。防幻觉三定律真源解决信谁三定律解决怎么写。它们是贯穿写前、写中、写后全流程的硬约束定律说明执行方式大纲即法律遵循大纲不擅自发挥Context Agent 强制加载章节大纲设定即物理遵守设定不自相矛盾Reviewer Agent 内置一致性审查发明需识别新实体必须入库管理Data Agent 自动提取并消歧三定律与三个 Agent 一一对应每一律都有明确的执行者和执行环节而不是泛泛的提示词叮嘱。具体到 Context Agent 定义 中第一条定律被翻译成数据权重排序——用户要求 章纲原文 / chapter_directive.goal MASTER_SETTING reasoning 裁决 CHAPTER_COMMIT CSV 检索——章纲原文始终压在检索结果之上第二条定律体现为任务书红线校验中的能力有来源能力 ≤ 已有记录第三条定律则明确新实体由>{ strand_tracker: { last_quest_chapter: 45, last_fire_chapter: 43, last_constellation_chapter: 40, current_dominant: quest, chapters_since_switch: 3, history: [{chapter: 46, dominant: quest}] } }判断逻辑是纯算术的chapters_since_switch 5触发 Quest 连击警告current - last_fire 10触发感情线断档警告current - last_constellation 15触发世界观线断档警告。每章提交时由dominant_strand字段Data Agent 可选输出驱动更新Reviewer 的 Pacing Checker 则据此产出节奏问题。这也解释了架构图中 Reviewer 维度表里Pacing CheckerStrand 比例与断档的存在——红线是写前约束Pacing 审查是写后兜底两端都有防线。总体架构架构文档给出的分层视图如下┌─────────────────────────────────────────────────────────────┐ │ Claude Code │ ├─────────────────────────────────────────────────────────────┤ │ Skills (7个): │ │ init / plan / write / review / query / learn / dashboard │ ├─────────────────────────────────────────────────────────────┤ │ Agents (3个): │ │ Context Agent / Data Agent / Reviewer (含六维审查) │ ├─────────────────────────────────────────────────────────────┤ │ Data Layer: │ │ state.json / index.db (SQLite) / vectors.db │ ├─────────────────────────────────────────────────────────────┤ │ Story System: │ │ .story-system/ (合同·提交·事件) │ └─────────────────────────────────────────────────────────────┘自上而下读这张图Skill 层是作者可见的/webnovel-*命令面Agent 层是三个各司其职的子代理Data Layer 是被派生的只读数据视图最底层的.story-system/才是事实主链——图是自上而下读命令流事实是自下而上定义的。这种方向分离正是真源划分思想的体现所有面向用户的面Skills、Dashboard、查询都跑在投影之上而事实变更只能从 Story System 这一条链进入。Agent 分工读、写、审三权分立Context Agent读文件agents/context-agent.md职责写作前构建创作任务书提供本章上下文、约束和追读力策略。它的定位是上下文压缩器先 research再输出一份五段写作任务书开篇委托、这章的故事、这章的人物、怎么写更顺、收在哪里给起草阶段不落盘、不暴露系统术语。基础上下文通过一条命令一次拿全python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} \ memory-contract load-context --chapter {NNNN}load-context的返回已包含story_contractsMASTER/volume/chapter/review 四层合同、recent_summaries、urgent_loops紧急伏笔、active_rules、protagonist、memory_pack追读力、genre_profile_excerpt等字段只有返回空 contracts 时才降级直接读.story-system/*.json。伏笔处理有一条量化规则remaining ≤ 5章或已超期的伏笔必须处理可选伏笔最多 5 条——这条强制消化机制直接服务于接得住伏笔的目标。Data Agent写文件agents/data-agent.md职责从正文提取accepted_events / state_deltas / entity_deltas / summary_text等 commit artifacts交给chapter-commit驱动 projection writers 更新state.json、index.db、摘要与长期记忆。Data Agent 是发明需识别定律的执行者。它的边界设计值得注意只生成三份 tmp artifactfulfillment_result.json、disambiguation_result.json、extraction_result.json到.webnovel/tmp/绝不直接写 state/index/summaries/memory/vectors——这些落盘动作全部由 chapter-commit 的投影链完成。实体消歧采用置信度分级0.8 自动采用0.5-0.8 采用并附 warning0.5 标记待人工避免把模型的不确定性直接写进事实库。extraction_result.json的顶层字段就是架构文档里点名的那几个accepted_events每条必含event_id、chapter、event_type、subject、payloadevent_type 覆盖power_breakthrough、open_loop_created、promise_paid_off、world_rule_revealed等 10 种枚举、state_deltasentity_id field old new嵌套字段用点号、entity_deltas、entities_appeared、scenes、summary_text。伏笔还有一条闭环规则摘要中每条埋设必须同步一条open_loop_created事件回收则用promise_paid_off或对应闭合事件——伏笔的有登记、有推进、有回收靠的就是这个事件枚举。Reviewer审文件agents/reviewer.md职责章节质量审查内部包含六个审查维度审查维度检查重点High-point Checker爽点密度与质量Consistency Checker设定一致性战力/地点/时间线Pacing CheckerStrand 比例与断档OOC Checker人物行为是否偏离人设Continuity Checker场景与叙事连贯性Reader-pull Checker钩子强度、期待管理、追读力从 reviewer.md 的实现约定看六维是逻辑维度而 Reviewer 实际逐项执行的是 5 个事实维度setting设定一致性能力与境界匹配、地点与世界观一致、timeline时间线跨章衔接、倒计时推进、角色不可同时出现在两地、continuity叙事连贯上章钩子回应、场景过渡、情绪弧连续、character角色一致性对话风格、知识边界、logic因果、动机、力量对比且每个维度必须输出显式结论无问题也要写 pass。它的禁区同样明确不评分、不评价文笔、不建议情节改动只报有 evidence原文引用或数据对比的可验证问题。结构化结果由 review_pipeline.py 复核并覆盖写回标准 artifact其中blockingtrue的问题会直接阻断写章流水线——这就是设定即物理从提示词变成关卡的机制。Story System合同驱动体系Story System 是整个架构的中枢以.story-system/为独立运行面由四部分组成合同种子MASTER_SETTING.json 章节合同 反模式配置合同优先运行时卷合同volumes/ 审查合同reviews/ 写前校验章节提交链commits/chapter_XXX.commit.json state/index/summary/memory 投影事件审计链events/chapter_XXX.events.json 修订提案 覆写账本当前版本默认即 contract-first commit-first.story-system/是主链真源旧的.webnovel/*降级为投影 / read-modelpreflight与 dashboard 会暴露 runtime health。核心链路如下story-system --persist - 写入合同种子MASTER_SETTING.json 等 story-system --emit-runtime-contracts --chapter N - 生成运行时合同 写前校验 chapter-commit --chapter N - 提交 accepted commit 执行各投影写入 story-events --chapter N / --health - 事件审计与健康检查 preflight / dashboard - story runtime health / fallback 状态 / latest commit 状态这些子命令统一从 scripts/webnovel.py 进入例如python -X utf8 webnovel.py --project-root ROOT preflight用于校验插件路径、项目根和 Story System 健康状态。源码级印证提交与投影只有一条执行入口架构文档特别强调了一句话事件审计链不另起第二套投影循环事件路由仅负责声明式激活 writer实际执行入口仍是ChapterCommitService.apply_projections()。在 chapter_commit_service.py 中可以逐句对应提交判定build_commit() 用 Pydantic 校验四类结果后判定status——存在 blocking 问题、漏覆盖的大纲节点或待人工消歧项即rejected否则accepted。提交文件落到.story-system/commits/chapter_NNN.commit.json携带contract_refsmaster/volume/chapter/review 四份合同引用与初始全pending的projection_status。事件入库apply_projections() 对 accepted 的提交先把accepted_events归一化后写入事件日志EventLogStore.write_events再由修订提案触发器检查是否需要落覆写账本——这正是修订提案 覆写账本部分的执行点。投影激活随后进入 apply_projection_writers()用EventProjectionRouter().required_writers(payload)声明本次需要哪些 writer五路投影 writerStateProjectionWriter/IndexProjectionWriter/SummaryProjectionWriter/MemoryProjectionWriter/VectorProjectionWriter按需执行未激活的标记skipped成功的记done异常的记failed:原因全部写回 commit 的projection_status并通过append_projection_run追加到.webnovel/projection_log.jsonl。这条链的工程意义在于单一执行入口事件链story-events只读审计与触发声明不直接写投影因此不会出现事件循环和提交循环各改一份 state的双写竞争。排查某个投影没同步时只需看 commit 文件里的projection_status和 projection log失败后可用projections子命令基于已有 commit 补跑或重放而不用重写章节。运维出口健康即产品的一部分真源与投影分离的代价是多了一个可能失步的层系统用两个出口对冲这个风险preflight在每次写章前暴露 story runtime health、fallback 状态和 latest commit 状态doctordoctor.py做阶段感知体检Dashboard 作为只读面板把story_runtime.mainline_ready、.story-system/commits/chapter_XXX.commit.json是否 accepted、各投影是否done/skipped直接摆给作者。README 给出的排查清单——mainline_ready是否为 true、commit 是否存在且 accepted、projection_status是否全绿——本质上就是按本文的真源划分逐层核对。小结Webnovel Writer 的架构可以用三句话概括事实只在.story-system/一处产生合同 accepted commit一切查询面都是可重放的投影防幻觉约束被拆到写前Context Agent 加载大纲、写中Reviewer 六维审查、写后Data Agent 事件提取三个可执行环节。这种单一事实源 派生视图 全程可审计的设计与数据库领域权威表 物化视图 事件溯源的思路同构也是它能支撑 200 万字量级连载时保持状态一致性的工程基础。更完整的演进细节合同优先运行时的分阶段设计可继续参考 story-system-phase5.md 与 docs/ 下的命令详解。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考