章节执行闭环深度解析：AI-Novel-Writing-Assistant如何逐章完成生成、审核、修复与状态回灌

章节执行闭环深度解析AI-Novel-Writing-Assistant如何逐章完成生成、审核、修复与状态回灌【免费下载链接】AI-Novel-Writing-Assistant面向长篇小说创作的 AI Native 开源系统用 Agent、世界观、写法引擎、RAG 和整本生产工作流帮助新手从一句灵感走到完整小说。AI-native engine for end-to-end novel creation — from idea to full chapters, with structured planning, worldbuilding, and agent-driven workflows.项目地址: https://gitcode.com/gh_mirrors/ai/AI-Novel-Writing-Assistant AI-Novel-Writing-AssistantAI 小说创作工作台是一个面向长篇小说的 AI Native 开源系统它把章节执行拆成「生成 → 审核 → 修复 → 状态回灌」的完整闭环帮助新手从一句灵感写到整本书。本篇用一张流程图讲清这套闭环为什么长篇不能一章一 prompt以及每个环节背后系统在做什么。一、为什么长篇写作需要闭环而不是一段提示词普通 AI 写作工具的用法是输入提示词 → 得到一段正文 → 不满意就重试。写短篇没问题写长篇却会越写越散第 30 章的人物记得第 3 章死掉的配角前面埋的伏笔永远没人兑现文风每章都在变脸像换了一个作者。AI-Novel-Writing-Assistant 的解法是章节执行不是一次生成而是一条可暂停、可恢复、可回灌的生产链。官方文档把这个闭环完整讲清楚了建议配合阅读docs/public/flow/chapter-execution.md。二、执行闭环全景一章正文要经过哪 5 道关卡章节任务单 → 上下文组装 → 正文生成 → 接收闸门审核 → 局部修复 ↑ ↓ └──── 状态回灌事实/角色/伏笔←──────┘环节系统在做什么关键产物① 上下文组装聚合书契约、角色硬事实、世界切片、事实账本、写法资产与 RAG 召回GenerationContextPackage上下文包② 正文生成writer 整章一次性写出可读正文正文草稿③ 接收闸门审核判断是否满足章节目标、连续性、义务合同审核报告、缺失义务清单④ 修复低风险问题局部 patch 修复不做无限重试修复后正文 修复记录⑤ 状态回灌把本章新事实、角色状态、伏笔变化写回账本下一章可用的上下文 第 ⑤ 步正是长篇与短篇的分水岭本章的产出会变成下一章的约束这就是状态回灌。三、第一步章节任务单 上下文组装正文不是裸写的。每章开始前系统会先准备一张章节任务单——它是正文生成的合同包含章节目标本章必须推进什么承接上一章防止开头脱离已有事实铺向下一章结尾服务后续节奏场景卡与出场角色、必须兑现的伏笔、禁忌硬约束。随后GenerationContextAssembler会把任务单、书契约、角色状态、世界规则、事实账本、伏笔账本、写法档案和知识库 RAG 片段组装成一个上下文包。核心实现在 GenerationContextAssembler.ts。这也是文档里强调的一句话长篇小说的后续章节依赖已发生事实和角色资源不能每章只靠临时提示词。四、审核与修复接收闸门如何卡住不合格章节正文写完不就算数。系统会用一次结构化接收闸门判断本章目标是否兑现缺失义务会输出结构化的missingObligations是否有连续性矛盾、角色越界、伏笔风险问题属于哪一档局部可修 / 需整章重写 / 需重规划。审核与修复的关键约束是修复不是无限循环。自动修文默认最多一次局部问题修不好就记录质量债务并继续后续章节只有明确的结构失配才会触发replan_required进入人工确认。审核评估服务见 ChapterAcceptanceAssessmentService.ts修复统一由 ChapterRuntimeCoordinator.ts 执行保证手动单章、批量执行和自动导演走的是同一条执行链。这里有一个面向新手的判断口诀正文可用、只是局部瑕疵 →记录质量债务继续写正文不可用/空正文 →重试生成或换模型提示需要重规划 →先读原因别直接点继续。五、状态回灌本章的账如何变成下一章的约束章节定稿后artifact_delta通道会做一次统一的资产抽取把本章沉淀为回灌对象作用事实账本已发生事件、不可逆结果防止后文违背前情角色状态位置、目标、关系、资源变化伏笔/承诺账本新铺垫、兑现、延期与风险提示世界状态地点、规则、势力变化质量债务进入后续修复与任务提示抽取由 ChapterArtifactDeltaService.ts 完成终态提交统一走 ChapterContentFinalizationService.ts正文版本与状态字段只能由 ChapterLifecycleService.ts 落库。更妙的是失败可恢复如果正文已保存但状态没回灌正确动作是重试同步而不是重写正文——重写反而会制造新的事实分叉。六、批量执行一本书如何自动写下去章节批次不是一次只写一章。批量执行会在每章之间保存状态并决定是否继续批次开始 → 读取章节批次就绪的范围每章组装上下文 → 生成 → 审核 → 修复 → 回灌遇到 checkpoint需要人工确认、重规划、配额耗尽→主动停下并通知而不是后台空转每本书还能选择问题处理策略优先完成整本书小问题记债务继续或质量优先停在章节边界等恢复。人工暂停不会被后台自动清除——这一点在 docs/public/flow/chapter-execution.md 中被明确写成了 checkpoint 约定是长链路任务最让人安心的设计。七、想深入源码从这里入手想理解什么看哪里闭环全貌与失败恢复手册docs/public/flow/chapter-execution.md双通道生产链设计决策docs/wiki/workflows/chapter-production-chain.md上下文组装server/src/services/novel/runtime/GenerationContextAssembler.ts审核 / 修复 / 终态提交server/src/services/novel/runtime/章节状态与生命周期server/src/services/novel/runtime/lifecycle/ChapterLifecycleService.ts八、总结一句话记住这套闭环生成解决写出来审核解决写得对不对修复解决能救的尽量救状态回灌解决下一章还认账。四步咬合成环一本书才能越写越连贯而不是越写越散。本地体验的话仓库通过 pnpm workspace 组织前后端安装依赖后执行pnpm dev即可启动详见 README.md 的快速开始一节。【免费下载链接】AI-Novel-Writing-Assistant面向长篇小说创作的 AI Native 开源系统用 Agent、世界观、写法引擎、RAG 和整本生产工作流帮助新手从一句灵感走到完整小说。AI-native engine for end-to-end novel creation — from idea to full chapters, with structured planning, worldbuilding, and agent-driven workflows.项目地址: https://gitcode.com/gh_mirrors/ai/AI-Novel-Writing-Assistant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考