我搞这个小说创作仓库，最初并不是为了研究 Agent，也不是为了展示什么 AI 工程能力。
原因其实特别朴素：小说和短剧看多了，我实在是被坑怕了。
好不容易找到一本感兴趣的小说，看到一半太监了；或者前面写得还不错，后面突然冒出一个完全无法接受的雷点。想重新找一本能看的，又要在一大堆作品里反复试毒。
书荒的时候真的烦得要死。
我就产生了一个想法：既然找一本自己想看的小说这么难，能不能让 AI 按照我的要求写给我看？
我想看什么题材，就写什么题材；不想看到哪些雷点，就从规则里提前排除；故事怎么发展，也可以按照自己的喜好控制。
简单来说，我想自给自足，实现"小说自由"。
后来学了很久 Agent、SOP、Skill、Trace 和 Eval 这些理论，我突然想起来：我其实早就按照自己当时对 Agent 的理解，搭过一套 AI 小说创作工作流。
它并不是一个独立 Agent，而是一个同时支持 Claude Code 和 Codex 的小说创作工作区。
我先定义小说创作 SOP，再把 SOP 映射成一组可以执行的 Skill，然后继续拆成选题、正文、品类护栏、验稿、投稿等更细的 Skill。仓库里还维护了 Workflow、Hooks、Memory、Eval、Trace、状态文件和检查脚本，让 Claude Code 或 Codex 能够接手并执行整套流程。
当时我觉得自己这套设计老牛了。
规则有了，流程有了，质检有了，连循环改稿都有了。理论上，我不仅能避开那些把我坑怕了的雷点，还能想看什么就生成什么。
结果真正跑起来以后，浪费时间、浪费钱、浪费 Token，最后写出来的东西还是不好看。
小说自由没实现，Token 倒是自由地消失了。
说难听点，不如回家种田。
流程没有跑错，结果却失败了
最让我难受的不是系统没有按照要求运行。
恰恰相反，它运行得很好。
它按照 SOP 完成创作，调用了我设计的 Skill，进入验稿 Workflow，再由多个角色从五个维度检查正文。发现问题以后就修改，修改完成以后继续检查，直到问题消失。
内部评分也很好看。
但我作为一个看了十五年以上网络小说的读者，真正读完正文以后，最直接的感觉还是：不好看，我不想继续读。
更现实的是，我把作品发到市场以后，平台确实给过推流，但没有人看。
这说明当前的问题不是"执行端有没有遵守流程"，而是"我设计的流程和 Eval，到底有没有衡量真正重要的东西"。
我第一次真正理解了 Eval 假阳性
以前设置 Eval，是因为我相信：
只要作品满足这些标准，最后的读者就会满意。
但现在出现了另一种情况：
- SOP 正确执行了；
- Skill 全部运行了；
- Eval 判定通过了；
- 内部评分很高；
- 最后的作品却不好看；
- 真实读者也不愿意继续阅读。
这就是 Eval 假阳性。
系统判定成功，但真正的业务目标没有实现。
评分从来不是目的。设置评分，是因为我们相信它能够保证最终结果更值得继续阅读。
如果作品得了高分，却不能让人继续读，那么这个高分没有意义。它最多只能证明作品满足了当前 Eval 能够识别的要求，不能证明作品真的好看。
如果一个正常、非恶意的用户明显不满意，而系统仍然认为任务完成，那么首先需要怀疑的就不应该是用户，而是 Eval 的标准。
无限 Loop 并不会自动带来好作品
我在验稿 Workflow 里设计过一个 Loop。
多个角色检查正文，收集问题，修改，再重新检查。如果仍然存在问题，就继续下一轮。
当时没有给循环设置明确阈值，因为我不希望人工介入。我希望系统能够自己发现问题、自己修改，直到作品真正合格。
实际运行以后，我发现问题数量并不会稳定下降。
一次真实 Trace 中，严重问题数量出现过这样的变化：
2 → 1 → 2 → 4 → 0 → 0
它不是持续收敛，而是在反复波动。
更重要的是，即使最后问题数量变成了 0，正文仍然没有变得好看。
"没有检测到问题"只代表当前质检角色无法再根据已有标准发现问题，并不代表作品已经具备阅读吸引力。
继续循环只会消耗更多 Token，却不一定带来对应收益，甚至可能在修改过程中破坏原本还不错的部分。
系统必须允许失败
以前我过于理想化了。
我总觉得再厉害一点的模型、多检查几个维度、多修改几轮，最终总能得到正确结果。
但模型本来就允许犯错，流程也可能无法收敛。
更合理的处理方式应该是：
- 每轮保存完整版本；
- 自动保留当前表现最好的版本；
- 记录每轮新增、解决和回归的问题；
- 达到轮次或资源预算后停止；
- 如果仍未满足交付条件，标记为"未收敛、不可交付"；
- 保留 Trace，供下一次优化流程和 Eval 使用。
失败状态不是系统没做好。
相反，能够识别失败、停止浪费资源，并留下可以分析的证据，才是一个可靠系统应该具备的能力。
至少它不会用更多 Token，把一个无法完成或者边际收益已经很低的任务伪装成成功。
Trace 应该帮助我回答什么
当作品不好看时，我现在只能笼统地说"不好看"，却很难解释究竟哪里不好。
这也是我目前最苦恼的地方。
因此，Trace 不能只记录"运行成功"和最终评分。它至少应该让我看到四类信息：
- 每一轮发现了什么问题；
- 为了解决问题调用了什么工具或 Skill；
- 模型依据什么做出判断；
- 正文经过了怎样的运行链路和版本变化。
只有把这些信息和最终阅读感受对照起来，我才能判断：
- 是选题阶段已经出了问题；
- 是正文生成没有实现选题承诺；
- 是某次修改把原本的优点改没了；
- 是质检标准遗漏了真正影响阅读欲望的因素；
- 还是整个 Eval 都在奖励错误的东西。
Trace 的价值不是证明流程跑过了，而是帮助我定位：流程究竟从哪里开始偏离真正的目标。
能交给脚本的，就不要继续消耗模型
这次优化也让我重新划分了脚本和模型的职责。
凡是输入、输出和判断规则可以固定的内容，都应该尽量交给脚本处理。例如：
- 文件和字段是否完整；
- 状态是否正确流转；
- 必要步骤是否执行；
- 输出格式是否符合约束；
- 是否出现重复、遗漏或明显冲突；
- Loop 是否超出预算。
这些问题不需要每次都让模型重新理解和判断。
而意图识别、文字质感、爽感、悬念和"是否值得继续阅读"这类难以固定编码的判断，仍然需要模型、Subagent，最终可能还需要人的阅读感受参与校准。
脚本解决确定性问题，模型处理非确定性问题。
但模型给出的高分，也不能直接被当成真相。
我缺少的可能不是更多质检，而是拆书和校准
我一直觉得自己的流程缺少一个重要环节：拆书。
给系统一篇我真正喜欢、愿意继续阅读的作品，让它按照当前仓库的标准分析：
- 为什么这篇作品好看；
- 它如何制造继续阅读的动力；
- 它在哪些地方满足了现有标准；
- 它有哪些优点根本没有被现有 Eval 捕捉到。
我以前似乎尝试过类似的做法，但效果并不好。
现在回头看，问题可能在于我让模型直接总结"优秀作品的规律"。模型很容易生成一套听起来正确、实际上无法区分好坏的标准。
相比之下，我更想尝试对比校准：
- 选择一段我愿意继续读的作品；
- 选择一段内部 Eval 高分、但我不愿继续读的作品；
- 隐去来源进行对比；
- 先记录我更愿意继续读哪一段；
- 再让模型解释两者的差异；
- 由我确认哪些差异确实影响了阅读感受；
- 只有反复出现并得到确认的差异，才逐步进入新的 Eval。
我的个人喜好当然不是整个市场的唯一标准。我不喜欢的作品，也可能是一部优秀作品。
但这套系统最初就是为了解决我自己的书荒：让我不用继续到处试毒，而是可以生成自己愿意读下去的小说。
因此，"我是否愿意继续阅读"不是一个后来临时增加的苛刻要求，而是这个项目从第一天开始就应该实现的核心目标。
如果系统内部评分很高，最后生成的作品却连我自己都读不下去，那么无论流程多完整、Eval 分数多漂亮，它都没有完成最初的任务。
我想实现的是小说自由，不是评分自由。
把一个环节拿出来，让社区参与共创
我也考虑过，把脱敏后的仓库直接开源，让更多人一起共创。
但仓库现在包含很多 Skill，整套流程又很长。如果直接扔出完整仓库或者一篇完整短故事，别人未必有时间看，也很难快速理解问题究竟出现在哪个环节。
更现实的方式可能是每次只拿出一个具体环节：
- 一次选题输入和输出；
- 一段正文及其验稿结果；
- 一轮修改前后的版本；
- 一份 Eval 标准和对应的 Trace；
- 一个系统评分很高、但实际不好看的失败案例。
社区可以帮助提出新的观察角度、判断标准或者改进想法。
我再把这些建议放回真实工作流中实践，观察最终正文和 Trace 是否发生了有意义的变化。
社区不能替我决定什么小说是我喜欢的，但可以帮助我把"不好看"逐渐拆成能够讨论、验证和改进的问题。
这件事也适用于 AI 客服助手
我原本真正想做的主功能，是一个 AI 客服助手。
小说工作流暴露的问题，同样会出现在客服 Agent 中。
一个客服 Agent 可能做到：
- 正确识别了意图；
- 按 SOP 调用了工具；
- 没有触发安全风险；
- 回复格式符合要求；
- 离线 Eval 全部通过。
但真实用户可能仍然反复追问、重新发起问题、投诉，或者给出很低的满意度。
这时不能只说"Agent 已经按照流程回答了"。
如果正常用户仍然没有解决问题，那么内部 Eval 同样出现了假阳性：流程完成了，但业务目标没有完成。
最后
这次我真正学到的，不是再增加几个质检维度，也不是再让模型多改几轮。
而是承认：
- 再厉害的模型也允许犯错；
- SOP 正确不代表业务结果正确；
- Eval 通过不代表用户满意；
- Loop 增加不代表质量持续提升；
- 没有检测到问题，也不代表作品已经好看。
一套可靠的 AI 工作流，不应该只能证明自己成功。
它还应该能够识别没有收敛的任务，保留目前最好的版本，停止无意义的资源消耗，并通过 Trace 告诉我：这一次为什么失败，下一次应该从哪里改。
允许失败，才能真正优化流程。
否则，再完整的 SOP、再漂亮的评分和再昂贵的模型，也可能只是在更加自动化地浪费时间和钱。
而我还在那里，看着一篇自己都读不下去的小说，认真怀疑：
要不还是回家种田吧。