ZGI Workflow：条件分支走错时先查哪一层

工作流里最让人困惑的故障，往往表现为"明明满足条件，却走了另一条路"。审批状态已经写成通过，流程却进入补充材料；金额低于阈值，后续节点仍然被跳过。只盯着最后一个节点，很难知道问题从哪一层开始。

条件分支的判断链可以拆成四段： 输入变量先进入变量池，条件节点读取指定路径并完成比较，调度器根据命中的分支句柄激活后续路径，节点输出再写回变量池。排查顺序跟着这条链走，通常比反复修改提示词更快。

概念示意图：从输入变量到下游输出，四层检查对应四类常见故障。

先看输入变量有没有到位

条件节点只能读取已经进入变量池的值。上游节点输出字段改名、路径层级写错，或者节点被跳过，都会让条件读取到空值或旧值。检查时先记录变量选择器、实际值和产生它的节点，确认三者能够对应起来。

在 ZGI Workflow 中，节点输出会写回变量池，后续节点按节点标识和字段读取。这个关系适合放进排查表： 输入来自哪个节点，字段叫什么，运行时拿到的类型是什么。字符串"100"和数字 100 也要分开看，比较操作可能因此出现不同结果。

输入值正确，仍可能在比较环节出错。常见原因包括大小写、前后空格、日期格式、空值处理，以及把"包含"误写成"等于"。多个条件同时存在时，还要确认使用的是 AND 还是 OR，以及条件组的顺序是否符合业务规则。

条件分支节点会根据变量选择器读取值，按逻辑运算计算每个条件，并保留条件结果。把每个条件的实际值、期望值、比较符号记下来，能让"看起来应该命中"变成可复核的记录。

排查层	需要核对	常见线索	处理动作
输入	变量路径、类型、最新值	空值、旧值、字段改名	回到上游节点确认输出
条件	比较符号、期望值、AND/OR	空格、大小写、格式差异	固定示例值做单次测试
分支	命中句柄与激活路径	false 分支被选中、节点被跳过	对照运行记录看调度结果
输出	下游节点输入与最终结果	输出字段缺失、状态未更新	检查变量回写和消费节点

条件结果为真，只代表某个分支被选中。后续节点是否执行，还要看图上的连接关系和上游分支状态。调度器会沿着激活的边继续运行；没有激活上游的节点可能被跳过。遇到"条件判断正确但结果没出来"，应把视线移到分支句柄和边的连接上。

运行记录里同时查看条件结果、分支句柄和节点状态，会比只看最终回答更有用。若命中句柄与预期一致，问题多半在连接或下游输入；若句柄就不对，再回到变量与比较条件。

准备三组固定数据： 明确命中、明确不命中、边界值。每组只改一个字段，记录输入、条件结果、命中分支和下游输出。这样可以排除并发任务、旧变量和外部接口波动带来的干扰。

对于金额、日期、枚举状态等字段，给出统一格式和默认值。对来自模型的自然语言结果，先经过结构化节点再进入条件判断，减少"已通过""通过了""审核通过"等表达差异造成的分支漂移。

分支问题经常在流程更新后再次出现。每次修正后，把测试样本、预期路径和实际结果保留下来；上线前再跑一遍，确认条件、连接和下游字段都没有变化。ZGI 的运行记录与变量池为这类复核提供了可追踪位置，团队可以围绕同一份记录讨论输入、判断和执行结果。

条件分支的稳定性来自链路清楚： 输入有来源，条件可复核，命中路径看得见，下游输出接得上。按照四层顺序检查，定位工作会更接近事实，也更容易沉淀成团队自己的验收清单。