v7-rfc-feedback-report-2026-06-16.md 13 KB
v7 RFC 反馈合并报告
日期：2026-06-16
范围：合并公开 RFC 反馈、Issue 引流状态、外部设计批判与事实校验，为 v7 实施计划提供输入。
状态：反馈综合报告，不是最终决策记录。
事实来源
- 公开 RFC：Discussion #118，2026-06-12 发布在 Announcements 分类。
- Issue 区指引：Issue #119，2026-06-12 创建，带
help wanted，作用是把只看 issue 区的用户引流到 RFC。 - 本地设计文档：
- 外部运行时事实校验：Node.js
node:sqlite官方文档。当前文档显示，node:sqlite在 Node v22.13.0 起不再要求--experimental-sqliteflag，但 SQLite 模块仍未完全稳定，当前状态是 release candidate。 - 外部设计批判：GLM 对 v7 PRD/RFC 的问题清单。其关于“RFC 未发布”的疑虑已经被事实排除；其关于 Issue #119 是否存在的疑虑经核对后也不成立。
总结
公开 RFC 流程是成立的：Discussion #118 已发布，Issue #119 也确实承担了 issue 区引流作用。目前公开反馈没有否定 v7 方向，反而集中验证了四个设计重点：降低 token 成本、增加作者确认点、改善弱模型可用性、明确 Codex / 多宿主协作模式。
外部设计批判也有价值，但最强的部分不是产品方向错误，而是 PRD/spec 中若干承诺过硬、边界不够诚实。建议在 v7.0 实施前优先处理三项：
- 自动模式的批次叠加视图必须补充一致性规则。
node:sqlite运行时承诺必须明确 Node patch 版本下限和降级方案。- 如果重建器和三审要确定性验证履历证据，履历必须使用结构化锚点。
其他问题更适合作为 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 处理。