AI 画完审批流，先别点保存：我给分支路由加了两道门禁

让 AI 生成审批流并不难给它表结构、节点角色和金额规则几秒钟就能画出一张“看起来很完整”的流程图。真正危险的恰恰是这种完整感——节点都在、线也连着但某条线可能指向不存在的节点分支代码看着合理却从没拿一组真实样例跑过。我这次没有继续给提示词加形容词而是在“生成”和“保存”之间放了两道可重复执行的门禁先检查拓扑再试跑条件。目标很朴素让错误停在设计阶段而不是等第一张费用单卡在半路时才发现。一、流程图最会制造“已经完成”的错觉审批流不是一张静态图。它至少同时包含节点集合、连线集合、起止约束和运行期路由。任意一层错了页面仍可能画得很漂亮。我先构造了一个故障包连线bad的终点写成并不存在的ghost并且整个流程没有结束节点。肉眼看 JSON 时这两个问题很容易被大量坐标、样式和节点配置淹没交给拓扑检查后结果直接收敛为两条错误ToNodeId 不存在ghost、至少需要 1 个结束节点。同时它还提示“审批”节点没有入线、没有出线。这道门不判断业务好不好只回答更基础的问题这张图在结构上有没有资格被保存。这一步特别适合放在 AI 生成之后。因为模型通常会同时产出节点 ID、二维坐标、连线和条件脚本内容一多它更容易保持“文字叙述一致”却漏掉“引用完整性”。而拓扑检查不理解自然语言也不接受“总监节点应该在后面”这样的解释它只认实际存在的 ID 和边。这种冷冰冰的确定性正好补上生成模型最不稳定的一环。二、第一道门把拓扑当成可验证数据我使用的有效样例只有四个节点开始、经理审批、总监审批、结束四条线组成一条常规直达路径和一条高额升级路径。{ FlowName: AI费用审批, Nodes: [ { Id: start, NodeType: Start, Title: 开始 }, { Id: manager, NodeType: Approval, Title: 经理审批 }, { Id: director, NodeType: Approval, Title: 总监审批 }, { Id: end, NodeType: End, Title: 结束 } ], Lines: [ { Id: l1, FromNodeId: start, ToNodeId: manager }, { Id: l2, FromNodeId: manager, ToNodeId: director }, { Id: l3, FromNodeId: manager, ToNodeId: end }, { Id: l4, FromNodeId: director, ToNodeId: end } ] }检查器会核对节点与连线 ID 是否重复、连线两端是否存在、是否恰好有一个开始节点、是否至少有一个结束节点并对孤立节点发出警告。多出口节点如果没有条件配置也会被标成风险。这个集合不复杂却能挡住最常见、也最难靠页面观感发现的结构错误。三、第二道门条件不是“写过”而是“跑过”拓扑通过不代表分支会走对。我的经理节点有两条路线金额大于 5000 元时升级到总监否则直接结束。用于可视化条件试跑的配置被放在一个明确标记块里/* MICROI_WF_LINE_CONDITION_JSON { routes: [ { name: 高额升级, nextNodeId: director, conditions: [{ field: Amount, operator: gt, value: 5000 }] }, { name: 常规直达, nextNodeId: end, default: true } ] } MICROI_WF_LINE_CONDITION_JSON */然后我给同一节点送入两组表单数据Amount8000命中“高额升级”返回NextNodeIddirectorAmount1200没命中高额条件落到“常规直达”返回NextNodeIdend。这不是在脑内推演而是同一份条件配置的确定性试跑。四、实测结果坏包被拒两个边界值各走其路验证对象输入结果故障拓扑ToNodeIdghost无结束节点okfalse返回 2 条错误、2 条警告有效拓扑4 节点、4 连线oktrue无警告高额样例Amount8000命中“高额升级”下一节点为director常规样例Amount1200命中默认路线下一节点为end两组样例证明了主路径与默认路径能被区分但它们不是完整测试集。准备真正上线时我还会补上阈值本身、刚刚越过阈值、字段缺失、null、数字字符串等边界输入并为每个分支保留期望节点。这里特意不把“建议补测”写成“已经测过”可复现的两个结果与待完成的扩展测试必须分开记录。这里有个很重要的边界条件试跑器不会执行任意手写 V8 代码。它只读取上述标记块中的结构化条件并支持等于、不等于、大小比较、包含、前后缀、空值等有限操作符。也就是说它适合验证设计器生成的可视化条件如果你在节点里写了自由度很高的网络请求、数据库访问或复杂循环这个工具不会假装已经替你验证。这个限制反而让我更放心。设计期检查应该是纯函数、可重复、无副作用真实业务代码仍要在受控环境中单独测试。五、为什么我让路线返回NextNodeId旧式做法常用一个数字LineValue再去匹配连线。数字简单但阅读验证结果时要再查一次映射。样例里直接返回NextNodeId日志能明确写出“去 director”或“去 end”更适合 AI 生成后的自动回读。这不意味着运行期只靠一个字段就安全。真正提交审批时后端仍应从权威表单数据重算条件并继续执行权限、状态机、幂等和事务约束。门禁负责在保存前发现设计错误不代替运行期控制。六、把两道门放进 AI 交付流水线我把顺序固定成读取当前表结构与权限事实 → 生成 Manifest 草案 →dryRun→ 拓扑检查 → 条件样例试跑 → 用户确认 → 写入 → 回读。Microi吾码AI 在这里负责生成与编排而不是跳过确认直接改数据库。AI 草案 - Manifest dryRun - check_workflow_package - test_workflow_condition(8000) - test_workflow_condition(1200) - confirm - write - readback官方的 AI 开发工具说明 也把需求、蓝图/数据库事实、Manifest 预览、用户确认、MCP 写入和回读验收串成一条链工作流引擎文档 则说明条件判断发生在后端审批流执行过程中。设计期门禁与运行期判断各守一段边界组合起来才完整。用户确认并不是多余的“最后点一下”。拓扑检查只能发现结构不成立条件试跑只能证明样例与配置一致它们都无法替业务负责人决定“超过 5000 元是否真的需要总监审批”。因此机器门禁负责把错误压缩成清晰事实人负责确认业务意图写入后再由回读证明系统接受了同一份配置。三者缺一AI 交付都容易停在看起来完成的状态。七、这次验证到了哪里没到哪里本文的源码行为来自当前工作区microi.mcp/src/advanced-tools.ts四组结果来自本地纯函数工具的实际调用故障包和有效包都已保存到文章归档便于复跑。三张场景图是 AI 概念视觉实测图已明确标注不冒充线上界面。原计划还要把同一案例写入官方iTdos租户的mci_demo并在os.itdos.com截图但当前官方 MCP 返回“Token 签名验证失败请重新登录”。因此这次没有写远端数据也没有把本地结果包装成生产验证。等连接恢复后正确的补验动作是写入、菜单回读、浏览器打开、再用两张真实费用单走完分支而不是把本文的纯函数结果改名叫“线上已通过”。如果只记住一句话AI 画完流程图只是“生成完成”拓扑能闭合、样例能走对、写入后能回读才接近“交付完成”。