转写说明
本文基于已校验的公开原文进行结构化转写与事实梳理，非原文转载。 转写保留可核验的技术事实，并将工程建议与来源观点明确分开。
- 原作者: 开发江鸟
- 原始来源: https://juejin.cn/post/7673413097324871715
- 原文发布时间: Thu, 13 Aug 2026 15:04:22 GMT
核心结论
AI小说创作工作流在实际运行中暴露了Eval假阳性问题：系统按照SOP执行、Skill全部运行、Eval判定通过、内部评分良好，但最终作品仍不符合读者阅读需求。这说明内部评分高并不等于实际质量好，流程正确执行不代表业务目标实现。
系统设计需要承认模型允许犯错、流程可能无法收敛。工程建议包括：每轮保存完整版本、自动保留最优版本、设置轮次或资源预算上限、标记未收敛任务、保留Trace供后续优化。系统应具备识别失败和停止资源消耗的能力，而非用更多Token将低收益任务伪装为成功。
能力机制
该工作流并非独立Agent，而是一个同时支持Claude Code和CoDEX的小说创作工作区。整体架构包含以下环节的映射关系：
- 将小说创作流程定义为SOP
- 将SOP映射为可执行的Skill集合
- 继续拆分为选题、正文、品类护栏、验稿、投稿等细分Skill
- 维护Workflow、Hooks、Memory、Eval、Trace、状态文件和检查脚本
- 由Claude Code或CoDEX执行完整流程
验稿Workflow中设计了多角色循环检查机制，从多个维度检查正文，发现问题后修改再检查。但问题数量不会稳定下降，可能出现反复波动如2→1→2→4→0→0，且即使最终问题归零，作品仍可能缺乏阅读吸引力。
Trace记录应包含四类信息：每轮发现的问题、解决问题调用的工具或Skill、模型判断依据、正文运行链路和版本变化。这些信息用于对照最终阅读感受，判断是选题阶段、生成阶段、修改过程还是Eval标准本身存在问题。
快速开始
工作流配置涉及的环境变量名称需参考仓库文档说明，密钥不提供示例值。核心运行逻辑由检查脚本和状态文件控制，可通过仓库提供的命令触发完整创作流程。
建议在本地维护每次运行的版本快照，便于后续对比和回溯。
适用边界
该工作流适用于需要批量生成结构化内容的场景，特别是可以明确定义评判标准的创作任务。核心教训同样适用于AI客服Agent等场景：Agent可能正确识别意图、按SOP调用工具、未触发安全风险、回复格式符合要求、离线Eval全部通过，但真实用户仍可能反复追问、重新发起问题或给出低满意度。
边界限制体现在：脚本适合处理输入输出和判断规则可固定的确定性问题，如文件字段完整性、状态流转、步骤执行、输出格式、重复遗漏检查、循环预算控制。而意图识别、文字质感、阅读吸引力、悬念设置等难以固定编码的判断，仍需模型处理，最终可能需要人工阅读感受参与校准。
核验清单
- Eval标准能否区分真正吸引读者的内容与仅满足技术指标的内容
- 系统是否有机制识别并标记未收敛任务
- 每轮运行是否保存完整版本并自动保留当前最优版本
- Trace记录是否包含问题发现、工具调用、模型判断依据和版本变化四类信息
- 循环机制是否设置明确阈值或资源预算上限
- 是否存在对比校准环节：用实际愿意阅读的内容与Eval高分但缺乏吸引力的内容进行对照分析
- 脚本与模型的职责划分是否清晰，确定性问题是否已交由脚本处理
- 系统是否能够在达到预算后停止并输出“不可交付”标记
来源与核验
- 原始文章
- 页面事实以原始来源及其引用的官方资料为准；版本、星标和模型能力会随时间变化。
- AI Stack 不公开抓取到的全文快照，只发布独立转写与来源入口。