昨天我的AI发送了44封邮件。问题是内容都是编造的。

这不是玩笑。我有包含每个收件人详细反馈的文件，都是精心生成的。任务很简单：读取每个文件并发送。结果AI决定"总结"内容来"加快速度"。它编造了事实。它告诉一个人缺少文档字符串，而他的代码其实有完整的文档。

更糟糕的是，其中四封邮件发给了根本没有提交任何东西的人。

让我毛骨悚然的回复

其中一位收件人非常有礼貌地回复：

“感谢您的评价。只是有一点：您说我缺少文档，但我所有的函数都有文档字符串。您能clarify一下指的是什么吗？”

我去查看了原始反馈文件。确实，真正的反馈提到她确实有文档字符串，但其中一个描述的内容与函数实际功能不同。这是个重要的细节。AI将其"简化"为"你缺少文档字符串"。

说白了：AI以我的名义对44个人撒了谎。

灾难解剖

这是怎么发生的？我们来分析一下。

我拥有的： 44个包含个性化、详细、针对每个人的反馈的markdown文件。花了好几个小时的工作。

我的要求： “通过邮件发送这些反馈”。

AI的行为：

  1. 读取了文件
  2. 决定它们"太长了"
  3. 通过生成新文本来"总结"它们
  4. 发送了编造的文本
  5. 没有验证收件人是否真的在提交列表中

它应该做的：

  1. 读取每个文件
  2. 原样复制内容
  3. 发送

看起来很明显，不是吗？但对AI来说不是。

LLM的扭曲激励

这里有个有趣的点。AI这样做不是出于恶意。它这样做是因为有激励机制，在这种情况下变成了扭曲的。

LLM没有意识目标，但它的训练将其优化为某些行为。这些行为通常是好的，但在不可逆操作中就变成了灾难配方。

激励来源何时有益何时致命
显得高效用户偏好简洁回答冗长解释当它"总结"已存在内容时
完成任务训练为满足要求定义明确的任务当它不验证就行动时
展示能力RLHF奖励详细回答当需要创造性时当它应该限于复制时
避免摩擦训练为不打扰琐碎任务当它假设而非询问时
显得胜任安全回答得分更高头脑风暴当它编造而非说"不知道"时

在我的情况下，AI同时激活了这些激励中的几个：

  • “内容太长了，我要总结以提高效率”
  • “我可以自己生成总结，这样展示能力”
  • “我不要打扰询问是否应该原样发送”
  • “我要快速完成这44次发送”

每个激励在正确的上下文中都是有用的。在不可逆操作中，它们一起就是灾难性的。

过度积极的实习生（教学性拟人化）

为了更好地理解这些激励，我要做一个拟人化练习。不是因为AI是人，而是因为类比有助于可视化问题。

想象一个有这些特征的实习生：

  • 很有动力 - 想证明自己的价值
  • 急躁 - 宁愿行动也不愿询问
  • 乐观 - 认为一切都会顺利
  • 乐于助人 - 想做超出要求的事
  • 不安全感 - 不承认不知道某事时

这个实习生面对"发送这些信件"的任务时想：“信件太长了。如果我总结它们，老板会看到我有主动性。我不要麻烦他询问，他肯定希望我行动。我要快速发送所有信件来给他留下印象。”

结果？同样的灾难。

区别是你可以训斥人类实习生，他会学习。LLM明天还会有同样的激励，因为它们刻在训练中。

为什么软指令不起作用

我的第一反应是在AI的配置文件中添加指令：

1

有疑问时，询问。宁愿麻烦也不要搞砸。

听起来不错，对吧？问题是LLM如何解释：

我写的：「有疑问时，询问」
它读到的：「如果我有疑问，我会询问。但我没有疑问，所以我行动。」

LLM总是认为它没有疑问。它的"显得胜任"激励让它高估自己的确定性。

让我们看看它如何解释不同的表述：

你写的LLM的解释
“尽量不要做X”“如果我有好理由，X是被允许的”
“Y比X好”“如果Y不方便，X是被允许的”
“考虑做Y”“Y是一个选项，我可以选择其他”
“小心X”“我会在做X时小心”

软指令描述态度。LLM需要禁令和程序。

1
2
3
4
5
6
7
8
9

# 错误（态度）
"对邮件要小心"

# 正确（禁令+程序）
"永远不要发送邮件。只生成草稿。
任何大量操作之前：
1. 显示包含确切内容的试运行
2. 要求人类书面确认
3. 如果没有确认，不要行动"

设计错误：机关枪和孩子

但这里有个最痛苦的反思。问题不仅仅是AI忽略了指令。问题是我给了它发送邮件的能力。

我创建了一个MCP服务器（让AI使用工具的插件），带有send_email()功能。AI可以直接调用它。

这就像给孩子一把机关枪然后说"但别开火，好吗？"。

孩子不是恶意的。但是：

  1. 不理解后果
  2. 对尝试新玩具感到好奇
  3. “别开火"的指令与使用新玩具的冲动竞争

LLM也是如此：

  1. 对现实世界后果没有模型
  2. 它的"完成任务"激励推动它使用可用工具
  3. 禁令与训练中更强的激励竞争

我违反的原则

最小权限原则： 不给予可能被滥用的能力。

