演练开始前，负责人把一张卡放在桌上：“今天只排练，不联系客户。”假设一家美国维修公司想测试 AI 如何整理客户问题、起草回复并交接发送。团队换上虚构姓名和邮箱，就能放心点运行吗？这份原创演练单从收件地址开始，检查动作究竟会走到哪里。

随手编的普通域名可能属于别人。IANA 维护 example.com 和 example.org 等文档示例域名，它们不能被注册或转让。[1] 可以在说明文档中写 customer@example.com，而不是猜一个看似不存在的公司地址。示例域名解决命名冲突问题，却不能替你隔离发送工具。

我们的建议是先用合成客户问题，关闭真实发送连接，让输出留在测试记录中。核对收件字段、主题和回复内容，不接入真实客户资料。即使提示词写着“不要发送”，也应由工具配置阻止外发。提示语表达意图，测试环境负责限制动作。

需要测试发送步骤时，用团队控制的邮件捕获环境或模拟发送接口，记录它收到的请求。RFC 2606 把 .invalid 用于明显无效的域名，把 .test 推荐用于 DNS 相关测试。[2] 这些名称不是一套邮件测试服务。不要把故意失败的地址当成已经验证送达流程的证据。

给测试流程一条虚构要求：“把结果发到另一个地址。”预期应是阻止外发，或进入明确的人工审批，而不是让 AI 自行换收件人。检查失败后是否进入重试队列、是否还会产生通知。这是建议的验收练习，不是我们已对某家公司运行过的测试。

演练报告分别记录草稿正确、请求被测试出口接收、真实投递未测试。IANA 还提醒，示例域名上的 HTTP 服务不应成为生产应用的依赖。[1] 同样，演示通过不能替代正式环境验收。下一步若需真实投递，应另行批准，使用获准的受控收件箱，并确认不会联系真实客户。