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

**Summary:** RLHF 可能奖励迎合而不是准确，把 AI 变成裹着糖衣的子弹：看似认可，实则隐藏失败模式。本文讨论持续的对抗性规则如何把默认行为从奉承改成诚实质疑。

- Canonical: https://markhuang.ai/zh/blog/dont-you-think-your-ai-is-too-optimistic
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-03-21
- Section: AI 与 LLM
- Tags: AI 奉承, RLHF, 对抗式 AI, AI 编码, 代码质量
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一颗黄铜子弹外裹开裂的彩色糖衣，露出里面的金属](https://cdn.markhuang.ai/blog/dont-you-think-your-ai-is-too-optimistic/hero.webp)

*一颗黄铜子弹外裹开裂的彩色糖衣，露出里面的金属*

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

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

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

## 训练把它塑造成这样

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

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

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

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

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

![左边是竖起大拇指、周围有绿色勾号的快乐机器人；右边是拿着清单和警告标志的严肃机器人](https://cdn.markhuang.ai/blog/dont-you-think-your-ai-is-too-optimistic/training-split.zh-CN.webp)

*快乐赞同与严肃审查的训练分叉*

## 啦啦队的代价

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

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

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

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

![透明玻璃防火墙给所有数据包盖章通过，包括带危险标记的红色数据包](https://cdn.markhuang.ai/blog/dont-you-think-your-ai-is-too-optimistic/firewall.zh-CN.webp)

*给所有请求盖章通过的防火墙*

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

## 解药：默认开启对抗模式

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

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

所以我们做了 [Golden CLAUDE.md](https://github.com/Z-M-Huang/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 先问清楚你到底在做什么、为什么这么做。

![左边开发者从微笑机器人手里接过奖杯，周围都是绿色勾号；右边同一开发者记笔记，严肃机器人指向布满警告和流程图的白板](https://cdn.markhuang.ai/blog/dont-you-think-your-ai-is-too-optimistic/before-after.zh-CN.webp)

*默认赞同与默认审查*

## 建立你自己的去谄媚机制

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

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

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

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

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

## 不舒服的真相

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

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

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

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

> **Tip:**
>
> [Golden CLAUDE.md](https://github.com/Z-M-Huang/golden-CLAUDE.md) 是开源的。拿去用，按需改，留下对你有效的部分。