Harness Engineering（駕馭工程）是 OpenAI 在 2026 年 2 月提出的工程做法，出處是〈Harness Engineering: Harnessing Codex in an Agent-First World〉。這篇文章後來被整理成一個公開的學習倉庫（deusyu 的 harness-engineering），本文依該整理閱讀。
Part 1 介紹概念，Part 2 記錄實作驗證。概念歸原作者，Part 2 的實作與修正是作者自己的紀錄。
Part 1：簡介 #
核心轉變 #
傳統：人寫程式碼 → 機器執行
HE： 人設計約束 → AI 寫程式碼 → 機器執行
工程師的產出，從程式碼變成一套約束系統：AGENTS.md、架構規則、自訂 linter、回饋迴路。一句話概括是「人類掌舵，智能體執行」。
六個核心概念 #
| 概念 | 一句話 |
|---|---|
| 倉庫即記錄系統 | 不在倉庫裡的東西，對 AI 不存在（Slack、腦中的知識都看不到） |
| 地圖而非手冊 | AGENTS.md 是目錄頁，不是百科全書，用漸進式揭露引導 AI 往下看 |
| 機械化執行 | 文件會腐爛，lint 規則不會；錯誤訊息要寫修復指令 |
| 智能體可讀性 | 優先選 API 穩定、訓練資料覆蓋好的「無聊」技術 |
| 吞吐量改變合併理念 | 糾錯成本低、等待成本高，PR 要短 |
| 熵管理 | AI 會複製倉庫裡已有的模式，包括壞模式，需定期清理 |
原文的場景是 3 到 7 人的精英團隊、從空倉庫開始、預算沒有上限。倉庫的 README 也註明這些經驗並非普遍適用，需依情境判斷。
Part 2：讀後心得 #
驗證方式 #
六個概念中，機械化執行最容易停在口號，因此選它實作驗證：一個 Pygame 貪食蛇，唯一的規則是 src/logic.py 不得出現 import pygame，渲染與邏輯必須分開。
- 做法：不在文件裡寫「請勿」，而是用
ast.parse()寫架構 linter 掃描logic.py，違規時以非零狀態結束並印出修復指令，再用 pre-commit hook 在每次 commit 前自動執行。 - 規模：9 個 commit、33 個測試（4 個 linter、29 個邏輯）。
有效的地方 #
- AST 比字串比對可靠。 註解裡的
# import pygame不會被誤判，linter 只看可執行的節點。 - 錯誤訊息的品質決定 AI 能否自行修正。 訊息寫明檔案、違反的規則與修復目標，AI 一次就改對。只寫
Architecture violation的話，需要多輪對話才能收斂。因此修復指令是必要條件，不是優化項目。 - Hook 是牆，文件是請求。 刻意在
logic.py加入import pygame後 commit，被 hook 擋下，git log 確認沒有新 commit。文件說的是「不應該這樣做」，hook 讓人「做不到」。 - 純函式的邏輯層容易測試。 六個函式都是「舊狀態進、新狀態出」，不依賴 pygame，也不需要模擬畫面。
被修正的地方 #
Code review 找到三個問題，原本的 TDD 週期都沒有發現：
| 問題 | 嚴重度 | 內容 |
|---|---|---|
step() 讓死掉的蛇復活 |
高 | 蛇已死亡時再呼叫，仍會移動並回傳活著的狀態 |
new_game() 修改了 dataclass |
中 | 其他函式都回傳新物件，只有它直接改欄位，違反不可變原則 |
spawn_food() 棋盤全滿時當掉 |
中 | 20×20 棋盤蛇長到 400 格，候選清單為空，random.choice 出錯，而這是真實的獲勝情境 |
原因在測試清單是按「功能」列的，不是按「不變量」列的：
| 列法 | 能抓到什麼 |
|---|---|
| 按功能（吃食物、移動、撞牆） | 三個問題都抓不到 |
| 按不變量（死亡狀態保持死亡、函式不改輸入、空輸入安全） | 全部抓得到 |
後續在測試清單加入「不變量測試」一節，涵蓋邊界輸入、終端狀態、不可變性，以及輸入空間耗盡時的隨機函式。不可變性有更根本的做法：@dataclass(frozen=True) 讓 Python 在違反時直接拋出例外，這才是機械強制，而不是另一條約定。
Code review 另外發現 linter 本身的缺陷：logic.py 有語法錯誤時，linter 回傳 None 並以 0 結束，等於宣告沒問題，屬於漏報。應改為回報解析失敗。
幾點結論 #
- 機械化執行是最後一道防線，不是唯一一道。 linter 守住架構邊界，守不住邏輯正確性。結構性的守護（linter、hook）與行為性的守護（測試）缺一層都有盲點。
- 寫程式的 AI 與審查的 AI 要分開。 三個問題都由獨立的 code review subagent 找到，呼應 Anthropic 文章中「評估者與實作者分離」的說法：同一個 agent 寫完再自審，容易有確認偏誤。
- 獨立 repo 帶來獨立的 hook 與測試閉環。 貪食蛇做成獨立的 git repo，pre-commit hook 只影響它自己，不干擾父倉庫。代價是第一次設定較麻煩。
單人開發的調整 #
倉庫中有一篇專門討論獨立開發者如何調整的文章（同樣由 deusyu 撰寫），依它整理的對照如下：
- 直接可用： 倉庫即記錄系統（三天後的自己就是另一個團隊成員）、
AGENTS.md（文章建議不超過 60 行）、機械化執行（需警惕測試帶來的虛假安全感）。 - 需要降級： 吞吐量降為單線程，保留「快速迭代勝過追求完美」；熵管理降為每批程式碼完成後自問「這段醜不醜」，手動重構。
- 需要重新定義： 智能體可讀性不再是選型標準，而是使用策略，在已選的技術裡優先用 AI 熟悉的慣用寫法。
- 不需要： 多智能體並行編排、自動垃圾回收 agent、複雜的 session 管理。
該文章引用了 lalitm 的公開案例，其中的對比最具參考價值：把設計與實作都交給 AI，程式碼庫容易失控；自己做設計、讓 AI 負責實作並持續審查重構，才能順利發布。AI 放大的是判斷力，沒有判斷力時，放大的就是錯誤。
限制 #
- 流程不能一律套用。 採用的 HE 流程是「設計規格、寫 TDD 計畫、每個任務交給全新的 subagent」。用在較大的功能很穩，但每個小任務都走一遍「寫測試、確認失敗、實作、確認通過、commit」，對快速驗證的原型太慢。原型因此改用「先做完整的最小流程，再整體測試一次」，嚴格逐步的流程留給高風險或長期維護的程式碼。
- 貪食蛇是很小的案例。 它能驗證機械化執行這個概念，不能證明整套方法在大型專案或多人協作下依然成立。
- 原文提到的規模數字（百萬行、上千個 PR）是 OpenAI 的敘述，無法獨立驗證。
參考 #
- OpenAI，〈Harness Engineering: Harnessing Codex in an Agent-First World〉（2026 年 2 月）
- deusyu，
harness-engineering學習倉庫（整理與延伸閱讀）