1. 工作流基础：什么是大模型工作流、工作流的核心要素、工作流与传统编程的区别

大家好，我是你们这门课的主讲。今天咱们聊聊最基础的东西——大模型工作流到底是什么。

说实话，我第一次接触这个概念时，也觉得有点虚。不就是把几个提示词串起来吗？后来踩了不少坑才明白，事情远没那么简单。

1.1 什么是大模型工作流

大模型工作流，说白了就是把多个大模型调用、数据处理、条件判断、人工审核等步骤，按照特定顺序编排成一个自动化流程。

举个例子。你让大模型写一篇产品文案：

• 第一步：输入产品参数，让模型生成初稿
• 第二步：检查初稿是否包含敏感词
• 第三步：如果包含，自动替换；如果不包含，进入下一步
• 第四步：让另一个模型做润色优化
• 第五步：输出最终结果

你看，这就不是一个简单的「问一句答一句」了。它涉及多个步骤、条件分支、甚至多个模型协作。

我在项目中遇到过最典型的场景是客服系统。用户问一个问题，工作流先判断意图，再决定调用哪个知识库，最后生成回复。如果模型不确定，还会转人工。整个过程完全自动化。

1.2 工作流的核心要素

一个完整的大模型工作流，离不开这几个要素。我习惯把它们分成五类：

要素	说明	我踩过的坑
触发节点	工作流怎么启动？定时、API调用、还是事件触发？	曾经忘了加频率限制，结果被用户刷爆了API额度
处理节点	每个步骤做什么？调用模型、处理数据、还是调用外部API？	模型调用超时没做重试，导致整个流程卡死
条件分支	根据结果走不同路径。比如模型输出不符合预期，就重新生成	条件写得太死板，模型稍微换个说法就匹配不上
数据流转	上一个步骤的输出怎么传给下一个步骤？	数据格式没统一，模型A输出JSON，模型B却要纯文本
错误处理	出错了怎么办？重试、跳过、还是通知人工？	曾经没做错误处理，半夜三点被报警电话吵醒

你想想看，这五个要素缺一个，工作流就跑不顺。尤其是错误处理，很多人一开始都不重视。

1.3 工作流与传统编程的区别

这个问题我经常被问到。很多开发朋友觉得：「不就是写代码吗？我用Python也能实现啊。」

嗯，这话对，也不对。

咱们直接看对比：

维度	传统编程	大模型工作流
确定性	输入相同，输出一定相同	输入相同，输出可能不同（模型有随机性）
调试方式	断点、日志、单元测试	需要检查提示词、模型输出、上下文
状态管理	变量、数据库、缓存	对话上下文、历史记录、中间结果
错误类型	语法错误、逻辑错误、异常	模型幻觉、输出格式不对、语义偏差
开发周期	写代码→测试→部署	写提示词→测试→调提示词→再测试

为什么会这样？因为大模型本身就不是一个「确定性的函数」。你给它同样的提示词，它每次回答可能都不一样。

我记得有一次做文档摘要工作流。传统编程的话，我写个正则匹配就能搞定。但用大模型，我得考虑：模型会不会漏掉关键信息？会不会自己编造内容？输出格式能不能保持一致？

说白了，传统编程是「你告诉计算机怎么做」，大模型工作流是「你告诉计算机你想要什么，它自己想办法」。

举个例子。传统编程里，你要判断用户输入是否包含「退款」这个词：

if "退款" in user_input:
    handle_refund()
else:
    handle_other()

但在大模型工作流里，你可能会这样写：

# 让模型判断用户意图
prompt = f"用户说：{user_input}\n请判断用户意图：退款、咨询、投诉、其他"
response = llm_call(prompt)

if "退款" in response:
    handle_refund()
elif "咨询" in response:
    handle_consult()
# ...

你看，判断逻辑从「精确匹配」变成了「语义理解」。这就是本质区别。

另外还有一个点——工作流天然支持可视化编排。传统编程你得看代码才能理解流程，但工作流可以用拖拽的方式画出来。这对非技术人员特别友好。

我在团队里推广工作流时，产品经理也能参与设计了。他画流程图，我来实现背后的逻辑。效率提升了不少。

小结一下

这一章咱们聊了三件事：

• 大模型工作流是什么——把多个步骤编排起来，让大模型协作完成任务
• 核心要素有哪些——触发、处理、分支、流转、错误处理，一个都不能少
• 和传统编程的区别——从确定性到不确定性，从精确匹配到语义理解

下一章，我会带大家动手搭一个最简单的工作流。到时候你就知道，这东西看着复杂，上手其实挺快的。

嗯，今天就到这儿。有问题欢迎在评论区交流。