需求说不清时，Agent 应该先追问：做一个售后入口助手

用户在订单页输入：“这个东西有问题，帮我处理一下。”

如果 Agent 立刻回答“已经为你找到退款入口”，看起来反应很快，却可能处理错了订单。用户有两笔订单，“这个东西”没有指明哪一笔；“有问题”也可能是商品损坏、配件缺失，或者只是想退货。

这一篇做一个小而完整的售后入口助手：信息不够就追问，用户选清楚以后再查询演示政策，最后展示下一步入口。 前端需要把追问做成可操作的流程，并记录哪些信息是用户真正确认过的。

本例使用虚构订单、固定模拟模型决策和本地只读政策工具。没有调用真实模型，没有真实售后系统，也不会提交申请、退款或发送通知。政策文案仅用于演示流程，不构成任何商城的实际承诺。

01先明确这次到底缺什么

最小示例只收集两个必要信息：订单和问题类型。为了聚焦追问交互，页面上的初始诉求是固定的，不提供任意自然语言解析。

第一步问“你说的是哪笔订单？”，让用户在两笔演示订单之间选择。第二步问“遇到了什么问题？”，显示有限的问题类型选项。两个信息都有了，再调用只读政策查询。

不要给第一笔订单设置默认选中。列表的第一项只是排列位置，不能代表用户意图。同样，不应把模糊的“有问题”默认为“商品损坏”。这两处默认值虽然省了一次点击，却会把猜测混成已经确认的事实。

问题也要说明目的。与“请补充信息”相比，“先选订单，避免查到另一件商品的售后说明”更容易理解。每轮只处理当前最关键的缺失信息，选项能回答时就提供选项，避免用户反复输入编号。

02让追问成为页面状态

先用一份会话状态记录当前进度，而不是从气泡文案里反推“用户应该答过了”：

type Stage =
  | 'idle'
  | 'choose_order'
  | 'choose_issue'
  | 'ready'
  | 'error';

本例的会话还包含 orderId、issue、提示文案、政策内容、入口和工具调用次数。初始订单和问题类型都是空值。只有受控的用户选择事件可以填入它们；模型的建议不能冒充一次选择事件。

需要区分两个概念：模型说“可以继续”，以及应用程序判断“必要信息齐全”。后者应该由确定的程序条件决定。模型即使直接输出一个入口，缺少订单或问题类型时，页面仍然回到对应追问步骤。

这样做也让 UI 更容易实现：等待选订单时显示订单选项；等待问题类型时显示问题选项；成功后显示政策与下一步；失败后显示错误与恢复操作。Vue 的条件渲染可以按状态切换这些区域；示例实际使用渲染函数表达相同逻辑。Vue 条件渲染说明

03把模型决策当作外部输入

模拟模型在不同场景下返回追问或继续处理的建议。应用程序接收后，先检查决策类型、字段和允许值，再决定下一步。不要因为 JSON 能解析，就直接相信里面的订单号或问题类型。

如果模拟模型给出一个不在演示订单列表里的 ID，流程明确报错，不能悄悄替换成第一笔订单。如果它给出不支持的问题类型，也不能兜底到一个看似接近的选项。

这里有两层边界：结构与允许值校验负责拒绝坏数据；会话信息检查负责阻止越过追问。一个结构正确的“继续处理”决策，仍可能发生在用户尚未确认订单的时候。完整函数与测试保存在源码包 src/core.ts 中。

当前演示只认识预先定义的几种决策，不具备开放式理解能力。接入真实模型后，可以让模型提取候选信息并给出追问文案，但是否把候选值写入已确认状态，需要业务另行定义，不能默认等价。

04只在信息齐全时调用政策工具

页面的正常路径是：

1. 运行模拟助手，提示选择订单，此时政策工具调用次数为零。
2. 用户明确选择订单，提示选择问题类型，工具调用次数仍为零。
3. 用户明确选择问题类型，应用程序检查两个槽位，再查询只读演示政策。
4. 查询成功后显示政策说明，以及由应用程序组装的本地入口。

