点击批准之前，AI 操作审批页应该显示什么？

“AI 想修改一条客户记录，是否批准？”这不足以作决定。审核人不知道是哪位客户、改什么，也不知道是否有经过确认的业务依据。

审批页应该先回答这些问题，再让人点击。否则人工审核容易变成走过场。

展示要执行的动作，而不只是摘要

修改记录时，显示目标系统、记录、当前值、拟修改值及其依据。发送消息时，展示收件人、标题、最终正文和附件。明确操作是在内部生效，还是会影响外部人员。

举例来说，把“更新交付日期”写成：“根据供应商确认，将 847 号订单的交付日期从 11 月 12 日改为 11 月 14 日。此操作仅更新内部订单，不通知客户。”如果还建议发送通知，就把通知单独提交审核。

审批针对的是审核人实际看过的操作版本。如果批准后收件人、日期或附件发生变化，应重新展示变更后的方案。在执行前，核对记录仍是预期版本，以及审核人是否有权批准这项操作。

确认按钮本身不能充当权限边界。实际执行动作的服务，需要独立于模型和界面落实这些检查。

提供修改草稿、要求补充信息、拒绝或升级处理的路径。如果拒绝后会进入待处理队列，应说明由谁接手。难以撤销的操作，应在批准之前明确告知。

批量处理时展示总量并让审核人查看异常。批准一组常规更新，不应顺带授权一条不相关的外部消息。

区分“已批准”“执行中”和“已完成”。审批确认的是决定，不代表目标系统已接收操作。外部请求超时时，应显示结果不确定，并引导核查，而不是让审核人重新批准同一个动作。

给同事看一条拟执行操作，不作口头解释。请他指出目标、变更、依据、后果，以及发现证据错误时该怎么办。再测试批准后方案发生变化，会不会触发重新审核。

如果对方无法从页面回答，就先补上缺失的信息，再扩大自动化范围。

执行阶段的异常处理可参考自动化重试指南。如果需要设计操作审核流程，欢迎联系 Storm Nova Labs。