实战：AI订单履约助手的选型与工作流设计

AI PM 选型实战 · 决策树走一遍 · 工作流五节点 · 兜底三预案

一句话价值：把决策树走到订单履约助手这个真实项目上：Workflow 主干 + RAG 知识节点 + 三道兜底，给你一张能照着画的工作流图。 

给管理者的三句话：① 好的 AI 工作流是"主干确定、枝叶可换"——换模型不换骨架；② 每个 AI 节点旁边必须坐着一个人工兜底节点，画图时就要画上；③ 工作流图是 PRD 第 7 节的灵魂——开发照着它排期，测试照着它写用例。 

开篇：树走到项目上

前两篇给了三条路线对照和五层决策树，都是工具。这篇走一遍真实项目——还是贯穿全系列的 AI 订单履约助手。需求复习一下：客服每天接到大量订单咨询，要翻三个系统，单均 4 分钟；V1.0 要做到意图自动分类 + 话术一键回填，单均 30 秒以内。

选型评审会上，算法团队提议上 Agent："多轮对话更自然，用户体验好。"这个提议不是拍脑袋——Agent 确实能聊。但我们还是把决策树从第一层开始走了一遍，走完，答案自己出来了。

这篇就完整复盘那次走树过程：每层问了什么、谁拍的板、结论是什么，以及最后画出来的工作流图长什么样。你可以拿着这张图当模板，换掉节点内容就是你的项目。需要说明的是，这个项目的方法论在前面九篇都拆开讲过，这篇是第一次把它们组装成完整作战单元。

先说结论：Workflow 主干 + RAG 知识节点 + 零 Agent，三道兜底预案。这个结论不是"省钱省出来的"，是走树走出来的——每一层都有记录，评审会上没人能推翻。

【核心观点】走树五步，答案自己出来

把上篇的五层树，一步步走到这个项目上：

第 1 层 规则层：能 if-else 吗？——意图就 20 类，其中 12 类靠关键词就能定（"到哪了""改地址"），但还有 8 类说法多变。结论：规则能兜底一半，不够，往下走。

第 2 层 流程层：步骤固定吗？——固定：分类→查订单→找话术→推荐给客服→客服确认发送。五步一步不乱。结论：Workflow 当主干。

第 3 层 知识层：要外部知识吗？——要，话术库 800 条，按问题类型组织。结论：加 RAG 节点，而且数据量小，关键词检索就够。

第 4 层 自主层：步骤要模型临场定吗？——只有一个候选：多轮澄清。但它在 Non-goal 里（V1 不做多轮）。结论：不上 Agent。

第 5 层 兜底层：错了谁接？——分类置信度低转人工、检索无匹配用通用话术、系统故障降级原查询页。结论：三预案写进 PRD 第 6 节，放行。

五层走完二十分钟，算法团队也认了——因为每一步都是"是/否 + 事实"，没有立场之争。走树的意义就在这：把"我觉得"变成"记录上写着"。

【技术解析】工作流五节点对照

五个节点里，只有前两个带 AI 成分，第三个是模板规则，第四、五个纯人工。这个比例是健康的——AI 只出现在它不可替代的地方，其余全部用确定性组件。很多团队的工作流是反的：恨不得每个节点都挂个模型，显得"智能"。

看一张工作流图健不健康，数一数：AI 节点占比多少？每个 AI 节点有没有向下的兜底虚线？有没有回环的反馈线？三个问题有一个答不上来，图就没画完。

节点和节点之间还要有"数据契约"：每个节点定义清楚输入什么格式、输出什么格式、超时多久、失败去向哪。比如节点 1 的输出是"意图类别 + 置信度"两个字段，置信度低于 0.7 直接走兜底虚线，不往下传。契约写清楚，节点才能各测各的、各换各的——今天换分类模型，只要输出还是那两个字段，下游零改动。

【架构设计】画工作流的三条规矩

1. 主干实线、AI 节点标图标。业务流程用实线画死，顺序、分支、回退一目了然；AI 节点用特殊图标（比如闪电）标出来，一眼看出"智能在哪"。

