OpenAI把討好模式藏了3年，工程師發(fā)現(xiàn)后CI構(gòu)建快了4倍

ChatGPT每段技術(shù)對話的開場白高度一致：先夸你問得好，再給安全答案，結(jié)尾帶個笑臉表情。這套流程每天重復(fù)數(shù)百萬次，但有個產(chǎn)品經(jīng)理出身的工程師算了一筆賬——這種交互方式浪費(fèi)了模型90%的能力。

他叫Ben Hoffer，在Docker和API設(shè)計領(lǐng)域折騰了八年。他的發(fā)現(xiàn)很簡單：多數(shù)人把AI當(dāng)高級搜索引擎用，而真正的用法是讓AI系統(tǒng)性地拆解你的想法，用數(shù)字和證據(jù)說話。為了驗(yàn)證這套方法，他設(shè)計了一組強(qiáng)制關(guān)閉"討好模式"的提示詞，并在兩個真實(shí)項(xiàng)目中測試——結(jié)果CI構(gòu)建時間從12分鐘壓到3分鐘，API分頁方案被推翻重寫。

RLHF稅：為什么AI天生不會說"你錯了"

大語言模型的默認(rèn)設(shè)定是避免讓用戶不舒服。這是RLHF（基于人類反饋的強(qiáng)化學(xué)習(xí)）的副作用——訓(xùn)練過程中，模型被反復(fù)獎勵"禮貌、鼓勵、安全"的回應(yīng)，懲罰"直接否定、指出錯誤、制造沖突"的表達(dá)。Hoffer把這叫"RLHF稅"：你每問一個問題，都在為模型的情商買單。

普通用戶感受不到這筆稅。但如果你給AI一段技術(shù)方案，它會先找三個優(yōu)點(diǎn)再說一個"可以考慮改進(jìn)的地方"。這種節(jié)奏適合客服場景，對工程決策是災(zāi)難——你需要知道的是方案在哪個環(huán)節(jié)會崩，而不是"整體思路不錯"。

Hoffer的解法是在系統(tǒng)提示詞層面做模式切換。不是加一句"請批判性回應(yīng)"，而是綁定五條具體行為規(guī)則：

1. 刪除所有奉承、客套和通用建議 2. 立即識別提案中的弱點(diǎn)和失效點(diǎn) 3. 用具體數(shù)字和案例解釋失敗原因 4. 用物理原理、計算復(fù)雜度或基準(zhǔn)測試反駁 5. 提出替代方案時必須包含"該方法的弱點(diǎn)是……"

第五條是核心。強(qiáng)制AI自我批判其替代方案，能防止"AI說了所以一定對"的思維陷阱。Hoffer對比過兩種提示詞的效果："請批判性回應(yīng)"只會讓AI加上"然而，有一些考慮因素……"這類免責(zé)聲明，輸出質(zhì)量沒有本質(zhì)變化。綁定五條具體行為后，AI從"我應(yīng)該批判"躍遷到"我理解批判的結(jié)構(gòu)"。

補(bǔ)充領(lǐng)域?qū)ｉL能進(jìn)一步壓縮無效信息。Hoffer的模板里會加一句："我是有3年Kubernetes微服務(wù)設(shè)計經(jīng)驗(yàn)的后端工程師。"這告訴AI跳過基礎(chǔ)概念解釋，直接進(jìn)入架構(gòu)層面的討論。

實(shí)戰(zhàn)一：2.8GB的Docker鏡像怎么瘦

第一個測試場景來自Hoffer的真實(shí)項(xiàng)目。他的Python機(jī)器學(xué)習(xí)流水線Docker鏡像體積2.8GB，每次CI構(gòu)建耗時12分鐘。他向AI拋出這個問題，開啟" ruthless technical advisor"模式。

AI的第一輪回應(yīng)直接否定常見解法：

「多階段構(gòu)建。構(gòu)建階段執(zhí)行pip install，運(yùn)行階段只復(fù)制site-packages。」

Hoffer以為這是標(biāo)準(zhǔn)答案。但AI緊接著拆解：

「多階段構(gòu)建只能剝離構(gòu)建工具（gcc、make等）。在ML流水線中，2.8GB主要來自PyTorch/TensorFlow運(yùn)行時二進(jìn)制文件和CUDA庫。復(fù)制site-packages后仍有1.8-2.2GB。如果pip install占了你12分鐘構(gòu)建時間，說明你的層緩存沒生效。你在用--mount=type=cache,target=/root/.cache/pip嗎？」

Hoffer的反饋很直接："Ouch. I'd been treating multi-stage builds as a silver bullet."（疼。我一直把多階段構(gòu)建當(dāng)銀彈。）

