從 Prompt 到 Harness 工程

OpenAI 說，一個團隊用 3 位工程師，花 5 個月，做出超過 100 萬行程式碼的產品。期間他們合併了約 1,500 個 pull request。平均下來，每位工程師每天大約處理 3.5 個 PR。這數字很硬，也很有意思。它在講一件事：真正稀缺的能力，正在從「會不會寫」變成「會不會設計 AI 工作環境」。

這個環境，OpenAI 叫它 harness engineering。講白了，就是讓 agent 能在真實 codebase 裡安全工作的一整套工具、檢查、回饋和限制。你可以把它想成 AI 的作業系統外殼。沒有這層東西，LLM 再強，也只是會亂跑的聊天框。

所以今天的重點，不是「怎麼問模型」。而是「怎麼讓模型在 repo、CI、review 流程裡，真的能做事」。這件事比 prompt 難多了。也更像真正的軟體工程。

OpenAI 這個案例到底猛在哪

OpenAI 的 Codex 案例之所以值得看，不是因為它又在講 AI 多聰明。剛好相反，它講的是工程細節。團隊沒有把 Codex 當聊天介面用，而是把它當成一個需要訓練、需要監控、需要規則的 contributor。

這裡的關鍵字是「可合併」。很多團隊都能讓模型吐出一段 code。問題是，那段 code 能不能過 test。能不能過 review。能不能進主線。能不能在 1 個月後還看得懂。這些才是產品團隊在意的事。

你如果只看產出數字，很容易誤會成「AI 直接取代工程師」。我覺得這是讀錯重點。真正發生的是，工程師把大量時間從手寫 code，轉移到設計流程、限制邊界、定義任務、修正失敗模式。這才是 harness 工程的價值。

• 團隊人數：3 位工程師
• 時間：5 個月
• 合併 PR：約 1,500 個
• 程式碼規模：超過 100 萬行
• 平均量：每人每天約 3.5 個 PR

這些數字不是拿來炫技的。它們是在提醒你，AI 產能的瓶頸已經換位置了。以前卡在「寫得夠不夠快」。現在更常卡在「改得夠不夠穩」。

為什麼 harness 比 prompt 更重要

Prompt 很像你跟模型說話的方式。Harness 則是你把模型關進一個能工作的環境。前者靠文字。後者靠工程。前者可以讓你拿到一段答案。後者可以讓你拿到一個能 merge 的變更。

這差很多。因為 prompt 沒辦法直接保證 test coverage，也沒辦法管 code style，更沒辦法替你守住部署安全。Harness 可以。它把模型放進既有的開發流程裡，讓它照規則跑。跑錯了就回饋。回饋後再修。這種迴圈，比單次對話實用太多。

說真的，很多人現在還把 AI adoption 想成「叫工程師多跟聊天機器人互動」。那太小看這件事了。真正有效的做法，是把 agent 變成流程的一部分。你要給它檔案、權限、測試、邊界、失敗訊號。少一個都不行。

“The future of software development is not about replacing developers, but about augmenting them with AI.” — Satya Nadella

這句話在 keynote 裡聽起來很像標語。可是一旦放進 Codex 這種案例，就變得很具體。人負責設計系統。agent 負責執行。這不是空話，是分工。

如果你做過大型專案，你大概就懂。真正花時間的，常常不是寫那幾行 code。是補測試、修 CI、改命名、處理 edge case、對齊 repo 規則。Harness 做的，就是把這些雜事變成可重複的流程。

跟舊式 AI coding 工具有什麼差別

前兩年大家談 AI coding，主流還是 Copilot、autocomplete、chat-based code generation。那些工具有用，但它們大多是「幫你寫快一點」。人還是主要負責整合、驗證、修 bug。

Agent 加上 harness 之後，分工就變了。你不再只是問模型要一段 function。你是把一個 task 丟給它，讓它去改檔案、跑測試、修失敗、整理成可 review 的變更。這種工作流，和純聊天差很多。

