docs(rfc): synthesize v7 feedback report

docs/architecture/v7-rfc-feedback-report-2026-06-16.md

@@ -0,0 +1,323 @@
+# v7 RFC 反馈合并报告
+
+> 日期：2026-06-16  
+> 范围：合并公开 RFC 反馈、Issue 引流状态、外部设计批判与事实校验，为 v7 实施计划提供输入。  
+> 状态：反馈综合报告，不是最终决策记录。
+
+## 事实来源
+
+- 公开 RFC：[Discussion #118](https://github.com/lingfengQAQ/webnovel-writer/discussions/118)，2026-06-12 发布在 Announcements 分类。
+- Issue 区指引：[Issue #119](https://github.com/lingfengQAQ/webnovel-writer/issues/119)，2026-06-12 创建，带 `help wanted`，作用是把只看 issue 区的用户引流到 RFC。
+- 本地设计文档：
+  - [v7-prd.md](v7-prd.md)
+  - [story-repo-spec-2026-06-10.md](story-repo-spec-2026-06-10.md)
+  - [multi-agent-adaptation-spec-2026-06-05.md](multi-agent-adaptation-spec-2026-06-05.md)
+- 外部运行时事实校验：Node.js `node:sqlite` 官方文档。当前文档显示，`node:sqlite` 在 Node v22.13.0 起不再要求 `--experimental-sqlite` flag，但 SQLite 模块仍未完全稳定，当前状态是 release candidate。
+- 外部设计批判：GLM 对 v7 PRD/RFC 的问题清单。其关于“RFC 未发布”的疑虑已经被事实排除；其关于 Issue #119 是否存在的疑虑经核对后也不成立。
+
+## 总结
+
+公开 RFC 流程是成立的：Discussion #118 已发布，Issue #119 也确实承担了 issue 区引流作用。目前公开反馈没有否定 v7 方向，反而集中验证了四个设计重点：降低 token 成本、增加作者确认点、改善弱模型可用性、明确 Codex / 多宿主协作模式。
+
+外部设计批判也有价值，但最强的部分不是产品方向错误，而是 PRD/spec 中若干承诺过硬、边界不够诚实。建议在 v7.0 实施前优先处理三项：
+
+1. 自动模式的批次叠加视图必须补充一致性规则。
+2. `node:sqlite` 运行时承诺必须明确 Node patch 版本下限和降级方案。
+3. 如果重建器和三审要确定性验证履历证据，履历必须使用结构化锚点。
+
+其他问题更适合作为 spec 澄清或 7.x 议题处理，包括 `.cache` 删除后的代价、关键词扫描的机械/语义边界、三审在弱宿主上的降级模式，以及公开 RFC 中“没有数据库”的措辞。
+
+## 公开 RFC 反馈
+
+### 1. Token 成本与弱模型现实
+
+事实：
+
+- 有用户反馈 Claude 在读完大纲前已经消耗过多预算。
+- 有用户反馈 DeepSeek v4 Pro 指令遵循能力较差。
+- 后续讨论多次把写作质量问题归因到模型是否能稳定遵循指令。
+
+影响：
+
+- 这支持 v7 “精准读取”和“脚本承担可计算工作”的方向。
+- v7 冒烟测试不能只覆盖 Claude/Codex 的强模型路径，也需要覆盖低预算、弱指令遵循模型下的可用性。
+
+建议：
+
+- 为 v7 增加低预算验证场景：构建书籍上下文、生成大纲/材料、写一章，并记录严格 token 成本。
+- 对弱模型宿主保持保守承诺。如果某宿主/模型不能可靠执行三审，应标记为兼容模式，而不是完整质量模式。
+
+### 2. 规划流程需要作者确认点
+
+事实：
+
+- 有用户指出 v6 `/webnovel-plan` 把卷纲和章纲生成绑定得过紧，作者很难先优化卷纲，再单独生成章纲。
+- 有用户强调，人类的情感判断和互动比全自动更重要。
+- 维护者回应中承认 v6 在创意阶段之后缺少足够的人机互动，v7 应该改善这一点。
+
+影响：
+
+- 这是 RFC 线程中最明确的产品反馈。
+- v7 需要避免把“单一入口状态机”做成“一条命令跑太远”。
+
+建议：
+
+- v7.0 规划流程设置明确停顿点：
+  - 建书前提 / 总纲
+  - 卷纲
+  - 章纲或场景 brief
+  - 初稿
+  - 审稿 / 定稿
+- 自动模式应描述为批量辅助，而不是替代作者判断。
+
+### 3. 主角动机 / 目标检查
+
+事实：
+
+- 有用户建议显式加入“主角动机 / 目标”，因为 AI 常写出行动逻辑弱的问题，例如无意义出行、无缘由冒险。
+- 维护者回应倾向于把它纳入审稿，而不是新增一个顶层术语类目。
+
+影响：
+
+- 它不适合变成伏笔、悬念、感情线之外的第四本“线索账本”。
+- 它很适合进入三审清单，尤其是编辑审和设定一致性审。
+
+建议：
+
+- 在审稿清单中加入：主角每个主要行动必须有即时驱动、可见压力、预期收益、情绪原因，或明确标注为非理性行为。
+- 在审稿报告中加入“动机缺口 / 行动逻辑缺口”这一类问题。
+
+### 4. 文风对齐 / 作者声音
+
+事实：
+
+- 有用户提出较完整的文风方案：从作者样本抽取风格指纹，拆成原子叙事操作，组合成场景级模式组，并为 scene beat 打文风标签。
+- 后续讨论指出，携带文风指导会增加 token 成本，弱模型也未必能遵守。
+- 维护者回应认可关键问题是让模型在正确时机使用正确技巧。
+
+影响：
+
+- 这验证了 PRD 当前判断：AI 味是分层问题，v7.0 不应过度承诺“反 AI 检测”。
+- 最可执行的方向不是只在成稿后修文风，而是在场景/章纲层就放入文风指导。
+
+建议：
+
+- v7.0 公开承诺保持保守：目标是“读者不出戏”，不是躲避 AI 检测器。
+- 将以下能力放入 v7.x 设计空间：
+  - 文风指纹抽取
+  - 作者确认过的写法模式
+  - scene beat 文风标签
+  - 可缓存的文风指导，避免 token 成本失控
+
+### 5. Codex / 多宿主编排
+
+事实：
+
+- 有用户尝试把系统迁移到 Codex，并建议由一个 master AI 控制阶段推进、ready payload、校验和阻塞。
+- 维护者回应认为这个思路可以吸收，同时指出成本权衡：更多 subagent 会增加 token 消耗，但上下文隔离能减少噪声。
+
+影响：
+
+- 这与 `multi-agent-adaptation-spec` 的方向一致：三审新鲜上下文有价值，但不是所有宿主都能等价支持。
+- 产品需要明确质量/成本模式，而不是假设多宿主体验完全一致。
+
+建议：
+
+- 定义两种模式：
+  - 兼容模式：一个主 agent 顺序执行各阶段，并明确报告审稿隔离下降。
+  - 质量模式：读者审、编辑审、设定一致性审分别由独立上下文或 subagent 执行。
+- 审稿报告中应说明本次使用了哪种模式。
+
+## 设计审查发现
+
+### A. v7.0 前必须处理
+
+#### A1. 自动模式叠加视图的一致性
+
+事实：
+
+- `story-repo-spec` 要求自动模式组装“已定稿内容 + 待定稿批次预登记”的叠加视图。
+- spec 没有定义：如果待定稿批次里的第 K 章被作者打回，而 K+1 到 N 章已经使用了第 K 章的预登记事实，应如何处理。
+
+风险：
+
+- 没有明确规则时，实现很容易滑向多版本状态管理。
+- 这会重新引入 v7 想要消除的状态冲突问题。
+
+建议决策：
+
+- v7.0 优先采用硬隔离：同一待定稿批次内，各章可以共享已定稿状态和已批准大纲，但不能依赖同批次前面未定稿章节的预登记事实。
+- 如果后续章节必须依赖前面待定稿章节，应缩小批次或设置显式批次 checkpoint。
+- 版本链叠加视图可以放到 7.x，除非已有具体实现设计。
+
+#### A2. `node:sqlite` 运行时承诺
+
+事实：
+
+- PRD/spec 目前写法是 Node >= 22，并以 Node 内置 `node:sqlite` 维持零第三方依赖承诺。
+- Node 官方文档显示，`node:sqlite` 在早期 Node 22 需要 `--experimental-sqlite`，从 v22.13.0 起不再需要该 flag，但模块仍未完全稳定。
+
+风险：
+
+- “Node >= 22”过宽。
+- 如果把 `node:sqlite` 作为唯一缓存层，用户在较早 Node 22 patch 或未来 API 变动下可能直接不可用。
+
+建议决策：
+
+- 如果 v7.0 使用 `node:sqlite`，运行时要求应写成 Node >= 22.13.0。
+- 安装/启动检测应输出精确 Node 版本，并说明内置 SQLite 是否可用。
+- 保留降级方案：v7.0 使用纯文件缓存，或把 SQLite 后端标记为可选。
+
+#### A3. 履历证据需要结构化锚点
+
+事实：
+
+- spec 要求线索履历行引用章节证据，三审负责检查证据是否真实存在。
+- cache rebuilder 被描述为格式参考实现。
+
+风险：
+
+- “见本章结尾对峙段”这类自然语言证据无法被脚本确定性重建或校验。
+- 语义验证难题会从写作时转移到重建时。
+
+建议决策：
+
+- 定稿章节加入结构化锚点，例如 `第152章#p087-p093` 或 `第152章 §3`。
+- 重建器只验证锚点存在，并指向稳定文本范围。
+- 证据语义是否成立仍由 AI 审稿负责。
+
+### B. 需要澄清的 spec 边界
+
+#### B1. 删除 `.cache/` 后的代价
+
+事实：
+
+- spec 写到删除 `.cache/` 后仍可正常回答所有查询。
+- 精准读取接口依赖索引访问。
+
+澄清建议：
+
+- 明确删除 `.cache/` 后，首次查询会触发冷重建，或临时降级为全文件扫描并给出提示。
+- 不应暗示删除缓存后仍是零成本。
+
+#### B2. 关键词扫描的机械/语义边界
+
+事实：
+
+- spec 已经写明信息差关键词命中只产出候选，不直接阻塞流程。
+
+澄清建议：
+
+- 显式写清二分：
+  - 关键词扫描 = 机械召回。
+  - 是否泄密 = 设定一致性审中的语义判断。
+
+#### B3. 三审新鲜上下文
+
+事实：
+
+- story spec 写到三审使用三个新鲜上下文。
+- multi-host spec 写到不支持的宿主会降级为单主 agent 顺序审稿，并声明兼容模式。
+
+澄清建议：
+
+- 把“新鲜上下文”从跨宿主不变量调整为宿主能力要求。
+- 兼容模式应诚实说明：审稿隔离度下降，仍然有用，但不等价于完整三审。
+
+#### B4. 公开“没有数据库”的措辞
+
+事实：
+
+- 公开 RFC 表述是没有数据库或隐藏状态。
+- 内部 spec 使用 `.cache/index.db` 作为可删除重建缓存。
+
+澄清建议：
+
+- 公开措辞改为：没有持久事实数据库；`.cache` 只是可删除、可重建的索引缓存。
+
+### C. 需要诚实降级或放入 7.x
+
+#### C1. 长程语义召回
+
+当前设计：
+
+- v7 把持久向量库从事实主路径移除，并把语义检索视为可选能力。
+
+边界：
+
+- Grep 和精准读取适合已知编号、已知关键词、已知章节的问题。
+- 它们不擅长开放式相似性问题，例如“以前有没有写过类似情绪处境”。
+
+建议：
+
+- 明确 v7.0 不强承诺开放式长程语义召回。
+- 语义检索可作为 7.x/plugin 能力，但不能成为事实来源。
+
+#### C2. AI 味 / 文风问题
+
+当前设计：
+
+- PRD 已写明 v7.0 处理禁词和句式体检，文风锚定放到后续。
+
+边界：
+
+- 这个范围是合理的，但不应包装成“v7.0 彻底解决 AI 味”。
+
+建议：
+
+- 公开口径保持保守：“读者不出戏”，不承诺 AI 检测器结果。
+- 文风指纹、scene beat 标签、作者写法模式放入 7.x。
+
+#### C3. 对话即编辑器
+
+当前设计：
+
+- “对话即编辑器”被列为不变量。
+
+边界：
+
+- 自然语言编辑可能被模型误解。
+- 可靠性来自预览、diff、确认和修复，而不是假设模型永远理解正确。
+
+建议：
+
+- 改写为默认交互方式，而不是绝对法律条款：
+  - 作者可以用自然语言提出结构化修改。
+  - 系统预览具体文件变更。
+  - 手改仍然是逃生门。
+
+#### C4. 定稿内容中的错别字例外
+
+当前设计：
+
+- 定稿章节只增不改，但错别字修正是例外。
+
+风险：
+
+- 没有结构化路径时，“错别字修正”和“事实变更”边界模糊。
+
+建议：
+
+- 增加 `fix:` 路径或命令，专门处理 typo-only 修改。
+- 要求 diff 足够小且不改变被追踪事实，否则进入吃书/修复流程。
+
+## 优先行动清单
+
+| 优先级 | 项目 | 动作 |
+| --- | --- | --- |
+| v7.0 实施前必须决策 | 自动模式叠加视图 | 选择待定稿批次硬隔离，或设计真正的版本链。 |
+| v7.0 实施前必须决策 | 缓存后端 | 若使用 `node:sqlite`，要求 Node >= 22.13.0；为更低版本提供降级或明确拒绝。 |
+| v7.0 实施前必须决策 | 履历证据锚点 | 在线索履历格式定稿前加入段落/小节级结构化锚点。 |
+| 实施前应更新 spec | 三审模式 | 区分完整新鲜上下文模式与兼容模式。 |
+| 实施前应更新 spec | 缓存删除语义 | 写清冷重建或全文件扫描降级。 |
+| 实施前应更新 spec | 关键词扫描 | 定义候选召回与语义判断的边界。 |
+| 应更新 v7 规划流程 | 作者确认点 | 拆分总纲、卷纲、章纲、初稿、审稿确认，避免一条命令跑太远。 |
+| 应更新审稿清单 | 动机检查 | 增加主角动机、目标和行动逻辑检查项。 |
+| 7.x backlog | 文风对齐 | 探索文风指纹、原子写法模式、scene beat 标签、缓存式文风指导。 |
+| 7.x/plugin backlog | 语义召回 | 可选语义搜索，但不作为事实来源。 |
+
+## 建议发布到 RFC 的跟进评论
+
+目前公开反馈强化了 v7 的两个核心方向：通过精准读取降低 token 成本，以及通过更舒适的确认点让作者参与判断，而不是追求全自动。反馈还补充了一个具体审稿项：主角动机、目标和行动逻辑应该被显式检查。
+
+进入实施计划前，建议先收束三个 spec 问题：自动模式待定稿批次的一致性规则、Node/SQLite 的精确运行时要求、线索履历证据的结构化锚点。其他问题可以作为 spec 措辞澄清或 7.x backlog 处理。