单条建议看起来没问题，放大到 500 条就可能变成事故
销售团队让 AI 给沉默客户补标签，并按行业发送不同跟进提醒。测试时挑了五条记录，结果都很准确，于是准备直接跑全库。正式执行后才发现，系统把“最近 30 天无成交”理解成“最近 30 天无联系”，一批正在跟进的客户被错误归类。
批量动作的风险不只来自准确率，还来自影响规模。一条分类错误可以手工修正，五百条错误会污染报表、触发消息、改变销售优先级。企业不能把小样本演示等同于正式执行，需要在真实数据范围上先做一次不产生副作用的预演。
预演不是再生成一份总结，而是展示具体差异
dry run 应使用与正式执行相同的筛选条件和业务规则，但只计算计划，不写入系统。结果要告诉负责人：共命中多少对象、哪些字段会从什么变成什么、多少记录缺数据、多少记录触发冲突、会调用哪些外部服务。
只显示“预计处理 500 条”远远不够。审核人需要看到随机样本、高风险样本和边界样本，并能按部门、地区、客户级别等维度拆分。发现某一组异常时，可以调整条件或排除范围，而不是全盘取消。
- 展示修改前后差异和预计影响数量。
- 单列缺字段、规则冲突和高价值客户。
- 提供随机样本与边界样本供人工抽查。
审批通过的是一份固定计划，不能执行时重新生成
有些系统预演完成后，用户点击执行，AI 又重新理解一次条件并生成新名单。审核人看到的 500 条和实际处理的 527 条不是同一批，预演就失去意义。正确做法是为计划生成版本和校验值，审批后执行锁定的对象与动作。
如果执行前数据已经变化，系统应提示差异并要求重新预演。不要悄悄使用最新数据继续跑。对于价格、库存、客户状态等变化频繁的字段，可以设置计划有效期，超过时间自动失效。
正式执行也要分批、限速，并保留停止按钮
即使预演通过，也不代表必须一次处理全部对象。可以先执行 10 条或一个小部门，检查写入结果和外部消息，再逐步扩大。批次之间设置观察窗口，出现异常率上升、接口报错或投诉时自动暂停。
每条动作记录计划 ID、执行时间、操作者、原值、新值和结果。系统需要支持停止尚未执行的部分，并为已经执行的内容准备恢复或补偿方案。批量自动化的控制能力，应和它的处理速度一起设计。
预演让业务负责人真正参与，而不是只看技术演示
业务负责人未必懂模型参数，但他能看懂哪些客户会被改标签、哪些邮件会被发送、哪些订单会被暂停。把影响范围用业务语言展示，才能让审批承担真实责任，也能发现技术团队不知道的例外。
企业 AI 落地不是把确认按钮保留就叫人工参与。好的确认发生在行动之前，信息足够、对象清楚、后果可判断。预演模式把“AI 认为应该做什么”变成一份可检查的执行计划，是批量自动化进入生产前必须补的一层。
要点总结
- 批量修改、外发消息和不可轻易恢复的动作都建议预演，风险越高，抽查和审批越严格。
- 会增加一步，但能显著降低批量返工和误操作成本；低风险稳定任务可在验证后简化审批。
- 应比较计划与当前数据，超过设定差异就让计划失效并重新预演，不能悄悄扩大范围。
参考来源说明
本文围绕“AI 准备一次改 500 条客户记录，先别点确认：批量动作要有预演模式”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。