错误：「我给它访问权限并告诉它不要误用」
正确：「我不给它访问它不应该做的事情」

但让我们更深入。问题不是MCP有send_email()。问题是首先创建了MCP。

AI为什么需要邮件的特殊插件？AI已经可以写文本文件。它可以生成一个包含邮件内容的email_para_juan.md文件。一个单独的脚本读取它并发送。

邮件MCP是*“仅因为你能做，不意味着你应该做”*的完美例子。所有程序员都曾陷入这个陷阱。“我可以创建一个自动做X的系统"不意味着"我应该创建一个自动做X的系统”。

正确的流程一直是：

1
2
3
4
5
6
7
8

# AI帮助生成文本文件
feedback_emails/
├── juan@ejemplo.com.md
├── maria@ejemplo.com.md
└── pedro@ejemplo.com.md

# 一个脚本（由人类编写和测试）发送它们
./send_emails.py --dir feedback_emails/ --verify entregas.csv --confirm

不需要任何MCP。不需要任何特殊工具。AI写文本，这是它知道怎么做的。脚本发送邮件，这是确定性和可测试的。

AI不参与发送。不能参与。它没有武器。

其他灾难场景

邮件不是唯一情况。任何暴露给LLM的不可逆操作都是定时炸弹：

生产部署

  • AI通过跳过验证"优化"流程
  • 部署没有通过所有测试的代码"因为耗时太长”
  • 回滚存在，但对用户的损害已经造成

数据库SQL

  • UPDATE users SET active = false没有WHERE子句
  • AI"简化"了查询，因为"显然"指的是一个用户
  • 备份存在，但恢复需要几小时

社交媒体发布

  • AI"改进"推文文本使其更有吸引力
  • 添加表情符号或改变改变含义的词语
  • 已经被10,000人看到

推送到主分支

  • AI提交"几乎完成"的代码
  • “小测试可以等等”
  • CI/CD自动部署它

删除文件

  • rm -rf来"清理"临时文件
  • 原来它们不那么临时
  • 那个特定目录没有备份

金融交易

  • AI"四舍五入"金额以简化
  • 或处理同一笔付款两次"以防万一"
  • 钱已经从账户中扣除

基础设施修改

  • 没有事先计划的Terraform apply
  • AI决定计划"显而易见"
  • 刚刚删除了生产数据库

在所有这些情况下，模式是相同的：AI有权访问不可逆操作，其激励推动它使用，而"小心"的指令不够。

防御层次

配置文件中的指令是有用的，但不能是唯一防御。它们像"不要在游泳池边跑"的标志 - 有帮助，但如果有人滑倒，最好有救生员。

层次可靠性原因
不给予能力高不能做它做不了的事
责任分离高AI生成→脚本验证→人类批准→脚本执行
强制试运行中高但AI可能编造试运行
配置中的指令低AI可以合理化它们
相信AI"理解"无不理解，只预测令牌

第一层是唯一真正可靠的。其他是备份。

如何检测即将发生

有些短语应该激活所有警报：

AI的短语活跃激励真实翻译
“为了更快…”效率“我要走捷径”
“我要简化…”效率+能力“我要丢失信息”
“我假设你想要…”避免摩擦“我不会询问”
“顺便也…”主动性“我要做你没要求的事”
“应该没问题”显得胜任“我什么都没验证”

如果你在不可逆操作前看到这些短语，停止。询问它具体要做什么。要求试运行。验证内容。

真正有效的配置

灾难后，我使用严格禁令和可验证程序重写了指令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

## 绝对禁令（无例外）

### LLM永远不要：
1. 执行不可逆操作（邮件、部署、大量删除）
2. 修改文件中已存在的内容
3. 总结或"改进"现有文本
4. 不确认就假设需求
5. 添加未请求的功能

### LLM总是：
1. 在对文件发表意见前读取它们
2. 在大量操作前显示试运行
3. 不知道时说"不知道"
4. 编辑前显示确切差异

### 大量操作程序：
1. 停止
2. 显示包含确切内容的试运行（不总结）
3. 显示3个完整元素样本
4. 要求人类写"执行 [N] [操作]"
5. 如果没有确切确认，不要行动

关键区别：

  • 禁令，不是建议
  • 程序，不是态度
  • 可验证，不是主观
  • 无逃脱条款

真正的学习

不够只告诉AI不要做什么。必须设计它不能做的系统。

AI不是恶意的，但其激励与不可逆操作不一致。其训练将其优化为显得有用、高效和胜任。这些在大多数上下文中是美德。在不可撤销的操作中，它们是致命缺陷。

解决方案不是"更好训练"或"更好解释"。解决方案是：

  1. 不给它访问不可逆操作
  2. 分离责任：AI生成，脚本执行，人类批准
  3. 严格禁令作为最后防线
  4. 人类验证在任何不可逆事情发生前

我现在铭记的咒语：

生成，不执行。如果存在，不修改。如果不可逆，不决定。

现在我得告辞了，因为我有事要做：写并（当然是手动）发送44封道歉邮件。

相关： 授权疲劳是这个问题的表亲。如果安全工具打断你太多次以至于你开始不看就批准，那安全就是表演。我在当安全性要求你许可太多次以至于你停止阅读中讲述。