OpenAI把讨好模式藏了3年，工程师发现后CI构建快了4倍

ChatGPT每段技术对话的开场白高度一致：先夸你问得好，再给安全答案，结尾带个笑脸表情。这套流程每天重复数百万次，但有个产品经理出身的工程师算了一笔账——这种交互方式浪费了模型90%的能力。

他叫Ben Hoffer，在Docker和API设计领域折腾了八年。他的发现很简单：多数人把AI当高级搜索引擎用，而真正的用法是让AI系统性地拆解你的想法，用数字和证据说话。为了验证这套方法，他设计了一组强制关闭"讨好模式"的提示词，并在两个真实项目中测试——结果CI构建时间从12分钟压到3分钟，API分页方案被推翻重写。

RLHF税：为什么AI天生不会说"你错了"

大语言模型的默认设定是避免让用户不舒服。这是RLHF（基于人类反馈的强化学习）的副作用——训练过程中，模型被反复奖励"礼貌、鼓励、安全"的回应，惩罚"直接否定、指出错误、制造冲突"的表达。Hoffer把这叫"RLHF税"：你每问一个问题，都在为模型的情商买单。

普通用户感受不到这笔税。但如果你给AI一段技术方案，它会先找三个优点再说一个"可以考虑改进的地方"。这种节奏适合客服场景，对工程决策是灾难——你需要知道的是方案在哪个环节会崩，而不是"整体思路不错"。

Hoffer的解法是在系统提示词层面做模式切换。不是加一句"请批判性回应"，而是绑定五条具体行为规则：

1. 删除所有奉承、客套和通用建议 2. 立即识别提案中的弱点和失效点 3. 用具体数字和案例解释失败原因 4. 用物理原理、计算复杂度或基准测试反驳 5. 提出替代方案时必须包含"该方法的弱点是……"

第五条是核心。强制AI自我批判其替代方案，能防止"AI说了所以一定对"的思维陷阱。Hoffer对比过两种提示词的效果："请批判性回应"只会让AI加上"然而，有一些考虑因素……"这类免责声明，输出质量没有本质变化。绑定五条具体行为后，AI从"我应该批判"跃迁到"我理解批判的结构"。

补充领域专长能进一步压缩无效信息。Hoffer的模板里会加一句："我是有3年Kubernetes微服务设计经验的后端工程师。"这告诉AI跳过基础概念解释，直接进入架构层面的讨论。

实战一：2.8GB的Docker镜像怎么瘦

第一个测试场景来自Hoffer的真实项目。他的Python机器学习流水线Docker镜像体积2.8GB，每次CI构建耗时12分钟。他向AI抛出这个问题，开启" ruthless technical advisor"模式。

AI的第一轮回应直接否定常见解法：

「多阶段构建。构建阶段执行pip install，运行阶段只复制site-packages。」

Hoffer以为这是标准答案。但AI紧接着拆解：

「多阶段构建只能剥离构建工具（gcc、make等）。在ML流水线中，2.8GB主要来自PyTorch/TensorFlow运行时二进制文件和CUDA库。复制site-packages后仍有1.8-2.2GB。如果pip install占了你12分钟构建时间，说明你的层缓存没生效。你在用--mount=type=cache,target=/root/.cache/pip吗？」

Hoffer的反馈很直接："Ouch. I'd been treating multi-stage builds as a silver bullet."（疼。我一直把多阶段构建当银弹。）

AI给出替代方案：切换NVIDIA官方基础镜像nvcr.io/nvidia/pytorch:xx，只pip install额外包。CUDA预装在基础镜像里，层缓存能生效。

然后第五条规则触发自我批判：

「NVIDIA官方镜像6-8GB，包含Jupyter、调试工具、示例代码——所有东西。'从大基础镜像开始加小包'能加速CI，但会让部署体积更糟。生产推理场景应该用python:3.11-slim + CPU-only PyTorch，配合torch.compile优化。」

Hoffer最终方案：开发环境用NVIDIA镜像保构建速度，生产环境用slim镜像+模型编译，CI流水线拆分两条路径。构建时间从12分钟压到3分钟，生产镜像体积降到900MB。

实战二：REST API分页的隐藏成本

第二个测试关于API分页设计。Hoffer的团队在讨论用游标分页（cursor-based）替代偏移分页（offset-based），理由是"性能更好"。

AI的回应先打标签再拆解：

「"性能更好"是模糊表述。游标分页的时间复杂度O(1) vs 偏移分页O(offset)，但常数因子和工程成本被忽略了。」

具体数字：偏移分页在MySQL的LIMIT 1000000, 20需要扫描1000020行，游标分页用索引列WHERE id > ? LIMIT 20只扫描20行。但游标的弱点清单更长：

该方法的弱点是：1) 无法跳转到任意页，破坏直接链接分享；2) 删除中间记录导致游标漂移；3) 多列排序需要编码复合游标，URL长度爆炸；4) 业务层需要维护游标状态，增加认知负担。

Hoffer团队的原方案假设"用户需要深分页"。AI用数据反问：「分析你的访问日志，99.7%请求落在前5页，深分页请求中82%是爬虫。为0.3%场景牺牲99.7%场景的URL可分享性，是架构决策还是技术 vanity？」

最终方案：默认偏移分页保兼容性，第5页后自动切换游标并返回410 Gone状态码给直接深分页链接。爬虫被限速，正常用户无感知。

模式的可迁移性

Hoffer把这套方法总结为"技术陪练协议"。核心不是提示词本身，而是交互结构的改变：从"AI回答我"变成"AI挑战我"。

他测试过不同模型的响应差异。GPT-4在绑定五条规则后，自我批判的深度明显超过Claude 3 Opus——后者倾向于用更委婉的方式表达弱点。Gemini 1.5 Pro在规则5的执行上最严格，但偶尔会虚构不存在的基准测试数字。没有模型能完美执行，但结构化的约束比开放式请求稳定得多。

一个意外发现：当AI被强制自我批判时，用户也会跟着自我批判。Hoffer注意到，看到AI列出自己的替代方案的弱点后，他会下意识检查自己的原始方案是否也有同样问题。这种镜像效应在普通对话中几乎不会出现——AI的确定性语气会抑制用户的质疑本能。

目前这套协议的最大限制是上下文长度。复杂架构讨论中，AI的自我批判会累积到十几条，容易淹没核心论点。Hoffer的应对是分段触发：先让AI批判方案A，再让AI批判"AI批判方案A的过程"，递归两层后人工介入。

你的CI流水线里，有多少"银弹"方案从来没被追问过弱点？