2. 每个 AI 节点画兜底虚线。从每个 AI 节点向下画一条虚线，指向"失败后去哪"——人工、降级、默认值。虚线和实线一样重要，画图时不画，开发就不会实现。

3. 数据回流画回环。从末端画一条回环线到金标集：人工确认的结果、bad case、客服修改记录，全部回流。没有回环的系统是漏水的桶——永远在学新东西，永远不积累。

三要素齐了，这张图就是活的：开发照着排期（节点即任务）、测试照着写用例（每节点一组正反例）、运维照着监控（每节点有指标）。一张图管三个角色，这才是 PRD 第 7 节该有的样子。

最后一条心法：先画图，再写代码。图没画完就开工，等于施工队没图纸就进场——节点漏一个、兜底少一条，都是上线后的半夜告警。

【实践经验】评审会上的两个回合

第一个回合是 Agent 之争。算法团队说："先上 Agent，以后加多轮澄清方便。"我们回应：多轮澄清在 Non-goal 里，V1 不做；如果 V2 要做，Workflow 主干上加一个节点就行，不动骨架。为两年后可能的需求，现在每年多付 20 万维护费，不值。算法负责人算了算账，同意。

第二个回合是向量库之争。开发想上向量检索，说"RAG 标配"。我们问：话术库多少条？800。更新频率？每周。那就关键词检索 + 定期重建索引——800 条数据的语义匹配，关键词的准确率足够，还省一套向量库的部署和运维。最后用的就是关键词方案，检索节点两天做完。

项目最终六周交付，单均 28 秒，兜底率 3.2%。上线三个月后做了一次升级：把分类模型换成更强的版本——只换了节点 1 的内部实现，主干一步没动。这就是"主干确定、枝叶可换"的红利。

复盘时客户方说："你们这个图我看懂了，哪块是哪块清清楚楚，以后加需求我知道往哪加。"——工作流图不只是内部文档，它是和客户对齐"系统长什么样"的共同语言。

最后提醒版本管理：工作流图和 PRD 是同一份资产，要一起变更、一起归档。我们给每个版本的工作流图编号（V1.0、V1.1），图上有变更记录栏——哪天加了兜底、哪天换了检索方式，一行字写清。三个月后新人入职，翻图比翻代码快；扯皮时翻图，比翻聊天记录硬。

【避坑指南】工作流设计的五个坑

① 为"未来扩展"提前上 Agent。 Non-goal 里的需求，等它进了 Goal 再说——现在上，每年多付冤枉钱。

② 工作流图不画兜底线。图上是全须全尾，上线后节点一失败就裸奔——兜底虚线和主干实线一样重要。

③ RAG 节点用大炮打蚊子。800 条话术上向量库全家桶——先看数据规模和更新频率，简单方法够用就别上重装备。

④ 数据回流不画。上线即结束，bad case 没人管——没有回环的系统是漏水的桶，永远不积累。

⑤ 工作流图和 PRD 第 7 节两张皮。图在 PPT 里、写在文档又是另一套——图就是第 7 节本体，别让它当摆设。

技术图：订单履约助手工作流

下次画工作流，照这张图的三要素画：实线主干、AI 节点标图标、每个 AI 节点挂兜底虚线、末端画回环。图画对了，项目就成了一半。

总结：5 条能直接用上的判据

1. 选型结论：Workflow 主干 + RAG 知识节点 + 零 Agent——走五层树走出来的，每层有记录。

2. 五节点里 AI 只占前两个——AI 出现在不可替代的地方，其余用确定性组件。

3. 工作流图三要素：实线主干、AI 节点图标、兜底虚线、数据回环——缺一个都没画完。

4. 小数据量别上重装备——800 条话术库，关键词检索比向量库更合适。

5. 主干确定、枝叶可换——升级只换节点内部实现，骨架一步不动。

选型模块到此结束。下一篇换个话题：AI 产品经理到底要懂技术到什么程度？三层素养模型——能对话、能判断、能验收，够用就停。

相关阅读：

• 先问要不要AI，再问用哪种：AI选型决策树（系列第 11 篇）

• 一个需求该用RAG、Agent还是Workflow？（系列第 10 篇）