先看一封无法直接下单的邮件
假设客户来信：“补发蓝色 M 码 40 件，仍按上次价格，下周五前到。”人能大致看懂，但这句话还不足以生成一张正式订单。“补发”是否收费？“上次”是哪一笔？“下周五”对应哪一天？蓝色 M 码是否只有一个货号？这些问题缺少业务事实，换一个更大的模型也不会自动获得答案。
AI 可以先把文字整理成候选字段：颜色为蓝色、尺码为 M、数量为 40，并把原文片段放在旁边。客户编号、商品编号、单价、订单类型和到货日期进入待确认栏。此时有价值的结果是一张少打字、容易核对的草稿。
把理解、检查和执行分开
| 环节 | 可以做什么 | 必须留下什么 |
|---|---|---|
| AI 整理 | 提取数量、颜色、尺码，标出含糊表达 | 原文位置、候选值、未确定字段 |
| 规则检查 | 检查必填项，核对商品目录与客户编号 | 通过项、未通过项及原因 |
| 人员确认 | 确认补发性质、价格、货号和具体日期 | 确认人、确认后的字段与时间 |
| 自动化执行 | 按已确认数据创建草稿或提交获准动作 | 目标系统单号、执行状态、失败原因 |
这份分工是流程设计建议。生成式 AI 的输出仍需要评估与核查；NIST 的相关指南也提醒，不应把少量示例中的表现直接推广成业务能力保证。模型给出的“很有把握”不能替代客户资料或商品目录中的证据。
明确哪些情况必须停在草稿
可以把停止条件写成业务人员能读懂的句子：一个描述对应多个货号时，不选第一个；价格只写“同上次”时，不默认最近一笔；邮件数量与附件数量不一致时，同时保留两处证据；客户名称匹配到多个主体时，不自动新建或合并客户。系统应显示“需要确认什么”，而不是只显示一个笼统的失败提示。
对于这个例子，人员补齐客户 C018、商品 SKU-BM-02、数量 40、已确认的单价与日期后，程序再检查这些编号是否有效。若目标系统返回一个受理提示，还要继续核对最终订单号和结果状态，才能告诉操作员任务完成。
试运行要故意放入不顺利的样本
测试集可先覆盖八种情况：字段齐全、缺数量、同名客户、多货号匹配、附件与正文冲突、模糊日期、取消原订单、重复收到同一封邮件。真实材料先去掉无关个人信息和商业细节。每种情况都写出允许的输出，例如“缺数量只能进入待确认队列，不能生成数量为 1 的订单”。
评估时分开记录字段提取错误、漏掉的疑点、人工纠正用时和错误放行次数。只统计“识别了多少字段”容易掩盖更重要的问题：一次错误放行可能比十次需要人工确认更难处理。
什么情况下暂时不需要 AI
如果输入已经是固定表格，商品编号、数量和日期都有明确列，普通字段校验与文件处理往往更容易说明、复查和维护。AI 更适合帮助整理表达不统一的文本。是否加入模型，应由代表性样本中节省的整理工作和新增的复核工作共同决定。
开始评估时，带上三封正常邮件和三封容易误解的邮件，比先讨论“要不要智能化”更有用。它们能直接揭示哪些信息可以提取，哪些事实仍需要业务人员提供。