当前系统架构诊断报告 (Current System Diagnosis)

文档状态: 诊断报告 (未引入 Story Intelligence System Spec 前) 诊断前提: 假设大语言模型（如 Opus 4.6）的指令遵循能力完美，能够完美解析并执行所有 Bash 命令和格式要求。 核心结论: 系统的痛点不在于模型写不好或执行失误，而在于系统提供给模型的信息结构、校验时机和数据流转机制存在根本性硬伤。系统试图用一套松散的管道脚本（Pipeline）去管理极其复杂的网文世界状态机（State Machine），最终不可避免地导致长篇连载走向崩盘。同时需要补一层更准确的校准：当前系统并不是完全没有结构化能力，而是已经具备多个半成品中枢，但仍缺少统一故事合同（SSOT）与统一章节提交主链。

一、核心架构与真理源缺陷 (Architecture & Single Source of Truth)

1. 多头真理（Multiple Sources of Truth）导致的认知撕裂

现象：系统的设定散落在 state.json（动态状态）、genre-profiles.md（静态调性）、index.db（碎片化实体）和 memory（长期事实）中。虽然 context_manager、genre_* 已经在尝试聚合这些信息，但它们本质上仍是运行时装配器和局部中枢，而不是统一的单一真理源（SSOT）。
危害：当剧情发生合理反转或设定升级时，系统无法做到全局同步。模型会同时接到冲突的指令（例如 md 要求主角废柴隐忍，而 state 显示已经天下无敌）。极度聪明的模型为了兼顾双方，反而会写出精神分裂般的割裂剧情。

2. 设定演进账本仅有雏形，尚未覆盖核心世界设定（Override Ledger Gap）

现象：网文的核心规则是会随着剧情推进被打破的（如主角打破了某项世界限制）。当前系统已在 v5.3 引入了 override_contracts 表（见 index_debt_mixin.py），具备完整的 CRUD 操作（含 constraint_type、rationale_type、rationale_text、payback_plan、due_chapter、status）。但该机制目前仅服务于追读力债务系统的软建议违背记录，尚未扩展为核心世界设定（力量体系、角色命运、世界规则）的演进账本。对于这些核心设定的修改，系统本质上仍只有静默覆盖（Overwrite）或局部投影更新。
危害：没有机制明确告诉 AI 注意，卷五已经合法推翻了卷一的隐忍设定，现在的最高准则是无敌爽文。系统把所有的旧规则和新状态一锅端地喂给 AI，造成严重的上下文污染和逻辑死锁。Override Contract 的基础设施已经存在，但其应用范围的局限性使得它无法解决这个核心问题。

二、上下文装配与知识供给痛点 (Context & Knowledge Assembly)

3. 机械截断导致的信息黑洞（The Blind Spot of Context Truncation）

现象：context_manager.py 确实已经在做上下文聚合，且 context_ranker.py 已经对 alerts 等信息做了优先级排序与筛选（说明系统并非完全无脑塞上下文）。但最终输出仍采用按权重（TEMPLATE_WEIGHTS）和字数预算，强行截断字符串（_compact_json_text）的方式来组装上下文。
危害：模型再聪明，也无法遵守它没看到的规则。关键毒点、核心力量限制或重要伏笔，极容易因为刚好超出字符串预算而被底层脚本静默丢弃。导致模型不得不靠幻觉（Hallucination）填补空白，引发设定崩塌。问题不在“没有聚合”，而在于聚合后的输入仍可能被预算逻辑打成信息黑洞。

4. 知识延迟绑定（Late-Binding）与泛化割裂

现象：系统并不只是中途临时查 CSV，它其实已经有 md 必读 + CSV 检索 + genre_profile 的双轨资料体系。但在写作中，系统仍要求大模型在具体阶段按需调用 reference_search.py 查通用条目（如如何写战斗）。
危害：查出来的大多是通用网文技巧，而不是本书专属设定。系统缺乏一个前置的聚合层把通用套路和本书主角特质、题材调性、系统边界揉合在一起，导致写出的剧情虽然套路标准，但千篇一律，缺乏本书的灵魂与特色。

三、流程编排与校验机制漏洞 (Workflow & Verification)

5. 事后验尸而非事前避坑的防线设计

