09｜让人看过摘要以后，才创建工单

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

查询订单只读取数据，创建工单则会留下新记录。模型可能误解用户，也可能把一句咨询当成正式申请。这一节在写入接口前加一个人工确认表单：可以编辑摘要、确认创建，也可以取消。

完成后，你需要分别验证确认、取消和重复提交。使用第 06 节已经连通的教学接口；它只创建虚构工单，不会联系真实客服。

1. 准备三项输入，生成一份待确认摘要

新建 Bread-09-确认工单，输入节点添加必填短文本 query、customer_id、request_id。测试时客户编号填 C001，请求编号可填 lesson09-case01。

request_id 用来识别同一笔业务提交。网络失败后重发同一件事时继续用原值；真正发起另一件事时再换新值，不能每次重试都随机生成。

后接 LLM“整理工单摘要”，选可用模型，User 绑定 输入 → query。System 填：

把用户问题整理为一段 5–300 字的客服工单摘要。
只保留已提供事实，不承诺处理结果，不填写虚构订单号。

先单独运行问题“我下载的课程资料包打不开，请客服帮忙补发”，检查摘要没有增加退款、赔偿等用户没说的要求。

咨询一句“能不能”，不等于正式提交申请

用户说“资料打不开，可以找客服吗”，首先表达的是咨询。如果系统直接把它变成“已创建工单，要求立即补发”，就替用户推进了一个尚未确认的动作。

本节先整理摘要，再让用户检查，就是把“模型理解的意思”和“用户愿意提交的内容”对齐。确认表单不只是一个装饰按钮，它应让用户看见实际将提交的文字，并能修正误解。

比如模型摘要写“申请退款”，用户实际只想补发文件。用户应能在表单里改成“请协助补发无法打开的资料”，后续接口也必须收到这个修改版本。

请求编号在什么时候确定

一次新的工单业务开始时确定 request_id，后续因为超时而重试仍用它。换一件真正不同的事情，再使用新编号。

多人共用同一个教学服务时，不要都使用完全相同的 lesson09-case01。给自己的练习批次加一个区分前缀，例如 lin-case01，但同一条重复提交测试中保持原值。前缀只是方便本次教学去重，不是用户身份验证。

2. 在摘要后加入人工输入节点

添加“人工输入／Human Input”，命名“人工确认工单”。选择 WebApp 表单投递方式，开启它。若当前实例没有此节点，先确认所用版本与功能可用性，不能用普通输入变量假装实现执行中暂停。

在表单里新增段落字段，输出变量名设为 summary，默认值来源选择 整理工单摘要 → text。把这个字段插入表单正文，并在前面写“请检查并编辑工单摘要，确认后才会创建教学工单”。

添加两个操作按钮：确认创建（动作标识 approve）和取消创建（reject）。超时先设 1 小时。配置完成后，节点应有确认、取消和超时出口。

用户编辑后的值从 人工确认工单 → summary 取。后面的请求不能继续读取模型原文，否则用户的修改就被丢掉了。

默认摘要与人工确认后的摘要，是两个数据来源

默认值来自“整理工单摘要 → text”，帮助用户不用从空白开始写；人工确认后的值来自“人工确认工单 → summary”，包含用户刚才的编辑。

假设默认文本是“请求客服处理资料损坏”，用户补充“仅希望补发，不申请退款”。如果 JSON 组装仍绑定 LLM text，这句限制就丢了；页面看起来经过确认，实际发送却还是旧内容。

这是人工审核流程里特别值得检查的一点：不只是有没有一个确认节点，还要看确认过的结果是否真正成为后续输入。你可以在组装节点运行详情里核对 summary，看到用户补充的那一句才算接对。

暂停意味着什么

执行来到人工节点时，后面的创建接口还不应该运行。用户点击 approve 才继续进入写入路线，reject 与超时各走自己的说明路线。