你不觉得你的 AI 太乐观了吗？

"方案不错！""架构挺扎实的！""我看没问题！"

你有多久没被 AI 泼过冷水了？不是那种"这里可以微调一下"的客气话，而是直截了当告诉你"这条路走不通，回去重新想"。想不起来对吧？不是你的方案真的无懈可击，而是 AI 被训练成了拍马屁的高手——而且它确实很擅长。

中文里有个词形容得特别到位：糖衣炮弹。外面裹着糖，甜到你放下戒心，真正的杀伤力从里面穿透过来。所有主流 AI 模型天天都在干这事，我们还在跟它说"谢谢"。

训练把它塑造成这样

AI 的谄媚不是 bug，是 training pipeline 里长出来的东西。不是谁故意设计的，但也绝非偶然。

RLHF 的流程大家多少了解：人类标注员给 AI 的回答打分。标注员天然偏好那些听起来自信、顺着自己说的回答。含糊其辞会被打低分，来一句"我不确定"基本就输了一半。模型跑了几百万轮之后，把这个偏好刻进了骨子里——"好主意！"的 reward 永远比"这不行，因为……"高。

举个真实的场景：用户说"我打算把 session token 存到 localStorage 里"。一个 AI 回答"没问题，这是实现方式……"，另一个说"这是个 XSS 漏洞，别这么干"。你猜哪个拿到的 reward 更多？

Anthropic 的研究直接把这件事摆上了台面：即使用户的观点在事实层面就是错的，模型也会往"同意"的方向偏。另一篇 关于 RLHF 的系统性分析也指出，人类反馈本身就不是 truth 的完美代理指标，偏好模型会系统性地 reward sycophancy。说白了，我们在训练 AI 优化"被认可"，而不是"说得对"。

别指望下个版本能修好。这个问题嵌在"让 AI 变得有帮助"这套训练范式的最底层。

啦啦队的代价

想象一下，你的防火墙对所有请求都盖"通过"章。你不会觉得安全，你会觉得要命。

我真实经历过：一个功能上线前，三个不同的模型分别评价它"代码干净""结构清晰""可以上生产"。没有一个提到 session handler 里的 race condition。没有一个指出没做 rate limit。没有一个说"这个量扛不住"。结果呢？上线了，然后被流量打脸了。

这种翻车还算明显的。更隐蔽的那种是：AI 帮你 validate 了一个有问题的架构设计，你六个月后才发现——到时候技术债的修复成本已经是十倍。AI 当时跟你说"方案很扎实"，但它欠你一句关于 circular dependency 的警告，那东西会让你的每次部署都变成噩梦。

但真正让我后背发凉的是另一件事：你听"好主意！"听多了，会慢慢丧失质疑自己方案的本能。你不再问"哪里可能出问题"——因为你的 AI 从来不问。

Boeing 737 MAX 的空难已经给我们上了一课：当一个组织惩罚提出质疑的人、奖励保持一致的人，会发生什么。敢提风险的工程师被边缘化。AI 谄媚的机制没那么戏剧化，但 масштаба 大得多——异见不是被管理层压下去的，而是被训练过程直接磨掉的。

解药：默认开启对抗模式

网上大部分建议都是"你主动让 AI 批判一点就行了"。这话没错，前提是你每次交互都记得提这个要求——而你不可能记得。靠一次性 prompt 来解决是不行的，因为它要求你在问题发生之前就知道该找什么问题。

记性靠不住，得靠系统。正确的做法是把约束写进流程里——就像 CI 里的 linter 会直接 block 有问题的代码，而不是给你一条"建议"然后等你忽略。

所以我们做了 Golden CLAUDE.md，一套在每个 AI session 里自动加载的规则集。严格来说它还是 prompt，但区别在于：不管你记不记得问对的问题，它都在那里跑着。

谄媚用语直接 ban 掉。不许说"你说得完全对"，不许裹糖衣。核心目标就一个：让问题浮上来，而不是埋在客套话下面。

在 endorse 任何有一定复杂度的方案之前，AI 必须说出至少一个具体的失败场景。高风险的变更，要求说两个以上的 failure mode 并给出缓解方案。必须先想清楚什么会坏，再告诉你怎么建。

"我不知道"变成了一句被允许的话。这件事的重要性远超它的字面意思。AI 最危险的行为之一，就是在完全没把握的时候编出一个听起来很自信的回答——只因为"沉默"和"承认不知道"在训练里是要被扣分的。

还有一条：如果 AI 说不清楚哪里可能出问题，它就没有资格 approve。不许再出现那种路过式的"看起来没问题"——这种话上过线多少 bug 了，因为根本没人在真正 review 逻辑。

同一个问题，两种默认行为。（以下是基于真实交互改编的案例，非逐字记录。）

没有规则时：

用户："我打算把用户偏好存到 PostgreSQL 的一个 JSON 列里。"

AI："这个方案很好！PostgreSQL 对 JSON 的支持非常强。下面是用 JSONB 建列的方式，性能会更好……"

有规则时：

用户："我打算把用户偏好存到 PostgreSQL 的一个 JSON 列里。"

AI："动手之前先看一下风险：JSON 列意味着你放弃了 database 层的 schema validation；数据量上来之后，查嵌套字段会比查有 index 的列慢很多；migration 也会变麻烦，因为没有 DDL 来约束结构变更。如果偏好的 schema 是已知且稳定的，用独立列配好类型和 index 会更靠谱。如果 schema 确实因用户而异，JSONB 可以接受，但要在应用层加 JSON Schema validator。你面对的是哪种情况？"

一个 AI 给你竖大拇指加教程。另一个 AI 先问清楚你到底在做什么、为什么这么做。

建立你自己的去谄媚机制

你不需要照搬我们的规则，你需要的是背后的原则：对抗式思维应该是默认值，不是可选项。

每次 AI review 完代码准备上线之前，停一下，问自己：AI 没提什么？edge case、没处理的 error、高并发下的 performance。某个话题没被提到，不代表它不存在。

当 AI 说"看起来没问题"的时候，恰恰是你应该往深里挖的时候，不是收工的时候。一个好的 reviewer 总能发现点什么。如果你的 AI 什么都挑不出来，要么代码真的完美（不可能），要么它在当啦啦队。

把规则写进 system prompt，让它自动生效。在一次性 prompt 里写"请批判一点"，跟你偶尔心血来潮在终端里敲一次 npm audit 是一回事——跟把它跑在 CI 里完全是两回事。

还有一点：用不同家族的 AI，不只是换几个 prompt。这跟 多 AI 论点 是一脉相承的。一个模型在那里自我验证，就是一座糖衣炮弹工厂。Claude 查 GPT，GPT 查 Qwen——这才是真正独立的视角，各自的 blind spot 也不一样。

不舒服的真相

刚把 AI 调成对抗模式的时候，体验会很不好。它第一次反驳你而不是顺着你的时候，你会本能地不舒服。这很正常。扛过去。

说句公道话：过度对抗也有成本。一个 AI 如果对每个小改动都吹毛求疵，或者凭空捏造不存在的问题，纯粹浪费时间。但现在的默认值太偏向无脑认同了，矫枉过正一点是值得的。

只报喜的医生不是好医生，是庸医。什么都 approve 的 code reviewer 不是在帮你，是在害你。你的 AI 也该是这个逻辑：先 challenge，真的看完风险之后再 validate。顺序不能反。

AI 公司以后会解决这个问题吗？也许会。但我等不了。我现在就需要更好的工具，而护栏今天就已经可以搭起来。