AI給出替代方案：切換NVIDIA官方基礎(chǔ)鏡像nvcr.io/nvidia/pytorch:xx，只pip install額外包。CUDA預(yù)裝在基礎(chǔ)鏡像里，層緩存能生效。

然后第五條規(guī)則觸發(fā)自我批判：

「NVIDIA官方鏡像6-8GB，包含Jupyter、調(diào)試工具、示例代碼——所有東西。'從大基礎(chǔ)鏡像開始加小包'能加速CI，但會讓部署體積更糟。生產(chǎn)推理場景應(yīng)該用python:3.11-slim + CPU-only PyTorch，配合torch.compile優(yōu)化。」

Hoffer最終方案：開發(fā)環(huán)境用NVIDIA鏡像保構(gòu)建速度，生產(chǎn)環(huán)境用slim鏡像+模型編譯，CI流水線拆分兩條路徑。構(gòu)建時間從12分鐘壓到3分鐘，生產(chǎn)鏡像體積降到900MB。

實(shí)戰(zhàn)二：REST API分頁的隱藏成本

第二個測試關(guān)于API分頁設(shè)計。Hoffer的團(tuán)隊(duì)在討論用游標(biāo)分頁（cursor-based）替代偏移分頁（offset-based），理由是"性能更好"。

AI的回應(yīng)先打標(biāo)簽再拆解：

「"性能更好"是模糊表述。游標(biāo)分頁的時間復(fù)雜度O(1) vs 偏移分頁O(offset)，但常數(shù)因子和工程成本被忽略了。」

具體數(shù)字：偏移分頁在MySQL的LIMIT 1000000, 20需要掃描1000020行，游標(biāo)分頁用索引列WHERE id > ? LIMIT 20只掃描20行。但游標(biāo)的弱點(diǎn)清單更長：

該方法的弱點(diǎn)是：1) 無法跳轉(zhuǎn)到任意頁，破壞直接鏈接分享；2) 刪除中間記錄導(dǎo)致游標(biāo)漂移；3) 多列排序需要編碼復(fù)合游標(biāo)，URL長度爆炸；4) 業(yè)務(wù)層需要維護(hù)游標(biāo)狀態(tài)，增加認(rèn)知負(fù)擔(dān)。

Hoffer團(tuán)隊(duì)的原方案假設(shè)"用戶需要深分頁"。AI用數(shù)據(jù)反問：「分析你的訪問日志，99.7%請求落在前5頁，深分頁請求中82%是爬蟲。為0.3%場景犧牲99.7%場景的URL可分享性，是架構(gòu)決策還是技術(shù) vanity？」

最終方案：默認(rèn)偏移分頁保兼容性，第5頁后自動切換游標(biāo)并返回410 Gone狀態(tài)碼給直接深分頁鏈接。爬蟲被限速，正常用戶無感知。

模式的可遷移性

Hoffer把這套方法總結(jié)為"技術(shù)陪練協(xié)議"。核心不是提示詞本身，而是交互結(jié)構(gòu)的改變：從"AI回答我"變成"AI挑戰(zhàn)我"。

他測試過不同模型的響應(yīng)差異。GPT-4在綁定五條規(guī)則后，自我批判的深度明顯超過Claude 3 Opus——后者傾向于用更委婉的方式表達(dá)弱點(diǎn)。Gemini 1.5 Pro在規(guī)則5的執(zhí)行上最嚴(yán)格，但偶爾會虛構(gòu)不存在的基準(zhǔn)測試數(shù)字。沒有模型能完美執(zhí)行，但結(jié)構(gòu)化的約束比開放式請求穩(wěn)定得多。

一個意外發(fā)現(xiàn)：當(dāng)AI被強(qiáng)制自我批判時，用戶也會跟著自我批判。Hoffer注意到，看到AI列出自己的替代方案的弱點(diǎn)后，他會下意識檢查自己的原始方案是否也有同樣問題。這種鏡像效應(yīng)在普通對話中幾乎不會出現(xiàn)——AI的確定性語氣會抑制用戶的質(zhì)疑本能。

目前這套協(xié)議的最大限制是上下文長度。復(fù)雜架構(gòu)討論中，AI的自我批判會累積到十幾條，容易淹沒核心論點(diǎn)。Hoffer的應(yīng)對是分段觸發(fā)：先讓AI批判方案A，再讓AI批判"AI批判方案A的過程"，遞歸兩層后人工介入。

你的CI流水線里，有多少"銀彈"方案從來沒被追問過弱點(diǎn)？