过去一年里，我见过不少团队在“工作流编排”这件事上走出一条相似的曲线：一开始用大模型很兴奋，觉得只要把需求写进Prompt，让模型自己“理解并完成流程”，就能省掉一大段工程化成本；接着在一两个Demo场景上尝到甜头，于是把更多流程、更多角色权限都交给 Prompt；最后在真实生产环境里被各种边界条件、审计要求、跨系统协作和长尾异常拖入泥潭，不得不重新拾起一套看似“古典”的方法——用状态机把业务拆开，画出可视化状态图，让工作流回到可验证、可回放、可治理的工程轨道上。
这里不讨论“Prompt 不行，状态机才是正道”这样简单的结论。当业务逻辑的复杂度跨过某条临界线，系统的主要矛盾会从“如何让模型看懂需求”转变为“如何让流程在不确定环境中稳定运行并可追责”，状态机恰好是一种能够把不确定性压缩到边界、把确定性放回系统核心的结构化工具。回归状态机并不意味着放弃大模型，而是重新分配它在系统里的位置，从“流程的解释器”变成“流程节点的能力插件”。
一、Prompt驱动的早期胜利：像写需求一样写流程
Prompt 驱动工作流的吸引力极强，尤其适合早期探索。它把“流程定义”从代码与配置里抽离出来，变成一段接近自然语言的描述：谁来做、什么时候做、做完如何判断、失败怎么办，都可以写进 Prompt，然后让模型在运行时动态生成下一步操作。团队最初会发现三件事：
第一，表达成本低。产品、运营甚至客服同学都能参与“流程的编写”，不必等待工程实现； 第二，扩展速度快。新增一个分支或变更一个规则，改 Prompt 即可； 第三，流程看起来更“聪明”。模型会根据上下文自己补全细节，甚至能对输入的异常数据做一些人类式的修复。
在需求波动大、流程还不稳定、需要快速试错的阶段，这些优势非常真实，它们并不是免费午餐，而是把工程上的确定性让渡给了模型的解释过程；当流程复杂度上涨，偿还这种让渡的方式非常昂贵。
