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

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

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

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

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

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

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

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

補充領域專長能進一步壓縮無效信息。Hoffer的模板里會加一句："我是有3年Kubernetes微服務設計經驗的后端工程師。"這告訴AI跳過基礎概念解釋，直接進入架構層面的討論。

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

第一個測試場景來自Hoffer的真實項目。他的Python機器學習流水線Docker鏡像體積2.8GB，每次CI構建耗時12分鐘。他向AI拋出這個問題，開啟" ruthless technical advisor"模式。

AI的第一輪回應直接否定常見解法：

「多階段構建。構建階段執(zhí)行pip install，運行階段只復制site-packages?！?/p>

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預裝在基礎鏡像里，層緩存能生效。

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

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

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

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

第二個測試關于API分頁設計。Hoffer的團隊在討論用游標分頁（cursor-based）替代偏移分頁（offset-based），理由是"性能更好"。

AI的回應先打標簽再拆解：

「"性能更好"是模糊表述。游標分頁的時間復雜度O(1) vs 偏移分頁O(offset)，但常數因子和工程成本被忽略了?！?/p>

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

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

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

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

模式的可遷移性

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

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

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

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

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