5.1 工作流思维：从对话到节点图

5.1 工作流思维：从对话到节点图

工作流是一张有向图：开始节点定义输入，中间节点各干一件事，结束节点定义输出。数据以变量的形式在节点间流动，每个节点的输出用"节点名.变量名"引用。与聊天助手的根本区别：流程结构由画布决定，模型只负责被安排的那几步。

第 5 章开篇。本节完成思维切换（对话思维到节点思维），产出一张最小但完整的流程图；5.2 拆零件，5.3 总装。三节共用同一条业务线：自动转工单。

同一个需求，两种脑子

先看脑子怎么换。客服主管的需求是"答不上的问题转工单"。用第 3 章的对话脑子做，方案是在系统提示词里加规则："无法回答时，输出工单格式如下……"——转单逻辑活在模型的行为习惯里，输出格式偶尔漂移，字段偶尔缺斤短两。用工作流脑子做，方案变成一张图：开始（收问题）→ 分类（政策/投诉/闲聊）→ 分支 →（各路处理）→ 结束（输出结果）。每一步在哪个节点、什么条件走哪条边，都白纸黑字画在画布上。

两种脑子的适用分界，1.2 节的问题二已经给过：过程确定、步骤固定的，上工作流。转工单正是此类——分类标准固定、每类的后续动作固定。

这张图就是 5.3 节要总装的目标形态。本节的剩下的任务：把图上用到的三个基本概念吃透——输入变量、变量引用、试运行。

概念一：开始节点是流程的合同

开始节点定义这条流程对外承诺的输入：变量名、类型、是否必填。它就像函数签名——调用方（API 或聊天入口）按合同传参，流程内部按合同取数。给转单流程定义的合同：

开始节点输入变量
question    string   必填   用户的原始问题
member_level string  选填   会员等级，默认普通会员
order_id    string   选填   订单号，投诉类必有用
​

设计合同的要领与 3.1 节的变量克制一脉相承：宁可少而必，不要全而空。每个变量都会流经全图，无用的变量是节点间流动的杂物。

概念二：变量引用是节点间的传送带

上游节点的输出，在下游用节点名加点号加变量名引用。分类器节点叫 classifier，它的分类结果就是 classifier.class_name；知识检索节点叫 knowledge，检索结果是 knowledge.result（一个分段数组）。LLM 节点的提示词里写上这些引用，模型就能看到上游产物：

LLM 节点（起名 answer）系统提示词片段：
请依据下面的参考资料回答用户问题。
参考资料：{{#knowledge.result#}}
用户问题：{{#start.question#}}
​

两个易错点。其一，引用改了节点名就全部断链——重命名节点时平台会尽量自动更新引用，但手工改过提示词的要自己复查。其二，数组与单个值不能混用——knowledge.result 是分段数组，直接塞给 LLM 是可以的（平台会拼接），但要取第一条的得分就得用支持数组下标的字段。变量类型不匹配是新手排障日志里的头号常客。

概念三：试运行是流程的调试器

画布右上角的"运行"按钮用开始节点的合同弹一个表单，填入测试值单次执行。执行完画布上每个节点顶着自己的状态：绿色通过、红色失败、灰色未到达。点开任一节点，能看到它本次运行的实际输入输出——这就是节点级排障的全部依据，相当于传统开发里的断点打印。

先跑一个最小验证，练手这个调试器：

试运行输入
question = "发票开错了公司名怎么办"
member_level = "普通会员"
order_id = "SO-20260826-001"

执行轨迹（画布节点状态）
开始        通过  变量就位
classifier  通过  分类结果：政策类 置信度 0.91
knowledge   通过  命中 3 段 含 FAQ·发票第 2 条
answer      通过  输出 168 字答案
结束        通过  输出变量 answer.text
​

一次通过当然最好，但真实世界里更常见的是红色节点。排障动作固定三步：点开失败节点看输入（数据问题）、看节点配置（逻辑问题）、看运行日志的错误信息（环境或语法问题）。5.2 与 5.3 会给足失败样本。

从需求到节点清单的翻译法

思维切换的最后一块拼图是翻译方法论。我的三步翻译法：

第一步，动词清单。把需求里所有动词列出来：分类、检索、生成、提交、回复。每个动词对应一类节点（图 5-1 的工具墙按职能取）。

第二步，画泳道。拿一张纸画三条道——用户侧、模型侧、系统侧。转单需求里"提问"在用户侧，"分类、生成"在模型侧，"提交工单"在系统侧。泳道交界的每个点，就是一条边。

第三步，标变量。每条边问一句"这条边上传的是什么数据"，答案就是变量名。全图标完，输入合同与输出合同自然浮现。

⚠️ 常见坑：一上来就在画布上拖十几个节点，线连成一团毛球，试运行一红就整个人懵住。正确节奏是"最小可跑"：先搭两三个节点的主干道（开始→分类→结束），跑通；再一段一段加支线，每加一段跑一次。画布是代码，增量交付的老规矩在画布上同样成立。

💡 关键直觉：把工作流当函数看——开始节点是参数表，结束节点是返回值，中间节点是语句，条件分支是 if，变量引用就是取值。带着这个映射看画布，工程师半天就能上手；反过来，非工程师把它当流程图看，也能上手。这是工作流范式对两种背景的人同时友好的原因。

本节要点回顾

• 两种脑子：对话脑子把逻辑写进提示词，工作流脑子把逻辑画进节点——确定性需求必须用后者；
• 开始节点是合同：变量名、类型、必填三项定义清楚，宁少而必；
• 变量引用是传送带：节点名.变量名取上游数据，重命名要复查断链，数组与单值不混用；
• 试运行是调试器：单次执行、节点级输入输出可见，排障三步看输入、看配置、看日志；
• 三步翻译法：动词清单、画泳道、标变量，从需求到节点图的可复现路径。

思维就位，下一节把工具墙上的重型零件——分支、迭代、代码执行——逐个拆开看构造。