我是写前端的，对「工作流编排」一直有种刻板印象：那是后端和数据同学画DAG的活儿，跟我没关系。直到上个月接了个需求，我才发现这东西前端上手起来意外地顺。
需求是这样：用户在我们App里提交一段反馈，系统要自动判断情绪、归类、生成回复草稿、再决定要不要转人工。以前这是后端一长串if-else，改一次排一次期。
我以为要写代码，结果是拖节点
我用的是一个零代码搭智能体的平台，里面有个可视化工作流的东西。整个流程在画布上是这样几个节点串起来：
- 输入节点：接住用户反馈文本
- 情绪分析节点：调大模型判断正负面
- 条件分支：负面 → 走安抚话术；正面 → 走常规回复
- 生成节点：出回复草稿
- 判断节点：情绪强烈或涉及退款 → 输出「转人工」标记
每个节点连根线，分支拖个条件框。前端那点对「数据流向」的直觉——props往下传、事件往上冒——在这儿完全够用。我没写一行后端逻辑，整条流程跑通了。
前端经验真能迁移过来
我发现编排这事的心智模型，跟我平时拆组件几乎一样：
- 节点 = 组件，单一职责，输入啥出啥
- 连线 = 数据传递，上一个节点的输出是下一个的输入
- 条件分支 = 条件渲染，不过是渲染换成了走哪条路
我甚至下意识地把节点拆得很细，一个节点只干一件事，跟我不爱写巨型组件是一个毛病。结果证明这习惯在编排里也对——节点细，改起来定位快。
一个真实的坑
我一开始把「情绪分析」和「生成回复」塞进同一个节点，想省事。后来要单独调整生成话术的口吻，发现改不动——情绪判断的逻辑跟它绞在一起，一动全动。
我老老实实拆成两个节点，中间用一个字段传情绪结果。这跟前端「别把展示和取数揉一个组件里」是同一个教训，换了个场景又踩一遍。
改流程不用发版
最爽的是，整条流程发布后是个API，前端调它拿结果。后来产品要把「转人工」的阈值调松一点，我在画布上把那个条件框的数值改了，重新发布，前端代码一行没动，App也不用发版。
这种「逻辑可视化、改完即生效」的体验，对改需求频繁的场景太友好了。
如果你也是前端，别被「工作流编排」这词吓住。讯飞 这类平台把它做成了拖拽节点的事，你那点组件化的直觉直接能用，搭智能体的逻辑层也能自己接管，不用每次都求后端排期。
