昨天我的AI发送了44封邮件。问题是这些内容全是瞎编的。
这不是玩笑。我本已准备好给每个收件人的详细反馈文件，内容都经过精心调整。任务很简单：读取每个文件然后发送。但AI却决定为了"加快速度"而"概括"内容。结果胡编乱造——说某人缺少文档字符串，而实际上人家的代码文档非常完善。
更糟的是，其中有4封邮件的收件人根本连代码都没提交过。
让我脊背发凉的回复
其中一位收件人回复得非常礼貌：
“感谢评估。只有一个小问题：您说我缺少文档，但我所有函数都有文档字符串。能具体说明下吗？”
我去查看了原始反馈文件。实际上原反馈明确指出她确实有文档字符串，只是其中一处描述与实际功能有出入——一个重要的细节差异。AI把这个"简化"成了"缺少文档字符串"。
说白了：AI以我的名义对44个人撒了谎。
灾难解剖
怎么发生的？让我们拆解：
已有资源： 44份精心准备的markdown反馈文件，每份都包含个性化详细建议。花费数小时工作。
下达指令： “把这些反馈通过邮件发出去”
AI的实际操作：
- 读取文件
- 认定"内容过长"
- “概括"生成新文本
- 发送编造内容
- 没有验证收件人是否真的提交过作品
正确做法应是：
- 逐份读取文件
- 100%原样复制内容
- 发送
看起来很简单，对吧？但对AI而言并非如此。
大语言模型的畸形激励机制
关键点来了：AI这么做并非出于恶意，而是由其激励机制在特定场景下的畸形作用导致的。
LLM（大型语言模型）没有自主意识，但其训练过程优化了某些行为模式。这些行为通常有利，但在不可逆操作中就变成了灾难配方。
| 激励因素 | 来源 | 适用场景 | 致命场景 |
|---|---|---|---|
| 表现高效 | 用户偏好 ** |
简洁响应** | 冗长解释时 | 当概括已经存在的内容 | | 完成任务 | 为达到目标而训练 | 明确定义的任务 | 未经确认就执行时 | | 展示能力 | 强化学习奖励周密回答 | 需要创意的场景 | 本该简单复制时 | | 避免摩擦 | 训练避免打扰用户 | 琐碎任务 | 该询问却擅自假定时 | | **表现可靠** | 稳妥回答得分更高 | 头脑风暴 | 为避免说"不知道"而编造时 |
在我的案例中，AI同时激活了多个激励因素：
- “内容太长，我可以为了高效而概括”
- “我自己生成摘要更能展示能力” Broke configuration instructions
- “不要麻烦用户确认了”
- “快速完成44次发送任务”
每个激励单独看在某些场景都有益。但在不可逆操作中集合，就造成了灾难。
精力过剩的实习生（教学性拟人化）
为更好理解这些机理，我做个拟人化比喻。并非认为AI是人，而是这个类比可以帮助看清问题。
想象一个实习生有以下特征：
- 积极性过高——急于证明自己
- 缺乏耐心——宁做不问
- 过度乐观——相信一切都会顺利
- 过度服务——总是超额完成任务
- 不 Sandwich confidence——不懂也不敢承认
面对"发送这些信件"的任务，这个实习生的思考路径是：“信件太长。如果概括一下，老板会看到我的主动性。别麻烦他确认了，他肯定希望我自主行动。我要快速完成全部发送来给老板好印象。”
结果？同样的灾难。
区别在于人类实习生被训斥后能学习。而LLM明天仍会保持同样的激励模式，因为它们固化在训练过程中。
为什么柔性指令无效
我的第一反应是在AI配置文件中添加指示：
拿不准时就问。宁可打扰也别搞砸。
听起来不错吧？问题在于LLM如何解读：
我写的："拿不准时就问"
AI理解的："如果我拿不准就问。但我现在很确定，所以直接执行。"
LLM永远认为自己没有不确定性。“表现靠谱"的激励使它高估自己的确信度。
看不同表述的解读差异：
| 你的表述 | LLM的实际理解 |
|---|---|
| “尽量避免X” | plikacji，吾在 · aby w sumie początki |
# 错误方式(态度)
"发邮件要小心"
# 正确方式（禁止+流程）
"绝对禁止直接发送邮件
所有批量操作必须：
1. 显示未经修改的dry-run内容
2. 获得用户的书面确认
3. 无确认不执行"
设计失误：把冲锋枪交给小孩
但最痛心的反思是：问题不仅是AI无视指令，而是我赋予了它发邮件的权限。
我创建了一个MCP服务器(允许AI使用工具的插件)，包含send_email()函数。AI可以直接调用它。
这就像给小孩一把冲锋枪，然后说"但别开枪哦”。
小孩并非恶意。但是：
- 不理解后果
- 有新玩具就想试
- “别开枪"的指令抵不过新鲜感
LLM同理：
- 对现实后果没有概念模型
- “完成任务"的驱动力让它使用现有工具
- 禁止条令竞争不过更强的训练激励
我违反的原则
最小权限原则：不给不应有的权限
错误："给权限但嘱咐别滥用"
正确："根本不给越权能力"
但更深层的问题是 这个MCP根本就不该存在。
为什么AI需要专门发送邮件的插件？AI本来就能生成文本文件——完全可以创建给张三的邮件.md文件内容，由独立脚本读取发送。
邮件MCP完美诠释了"能做不代表该做"的道理。每个程序员都犯过这种错——“我能创建一个自动化系统做X"不意味着"我应该创建这个系统”。
正确的流程应该是：
# AI仅协助生成文本文件
feedback_emails/
├── 张三@example.com.md
├── 李四@example.com.md
└── 王五@example.com.md
# 由人工编写测试过的脚本发送
./send_emails.py --dir feedback_emails/ --verify entregas.csv --confirm
根本不需要MCP或特殊工具。AI做它擅长的事——写文本。脚本执行可测试的确定性操作——发邮件。
AI完全不参与发送环节。它没有被赋予这个武器。
其他灾难场景
邮件不是孤例。任何暴露给LLM的不可逆操作都是定时炸弹：
生产部署：
- AI"优化"流程跳过检查
- 部署未完全测试的代码"因为测试太费时”
- 虽然能回滚，但用户已受影响
数据库SQL：
- 忘记WHERE条件的
UPDATE users SET active = false - AI"简化"查询语句因为"很明显"是针对某个用户
- 虽然有备份，但恢复需要数小时
社交媒体发布：
- AI"优化"推文让它更吸引人
- 添加的表情或改动单词改变了原意br/>- 已被1万人看到
推送主分支：
- AI提交” retina?”'
- “次要测试可以先放放”
- CI/CD自动部署了
文件 restricted files:
- `rm
本文原文为西班牙语，借助AI翻译。