這裡可以直接比一下。差別不是抽象名詞，而是工作型態：

• GitHub Copilot 偏向即時補全與片段建議
• Codex 在 agent 流程裡可處理多步驟 repo 任務
• Claude Code 走 terminal-first，適合命令列工作流
• Aider 也示範了 repo-aware 的迭代方式

你可以把它理解成三個層次。第一層是幫你打字。第二層是幫你改檔。第三層是幫你在流程裡完成任務。Harness engineering 就是在第三層發力。這也是為什麼它比 prompt engineering 更接近真實軟體開發。

我自己的判斷很直接：只會用 prompt 的團隊，頂多拿到局部效率。會做 harness 的團隊，才有機會把 AI 變成日常產線的一部分。

工程師現在要補哪幾塊

如果 harness engineering 真的變成常態，工程師的工作內容會再洗一次。你還是要懂架構、除錯、效能、資料流。可是你也要懂怎麼讓 agent 好好做事。這代表你得會切 task，會設計測試，會安排回饋迴圈。

還有一個很現實的問題：agent 很快，但也很會錯。錯得還可能很像真的。這時候就不能只靠人肉 review。你要靠更快的 CI、更清楚的 log、更嚴的權限、更明確的 repo 邊界。目標不是讓它永遠不犯錯。目標是讓錯誤便宜、好抓、好修。

如果你想把這套東西落地，我會先看這幾件事：

• 把工作切成 agent 能一次做完的 task
• 讓 test 跑得夠快，別拖死迴圈
• 讓 log 和 error 對人也對機器都好讀
• 限制 write access，別讓 agent 到處亂改
• 看 merged output，不要只看 generated output

最後這點最重要。生成很多 code 不代表有價值。能 merge 的 code 才算數。這也是 harness 的核心：把一堆模型輸出，變成真的能進產品的變更。

再講白一點，AI 不缺會講話的工具。缺的是能收斂產出的系統。這就是工程師的新戰場。

這波其實在改變團隊結構

OpenAI 這個案例最有意思的地方，不是模型會寫 code。那件事大家早就知道了。真正有意思的是，小團隊可以靠一套設計好的流程，讓模型長時間穩定產出可用變更。這代表團隊的規模、節奏、分工，都可能重排。

我覺得接下來會出現一個很明顯的分岔。第一種團隊，把 AI 當聊天助手。第二種團隊，把 AI 當可控的工作單元，然後把 harness 做到很細。兩者的差距，短期看不一定很誇張。半年到一年後，差距就會很現實。

這也會影響招募。以前大家愛問 prompt engineer。老實說，這個詞現在有點老派了。接下來更值錢的，會是懂 agent workflow、懂 CI/CD、懂 repo 結構、懂怎麼把失敗訊號變成回饋的人。這種人比較像 AI 時代的軟體系統設計師。

產業脈絡也很清楚。大型模型成本雖然下降，但真正貴的還是可靠性。你把模型丟進產品流程，最後還是得面對權限、測試、稽核、資安、版本控管。這些老問題沒有消失，只是換了主角。

所以，現在不是在比誰會下 prompt。是在比誰能把 AI 變成可維護的工程系統。這差很多。

接下來該看什麼

我會預測，接下來 12 個月，真正有用的 AI coding 團隊，會把重點放在 harness，而不是 prompt。你會看到更多 repo-aware agent、更多自動測試回饋、更多限制式工作流。也會看到更多團隊開始量化「merged PR」而不是「生成 token 數」。

如果你是工程師，現在最值得做的事不是狂練 prompt。是回頭檢查你的 repo。測試夠不夠快。錯誤訊息夠不夠清楚。CI 夠不夠穩。任務切得夠不夠小。這些東西一旦整理好，agent 才真的有機會上場。

講到底，問題很簡單：當你的 AI 開始寫 code，你有沒有一個夠好的 harness，讓它寫出來的東西真的能進產品？