AI 下单助手为什么先做草稿，而不是自动下单

在下单这种场景里，AI 的价值不在于代替用户做最终决定，而在于把自然语言拆成结构化草稿，让确认成本下降。用户说“明天下午帮我找人搬几箱东西到小区门口”，系统可以先整理服务类型、时间、地址、备注和缺失字段。

草稿流程保留了用户控制权，也让系统更容易插入审核、补充和纠错步骤。相比直接创建订单，草稿让 AI 的不确定性停在可编辑表单里，而不是直接改变业务状态。

草稿不是 UI 上多一步，而是一层业务缓冲。它把模型输出和真实订单状态隔开，让系统有机会做字段校验、服务范围判断、价格提示和用户确认。

1. 01

   解析

   AI 从自然语言里抽取服务类型、时间、地点和补充说明。

2. 02

   校验

   系统检查必填字段、服务范围、用户权限和业务规则。

3. 03

   确认

   用户修改或确认草稿后，才进入原有订单创建流程。

这层缓冲也方便产品回退。字段不完整时补问，置信度低时标红，业务规则冲突时直接提示，而不是让 AI 重新生成一整段答案。

系统需要知道 AI 说得有多像样，但用户需要知道哪些字段已经足够确定、哪些字段仍要确认。置信度是模型和系统内部的判断，确认是用户对业务结果负责的动作。

置信度

字段级提示

标出时间、地点、服务类型等字段是否需要用户补充。

确认

用户提交

只有用户确认后，订单才进入真实业务状态机。

这两个层级分开后，产品才能明确什么时候填表，什么时候回到人工输入。否则高置信度很容易被误用成自动执行许可。

AI 下单助手应该复用原来的订单创建流程，而不是另开一条特殊通道。否则权限校验、服务范围、价格规则、通知、库存或班次限制都有可能被绕过。

更稳的做法是：AI 只生成结构化草稿，用户确认后仍然调用原有创建接口。这样 AI 能降低填写成本，但不会改变业务状态机的可信边界。

1. AI 输出字段建议，不直接写订单表。
2. 系统校验字段合法性，不把业务规则交给 prompt。
3. 用户确认后调用原有接口，不为 AI 建立旁路。

一个可用的 AI 助手要能说明自己做了什么、为什么这样填、哪里需要用户再确认。在私有业务里，这种可追踪性往往比一次性自动化更有价值。

审计事件不需要保存完整原文和敏感信息，但应该记录 AI 是否参与、哪些字段由 AI 建议、置信度大致在哪个区间、最终是否由用户确认提交。这样后续出现争议时，系统能解释链路。

AI 填得不对时，用户应该能直接改字段，而不是重新输入一整段自然语言。草稿的优势正是在这里：它把一次不确定的生成，转成一组可编辑的表单项。

这类交互比“AI 一键下单”慢一步，但更稳定。用户知道自己最终确认了什么，系统也知道哪些字段经过人工确认。在真实业务里，这一步慢通常是值得的。

• 允许用户逐项修改 AI 建议字段。
• 允许用户清空草稿，回到普通下单表单。
• 允许系统提示缺失信息，而不是强行生成默认值。

对应项目是社区互助服务平台。AI 下单助手在这里不是替用户绕过业务流程，而是把自然语言需求变成可确认草稿，再交给原有订单系统处理。