首先我不是一名专业的技术人员，我是一名产品经理，但是可以使用AI完成一些简单的代码工作，不是很会使用git，我下载了你带代码，在本地让AI运行过程中，发现一些问题，在自动编导过程中经常会因为JSON报错卡住，AI告诉我验证比较严格，AI返回的有时候是对象，有时候是数组。我让AI帮我修改了这个问题，但是我不会提交合并，所以把AI的计划发给你参考。感谢你的分享，你这个是我目前看到功能最全的，因为比较全面所以我用AI合并和删减功能最方便。希望对你有用。
AI-Novel-Writing-Assistant 全流程稳定化修复方案
Summary
这次方案只针对 AI-Novel-Writing-Assistant，采用“auto_to_ready 自动跑到章节正文前，再暂停一次确认”的单检查点模式。
基于现有代码的根因排查，当前不稳定主要来自 5 个点：waiting_approval 被 UI 显示成像失败、章节细化产物只有结构校验没有业务可用性门禁、坏产物会直接落库并继续推进、章节修复默认整章重写导致越修越漂、模型路由只有粗粒度 planner/writer/review/repair，不足以支撑稳定生产。
这份方案的目标不是“让上游模型永不失败”，而是把失败统一收敛成 3 种可控结果：自动重试、降级补全、明确暂停并给出原因，不再出现“假完成、假报错、静默卡住”。
Implementation Changes
1. 工作流与状态语义重构
- 保留后端真实状态
waiting_approval，但新增统一展示语义 displayStatus=paused，任务中心和步骤条不再把暂停映射成 cancelled。
auto_to_ready 改为单检查点流程：候选方向 -> 故事宏观规划 -> 角色准备 -> 卷战略 -> 节奏/拆章 -> 前 10 章细化 -> 完整性巡检 -> 同步章节资源 -> front10_ready 暂停。- 中间的
character_setup_required、volume_strategy_ready 等检查点在自动模式下改成“里程碑事件”而不是阻塞暂停；只有硬失败或低可信度才真正中断。
front10_ready 只允许在“前 10 章全部通过细化完整性巡检”后记录；任何一章不合格都回到 structured_outline 修复，不允许标记 ready。- 所有暂停态都附带
blockingReason、resumeAction、lastHealthyStage，前端统一显示“为什么停、停在哪、继续后会做什么”。
2. 章节细化产物加硬门禁，不让坏数据进库
- 为
purpose、boundary、taskSheet 全部增加“Schema + 语义可用性”双层校验，现有只要 z.string().min(1) 就算通过的策略废弃。
taskSheet 改为“内部结构化、外部兼容文本”的双存储：内部最少包含 tone、conflict、advance、endingHook、mustPreserve；现有文本字段继续保留给 UI 和旧逻辑读取。- 业务校验明确拦截这些值：纯数字、仅回显章号、长度不足、只复述标题/摘要、缺少推进目标、缺少结尾要求、与相邻章节节奏明显冲突。
- 每次章节细化生成后执行“章节细化完整性巡检”，输出
artifactHealth；只有 artifactHealth=ready 才允许 syncVolumeChapters。
- 对失败的细化产物采用三段式恢复：先语义重试，再切换 fallback 模型，最后走“确定性兜底生成器”从摘要、边界和相邻章节拼出可用 taskSheet，保证不会因为单章坏 JSON 卡死整本书。
- 增加历史数据回扫与修复任务，自动识别像
"7"、"10" 这种已落库坏 taskSheet，并回填合法版本后再允许继续执行。
3. 章节正文链路改成“契约写作 + 段落级修补”
- 在章节正文前新增
Chapter Contract：从章节摘要、purpose、boundary、taskSheet、活跃角色、最近状态、世界观片段组装成单章事实包。
- 写作、审查、修补全部只读同一份 contract，避免“写作一套、审查一套、修文又一套”。
- 审查结果固定结构化，至少包含
issueId、severity、paragraphIds、evidence、fixType、blocking，不再依赖展示文案做后续动作。
优化/修复 默认改为 patch_first：只允许对白名单段落做替换、插入、删除，禁止默认整章重写。- 只有在命中这些条件时才允许升级为整章重写：P0 问题跨越超过 35% 段落、核心结构缺失、首尾逻辑断裂无法局部修复、或用户明确选择“重写”。
- 修补完成后必须再次跑“事实一致性 + 题材门禁 + 审查回归”；如果新增 P0，直接阻断保存并回退到修补前内容。
4. 模型路由从粗粒度升级为阶段级
- 在现有
planner/writer/review/repair 粗路由之上，新增小说生产专用阶段路由：director_candidate、story_macro、character_setup、volume_strategy、beat_sheet、chapter_list、chapter_purpose、chapter_boundary、chapter_task_sheet、chapter_write、chapter_review、chapter_patch、chapter_polish、state_extract。
- 路由优先级固定为：
本次动作显式覆盖 > 阶段路由 > 现有 taskType 路由 > 全局默认模型。
- 每个阶段支持最多 3 个 fallback 路由；触发条件统一为超时、5xx、429、JSON 无法修复、语义校验连续失败。
- 自动导演前半段默认偏稳定模型，章节正文偏创作模型，审查和 patch 偏结构化/遵循性强模型；不再让一个模型包办全部阶段。
- 任务详情和运行日志必须记录“阶段命中模型”和“fallback 是否发生”，方便排查为什么这次质量变差。
5. 超时、心跳、重试、降级统一治理
- 为 LLM 调用增加阶段级超时默认值：规划类 120s、章节细化 120s、正文生成 240s、审查 120s、patch 修补 180s。
- 为自动导演和章节流水增加统一心跳机制，标准为每 10s 更新一次；连续 3 个窗口无心跳视为
stalled，自动进入恢复流程。
- 恢复流程固定为：重读最新已持久化工作区 -> 从最后健康阶段重入 -> 跳过已完成且健康的产物，不重复生成。
- 后台异步任务不再只吞异常；所有异常都必须写入任务状态、失败摘要、失败阶段和建议动作。
- RAG、向量库、外部健康检查一律改成“可降级依赖”：不可用时退化成本地事实包和状态快照，不允许拖死主流程。
6. 客户端与桌面端的可观测性修复
- 任务卡片、步骤条、小说详情页统一新增
运行中 / 暂停待确认 / 自动重试中 / 降级补全中 / 失败待处理 五种可视状态。
front10_ready 页面直接展示前 10 章细化健康度，例如“10/10 通过”或“8/10 通过，2 章待自动修复”，不再只显示一句模糊总结。- 对章节细化失败、正文修补失败、模型 fallback、RAG 降级都显示明确原因和恢复建议，不再让用户靠猜。
- 桌面端保留本地模型配置与运行历史缓存，重启应用后仍能恢复到当前任务视图和最近一次健康阶段。
- 所有“继续”按钮都绑定具体恢复动作，不再只是重新打一遍全流程。
Public APIs / Types Changes
NovelWorkflow 任务摘要/详情新增：displayStatus、blockingReason、resumeAction、lastHealthyStage、artifactHealthSummary。DirectorRunMode=auto_to_ready 的语义固定为“自动跑到 front10_ready 单检查点”；stage_review 保留人工多检查点模式。VolumeChapterPlan 增加结构化 taskSheetStruct 与 artifactHealth；原 taskSheet 继续保留用于兼容展示。ReviewIssue 扩展为：id、paragraphIds[]、blocking、fixType；review 接口返回稳定结构，前端不再解析自然语言。- 章节修复接口增加
repairStrategy: patch_first | rewrite_only，默认 patch_first。
- 模型路由配置接口增加
novelStageRoutes，支持阶段级主路由与 fallback 列表；原全局 taskType 路由继续兼容。
- 生产状态接口新增：
directorHealth、artifactHealth、runtimeHealth、ragDegradedReason、lastFallbackRoute。
Test Plan
- 单元测试：
waiting_approval -> paused 的展示映射正确，步骤条不会再显示 cancelled。taskSheet 语义门禁能稳定拦截纯数字、空泛文本、回显标题、缺少结尾要求等坏产物。- 阶段路由优先级与 fallback 选择正确。
- patch 白名单生效，未命中段落不会被修改。
- 集成测试：
- 自动导演完整跑到
front10_ready，前 10 章有任何一章细化损坏时不得记录 ready。
- 模拟 LLM 超时、429、5xx、坏 JSON、语义失败，验证会自动重试、切 fallback、再走兜底，而不是卡死。
- 章节执行链路走通：
contract -> write -> review -> patch -> re-review -> approved。
- patch 路径引入新 P0 时必须阻断保存并保留修补前正文。
- 回归测试：
- 用当前这本《最后一班地铁的假规则》回归，确认
front10_ready 不会在坏 taskSheet 存在时误报完成。
- 用已有的短篇、悬疑、长篇样本分别验证节奏约束、体量约束和修补稳定性。
- 验证 RAG 不可用时主流程仍可跑通，只显示降级提示。
- 验收指标：
- “暂停被显示成失败”的误报率降到 0。
- 坏章节细化产物进入 ready 状态的误放行率降到 0。
- 无心跳卡死超过 30s 但前端无提示的情况降到 0。
优化/修复 路径中段落级修改占比超过 90%，整章重写只在升级条件命中时发生。
Assumptions
- 默认只修
AI-Novel-Writing-Assistant，不同时改旧项目。
- 默认自动边界为
front10_ready，即正文前暂停一次确认。
- 默认质量策略为强门禁，宁可暂停修复，也不允许坏产物假完成。
- 默认章节细化保持串行执行，优先稳定而不是追求最快速度。
- 默认
repairStrategy=patch_first，整章重写只作为升级手段。
- 默认 RAG 为非阻塞依赖，异常时自动降级，不阻断小说主流程。
首先我不是一名专业的技术人员，我是一名产品经理，但是可以使用AI完成一些简单的代码工作，不是很会使用git，我下载了你带代码，在本地让AI运行过程中，发现一些问题，在自动编导过程中经常会因为JSON报错卡住，AI告诉我验证比较严格，AI返回的有时候是对象，有时候是数组。我让AI帮我修改了这个问题，但是我不会提交合并，所以把AI的计划发给你参考。感谢你的分享，你这个是我目前看到功能最全的，因为比较全面所以我用AI合并和删减功能最方便。希望对你有用。
AI-Novel-Writing-Assistant 全流程稳定化修复方案
Summary
这次方案只针对
AI-Novel-Writing-Assistant，采用“auto_to_ready自动跑到章节正文前，再暂停一次确认”的单检查点模式。基于现有代码的根因排查，当前不稳定主要来自 5 个点：
waiting_approval被 UI 显示成像失败、章节细化产物只有结构校验没有业务可用性门禁、坏产物会直接落库并继续推进、章节修复默认整章重写导致越修越漂、模型路由只有粗粒度planner/writer/review/repair，不足以支撑稳定生产。这份方案的目标不是“让上游模型永不失败”，而是把失败统一收敛成 3 种可控结果：
自动重试、降级补全、明确暂停并给出原因，不再出现“假完成、假报错、静默卡住”。Implementation Changes
1. 工作流与状态语义重构
waiting_approval，但新增统一展示语义displayStatus=paused，任务中心和步骤条不再把暂停映射成cancelled。auto_to_ready改为单检查点流程：候选方向 -> 故事宏观规划 -> 角色准备 -> 卷战略 -> 节奏/拆章 -> 前 10 章细化 -> 完整性巡检 -> 同步章节资源 ->front10_ready暂停。character_setup_required、volume_strategy_ready等检查点在自动模式下改成“里程碑事件”而不是阻塞暂停；只有硬失败或低可信度才真正中断。front10_ready只允许在“前 10 章全部通过细化完整性巡检”后记录；任何一章不合格都回到structured_outline修复，不允许标记 ready。blockingReason、resumeAction、lastHealthyStage，前端统一显示“为什么停、停在哪、继续后会做什么”。2. 章节细化产物加硬门禁，不让坏数据进库
purpose、boundary、taskSheet全部增加“Schema + 语义可用性”双层校验，现有只要z.string().min(1)就算通过的策略废弃。taskSheet改为“内部结构化、外部兼容文本”的双存储：内部最少包含tone、conflict、advance、endingHook、mustPreserve；现有文本字段继续保留给 UI 和旧逻辑读取。artifactHealth；只有artifactHealth=ready才允许syncVolumeChapters。"7"、"10"这种已落库坏 taskSheet，并回填合法版本后再允许继续执行。3. 章节正文链路改成“契约写作 + 段落级修补”
Chapter Contract：从章节摘要、purpose、boundary、taskSheet、活跃角色、最近状态、世界观片段组装成单章事实包。issueId、severity、paragraphIds、evidence、fixType、blocking，不再依赖展示文案做后续动作。优化/修复默认改为patch_first：只允许对白名单段落做替换、插入、删除，禁止默认整章重写。4. 模型路由从粗粒度升级为阶段级
planner/writer/review/repair粗路由之上，新增小说生产专用阶段路由：director_candidate、story_macro、character_setup、volume_strategy、beat_sheet、chapter_list、chapter_purpose、chapter_boundary、chapter_task_sheet、chapter_write、chapter_review、chapter_patch、chapter_polish、state_extract。本次动作显式覆盖 > 阶段路由 > 现有 taskType 路由 > 全局默认模型。5. 超时、心跳、重试、降级统一治理
stalled，自动进入恢复流程。6. 客户端与桌面端的可观测性修复
运行中 / 暂停待确认 / 自动重试中 / 降级补全中 / 失败待处理五种可视状态。front10_ready页面直接展示前 10 章细化健康度，例如“10/10 通过”或“8/10 通过，2 章待自动修复”，不再只显示一句模糊总结。Public APIs / Types Changes
NovelWorkflow任务摘要/详情新增：displayStatus、blockingReason、resumeAction、lastHealthyStage、artifactHealthSummary。DirectorRunMode=auto_to_ready的语义固定为“自动跑到front10_ready单检查点”；stage_review保留人工多检查点模式。VolumeChapterPlan增加结构化taskSheetStruct与artifactHealth；原taskSheet继续保留用于兼容展示。ReviewIssue扩展为：id、paragraphIds[]、blocking、fixType；review接口返回稳定结构，前端不再解析自然语言。repairStrategy: patch_first | rewrite_only，默认patch_first。novelStageRoutes，支持阶段级主路由与 fallback 列表；原全局taskType路由继续兼容。directorHealth、artifactHealth、runtimeHealth、ragDegradedReason、lastFallbackRoute。Test Plan
waiting_approval -> paused的展示映射正确，步骤条不会再显示cancelled。taskSheet语义门禁能稳定拦截纯数字、空泛文本、回显标题、缺少结尾要求等坏产物。front10_ready，前 10 章有任何一章细化损坏时不得记录 ready。contract -> write -> review -> patch -> re-review -> approved。front10_ready不会在坏 taskSheet 存在时误报完成。优化/修复路径中段落级修改占比超过 90%，整章重写只在升级条件命中时发生。Assumptions
AI-Novel-Writing-Assistant，不同时改旧项目。front10_ready，即正文前暂停一次确认。repairStrategy=patch_first，整章重写只作为升级手段。