# 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 处理。
