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