现象：系统高度依赖 Step 3 的 Reviewer Agent 去审查已经写完的正文，发现 Blocking 毒点后再打回 Step 4（润色）修复。
危害：防线设得太晚。如果模型在起草时犯了方向性或结构性错误（如写死了不该死的核心角色，或触碰了严重毒点），依靠润色（改表达不改事实）是根本救不回来的。这会导致无解的死循环，或只能产出打补丁式的劣质文本。

6. 缺乏大纲履约的强制校验（No Fulfillment Verification）

现象：系统已经能读取 chapter outline、plot_structure、mandatory_nodes、prohibitions 这类计划信息，但在写后提交阶段，只会提取记录实际写了什么（What is），不会严谨地进行结构化 Diff，对比大纲要求写什么（What was planned vs. achieved，如 CBN/CEN 节点）。
危害：如果模型因为篇幅原因漏写了一个关键的暗杀伏笔，系统只会完美地提取已写的内容，而不会报错大纲要求未履约。这会悄无声息地引发后续章节大纲的连锁崩盘。

四、数据回写与后置处理隐患 (Data Write-back & Disambiguation)

7. 事务割裂与幽灵状态（Fragmented DB Transactions）

现象：Step 5 要求将结果分别写入 state.json、index.db、summaries 和 memory 四个不同的地方。需要校准的是：当前 state_manager 对自身写盘已经有局部原子写和 pending 快照保护，但这仍然不是跨存储的章节级事务一致性（ACID）。此外，StateManager 内部还维护了 state.json + SQLite（index.db）的双写同步逻辑（_sync_to_sqlite、_sync_pending_patches_to_sqlite），包含 pending 快照恢复机制，这在单个模块内部就已经引入了额外的一致性复杂度。
危害：风险存在于两个层面。内层：StateManager 的 JSON + SQLite 双写如果部分失败，虽然有快照恢复，但恢复逻辑本身也可能在极端情况下不完整。外层：四个存储的跨库写操作一旦中途发生中断，仍然会导致 DB 记录角色已死，而 state.json 里角色还活着，或摘要和长期记忆没有同步更新。这种幽灵状态会在生成下一章时把模型彻底搞疯。

8. 幻觉错误被后置消歧放大为索引污染风险（Index Pollution via Disambiguation）

现象：如果在 Step 2 模型产生了幻觉，把主角林辰错写成了张辰，后置消歧未必会直接报错打回。需要校准的是：当前系统对消歧有置信度分层，不是无脑把所有错误都写死；但它确实存在一个风险窗口，一旦错误命中“可采用”区间，后置消歧就可能把错误实体归并写入后续索引链路。
危害：这意味着纯粹的写作幻觉，不一定会被当场拦截，反而可能以“低置信但被采用”的形式被沉淀为别名、出场记录、关系记录或状态更新。长期来看，这仍会污染数据库，使后续消歧越来越乱。

9. 消歧警告的向后传染（Context Leaking）

现象：如果 Step 5 发现模棱两可的名字且无法自动消歧，会将其记入 state.json 的 disambiguation_pending，高于阈值但仍不稳的则进入 disambiguation_warnings，并在写下一章时通过上下文装配链被继续读取。
危害：上一章的消歧烂账，变成了下一章起草时的噪音。这极大地分散了模型写新剧情的注意力，甚至诱导模型在新章节中强行加戏去解释上一章的名字问题，破坏行文流畅度。

10. 状态投影主导，语义事件只有痕迹没有主链（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_manager + context_ranker 在做上下文聚合与优先级排序
genre_* 在做题材归一化与画像构建
state_manager 在做结构化状态回写（含 JSON + SQLite 双写同步）
memory writer / orchestrator 在做长期事实沉淀
override_contracts 在做追读力债务的违背记录（Override Ledger 雏形）

但这些能力还没有被收束成一个统一的故事事实系统。

因此，当前系统最根本的问题不是“模型不够强”，而是：

系统已经有多个局部结构层（包括 Override Contract 雏形和 Delta 事件底座），但还没有统一故事合同（Story Contract）、统一章节提交主链（Commit Chain）和覆盖全局世界设定的统一演进账本（Override Ledger）。

这也正是新架构的核心价值所在：

生成强约束的 Master / Volume / Chapter JSON 合同
建立显式的 Override 账本
事前给足绝对红线、系统边界和消歧域
把 state / index / summary / memory / RAG 从“散落真理源”降级为“合同提交后的投影层”

只有提供完美、无歧义、可追溯且前后一致的输入，大模型才能持续、稳定地输出高质量的长篇连载。

current-system-diagnosis.md 10 KB Permalink Histórico Raw