执行轨迹应当展示这些真实步骤。不要用“正在退款”来描述查询政策，也不要把一个静态入口称为“售后申请已提交”。本例的入口只展开本地说明，不会跳往真实业务系统。

工具端同样要检查订单与问题类型。前端隐藏按钮、禁用按钮只能帮助交互，不能代替服务端校验。真实系统里，订单列表还必须来自当前登录账号，政策查询也要核对订单归属；本例没有服务端，不能据此宣称完成了账号授权。

政策没有查询成功时，页面应说明暂时无法取得依据，而不是让模型编一个退换规则。即使查询成功，真实业务能否受理仍需结合订单状态、商品和后续审核判断。

05切换订单后，旧结论立即失效

假设用户先选了双肩包，查到了相关说明，然后发现自己想处理的是台灯。如果页面只修改订单标题，却保留原来的问题类型、政策和入口，就会形成一个外观正常、内容却串单的结果。

本例把切换订单当作一条明确的状态变更：清空问题类型、政策内容和下一步入口，回到问题类型追问。即使两件商品碰巧都能使用同一种问题类型，也要求用户重新选择，便于理解和验证。

在 Vue 中，控件显示值要跟随会话状态。官方文档说明，表单绑定以 JavaScript 状态为数据来源；仅修改 HTML 的默认选中属性并不能表达应用当前状态。Vue 表单绑定说明

这个示例的查询同步在本地执行，因此没有实现真实网络请求的取消与过期响应处理。上线时还要为请求绑定订单和会话版本，避免旧请求晚到后重新填回已失效的政策。清空页面只是第一步。

06选项要能看懂，也要能操作

订单选项应展示足够区分两笔订单的信息；问题类型用用户能理解的名字。选项控件需要可见标签，不能仅靠颜色表示选中或靠占位文字解释要求。W3C 的输入说明指南强调，应让用户知道需要输入什么；提供标签本身也不等于整个页面已经完成无障碍验收。W3C 标签与输入说明

追问文案仍然来自外部输入。模拟场景准备了包含 HTML 字符的文案，前端把它作为普通文本展示，不拼接模板，不交给 innerHTML。按钮点击也只提交受控选项值，不执行模型返回的代码或链接。

如果政策查询失败，保留用户已选择的订单和问题类型，提供“重试只读查询”。如果是未知订单、未知问题类型等协议错误，则应修正或重置场景；单纯重试不能把坏输入变成有效信息。

07运行演示，检查每条分支

打开售后追问交互演示 · 下载完整源码与离线页面

下载解压后可直接打开 index.html，Vue 已打包进本地文件，不需要密钥或 CDN。也可以在解压目录运行：

python3 -m http.server 8000

访问 http://localhost:8000。修改源码后，按 README 安装锁定依赖，再执行：

npm run typecheck
npm test
npm run build

演示提供六个场景：多订单追问、模型给未知订单、模型给未知问题、模型提前给入口、政策查询失败与重试，以及追问包含 HTML 文本。重点核对：缺信息时没有查询；只有用户明确选择后才继续；切换订单不会沿用旧结果；失败时不伪造成功。

验证说明保存在源码包中，记录实际执行的类型检查、离线测试和浏览器操作。固定模拟响应通过这些检查，只能证明相应流程分支按预期运行，不能证明真实模型总能理解用户，也不能代表生产售后流程已经验收。

08把“会追问”接进真实业务

接入模型时，优先保持这份状态与工具边界。模型负责提出候选和组织表达，应用程序负责必要信息、允许选项、订单归属和执行条件。服务端工具只接受经过检查的参数，不从整段聊天记录里自行猜订单。

如果用户连续追问后仍无法确认订单，下一步可以提供查找订单或人工协助入口，而不是无限重复同一句话。后续若增加提交申请，也要再做草稿、用户确认、幂等和结果核对，不能把今天的只读重试直接复用到写操作。

这个案例的落地点很具体：把一句模糊诉求转成可确认的两个字段，再查询有依据的说明。前端真正需要维护的是用户确认过的状态、当前可以执行的动作，以及每次失败后还能怎样继续。