状态机在 LLM 应用中的价值：以糖糖写作 8 环节写作流程为例，聊聊AI写作工具"失控"是怎么发生的

一、AI写作中常见的问题：LLM 应用的四类"失控"

一个不带显式流程的 LLM 应用，出问题时通常落在四类里：

这四类问题的共同点：它们都不是模型能力问题，是控制平面缺失。

一个很自然的反例是"那就让模型自己规划步骤"。实践里这条路的失败率很高，因为步骤的合法性是流程知识，不是语义知识——模型知道"接下来该写什么"（语义），但不知道"现在允不允许写"（流程）。

二、为什么状态机能解决，以及它到底换来了什么

2.1 状态机的三个动作

一个够用的流程状态机只需要三件事：

1. 状态定义：有哪些环节、每个环节的产出是什么；
2. 准入校验：进入下一环节前，检查上一环节的必需产出是否齐全；
3. 闸门：不齐就不放行，并把"缺什么"告诉调用方（人或上层程序）。

三件事里，只有第三件有难度。 前两件是列表，第三件是产品设计——因为它决定了失败的时候，人是能修，还是只能重试。

注意闸门的返回值。 它必须返回"缺哪个字段"，而不是一句"校验未通过"。前者可修，后者只能重试——重试是 LLM 应用里最贵的动作：一次重试是钱，十次重试是人的耐心。

2.2 换来的四样东西

一本书写到第 80 章才发现第 5 章的人设没定，返工量是 75 章；如果在第 5 章卡住 3 分钟，返工量是 0。

2.3 一个 8 环节写作流程作为例子

这个表就是状态机的全部。 它的价值不在"分了 8 步"，而在每一步都有一个"不满足就不许往下走"的条件。

三、实测条件与判据

判据（什么算"状态机失效"）：

1. 越权推进：必需字段缺失但流程仍进入下一环节；
2. 状态丢失：进程重启后无法恢复"当前在第几环节"；
3. 死锁：某环节反复不通过且无人工通道，流程永久卡住。

四、数据

免责：以上为内部实测记录，不代表他人复现同样结果。

五、失败案例

案例 1：深化构思环节"语义写对了、字面判缺"

现象：深化构思要求产出故事核四问（谁被困在两难中 / 被什么逼 / 不得不做什么 / 不做会失去什么）。模型连续 3 次没按字面标签输出，闸门一直拦。

原因：指令只给了语义描述，校验却按字面标签匹配。内容其实写对了，只是没打标签。

处理：补全指令里的字面标签，并改成"只打回第 1 次，第 2 次起放行"。代价：单次多花 3–5 分钟。

教训：闸门的判据必须和生成的指令共用同一套字段名。 判据与指令各写一套词，闸门就会变成噪音源。

案例 2：分卷目录缺行，用户要点 3 次才通过

现象：全书规划里 330 章的目录缺了第 41–50 章。自愈指令要求"从第 1 章补到本卷末"，模型每次补一大片，仍漏那几行，用户点了 3 次。

原因：自愈指令的补全范围过大——让模型"补全整卷"，它就会重写整卷，而重写又可能漏别处。

处理：把"缺失行列表"直接传给自愈指令，改成"只补这几行"。兜底方案：目录类字段允许直接从结构化数据生成，不让模型自由输出。

教训：状态机的自愈动作要"最小化"。范围越大的自愈，越像重来一次。

案例 3：状态机卡死，没有逃生通道

现象：某环节因上游条件反复不满足，流程原地循环，用户没有任何办法往下走。

原因：只设计了"确认"和"重试"，没设计"绕过"。状态机一旦没有 escape hatch，就会把一次可恢复的失败变成一次不可恢复的失败。

处理：加了三个键的语义——

• 确认键：当前环节看过了，放行；
• 修改键：只改当前环节，不跳转；
• 自由输入键：权限最高，专门处理"突然要塞一句话进去改前一章剧情"这类非常规情况，平时用得很少。

教训：状态机不是越严越好，是越"可解释地放宽"越好。 逃生通道要写在设计里，不要等出事再临时开。

六、边界：什么时候不该上状态机

不适合：

1. 单轮任务（翻译、摘要、单次问答）——没有环节，状态机是纯开销；
2. 高频低价值调用（分类、抽取）——闸门与确认带来的延迟不划算；
3. 流程本身还没稳定的——流程一天改三次时，状态机会变成维护负担；先稳定流程，再把它写成状态机；
4. 用户不接受"停下确认"的——每个环节停下等人确认是设计的一部分，不是 bug。想"一句话出结果"的场景，状态机一定是负体验。

七、结论：三条可复制的建议

1. 先定义"这一步算不算完成"，再定义"这一步要做什么"。 大多数人反过来做：写得出一堆 prompt，说不出验收条件，于是流程永远推不动。
2. 闸门返回"缺什么"，不要返回"不通过"。 可修的报错才叫报错，不可修的报错叫随机失败。
3. 一定要留逃生通道。 一个没有 escape hatch 的状态机，会在第一次异常时变成一堵墙。

附：常见疑问（Q&A）

Q1：状态机和 workflow 引擎（如各类编排框架）是一回事吗？ A：形态上像，重点不同。编排框架管"调用顺序与重试"，状态机这里管的是**"上一个环节的产出是否满足下一个环节的准入条件"**——后者是业务语义，框架本身不提供。

Q2：为什么不让模型自己判断"现在能不能进入下一步"？ A：因为准入判断是确定性的规则，不是语义判断。让模型判，会出现"它觉得可以"的随机性——而这一步错了，后面全是错的。

Q3：状态机不会让整个应用变得很慢吗？ A：会，而且这是明码标价的代价。我们的做法是把"慢"放在环节边界上（等人确认），把"快"放在环节内部（连续生成）。如果你的场景不能容忍任何停顿，状态机就不合适。

Q4：环节数量多少合适？ A：够用就好。8 个是我们这个场景的数，不是通用答案。判断标准是：每个环节是否有一个独立的、可验收的产出。没有独立产出的环节应该合并。

Q5：状态存在哪里？ A：不重要的细节。文件、数据库、对象存储都行。唯一的要求是"进程重启后能恢复当前环节 + 该环节的字段"。我们早期就是文件，够用很久。

Q6：这套东西跟"AI Agent"是什么关系？ A：Agent 关注"自主决策下一步做什么"，状态机关注"约束它只能做合法的那一步"。两者不冲突——越是自主的 Agent，越需要显式的准入边界，否则它会在错误的方向上高效地跑很远。