不管在什么时代，对业务流程的抽象都不会发生变化，仍然是：人、事、物、规则

不管在什么时代，对业务流程的抽象都不会发生变化，仍然是：人、事、物、规则

LLM的最大优势是理解语义、做决策、制定计划、生成内容，在LLM时代的编程，本质是让渡了大脑的部分能力给AI，可以把LLM当成第二大脑。

传统的编程范式会经过几个阶段，用户提出需求 → 产品设计业务流程 → 程序员绘制业务流程图 → 程序员翻译成代码语言 → 机器执行。在LLM时代可能会直接变成用户提出需求 → LLM → 机器执行。

LLM会极大缩短业务需求的交付周期，但正如火车在刚发明的时候甚至不如马车跑得快一样，LLM在最开始的稳定性和性能都是弱于传统编码方式的，但它是完完全全的新物种，有非常大的想象空间，并在持续进化中。

LLM的编程革命不是一蹴而就的，是逐步渗透的过程，我们需要做的就是拥抱变化，并加速这个过程的发生。在这个过程中，核心会经历以下几个阶段，

1. 通过语义描述生成代码。Github Copilot已经在这么干了，目前只是用来生成原子化的代码片段，如生成单元测试
2. 将语义函数Semantic Function作为已有业务流程的一部分，用于实现那些无法通过代码直接实现的功能，比如解析工单、解析告警消息、解析用户的咨询等对非结构化文本的解析。这要求我们对LLM的调用进行封装，并注册为HTTP或微服务等内部协议，方便已有流程调用。语义函数有确定性的服务描述、确定性的返回结果、可以不确定性的入参String
3. 将语义函数与传统函数Native Function进行编排，组装成业务流程。由于语义函数已注册到内部服务中心，可以方便被本地函数调用，也方便被其他语义函数调用，集成在已有的业务流程中。比如在告警处理流程中，嵌入一个语义函数将文本化的告警信息解析成结构化的内容，并提取关键信息
4. 用语义（结构化的Prompt）实现低代码编排业务流程，结合着BPMN引擎，通过语义生成Flow的描述文件，需要程序员再做一层double check和调整。OpenAI的GPTs，通过Action来调用外部服务，本质上也是低代码的实现
5. 零代码实现，将原始需求直接转化为结果，省略中间所有步骤。这里需要注意，最终可能不是一个全知全能的Agent自己设计精确的流程，很可能是Mixture of experts的形式，用一个团队来实现复杂的、模糊的需求