Discussion #118 评论遗漏分析
分析范围
- 原始数据:Discussion #118 的 7 条评论(2026-06-12 至 2026-06-22)
- 对照基准:
docs/architecture/v7-rfc-feedback-report-2026-06-16.md
- 分析目标:识别反馈报告未覆盖或处理不充分的关键反馈
一、已在反馈报告中覆盖的要点
1.1 Token 成本与弱模型现实
- ✅ yedonglai8-lab (06-12):"claude opus4.8 大纲还没读完,先破产了。token烧的有点厉害,其他都是棒棒的。用deepseek v4 pro不能看"
- 报告覆盖:§1 "Token 成本与弱模型现实",明确提到 Claude 预算消耗和 DeepSeek v4 Pro 指令遵循能力差
1.2 规划流程缺少确认点
- ✅ Chained1001 (06-12):"V6 版本的 /webnovel-plan 环节会同步生成卷纲与章纲,二者生成流程相互绑定。用户无法先调整优化卷纲,再单独生成章纲。"
- 报告覆盖:§2 "规划流程需要作者确认点",完整引用该反馈并提出明确停顿点方案
1.3 主角动机/目标检查
- ✅ Chained1001 (06-13):"能否单独新增主角动机 / 目标这一项?目前 AI 生成剧情时常出现主角行为逻辑薄弱的问题,比如无故辗转地点、贸然冒险,行动缺乏合理支撑。"
- 报告覆盖:§3 "主角动机 / 目标检查",建议纳入三审清单
1.4 文风对齐方法
- ✅ wangwwno1 (06-13):完整的文风分析方法(风格指纹、原子模式、复合语群、逐段约束、从修改中学习)
- 报告覆盖:§4 "文风对齐 / 作者声音",认可方向并建议放入 7.x 设计空间
1.5 Codex 多宿主编排
- ✅ Fahaoxi (06-14):"很喜欢这个项目,也试着将其迁移到codex上运行。个人感觉最优的方式还是让一个主控ai来调控负责阶段推进、ready payload、验收和阻断"
- 报告覆盖:§5 "Codex / 多宿主编排",建议定义两种模式(兼容模式 vs 质量模式)
二、遗漏的关键反馈
2.1 术语自然度反馈 — 完全遗漏
来源:Chained1001 (06-13 03:59)
原文:
"大佬,还有个问题想请教。你之前列出的评判维度:伏笔、悬念、感情线、细纲、审稿、吃书、全书近况,麻烦帮忙看看其中有没有表述生硬、不合适的地方。"
性质:直接回应 RFC 主文"征集意见"第 1 条(术语是否自然)
遗漏原因:
- 该评论同时提出了两个问题:术语反馈 + 主角动机建议
- 反馈报告只提取了主角动机部分(§3),完全忽略了术语自然度反馈
- 这是用户对 RFC 正式提问的直接回应,属于最应该处理的反馈类型
实际影响:
- 用户明确请求对术语表进行评审("麻烦帮忙看看")
- 维护者未在 Discussion 中回复该问题
- 反馈报告也未记录该反馈或说明"无术语反馈"
2.2 审稿无限循环问题 — 覆盖不足
来源:shuimushanjia (06-22 06:16)
原文:
"个人在用AI写小说遇到的一点问题:每次让AI审查修改后,再次审查又会出现新的问题,似乎无穷无尽。AI似乎很难站在一个正真的作者角度统筹把握整本书,经常在前文故作高深埋了一个伏笔之后就没了下文,似乎没将这判定为伏笔。AI对一些设定的理解不够深刻,在正文中表现不出设定的亮点。"
问题拆解:
- 审稿循环问题:"每次让AI审查修改后,再次审查又会出现新的问题,似乎无穷无尽"
- 伏笔追踪失效:"经常在前文故作高深埋了一个伏笔之后就没了下文,似乎没将这判定为伏笔"
- 设定理解浅薄:"AI对一些设定的理解不够深刻,在正文中表现不出设定的亮点"
报告覆盖情况:
- ❌ 审稿循环问题:完全未提及
- ⚠️ 伏笔追踪问题:隐含在 §3(三审负责"伏笔、悬念、感情线"检查),但没有明确说明如何防止"埋了没用"
- ⚠️ 设定理解问题:隐含在 §1(弱模型指令遵循问题),但没有具体到"设定表现不出亮点"
为何重要:
- 审稿循环是 v6 实际使用中的严重体验问题,直接影响工作流可用性
- 该问题在 2026-06-22 提出(RFC 反馈报告 06-16 之后),但报告未更新
- v7 的三审机制(读者审、编辑审、设定校对)是否能解决审稿循环?报告未说明
2.3 文风标注的 Token 成本权衡 — 覆盖浅薄
来源:wangwwno1 (06-13 06:37)
原文:
"是的,而且我为了便宜用dsv4,它文风不稳定,比其他模型更需要显式约束进行引导。考虑到文风只能在草稿层面落实,最合适的做法应该是在草稿上一层,也就是规划每一个场景的节奏时确定。我不太熟悉网文写作,但这看起来对应网文中的章纲?在这一阶段需要确定核心冲突,冲突的解决过程,制定故事节拍。目前我是在节拍引入风格标记,告诉模型应该采用哪些手法来落实这部分内容。这样模型可以结合当前的故事节奏、涉及的意象和伏笔等一系列信息,来分析什么写法最合适,并写到细纲里。"
核心洞察:
- 弱模型需要显式文风约束:"dsv4 文风不稳定,更需要显式约束"
- 文风应在章纲层引入:"最合适的做法应该是在草稿上一层,也就是规划每一个场景的节奏时确定"
- 节拍级别的文风标记:"在节拍引入风格标记,告诉模型应该采用哪些手法"
报告覆盖情况:
- ⚠️ 报告 §4 提到"在场景/章纲层就放入文风指导",但没有明确:
- 弱模型可能必须有文风约束才能稳定输出(不是可选优化)
- 节拍级标记是解决 token 成本的关键(不是全局模板)
- ⚠️ 报告提到"携带文风指导会增加 token 成本",但没有提到用户已经给出解法:节拍级别标记 + 章纲时确定,而不是草稿时全文携带
为何重要:
- 这直接关系到 v7 对弱模型的承诺范围(§1 建议的"兼容模式"应该包含什么?)
- 用户已经验证的实施路径(节拍标记)应该进入 v7.0 设计考量,而不是笼统地"放入 7.x"
2.4 AI 的"中庸不出错"倾向 — 未处理
来源:shuimushanjia (06-22 06:16)
原文:
"有一点我很认可:AI训练了大量语料知识,有好的有差的,特别是质量中等的内容很多。那么AI在思考问题时更偏向于输出中庸不出错的回答。AI写的小说总感觉差口气,哪怕把大纲与细纲都写好,只让AI填充正文,还是感觉差点意思。这样如何让AI给出高质量回答是个难题。"
核心问题:
- AI 输出"中庸不出错",即使有完整大纲和细纲,正文质量仍然"差口气"
- 这是对 AI 辅助写作根本可行性的质疑
报告覆盖情况:
- ❌ 完全未提及
- 该问题在 2026-06-22 提出(反馈报告 06-16 之后)
为何重要:
- 这是对 v7 核心价值主张的挑战:"把流程和检查做得再好,AI 写的东西还是平庸怎么办?"
- 如果维护者认可这个现实,应该在 v7 承诺中明确:系统的目标是"可用的初稿"而不是"发表级正文"
- 如果维护者有解法(如文风对齐、审稿机制),应该说明为什么 v7 能改善这个问题
三、时间线问题
3.1 反馈报告日期 vs 实际评论时间
- 反馈报告日期:2026-06-16
- 报告覆盖的评论:截至 2026-06-14 的 6 条评论(最后一条是 Fahaoxi 的 Codex 迁移)
- 遗漏评论:shuimushanjia 的评论(2026-06-22),共 1 条
问题:
- 反馈报告标题是"v7 RFC 反馈合并报告",但实际只覆盖到 06-14
- 06-22 的评论包含两个重要问题(审稿循环、AI 平庸倾向),完全未纳入
- RFC 征集期原计划 ~06-19 收口,但 06-22 仍有新评论,说明征集期实际延长或未明确关闭
四、建议处理方式
4.1 术语自然度反馈 — v7.0 前处理
建议:
- 在 Discussion #118 回复 Chained1001,说明术语评审结果:
- 伏笔、悬念、感情线、细纲、审稿、吃书、全书近况 — 这些术语经内部审查和用户反馈,认为自然、无需修改
- 或指出具体调整(如有)
- 在 RFC 跟进评论中补充:"术语自然度已收到反馈确认,无需调整"
理由:
- 这是 RFC 正式提问,用户明确请求反馈,不回复会显得忽略用户
- 术语是格式层的一部分,RFC 阶段应该收口
4.2 审稿无限循环 — 纳入 v7.0 设计
建议:
- 在反馈报告补充 §2.6 "审稿循环终止机制":
- 问题:AI 审稿后修改,再审查又出现新问题,无限循环
- v7 的解法:
- 三审输出结构化问题清单,每个问题有 severity + blocking
- 只有 critical + blocking 问题阻断定稿,其他问题作为建议
- 作者审稿时可以选择"接受当前版本"(即使有非阻断问题),系统不强制完美
- 实施要点:审稿报告模板应明确区分"阻断性问题"和"优化建议"
- 在
story-repo-spec 补充审稿流程的终止条件
理由:
- 审稿循环是工作流可用性的核心问题,v7 必须有明确解法
- v6 的 reviewer 已经有 severity 机制(可参考),但可能执行不严格
4.3 伏笔追踪失效 — 澄清 v7 改进点
建议:
- 在 RFC 跟进评论中说明 v7 如何改善"伏笔埋了没用":
- 每条伏笔有独立档案,记录"何时埋下、推进到哪、计划何时收尾"
- 三审的"设定校对"环节会核对"本章应推进的伏笔是否真的写到正文"
- 搁置过久时系统提示"悬了太久"(提醒,不阻断)
- 明确 v7 不承诺的部分:
- 系统不负责"伏笔是否精彩",只负责"是否遗漏"
- "故作高深埋伏笔但后续平庸"是创作质量问题,不是系统能解决的
理由:
- v7 的伏笔跟踪机制是核心卖点,应该明确对标 v6 的该问题
- 但要诚实划定边界,避免过度承诺
4.4 文风标注 Token 成本 — 纳入 7.x 具体方案
建议:
- 在反馈报告 §4 补充用户已验证的路径:
- 节拍级文风标记(在章纲确定,不是草稿时全文携带)
- 适合弱模型场景(DeepSeek v4 等)
- 在 7.x backlog 中明确:
- v7.0:不做文风标注
- v7.x:探索节拍级文风标记(参考 wangwwno1 方案)
理由:
- 用户已经给出具体实施路径,不应该笼统地"放入 7.x"
- 节拍级标记与 v7 的"章纲 → 细纲 → 草稿"流程天然契合
4.5 AI 平庸倾向 — 文档澄清
建议:
- 在 PRD 或 README 明确 v7 的质量承诺范围:
- v7 的目标是"可用的初稿",不是"免修改的发表稿"
- 系统负责流程、一致性、机械检查,不负责"文笔是否出彩"
- 作者的人类判断和修改仍然是必需的
- 在 RFC 跟进评论中回应该用户:
- 承认 AI 的"中庸不出错"是现实
- 说明 v7 通过文风铁律、禁词、审稿机制改善但不消除该问题
- 7.x 的文风对齐功能会进一步优化
理由:
- 这是对核心价值主张的质疑,必须正面回应
- 诚实的边界承诺比回避问题更能建立信任
4.6 反馈报告更新 — 补充 06-22 评论
建议:
- 更新反馈报告标题或说明:
- "v7 RFC 反馈合并报告(截至 2026-06-14)"
- 或补充 §6 "后续反馈"覆盖 06-22 评论
- 在 RFC 跟进评论中说明:
五、优先级评估
| 反馈项 |
优先级 |
建议动作 |
阻塞 v7.0 实施? |
| 术语自然度反馈 |
高 |
回复用户 + RFC 跟进评论 |
否 |
| 审稿无限循环 |
关键 |
补充 spec §审稿终止机制 |
是 |
| 伏笔追踪失效 |
中 |
RFC 跟进评论说明改进点 |
否 |
| 文风标注成本 |
中 |
更新 7.x backlog 具体方案 |
否 |
| AI 平庸倾向 |
高 |
文档澄清质量承诺边界 |
否 |
| 反馈报告更新 |
低 |
补充日期范围说明 |
否 |
关键发现:
- 审稿无限循环是唯一可能阻塞 v7.0 实施的遗漏问题
- v7 必须有明确的审稿终止机制,否则会重现 v6 的该问题
六、与现有决策的交叉验证
6.1 两审调整 vs 审稿循环
PRD (06-26) 已经决策:从"三审"调整为"两审"(事实审查 + 编辑审),去掉主观的"读者审"。
关联:
- 去掉"读者审"(爽不爽)可以减少主观评价带来的审稿循环
- 但 shuimushanjia 的问题是"事实问题无穷无尽",不是主观评价问题
- 两审调整未必能解决审稿循环,仍需要明确的终止机制
6.2 主角动机检查 vs 行为逻辑问题
PRD 已纳入"主角动机检查"到编辑审(RFC 反馈 Chained1001)。
关联:
- shuimushanjia 的"伏笔埋了没用"和"设定表现不出亮点"是更深层的问题
- 主角动机检查只覆盖"行动逻辑",不覆盖"伏笔追踪"和"设定理解"
- 需要在事实审查中明确"伏笔履历验证"的职责
七、总结
7.1 反馈报告完整性评估
- 覆盖率:5/7 条评论,71%
- 遗漏:1 条完全遗漏(06-22),1 条部分遗漏(术语反馈)
- 深度:对已覆盖评论的提取较完整,但缺少"为什么 v7 能解决该问题"的说明
7.2 关键遗漏优先级
- 审稿无限循环 — 必须在 v7.0 前设计终止机制
- 术语自然度 — 用户正式提问,必须回复
- AI 平庸倾向 — 需要澄清质量承诺边界
- 文风成本权衡 — 用户已给出解法,应纳入 7.x 具体方案
7.3 建议后续动作
- 更新
story-repo-spec 补充审稿终止机制(§8.6)
- 在 Discussion #118 回复 Chained1001 的术语反馈
- 发布 RFC 跟进评论,补充遗漏反馈的处理情况
- 更新反馈报告或标注日期范围
分析完成时间:2026-06-26
分析依据:Discussion #118 完整评论(7 条)+ RFC 反馈报告 2026-06-16
八、补充分析(2026-06-27):新评论 + v7 逐条核验
本节是对 2026-06-26 分析的补订。两个动因:①出现第 8 条评论(freezero2020,06-26),原分析未收录;②原分析对照的是「反馈报告」,本节改为直接对照 v7 spec 0.7,给出"v7 是否已解决"的实判。
8.1 新评论:freezero2020(2026-06-26)— 设定集与大纲解耦
原文:
设定集可否不关联大纲的内容,设定集里只保留设定的原意,其他与大纲有关的(类似章节安排)放在单独的文件里。我在设定完成后,尝试安排不同的文风、进度,结果发现每次改动都会涉及相当多的文件,经常发生大纲与设定集不同步……感觉将大纲与设定集最好单向关联,且在不同阶段给予不同的优先级似乎要好一些。
诉求拆解:①设定只存"设定原意",章节排程类内容挪出;②大纲↔设定双向交叉导致改一处牵连多文件、频繁不同步;③希望单向关联 + 分阶段优先级。
v7 现状核验:v7 在目录层已三分,比 freezero2020 设想的更彻底——
定稿/设定/(只进不改,已发生的客观事实记账)
大纲/(作者意图,随时可改)
文风/(品味库,独立顶层)
文风、进度(卷纲)已各自独立可改,角色卡只记客观事实(境界/位置/持有/状态),不含排程。主体诉求 v7 已满足。
残留 gap:v7 是隐含单向(大纲引用设定正名,设定只做事实记账),但 §1 不变量未显式写死"设定层不得写排程/章节安排、依赖方向单向"。→ 处置见 §8.3 决策 D4。
8.2 新发现的真缺口:未登记伏笔检测(呼应 shuimushanjia 06-22)
shuimushanjia 的伏笔抱怨在原分析 §2.2/§4.3 已部分处理,但定性不准。重新核验 v7 流程后定性如下:
- v7 伏笔系统是纯声明制:只跟踪细纲「本章要写到的事」声明过、front matter 登记过的条目(§7→§8→§4.1→§5)。对"规划阶段就想好的伏笔"闭环完备(收尾计划必填、悬了太久、卷复盘清账)。
- 盲区:§8 第 4 步写稿是「AI 干净上下文」,AI 可能在正文里即兴埋钩子。但只有声明过的才会在第 8 步入账。即兴埋的坑无条目 → 不进"悬了太久"、卷复盘扫不到 → 烂尾。这正是 shuimushanjia 说的"埋了一个伏笔之后就没了下文,似乎没将这判定为伏笔"。
- 结论:shuimushanjia 抱怨的不是"系统忘了已登记的坑"(那部分 v7 防得很死),而是声明制天生看不见 AI 即兴挖的坑。→ 处置见 §8.3 决策 D3。
8.3 两条确定的设计处置(收敛为 D3 / D4,详见 prd.md / design.md)
D3:未登记伏笔检测(给声明制加补漏网)
- 落点:事实审查(§8 第 6 步),搭已有的整章通读——现检查是"声明推进了,正文真有吗",新增反方向"正文出现疑似伏笔,反查有无条目",同一次读取,边际成本≈0。
- 形态:结构化问题清单新增
category=unregistered_thread,severity low/medium,blocking 永远 false;走信息差泄密扫描同款"候选制,不拦截"。
- 作者裁决(审稿单第 7 步):登记成条目(触发收尾计划必填,自动防悬空)/ 忽略(普通描写)/ 删掉。
- 风险:误报。判定门槛保守——仅捞"刻意强调 + 明显悬置 + 本章无即时解释 + 结构像 setup"者;非阻断,误报代价低,但宁紧勿松。
- 版本:可进 v7.0(成本低、对口最高频反馈、非阻断风险小)。
D4:设定↔大纲单向依赖(不变量)
- 落点:spec §1 设计不变量补一条——"设定层只记已发生的客观事实,不写排程/章节安排;依赖单向:大纲 → 设定,设定不反向引用大纲条目编号或卷号排程"。
- 性质:纯文档约束,零代码成本,直接回应 freezero2020。
- 版本:v7.0(spec 0.7 文字增补)。
8.4 其余反馈的 v7 核验结论(速查)
| 反馈 |
v7 判定 |
依据 |
| 审稿无限循环(shuimushanjia) |
✅ 已解决 |
§8 审稿终止机制(D2);"改完接受不重审"=循环终止保证 |
| 多视角审核(onenuo28) |
✅ 已解决 |
两审各自新鲜上下文 |
| 主控编排/ready payload(Fahaoxi) |
✅ 已解决 |
状态机单入口 §10 + 备料 §8.3 |
| 设定/大纲解耦(freezero2020) |
🟡 主体已解决,补 D4 |
目录三分;缺单向依赖不变量 |
| 伏笔即兴埋坑(shuimushanjia) |
🟡 补 D3 |
声明制盲区 |
| 文风对齐/节拍标记(wangwwno1 等) |
⛔ v7.0 不做,7.x |
建议细纲节拍预留"手法标签"字段位,低成本铺路 |
| AI 中庸/设定不出彩(shuimushanjia) |
⚠️ 边界 |
文风铁律+best-of-N+编辑审缓解,不消除;PRD 明确"可用初稿"承诺 |
补充分析完成时间:2026-06-27
补充依据:Discussion #118 第 8 条评论(freezero2020 2026-06-26)+ story-repo-spec 0.7 全文核验