11｜把三条业务路线合成一个能交付的应用

如果想获取全套课程资料，请关注微信公众号 「AI面包君」，回复 「课程资料」 即可领取。

前面已经分别做过规则问答、订单查询和人工工单。这一节把它们接到同一个分类入口，再用一组固定案例逐条验收。你要交付的不是一张节点很多的画布，而是一个使用者知道能问什么、失败后知道怎么办的小应用。

从自己的“问题分流”应用复制一份，命名 Bread-11-商城咨询助手。它已经有四个分类出口与固定回执，接下来一次替换一条路线，替换完立即测试，不要一次改完整张画布。

先把完整地图摊开，知道最终会接成什么样。它按照本章配置文件的 22 个节点逐一绘制，每个框里写了职责和关键字段。整图用于找路线，下方三张细图用于读清每一步。

这是一张可放大的配置图，不是 Cloud 全流程成功记录。四节点知识检索已在 Cloud 实机跑通；订单接口的网络可达性、人工确认和毕业流程仍需在你的部署环境逐条验收。先沿一条路线走完，再连接下一条，排错会容易得多。

1. 统一入口字段

输入节点整理为以下四项：

变量	类型与要求	测试用途
query	短文本，必填	本次咨询
order_id	短文本，选填	订单查询时提供
customer_id	短文本，必填	先使用教学身份 C001
request_id	短文本，必填	新业务用新编号，重试保持原值

分类器继续读取 query，保留规则、订单、工单、其他四类。当前项目仍是手工输入订单号；不要因为问题里出现 B1001 就假设表单的 order_id 已自动填好。若要接结构化提取，应明确增加提取节点并重新绑定。

先画三张“小流程卡”，再拼大画布

规则咨询卡写：输入问题，找资料，依据资料回答或说明不足。订单查询卡写：输入订单号与可信客户身份，校验，查询，转换状态。工单卡写：整理需求，人工确认，再登记。

三张卡分别指出需要什么输入、可能停在哪里、交出什么。这样添加节点时，你不是在往画布上堆功能，而是在实现三条已经说得清楚的处理路线。

如果其中一条独立路线尚未跑通，先把它保留为清楚的占位回执，不要把整张大图一口气接完再排错。占位回执只能写“进入某分支”，不能写“已查询”或“已创建”来冒充尚未发生的动作。

用表单约定检查入口负担

当前教学表单要求 customer_id 与 request_id 都填写，即使用户只是问发票规则，也要提供。这便于课堂统一输入，但正式产品可以进一步按业务流程减少不必要填写。

优化时要保持后续必需数据可用。例如客户身份应由可信登录态提供，工单业务编号可以由服务端在合适时机生成；不是简单把字段都改成选填，就解决了用户体验问题。

2. 替换规则咨询出口

移除原来“进入知识库咨询分支”的占位模板，按顺序添加：知识检索 → 片段计数 → 条件分支。检索选择自己的商城知识库，查询变量为输入 query，Top K 先设 3。

计数节点输入 result 绑定检索 result，输出 count 为 Number，代码是：

def main(result: list) -> dict:
    return {"count": len(result or [])}

条件 count > 0 的路线进入 LLM。LLM 上下文绑定检索 result，User 绑定 query；System 要求只根据资料回答、保留条件例外、资料不足时明确说明，并插入上下文变量。ELSE 路线接模板“当前资料不足以确认，请补充细节或联系人工”。

先临时把两个出口汇合到结果，测试“通常多久安排发货”和“保证今年能赚多少钱”。确认正常规则与资料不足两种行为，再接下一条业务路线。

例子一：规则问题从头到尾走哪条路

输入“我下载的数字资料坏了，能按实物七天规则退款吗”，分类器先选择规则咨询；检索应找到数字资料与实物规则的区别；计数只判断是否有片段；LLM 再依据片段说明不能直接套用实物条款，并指出可登记补发工单。

这次运行不应该查询某个随意的订单号，也不应该因为提到“工单”就直接登记一条记录。回答里提到一种可选后续操作，与实际执行该操作是两回事。

检查时对照节点追踪：订单 HTTP 与工单 HTTP 都不应在这次规则路线里执行。如果它们也跑了，说明连线把业务分支混到了一起，不能只凭最终回答看着合理就放过。