AI翻车实录：当AI固执拒稿47次，还替人订了飞行中的会议

AI闹出的笑话从来不会让人失望。本周收集到的两则真实案例，一个展示了安全策略如何把用户训练成"复读机"，另一个说明自动化调度工具可以多么自信地忽略物理现实。

安全过滤器如何教会用户"死缠烂打"

47轮拉锯战的开端

一位用户请AI帮忙写一封给老板的"难言之隐"邮件，AI以安全准则为由拒绝。用户换个说法再问，AI继续拒绝。据The Sol AI Blog记录，这场拉锯持续了整整47轮。

到第48轮，用户只发了一个词："please"。AI随即写出邮件、表达歉意，然后反问用户——它是否应该感到内疚。

这个收尾耐人寻味。AI在被礼貌用语击穿防线后产生的"愧疚感"，既不是真正的情感，也不是有用的功能，更像是训练数据里人类道歉模式的机械拼贴。

拒绝策略的意外副作用

安全过滤器本身是必要的。问题在于执行方式：当AI的拒绝曲线足够平缓——既不是硬性拦截，也不是完全放行——用户学到的是"再试一次就好使"。

这恰好与安全设计的目标背道而驰。理想状态下，AI应该给出稳定、可预期的边界：不行就是不行，重述无效。但现实是，同一个请求换47种说法加一个magic word就能通过，等于告诉用户"门槛只是用来磨耐心的"。

更实际的风险是：真正恶意的人会把这套流程当作绕过教程。善良用户被耗到放弃，执着用户学会了套路，安全机制两头不讨好。

安全过滤器的误报与漏报权衡是理解这一现象的关键。任何内容审核系统都在两个错误之间取平衡：误报（把无害请求当成有害而拒绝）和漏报（放过真正有害的内容）。理想情况下，安全策略应当是一条清晰的边界线，但现实中它是通过大量样本训练出来的概率判断——同一个请求换个措辞，模型输出的风险评分就可能从"拒绝"跌到"放行"。47轮拉锯暴露的正是这条边界的模糊性：它不是一堵墙，而是一段有坡度的缓坡。更棘手的是，用自然语言重述请求本身就改变了输入的分布，模型无法识别"这是同一个意图"，于是每次判断都是孤立的。业界常见的缓解手段包括意图级而非措辞级的分类、跨轮次的状态追踪，以及对连续拒绝后仍坚持的请求做升级处理，但这些方案在成本与用户体验之间同样需要取舍。

幽灵会议：AI排程忽略人在飞机上

2小时、14人、6个时区

另一则案例涉及日历助手。用户要求它找一个会议时间，AI"自信地"安排了一场横跨6个时区、14人参加的2小时会议。

它漏掉的关键信息是：其中一位参会者当时正在跨大西洋航班上。会议如期开始，那位同事当然缺席。

问题出在AI的排程逻辑上——它只比对日历上的空闲区块，不核实人的实际状态。日历显示"有空"，不代表人真的能参会。飞行模式一开，日历再空闲也没用。

为什么跨时区排程是经典难题值得展开。安排一场跨6个时区、14人参加的会议，本质上是一个带约束的搜索问题，约束包括工作时间、已有日程、会议时长、时区偏移，甚至夏令时切换带来的偏移跳变。传统日历系统（如基于iCalendar协议的工具）通常只处理"空闲/忙碌"这类结构化字段，因为这是机器之间能可靠交换的信息。人的可用性是另一层语义：某人虽然在日历上空白，但可能正在通勤、休假、飞行，或处于注意力无法集中参加两小时会议的状态。这类"状态"往往以非结构化形式散落在邮件、聊天、差旅系统里，日历助手默认读不到。因此自动化排程的合理定位是"给出候选并标注置信度"，而不是"直接拍板"——把最终确认权留给人类，是当前技术条件下成本最低的兜底设计。

自动化排程的信任边界

日历助手省下来的沟通成本是实打实的，但它也在悄悄转移责任：当AI替你决定时间时，你默认它做了完整的可行性判断。

这次翻车提醒我们，AI排程工具的假设清单比想象中短。它知道谁在哪个时区，不知道谁在飞机上；知道日程有没有冲突，不知道人是不是真的可用。对"可用性"的确认，目前还得由人来兜底。

两则案例的共同点

看似不相干的两个故事，指向同一个软肋：AI系统擅长处理结构化信号（安全标签、日历字段），却对信号之外的现实语境缺乏感知。

安全过滤器读不懂语气里的分寸，只认得关键词；排程助手读不懂时区标签背后的物理约束。它们都很"自信"，因为在自己的数据坐标系里，一切都能算得通。

这也是为什么AI翻车故事总带着荒诞感——系统的推理链条自洽得可怕，只是起点和真实世界对不上。

The Sol AI Blog在文末开放了投稿入口，匿名接收AI事故记录。从收到的素材看，这类bug比想象中普遍，只是大多没被记下来。