客服任务拆解与结构化输入

核心概念

结构化输入把自然语言转成明确字段，便于系统校验和路由。字段可以包含任务类型、门店、设备、故障描述、紧急程度和联系方式。每项还应区分用户提供、可信记录取得和暂时未知，避免猜测被当成事实。

字段完整不等于允许执行。身份、权限和业务规则仍由服务端检查；模型适合提取候选信息和提出追问，不能自行授予权限或把用户愿望当成批准。

情境拆解

员工说“昨天那台又坏了，快帮我报一下”。系统不知道设备编号，也不确定是否已有未关闭工单。可以先询问设备，或在授权范围内查询候选设备及现有工单，不能直接猜一台设备建单。

把任务拆为识别意图、补齐必要字段、检查既有记录、形成动作摘要、确认和执行。若员工只是问报修流程，应提供知识回答，不应自动创建工单。

常见误区

用一个自由文本字段承载全部信息，会让后续校验难以稳定复用。反过来，一次追问所有字段也可能增加负担。先问阻止下一步的关键缺口，非必要说明可保留为空。

模糊指代不能直接变成工具参数

用户说：“昨天那台又坏了，帮我处理。”这句话可能意味着新建报修，也可能是查询昨天的工单或补充故障说明。意图和设备编号都还没有确定。

可以回复：“你想查询已有工单，还是提交新的报修？请确认设备编号。”追问应解决下一步必需的信息，不要一次索取与任务无关的个人资料。

动手：做五个字段提取例子

1. 编写咨询、建单、查状态、补充记录和模糊指代五种合成请求。
2. 为每项标注意图、已知字段、字段来源和未知字段。仅模型猜测的内容，不能标记为已确认。
3. 写出下一句最必要的追问，以及何时仍不能执行。
4. 检查追问回答后是否改变动作。用户改变设备或描述，应更新摘要，不能沿用旧确认。

原始请求：
可能意图：
已确认字段及来源：
未知或冲突字段：
下一句追问：
用户回复后的动作：
执行前仍需检查：

检查产物

提取结果能追溯到用户输入或可信系统信息。没有设备编号时不会凭历史猜测建单；不明确是查询还是写入时，不用“帮我处理”作为执行许可。