webnovel-writer 长篇连载崩溃根因诊断从松散管道到统一故事合同Story Contract的架构演进【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer导读本文基于 webnovel-writer 项目《当前系统架构诊断报告》系统剖析一套基于大模型指令的网文创作辅助系统在 200 万字量级连载场景下的结构性缺陷。报告的核心结论是系统的痛点不在于模型写不好或执行失误而在于系统提供给模型的信息结构、校验时机和数据流转机制存在根本性硬伤——试图用松散的管道脚本Pipeline管理极其复杂的网文世界状态机State Machine最终必然导致长篇连载走向崩盘。读完本文你将理解多头真理源上下文截断黑洞事后验尸式防线事务割裂等 10 个致命问题的具体成因、源码级证据以及它们如何共同指向统一故事合同SSOT 统一章节提交主链Commit Chain 统一演进账本Override Ledger这一新架构方向。一、诊断前提与核心结论这份诊断报告写于引入 Story Intelligence System Specstory-system-phase4.md 与 story-system-phase5.md 所描述的统一故事智能系统之前其诊断前提是假设大语言模型如 Opus 4.6的指令遵循能力完美能够完美解析并执行所有 Bash 命令和格式要求。即使在这样的理想前提下系统依然会崩溃。这恰好证明了问题不在模型侧而在系统侧。报告同时给出了一个重要的校准结论当前系统并不是完全没有结构化能力而是已经具备多个半成品中枢但仍缺少统一故事合同SSOT与统一章节提交主链。也就是说系统不是裸奔而是在靠多个局部结构层缝缝补补。核心结论一句话概括系统已经有多个局部结构层包括 Override Contract 雏形和 Delta 事件底座但还没有统一故事合同Story Contract、统一章节提交主链Commit Chain和覆盖全局世界设定的统一演进账本Override Ledger。这正是报告最后指出的新架构核心价值所在生成强约束的Master / Volume / ChapterJSON 合同建立显式的 Override 账本事前给足绝对红线、系统边界和消歧域把state / index / summary / memory / RAG从散落真理源降级为合同提交后的投影层。二、核心架构与真理源缺陷Architecture Single Source of Truth2.1 多头真理Multiple Sources of Truth导致的认知撕裂现象系统的设定散落在四个不同的载体中载体类型职责state.json动态状态主角状态、进度、位置、关系快照genre-profiles.md静态调性题材画像与写作调性见 genre-profiles.mdindex.db碎片化实体SQLite 索引实体别名、出场记录、关系记录memory长期事实项目记忆与长期事实沉淀见 memory/ 目录虽然context_managercontext_manager.py和genre_*系列模块genre_aliases.py、genre_profile_builder.py已经在尝试聚合这些信息但它们本质上仍是运行时装配器和局部中枢而不是统一的单一真理源SSOT。危害当剧情发生合理反转或设定升级时系统无法做到全局同步。模型会同时接到冲突的指令——例如大纲outline要求主角废柴隐忍而state.json显示主角已经天下无敌。极度聪明的模型为了兼顾双方反而会写出精神分裂般的割裂剧情。从源码看ContextManager._build_packcontext_manager.py#L165-L269确实把chapter_outline、protagonist_snapshot、worldview_skeleton、power_system_skeleton、story_contract、memory、long_term_memory等多个来源一股脑装进同一个 context pack——这正是多头真理在实现层面的直接体现装配器只负责都拿来不负责谁说了算。2.2 设定演进账本仅有雏形尚未覆盖核心世界设定Override Ledger Gap现象网文的核心规则是会随着剧情推进被打破的如主角打破了某项世界限制。当前系统已在 v5.3 引入了override_contracts表见 index_debt_mixin.py具备完整的 CRUD 操作字段包括字段含义constraint_type被违背的约束类型rationale_type违背理由类型rationale_text违背理由文本payback_plan偿还计划追读力债务due_chapter到期章节status状态pending / fulfilled / cancelled源码层面的实现相当严谨create_override_contractindex_debt_mixin.py#L15-L97使用 SQLite 的INSERT ... ON CONFLICT ... DO UPDATE实现原子 UPSERT要求 SQLite 3.24且完全冻结终态——已fulfilled/cancelled的合约所有字段都不会再被修改get_pending_overrides与get_overdue_overrides则负责按due_chapter排序提取待偿还债务。但该机制目前仅服务于追读力债务系统的软建议违背记录尚未扩展为核心世界设定力量体系、角色命运、世界规则的演进账本。对于这些核心设定的修改系统本质上仍只有静默覆盖Overwrite或局部投影更新。危害没有机制明确告诉 AI卷五已经合法推翻了卷一的隐忍设定现在的最高准则是无敌爽文。系统把所有的旧规则和新状态一锅端地喂给 AI造成严重的上下文污染和逻辑死锁。Override Contract 的基础设施已经存在但其应用范围的局限性使它无法解决核心问题——这正印证了基础设施就位、应用范围缺位的典型架构半成品状态。三、上下文装配与知识供给痛点Context Knowledge Assembly3.1 机械截断导致的信息黑洞The Blind Spot of Context Truncation现象context_manager.py确实已经在做上下文聚合且context_ranker.py已经对 alerts 等信息做了优先级排序与筛选说明系统并非完全无脑塞上下文。但最终输出仍采用按权重和字数预算、强行截断字符串的方式来组装上下文。源码证据链完整ContextManager.TEMPLATE_WEIGHTS定义了 4 种写作模板的权重context_weights.py#L12-L17TEMPLATE_WEIGHTS: dict[str, dict[str, float]] { plot: {core: 0.40, scene: 0.35, global: 0.25}, battle: {core: 0.35, scene: 0.45, global: 0.20}, emotion: {core: 0.45, scene: 0.35, global: 0.20}, transition: {core: 0.50, scene: 0.25, global: 0.25}, }权重还会按连载阶段动态调整TEMPLATE_WEIGHTS_DYNAMIC_DEFAULTcontext_weights.py#L19-L38early≤30 章重core0.48、late≥120 章重global0.35。阶段判定逻辑见_resolve_context_stagecontext_manager.py#L584-L591。_assemble_json_payload按SECTION_ORDER顺序组装 payload权重 0 或属于EXTRA_SECTIONS的区块才会进入输出context_manager.py#L120-L141。截断发生在更底层_load_outline直接对大纲做max_chars1500的截断context_manager.py#L690-L691_extract_summary_excerpt对剧情摘要做excerpt[:max_chars]的硬截断context_manager.py#L742-L749章节摘要文件按ch{chapter:04d}.md命名从summaries/目录读取context_manager.py#L751-L758。危害模型再聪明也无法遵守它没看到的规则。关键毒点、核心力量限制或重要伏笔极容易因为刚好超出字符串预算而被底层脚本静默丢弃导致模型不得不靠幻觉Hallucination填补空白引发设定崩塌。问题不在没有聚合而在于聚合后的输入仍可能被预算逻辑打成信息黑洞。3.2 知识延迟绑定Late-Binding与泛化割裂现象系统并不只是中途临时查 CSV它其实已经有md 必读 CSV 检索 genre_profile的双轨资料体系。ContextManager._build_pack中既有genre_profile self._build_runtime_genre_profile(state, story_contract)的运行时画像构建也有从index_manager拉取 reading power、pattern usage、review trend 等读者信号的_load_reader_signalcontext_manager.py#L271-L313。但在写作中系统仍要求大模型在具体阶段按需调用reference_search.pyreference_search.py查通用条目如如何写战斗。CSV 资料库见 references/csv/其中包含写作技法、场景写法、桥段套路、爽点与节奏、裁决规则等分门别类的通用条目。危害查出来的大多是通用网文技巧而不是本书专属设定。系统缺乏一个前置的聚合层把通用套路和本书主角特质、题材调性、系统边界揉合在一起导致写出的剧情虽然套路标准却千篇一律缺乏本书的灵魂与特色。知识供给的晚绑定让通用知识无法与专属设定在写作前完成融合。四、流程编排与校验机制漏洞Workflow Verification4.1 事后验尸而非事前避坑的防线设计现象系统高度依赖 Step 3 的 Reviewer Agent 去审查已经写完的正文发现 Blocking 毒点后再打回 Step 4润色修复。相关实现与规范见 reviewer.md、review-schema.md 与 blocking-override-guidelines.md。危害防线设得太晚。如果模型在起草时犯了方向性或结构性错误如写死了不该死的核心角色或触碰了严重毒点依靠润色改表达不改事实是根本救不回来的。这会导致无解的死循环或只能产出打补丁式的劣质文本。校验的时机问题本质上是预防 vs. 治疗的架构选择——当前的架构默认选择了后者。4.2 缺乏大纲履约的强制校验No Fulfillment Verification现象系统已经能读取chapter outline、plot_structure、mandatory_nodes、prohibitions这类计划信息。大纲加载逻辑见 chapter_outline_loader.py它会按章节号匹配第N章*.md文件、按卷号匹配第N卷-详细大纲.md文件chapter_outline_loader.py#L76-L98并从state.json的progress.volumes_planned反推卷号chapter_outline_loader.py#L36-L73。但在写后提交阶段系统只提取记录实际写了什么What is不会严谨地进行结构化 Diff对比大纲要求写什么What was planned vs. achieved如 CBN/CEN 节点。危害如果模型因为篇幅原因漏写了一个关键的暗杀伏笔系统只会完美地提取已写的内容而不会报错大纲要求未履约。这会悄无声息地引发后续章节大纲的连锁崩盘——一个未完成的关键节点会在后续章节中被当成已完成继续推理。五、数据回写与后置处理隐患Data Write-back Disambiguation5.1 事务割裂与幽灵状态Fragmented DB Transactions现象Step 5 要求将结果分别写入state.json、index.db、summaries和memory四个不同的地方。需要校准的是当前state_managerstate_manager.py对自身写盘已经有局部原子写和 pending 快照保护——它内部维护了大量 pending 缓冲_pending_entity_patches、_pending_state_changes、_pending_disambiguation_warnings等state_manager.py#L140-L152写盘时与security_utils.atomic_write_json保持一致使用state.json.lock锁文件state_manager.py#L126。但 StateManager 内部还维护了state.json SQLiteindex.db的双写同步逻辑_sync_to_sqlite、_sync_pending_patches_to_sqlite包含 pending 快照恢复机制——这在单个模块内部就已经引入了额外的一致性复杂度。危害风险存在于两个层面内层StateManager的 JSON SQLite 双写如果部分失败虽然有快照恢复但恢复逻辑本身也可能在极端情况下不完整外层四个存储的跨库写操作一旦中途发生中断仍会导致 DB 记录角色已死而state.json里角色还活着或摘要和长期记忆没有同步更新。这种幽灵状态会在生成下一章时把模型彻底搞疯——它读到的每个存储都在讲述一个略有出入的故事版本。值得说明的是新架构引入的ChapterCommitServicechapter_commit_service.py正是为了解决这一问题的尝试——它通过apply_projection_writers统一驱动StateProjectionWriter、IndexProjectionWriter、SummaryProjectionWriter、MemoryProjectionWriter、VectorProjectionWriter五个投影写入器chapter_commit_service.py#L98-L111把提交结果落盘为.story-system/commits/chapter_XXX.commit.jsonchapter_commit_service.py#L91-L96。注意这是诊断之后的演进产物恰好验证了统一章节提交主链正是报告指出的正确方向。5.2 幻觉错误被后置消歧放大为索引污染风险Index Pollution via Disambiguation现象如果在 Step 2 模型产生了幻觉把主角林辰错写成了张辰后置消歧未必会直接报错打回。需要校准的是当前系统对消歧有置信度分层不是无脑把所有错误都写死——ContextManager.apply_confidence_filtercontext_manager.py#L157-L163按min_confidence阈值过滤低置信条目filter_invalid_itemscontext_manager.py#L143-L155还会剔除被index_manager标记为confirmed无效的实体仅对pending无效的实体附加pending_invalid警告。但它确实存在一个风险窗口一旦错误命中可采用区间后置消歧就可能把错误实体归并写入后续索引链路。危害纯粹的写作幻觉不一定会被当场拦截反而可能以低置信但被采用的形式沉淀为别名、出场记录、关系记录或状态更新。长期来看这仍会污染数据库使后续消歧越来越乱——错误的实体关系一旦进入索引就会成为后续所有章节上下文装配的既定事实。5.3 消歧警告的向后传染Context Leaking现象如果 Step 5 发现模棱两可的名字且无法自动消歧会将其记入state.json的disambiguation_pending高于阈值但仍不稳的则进入disambiguation_warnings并在写下一章时通过上下文装配链被继续读取。实现见_build_pack中的 alerts 组装context_manager.py#L261-L268alerts: { disambiguation_warnings: ( state.get(disambiguation_warnings, [])[-alert_slice:] if alert_slice else [] ), disambiguation_pending: ( state.get(disambiguation_pending, [])[-alert_slice:] if alert_slice else [] ), },其中alert_slice max(0, int(self.config.context_alerts_slice))即通过配置控制警报条数切片默认取最近若干条。ContextRanker.rank_alerts还会对这些警报做排序context_ranker.py#L42-L45。危害上一章的消歧烂账变成了下一章起草时的噪音。这极大地分散了模型写新剧情的注意力甚至诱导模型在新章节中强行加戏去解释上一章的名字问题破坏行文流畅度。问题从数据质量升级为了上下文信噪比——警报系统本应保护剧情却成了剧情流畅性的干扰源。5.4 状态投影主导语义事件只有痕迹没有主链State Overwrite vs. Delta Events现象Data Agent 和数据链并不是完全没有 Delta 事件实际上已经存在六类事件痕迹事件类型说明state_changes状态变更relationship_events关系事件timeline_events时间线事件world_rules世界规则open_loops未闭合叙事环reader_promises对读者的承诺其中关系事件层面代码里已经有比relationships_new更完整的relationship_events表具备较强的结构化能力。但这些事件整体仍分散在state、index、memory等不同层里没有统一的 canonical event log。系统主链仍然更偏向状态投影更新而不是事件驱动更新。危害结果就是系统能记录已经变成金丹却很难以统一方式表达如何突破、消耗了什么资源、引发了什么异象、这次突破应如何修改上层世界规则。这使得系统无法自动感知并触发设定升级或力量体系阈值扩展模型仍然需要像瞎子摸象一样去猜目前的战力天花板。六、总结半成品中枢的缝补现状与新架构的收束方向在没有引入 Story Intelligence System Spec 的前置契约约束之前系统并不是完全靠大模型裸奔而是已经靠多个半成品中枢在缝缝补补半成品中枢职责现状context_managercontext_ranker上下文聚合与优先级排序已可用但存在预算截断黑洞genre_*genre_aliases.py、genre_profile_builder.py题材归一化与画像构建已可用但知识晚绑定state_manager结构化状态回写含 JSON SQLite 双写同步局部原子写缺跨库事务memory writer / orchestrator长期事实沉淀已可用未收束进主链override_contracts追读力债务的违背记录Override Ledger 雏形已可用未覆盖核心世界设定但这些能力还没有被收束成一个统一的故事事实系统。因此当前系统最根本的问题不是模型不够强而是系统已经有多个局部结构层包括 Override Contract 雏形和 Delta 事件底座但还没有统一故事合同Story Contract、统一章节提交主链Commit Chain和覆盖全局世界设定的统一演进账本Override Ledger。这也正是后续新架构见 narrative-intelligence-roadmap-2026-06-10.md、story-repo-spec-2026-06-10.md 及 phase0 系列审计计划的核心价值所在生成强约束的Master / Volume / ChapterJSON 合同让写什么在写作前就被结构化锁定杜绝信息在装配阶段的静默丢失建立显式的 Override 账本让旧规则被新剧情合法推翻成为一等公民而非靠模型自行理解冲突指令事前给足绝对红线、系统边界和消歧域把防线从事后验尸前移到事前避坑把state / index / summary / memory / RAG从散落真理源降级为合同提交后的投影层用单一提交主链驱动多存储的确定性回写消除幽灵状态与事务割裂。只有提供完美、无歧义、可追溯且前后一致的输入大模型才能持续、稳定地输出高质量的长篇连载。这份诊断报告的价值在于它用 10 个具体可复现的问题把AI 网文创作系统崩溃这一模糊现象拆解成了一个个可以用架构手段逐一击破的工程缺陷。延伸阅读仓库内相关资源诊断之后的新架构演进story-system-phase4.md、story-system-phase5.md、narrative-intelligence-roadmap-2026-06-10.md上下文装配实现context_manager.py、context_ranker.py、context_weights.py章节提交主链chapter_commit_service.py、chapter_commit_schema.pyOverride Ledger 雏形index_debt_mixin.py、override_ledger_service.py校验与审查体系prewrite_validator.py、reviewer.md、review-schema.md【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
webnovel-writer 长篇连载崩溃根因诊断：从松散管道到统一故事合同（Story Contract）的架构演进
webnovel-writer 长篇连载崩溃根因诊断从松散管道到统一故事合同Story Contract的架构演进【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer导读本文基于 webnovel-writer 项目《当前系统架构诊断报告》系统剖析一套基于大模型指令的网文创作辅助系统在 200 万字量级连载场景下的结构性缺陷。报告的核心结论是系统的痛点不在于模型写不好或执行失误而在于系统提供给模型的信息结构、校验时机和数据流转机制存在根本性硬伤——试图用松散的管道脚本Pipeline管理极其复杂的网文世界状态机State Machine最终必然导致长篇连载走向崩盘。读完本文你将理解多头真理源上下文截断黑洞事后验尸式防线事务割裂等 10 个致命问题的具体成因、源码级证据以及它们如何共同指向统一故事合同SSOT 统一章节提交主链Commit Chain 统一演进账本Override Ledger这一新架构方向。一、诊断前提与核心结论这份诊断报告写于引入 Story Intelligence System Specstory-system-phase4.md 与 story-system-phase5.md 所描述的统一故事智能系统之前其诊断前提是假设大语言模型如 Opus 4.6的指令遵循能力完美能够完美解析并执行所有 Bash 命令和格式要求。即使在这样的理想前提下系统依然会崩溃。这恰好证明了问题不在模型侧而在系统侧。报告同时给出了一个重要的校准结论当前系统并不是完全没有结构化能力而是已经具备多个半成品中枢但仍缺少统一故事合同SSOT与统一章节提交主链。也就是说系统不是裸奔而是在靠多个局部结构层缝缝补补。核心结论一句话概括系统已经有多个局部结构层包括 Override Contract 雏形和 Delta 事件底座但还没有统一故事合同Story Contract、统一章节提交主链Commit Chain和覆盖全局世界设定的统一演进账本Override Ledger。这正是报告最后指出的新架构核心价值所在生成强约束的Master / Volume / ChapterJSON 合同建立显式的 Override 账本事前给足绝对红线、系统边界和消歧域把state / index / summary / memory / RAG从散落真理源降级为合同提交后的投影层。二、核心架构与真理源缺陷Architecture Single Source of Truth2.1 多头真理Multiple Sources of Truth导致的认知撕裂现象系统的设定散落在四个不同的载体中载体类型职责state.json动态状态主角状态、进度、位置、关系快照genre-profiles.md静态调性题材画像与写作调性见 genre-profiles.mdindex.db碎片化实体SQLite 索引实体别名、出场记录、关系记录memory长期事实项目记忆与长期事实沉淀见 memory/ 目录虽然context_managercontext_manager.py和genre_*系列模块genre_aliases.py、genre_profile_builder.py已经在尝试聚合这些信息但它们本质上仍是运行时装配器和局部中枢而不是统一的单一真理源SSOT。危害当剧情发生合理反转或设定升级时系统无法做到全局同步。模型会同时接到冲突的指令——例如大纲outline要求主角废柴隐忍而state.json显示主角已经天下无敌。极度聪明的模型为了兼顾双方反而会写出精神分裂般的割裂剧情。从源码看ContextManager._build_packcontext_manager.py#L165-L269确实把chapter_outline、protagonist_snapshot、worldview_skeleton、power_system_skeleton、story_contract、memory、long_term_memory等多个来源一股脑装进同一个 context pack——这正是多头真理在实现层面的直接体现装配器只负责都拿来不负责谁说了算。2.2 设定演进账本仅有雏形尚未覆盖核心世界设定Override Ledger Gap现象网文的核心规则是会随着剧情推进被打破的如主角打破了某项世界限制。当前系统已在 v5.3 引入了override_contracts表见 index_debt_mixin.py具备完整的 CRUD 操作字段包括字段含义constraint_type被违背的约束类型rationale_type违背理由类型rationale_text违背理由文本payback_plan偿还计划追读力债务due_chapter到期章节status状态pending / fulfilled / cancelled源码层面的实现相当严谨create_override_contractindex_debt_mixin.py#L15-L97使用 SQLite 的INSERT ... ON CONFLICT ... DO UPDATE实现原子 UPSERT要求 SQLite 3.24且完全冻结终态——已fulfilled/cancelled的合约所有字段都不会再被修改get_pending_overrides与get_overdue_overrides则负责按due_chapter排序提取待偿还债务。但该机制目前仅服务于追读力债务系统的软建议违背记录尚未扩展为核心世界设定力量体系、角色命运、世界规则的演进账本。对于这些核心设定的修改系统本质上仍只有静默覆盖Overwrite或局部投影更新。危害没有机制明确告诉 AI卷五已经合法推翻了卷一的隐忍设定现在的最高准则是无敌爽文。系统把所有的旧规则和新状态一锅端地喂给 AI造成严重的上下文污染和逻辑死锁。Override Contract 的基础设施已经存在但其应用范围的局限性使它无法解决核心问题——这正印证了基础设施就位、应用范围缺位的典型架构半成品状态。三、上下文装配与知识供给痛点Context Knowledge Assembly3.1 机械截断导致的信息黑洞The Blind Spot of Context Truncation现象context_manager.py确实已经在做上下文聚合且context_ranker.py已经对 alerts 等信息做了优先级排序与筛选说明系统并非完全无脑塞上下文。但最终输出仍采用按权重和字数预算、强行截断字符串的方式来组装上下文。源码证据链完整ContextManager.TEMPLATE_WEIGHTS定义了 4 种写作模板的权重context_weights.py#L12-L17TEMPLATE_WEIGHTS: dict[str, dict[str, float]] { plot: {core: 0.40, scene: 0.35, global: 0.25}, battle: {core: 0.35, scene: 0.45, global: 0.20}, emotion: {core: 0.45, scene: 0.35, global: 0.20}, transition: {core: 0.50, scene: 0.25, global: 0.25}, }权重还会按连载阶段动态调整TEMPLATE_WEIGHTS_DYNAMIC_DEFAULTcontext_weights.py#L19-L38early≤30 章重core0.48、late≥120 章重global0.35。阶段判定逻辑见_resolve_context_stagecontext_manager.py#L584-L591。_assemble_json_payload按SECTION_ORDER顺序组装 payload权重 0 或属于EXTRA_SECTIONS的区块才会进入输出context_manager.py#L120-L141。截断发生在更底层_load_outline直接对大纲做max_chars1500的截断context_manager.py#L690-L691_extract_summary_excerpt对剧情摘要做excerpt[:max_chars]的硬截断context_manager.py#L742-L749章节摘要文件按ch{chapter:04d}.md命名从summaries/目录读取context_manager.py#L751-L758。危害模型再聪明也无法遵守它没看到的规则。关键毒点、核心力量限制或重要伏笔极容易因为刚好超出字符串预算而被底层脚本静默丢弃导致模型不得不靠幻觉Hallucination填补空白引发设定崩塌。问题不在没有聚合而在于聚合后的输入仍可能被预算逻辑打成信息黑洞。3.2 知识延迟绑定Late-Binding与泛化割裂现象系统并不只是中途临时查 CSV它其实已经有md 必读 CSV 检索 genre_profile的双轨资料体系。ContextManager._build_pack中既有genre_profile self._build_runtime_genre_profile(state, story_contract)的运行时画像构建也有从index_manager拉取 reading power、pattern usage、review trend 等读者信号的_load_reader_signalcontext_manager.py#L271-L313。但在写作中系统仍要求大模型在具体阶段按需调用reference_search.pyreference_search.py查通用条目如如何写战斗。CSV 资料库见 references/csv/其中包含写作技法、场景写法、桥段套路、爽点与节奏、裁决规则等分门别类的通用条目。危害查出来的大多是通用网文技巧而不是本书专属设定。系统缺乏一个前置的聚合层把通用套路和本书主角特质、题材调性、系统边界揉合在一起导致写出的剧情虽然套路标准却千篇一律缺乏本书的灵魂与特色。知识供给的晚绑定让通用知识无法与专属设定在写作前完成融合。四、流程编排与校验机制漏洞Workflow Verification4.1 事后验尸而非事前避坑的防线设计现象系统高度依赖 Step 3 的 Reviewer Agent 去审查已经写完的正文发现 Blocking 毒点后再打回 Step 4润色修复。相关实现与规范见 reviewer.md、review-schema.md 与 blocking-override-guidelines.md。危害防线设得太晚。如果模型在起草时犯了方向性或结构性错误如写死了不该死的核心角色或触碰了严重毒点依靠润色改表达不改事实是根本救不回来的。这会导致无解的死循环或只能产出打补丁式的劣质文本。校验的时机问题本质上是预防 vs. 治疗的架构选择——当前的架构默认选择了后者。4.2 缺乏大纲履约的强制校验No Fulfillment Verification现象系统已经能读取chapter outline、plot_structure、mandatory_nodes、prohibitions这类计划信息。大纲加载逻辑见 chapter_outline_loader.py它会按章节号匹配第N章*.md文件、按卷号匹配第N卷-详细大纲.md文件chapter_outline_loader.py#L76-L98并从state.json的progress.volumes_planned反推卷号chapter_outline_loader.py#L36-L73。但在写后提交阶段系统只提取记录实际写了什么What is不会严谨地进行结构化 Diff对比大纲要求写什么What was planned vs. achieved如 CBN/CEN 节点。危害如果模型因为篇幅原因漏写了一个关键的暗杀伏笔系统只会完美地提取已写的内容而不会报错大纲要求未履约。这会悄无声息地引发后续章节大纲的连锁崩盘——一个未完成的关键节点会在后续章节中被当成已完成继续推理。五、数据回写与后置处理隐患Data Write-back Disambiguation5.1 事务割裂与幽灵状态Fragmented DB Transactions现象Step 5 要求将结果分别写入state.json、index.db、summaries和memory四个不同的地方。需要校准的是当前state_managerstate_manager.py对自身写盘已经有局部原子写和 pending 快照保护——它内部维护了大量 pending 缓冲_pending_entity_patches、_pending_state_changes、_pending_disambiguation_warnings等state_manager.py#L140-L152写盘时与security_utils.atomic_write_json保持一致使用state.json.lock锁文件state_manager.py#L126。但 StateManager 内部还维护了state.json SQLiteindex.db的双写同步逻辑_sync_to_sqlite、_sync_pending_patches_to_sqlite包含 pending 快照恢复机制——这在单个模块内部就已经引入了额外的一致性复杂度。危害风险存在于两个层面内层StateManager的 JSON SQLite 双写如果部分失败虽然有快照恢复但恢复逻辑本身也可能在极端情况下不完整外层四个存储的跨库写操作一旦中途发生中断仍会导致 DB 记录角色已死而state.json里角色还活着或摘要和长期记忆没有同步更新。这种幽灵状态会在生成下一章时把模型彻底搞疯——它读到的每个存储都在讲述一个略有出入的故事版本。值得说明的是新架构引入的ChapterCommitServicechapter_commit_service.py正是为了解决这一问题的尝试——它通过apply_projection_writers统一驱动StateProjectionWriter、IndexProjectionWriter、SummaryProjectionWriter、MemoryProjectionWriter、VectorProjectionWriter五个投影写入器chapter_commit_service.py#L98-L111把提交结果落盘为.story-system/commits/chapter_XXX.commit.jsonchapter_commit_service.py#L91-L96。注意这是诊断之后的演进产物恰好验证了统一章节提交主链正是报告指出的正确方向。5.2 幻觉错误被后置消歧放大为索引污染风险Index Pollution via Disambiguation现象如果在 Step 2 模型产生了幻觉把主角林辰错写成了张辰后置消歧未必会直接报错打回。需要校准的是当前系统对消歧有置信度分层不是无脑把所有错误都写死——ContextManager.apply_confidence_filtercontext_manager.py#L157-L163按min_confidence阈值过滤低置信条目filter_invalid_itemscontext_manager.py#L143-L155还会剔除被index_manager标记为confirmed无效的实体仅对pending无效的实体附加pending_invalid警告。但它确实存在一个风险窗口一旦错误命中可采用区间后置消歧就可能把错误实体归并写入后续索引链路。危害纯粹的写作幻觉不一定会被当场拦截反而可能以低置信但被采用的形式沉淀为别名、出场记录、关系记录或状态更新。长期来看这仍会污染数据库使后续消歧越来越乱——错误的实体关系一旦进入索引就会成为后续所有章节上下文装配的既定事实。5.3 消歧警告的向后传染Context Leaking现象如果 Step 5 发现模棱两可的名字且无法自动消歧会将其记入state.json的disambiguation_pending高于阈值但仍不稳的则进入disambiguation_warnings并在写下一章时通过上下文装配链被继续读取。实现见_build_pack中的 alerts 组装context_manager.py#L261-L268alerts: { disambiguation_warnings: ( state.get(disambiguation_warnings, [])[-alert_slice:] if alert_slice else [] ), disambiguation_pending: ( state.get(disambiguation_pending, [])[-alert_slice:] if alert_slice else [] ), },其中alert_slice max(0, int(self.config.context_alerts_slice))即通过配置控制警报条数切片默认取最近若干条。ContextRanker.rank_alerts还会对这些警报做排序context_ranker.py#L42-L45。危害上一章的消歧烂账变成了下一章起草时的噪音。这极大地分散了模型写新剧情的注意力甚至诱导模型在新章节中强行加戏去解释上一章的名字问题破坏行文流畅度。问题从数据质量升级为了上下文信噪比——警报系统本应保护剧情却成了剧情流畅性的干扰源。5.4 状态投影主导语义事件只有痕迹没有主链State Overwrite vs. Delta Events现象Data Agent 和数据链并不是完全没有 Delta 事件实际上已经存在六类事件痕迹事件类型说明state_changes状态变更relationship_events关系事件timeline_events时间线事件world_rules世界规则open_loops未闭合叙事环reader_promises对读者的承诺其中关系事件层面代码里已经有比relationships_new更完整的relationship_events表具备较强的结构化能力。但这些事件整体仍分散在state、index、memory等不同层里没有统一的 canonical event log。系统主链仍然更偏向状态投影更新而不是事件驱动更新。危害结果就是系统能记录已经变成金丹却很难以统一方式表达如何突破、消耗了什么资源、引发了什么异象、这次突破应如何修改上层世界规则。这使得系统无法自动感知并触发设定升级或力量体系阈值扩展模型仍然需要像瞎子摸象一样去猜目前的战力天花板。六、总结半成品中枢的缝补现状与新架构的收束方向在没有引入 Story Intelligence System Spec 的前置契约约束之前系统并不是完全靠大模型裸奔而是已经靠多个半成品中枢在缝缝补补半成品中枢职责现状context_managercontext_ranker上下文聚合与优先级排序已可用但存在预算截断黑洞genre_*genre_aliases.py、genre_profile_builder.py题材归一化与画像构建已可用但知识晚绑定state_manager结构化状态回写含 JSON SQLite 双写同步局部原子写缺跨库事务memory writer / orchestrator长期事实沉淀已可用未收束进主链override_contracts追读力债务的违背记录Override Ledger 雏形已可用未覆盖核心世界设定但这些能力还没有被收束成一个统一的故事事实系统。因此当前系统最根本的问题不是模型不够强而是系统已经有多个局部结构层包括 Override Contract 雏形和 Delta 事件底座但还没有统一故事合同Story Contract、统一章节提交主链Commit Chain和覆盖全局世界设定的统一演进账本Override Ledger。这也正是后续新架构见 narrative-intelligence-roadmap-2026-06-10.md、story-repo-spec-2026-06-10.md 及 phase0 系列审计计划的核心价值所在生成强约束的Master / Volume / ChapterJSON 合同让写什么在写作前就被结构化锁定杜绝信息在装配阶段的静默丢失建立显式的 Override 账本让旧规则被新剧情合法推翻成为一等公民而非靠模型自行理解冲突指令事前给足绝对红线、系统边界和消歧域把防线从事后验尸前移到事前避坑把state / index / summary / memory / RAG从散落真理源降级为合同提交后的投影层用单一提交主链驱动多存储的确定性回写消除幽灵状态与事务割裂。只有提供完美、无歧义、可追溯且前后一致的输入大模型才能持续、稳定地输出高质量的长篇连载。这份诊断报告的价值在于它用 10 个具体可复现的问题把AI 网文创作系统崩溃这一模糊现象拆解成了一个个可以用架构手段逐一击破的工程缺陷。延伸阅读仓库内相关资源诊断之后的新架构演进story-system-phase4.md、story-system-phase5.md、narrative-intelligence-roadmap-2026-06-10.md上下文装配实现context_manager.py、context_ranker.py、context_weights.py章节提交主链chapter_commit_service.py、chapter_commit_schema.pyOverride Ledger 雏形index_debt_mixin.py、override_ledger_service.py校验与审查体系prewrite_validator.py、reviewer.md、review-schema.md【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
