💡 這課會告訴他問題可能根本不在模型，而在「有沒有把公司內部知識鋪好路給 AI 走」——這套做法叫「情境工程（Harness Engineering）」
🧭 這到底是什麼（白話版）
這篇文章講的是一個叫做 Harness Engineering（情境工程）把「餵給 AI 的資料、能用的工具、周遭規範」設計好，而不是換一顆更貴的模型 的做法。核心想法很反直覺：作者故意把 AI 模型和 coding agent 當成 黑盒子把一個東西當作「不用管內部怎麼運作，只看丟進去、拿出來的結果」——完全不去換模型、不去微調，而是專心把模型「周圍」的兩根槓桿轉緊：一是給它的資訊（context），二是給它能用的工具。
為什麼周邊環境比模型本身重要？因為每個組織都有一堆「這個系統這樣做才對」的隱藏規矩，文章稱之為 非功能性需求除了「功能做出來了沒」之外，還要顧到的安全性、可維護性、效能、風險等隱藏規矩，包括可靠度、資安、相容性、好不好維護、效能、好不好操作、風險承受度，還有整體的精緻程度。這些規矩通常只存在老工程師的腦袋裡、內部 wiki，或者「大家都知道不能這樣寫」的默契中，從來沒有寫成 AI 讀得懂的文字。
作者用一個很生動的比喻：通用模型的權重（訓練完之後模型記住的東西）只看得到組織知識的 冰山比喻表面看得到的只是一小部分，海面下才藏著更大量看不到的知識與規則一角，海面下才是真正龐大的部分——現在系統跑到哪個狀態、公司自己一套的 本體論（ontology）一個組織內部對「這些名詞、這些流程分別代表什麼」的一套共同定義方式（例如「我們公司講的客戶特別指哪一種人」）、品質底線在哪、以前踩過哪些雷、誰有權限拍板。情境工程要做的，就是把這些藏在海面下的東西，變成 AI 代理人拿得到、看得懂的上下文跟工具，這是屬於 Last-mile 工程把一個通用的東西，加工成能直接在你家、你公司使用的最後一段客製化工程 的工作——把一個什麼都懂一點的通用模型，加工成「懂我們公司規矩」的可用員工。
更關鍵的是，這件事可以越做越好：因為工作是不斷重複的迭代賽局，每一次 AI 產出被接受、被打回票、出錯，或使用者給了回饋，都可以變成下一次的情境、界線、工具、範例和檢查點，讓組織的判斷力隨時間累積，而不是每次都從零開始教一次。
🎯 為什麼值得你花時間
省下的是最貴的資源——工程師的審核時間文章的重點不是讓 AI 寫得更快，而是讓工程師不用重新讀懂問題、否決錯誤方案、再解釋一次。情境沒鋪好，AI 產出再快也只是把審核工作量轉嫁給人。
護城河在組織知識，不在模型參數換更貴的模型不會讓 AI 自動知道你們公司的內部規範跟踩過的雷。真正的優勢是把這些私有、會變動的流程知識變成可檢索、可執行的上下文，這是競爭對手複製不走的部分。
沒有證明的產出，人只能重做一次文章強調 agent 要能「證明結果」。如果 AI 只丟出一段程式碼卻沒有測試、沒有引用規範、無法被追溯，審核的人等於要重新驗證一遍，等同於自己重做。
⚙️ 它是怎麼運作的
1
回復意圖情境工程要讓 AI 代理人搞懂這個任務真正要解決的問題是什麼，而不是照字面執行，避免像案例中把時區 bug 誤判成 session 過期。