Webnovel Writer 数据层设计揭秘state.json、index.db 与 vectors.db 三库分工全解析【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是一款基于 Claude Code 的长篇网文辅助创作系统用 state.json、index.db、vectors.db 三层存储分工协作解决 AI 写作中的遗忘与幻觉问题支持 200 万字量级连载。为什么长篇网文 AI 写作要先解决「记忆」问题写 200 万字网文最大的敌人不是灵感而是记忆。写到第 300 章时AI 很容易把主角的境界写错、把伏笔忘了回收、甚至编出没设定过的新设定。Webnovel Writer 的思路很直接把故事的全部事实拆成三层存储各司其职——存储角色一句话定位state.json仪表盘5KB 精简状态进度、主角快照、节奏追踪index.db结构化主库SQLite实体、别名、关系、状态变化vectors.db语义检索引擎向量 BM25 混合检索按需找回旧场景三者都位于项目的.webnovel/目录下完整目录约定见 system-data-flow.md架构总览见 overview.md。state.json小于 5KB 的「仪表盘」早期版本里实体、关系、状态变化全都塞在 state.json 里结果 20 章之后文件爆炸token 成本飙升。于是团队做了一个关键架构决策把大数据迁出state.json 只留「最常读、体积小」的状态。现在它只保留这些高频字段progress当前章节、总字数、卷进度protagonist_state主角境界、位置、金手指快照strand_tracker主线/感情线/世界观线的节奏追踪chapter_meta每章的钩子类型、开场模式避免连续重复套路disambiguation_pending待人工确认的消歧记录完整字段说明见 state-schema.md。它被刻意压到5KB 以内Context Agent 每章都可以全量读入几乎零成本。index.dbSQLite 主存储实体关系全在这里index.db承担了原本 state.json 里最膨胀的几块数据核心表结构如下表存什么解决的痛点entities角色/地点/物品/势力/招式含当前状态 JSON主角境界、位置不再散落在各章aliases别名一对多映射如「天云宗」→地点势力同名实体自动消歧state_changes字段变更流水旧值→新值章节号任何变化都可审计回溯relationships实体间关系图谱人物关系网不丢失chapters/scenes/appearances章节元数据与出场记录快速查询「谁在第几章出场」此外还有追读力债务、审查指标等运营型表v5.3/v5.4 引入。表结构文档见 index-schema.md。它的读接口由 index_manager.py 统一管理写入则走 sql_state_manager.py 的增量写入。SQLite 让按需查询成为可能——不需要把几千个实体全塞进上下文一句 SQL 就能只取核心角色。老项目可以通过一条命令完成迁移自动备份旧 state.json 再精简python webnovel-writer/scripts/webnovel.py migrate --backup实现见 migrate_state_to_sqlite.py。vectors.db向量 BM25 混合检索把 200 万字「装回」上下文结构化数据解决「是什么」但「第 47 章那场雨夜戏是怎么写的」这类问题需要语义检索。vectors.db由 rag_adapter.py 管理内部有两张关键表vectors 表章节切块chunk 向量嵌入支持语义相似度搜索bm25_index 表倒排索引支持关键词精确匹配查询时走混合检索向量和 BM25 并行召回用 RRF 融合排序再经 rerank 精排取 Top 结果。这样「语义相近」和「精确命中」各占一半检索质量远超单一方式。检索配置Top-K、超时、降级策略等集中在 config.pyAPI 接入方法见 rag-and-config.md。更妙的是即使嵌入 API 不可用BM25 索引仍能让关键词检索正常工作——这是典型的优雅降级设计。一条单向数据链谁在读谁在写三库不是各自为政而是嵌在一条清晰的读写链里写作前—— Context Agent 全量读 state.json便宜SQL 按需查 index.db精准RAG 检索 vectors.db兜底组装出本章「创作任务书」。写作后—— Data Agent 从正文提取 accepted 提交物驱动投影写入器一次性更新index.db新实体/关系/状态变化→ state.json进度/主角快照→ summaries章节摘要→ vectors.db向量嵌入。 这套分工背后是明确的「真源」原则.story-system/合同树是写后主链真源而 state.json、index.db、vectors.db 都是它的投影/read-model——可以随时重建永不与正文打架。快速自检三库健康度怎么看用内置状态报告即可检查三者是否正常生成python webnovel-writer/scripts/webnovel.py status若 state.json 意外膨胀比如手动塞了实体数据跑一次migrate就能收回 SQLite。日常维护命令清单见 commands.md。小结三库分工是「不遗忘」的工程底座state.json小到能全量读负责「现在到哪了」index.db结构化可查询负责「设定是什么、变了没」vectors.db语义可检索负责「以前写过类似的吗」三者配合让 AI 在 200 万字连载里既不遗忘、也不幻觉——这正是 Webnovel Writer 数据层设计的精髓。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Webnovel Writer 数据层设计揭秘：state.json、index.db 与 vectors.db 三库分工全解析
Webnovel Writer 数据层设计揭秘state.json、index.db 与 vectors.db 三库分工全解析【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是一款基于 Claude Code 的长篇网文辅助创作系统用 state.json、index.db、vectors.db 三层存储分工协作解决 AI 写作中的遗忘与幻觉问题支持 200 万字量级连载。为什么长篇网文 AI 写作要先解决「记忆」问题写 200 万字网文最大的敌人不是灵感而是记忆。写到第 300 章时AI 很容易把主角的境界写错、把伏笔忘了回收、甚至编出没设定过的新设定。Webnovel Writer 的思路很直接把故事的全部事实拆成三层存储各司其职——存储角色一句话定位state.json仪表盘5KB 精简状态进度、主角快照、节奏追踪index.db结构化主库SQLite实体、别名、关系、状态变化vectors.db语义检索引擎向量 BM25 混合检索按需找回旧场景三者都位于项目的.webnovel/目录下完整目录约定见 system-data-flow.md架构总览见 overview.md。state.json小于 5KB 的「仪表盘」早期版本里实体、关系、状态变化全都塞在 state.json 里结果 20 章之后文件爆炸token 成本飙升。于是团队做了一个关键架构决策把大数据迁出state.json 只留「最常读、体积小」的状态。现在它只保留这些高频字段progress当前章节、总字数、卷进度protagonist_state主角境界、位置、金手指快照strand_tracker主线/感情线/世界观线的节奏追踪chapter_meta每章的钩子类型、开场模式避免连续重复套路disambiguation_pending待人工确认的消歧记录完整字段说明见 state-schema.md。它被刻意压到5KB 以内Context Agent 每章都可以全量读入几乎零成本。index.dbSQLite 主存储实体关系全在这里index.db承担了原本 state.json 里最膨胀的几块数据核心表结构如下表存什么解决的痛点entities角色/地点/物品/势力/招式含当前状态 JSON主角境界、位置不再散落在各章aliases别名一对多映射如「天云宗」→地点势力同名实体自动消歧state_changes字段变更流水旧值→新值章节号任何变化都可审计回溯relationships实体间关系图谱人物关系网不丢失chapters/scenes/appearances章节元数据与出场记录快速查询「谁在第几章出场」此外还有追读力债务、审查指标等运营型表v5.3/v5.4 引入。表结构文档见 index-schema.md。它的读接口由 index_manager.py 统一管理写入则走 sql_state_manager.py 的增量写入。SQLite 让按需查询成为可能——不需要把几千个实体全塞进上下文一句 SQL 就能只取核心角色。老项目可以通过一条命令完成迁移自动备份旧 state.json 再精简python webnovel-writer/scripts/webnovel.py migrate --backup实现见 migrate_state_to_sqlite.py。vectors.db向量 BM25 混合检索把 200 万字「装回」上下文结构化数据解决「是什么」但「第 47 章那场雨夜戏是怎么写的」这类问题需要语义检索。vectors.db由 rag_adapter.py 管理内部有两张关键表vectors 表章节切块chunk 向量嵌入支持语义相似度搜索bm25_index 表倒排索引支持关键词精确匹配查询时走混合检索向量和 BM25 并行召回用 RRF 融合排序再经 rerank 精排取 Top 结果。这样「语义相近」和「精确命中」各占一半检索质量远超单一方式。检索配置Top-K、超时、降级策略等集中在 config.pyAPI 接入方法见 rag-and-config.md。更妙的是即使嵌入 API 不可用BM25 索引仍能让关键词检索正常工作——这是典型的优雅降级设计。一条单向数据链谁在读谁在写三库不是各自为政而是嵌在一条清晰的读写链里写作前—— Context Agent 全量读 state.json便宜SQL 按需查 index.db精准RAG 检索 vectors.db兜底组装出本章「创作任务书」。写作后—— Data Agent 从正文提取 accepted 提交物驱动投影写入器一次性更新index.db新实体/关系/状态变化→ state.json进度/主角快照→ summaries章节摘要→ vectors.db向量嵌入。 这套分工背后是明确的「真源」原则.story-system/合同树是写后主链真源而 state.json、index.db、vectors.db 都是它的投影/read-model——可以随时重建永不与正文打架。快速自检三库健康度怎么看用内置状态报告即可检查三者是否正常生成python webnovel-writer/scripts/webnovel.py status若 state.json 意外膨胀比如手动塞了实体数据跑一次migrate就能收回 SQLite。日常维护命令清单见 commands.md。小结三库分工是「不遗忘」的工程底座state.json小到能全量读负责「现在到哪了」index.db结构化可查询负责「设定是什么、变了没」vectors.db语义可检索负责「以前写过类似的吗」三者配合让 AI 在 200 万字连载里既不遗忘、也不幻觉——这正是 Webnovel Writer 数据层设计的精髓。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考