PM 不打 code，卻交付十萬行 production code：OpenAI 的 Harness Engineering 全解

2026-06-08

PM 不打 code，卻交付十萬行 production code：OpenAI 的 Harness Engineering 全解

關於作者

Aakash Gupta 是 The Growth Podcast 的主持人，PM 領域的資深玩家（10+ 年 product growth 經驗，做過 Apollo.io、Affirm、Belong 等公司的 PM 主管），現在以「AI PM」為主題經營 6.5 萬訂閱的 Podcast/Newsletter。

這一集他訪問的是 Ryan Lopopolo——OpenAI Member of Technical Staff，也是 OpenAI 那篇談「harness engineering」文章的作者。他帶的 Frontier 團隊，是 OpenAI 內部把「PM 不打 code 卻交付 production code」這件事走到極致的單位。

在這篇文章中，Aakash 想告訴我們：多數公司還在爭論「PM 該不該寫 code」，OpenAI 已經在爭論「PM 寫 code 的最佳方式」。差別不是工具，是整個 SDLC（軟體開發生命週期）被圍繞 agent 重新設計了。

一個讓人坐直的事實

「Ryan 團隊的 PM，總共交付了大約 10 萬行 production code。」

我第一次讀到這句話，反射動作是去找下一句的 caveat。沒有。

接著的問題是：他們有打開 IDE 嗎？

Hell no!

PM 的「寫 code」發生在 PRD、測試、文件、harness 規則裡——typing 是 model 的事。

如果你跟我一樣，過去十年看著一個 feature 從 PRD 到 prod 通常要花上「幾週、幾個月、甚至幾個 quarter」，Ryan 描述的世界會讓你坐直：這個延遲可以縮到幾天、幾小時、甚至幾分鐘。而 PM 是在 loop 裡面寫東西，不是在 Jira 上看著別人寫。

這篇文章的真正命題不是「PM 也能 vibe coding 啦」這種口號，而是：當 GPT-5 級別的模型把「生成 code」變成廉價資源後，整個工程系統的設計重心會往哪裡跑？

Ryan 的答案是 harness——「裝載 agent 的環境」——而這個環境改寫了 PM、Designer、Engineer 三種人的工作描述。

核心邏輯還原

Aakash 與 Ryan 真正想處理的問題不是「AI 能不能寫 code」，而是：

當 code 不再是稀缺資源，團隊的判斷力（judgment）應該以什麼形式存在於系統裡？

他們的推理鏈大致是這樣：

  1. GPT-5 可以大量生成 code →
  2. 真正稀缺的，是 驗證它、安全部署它、確保它解的是正確問題 →
  3. 那麼「團隊的品味、設計決策、業務邏輯邊界」就不能再放在 Slack、PPT、設計師腦袋裡 →
  4. 必須沉澱到 agent 看得懂的 artefact 裡：docs、tests、lints、review rules、observability →
  5. 這套 artefact 集合，就叫做 harness（吊帶/外掛） →
  6. 一旦 harness 夠強，「會 typing 的人」不再是門檻，PM 和 Designer 都能 plug in →
  7. 所有人的工作描述都改變：PM 寫 harness 看得懂的東西、Designer 出 painted door、Engineer 蓋 harness 本身

這條鏈子最大的反直覺點在於——護城河從「會寫 code 的人」轉移到「會蓋 harness 的人」。

Ryan 給出的決策框架，是 harness 必須包含的四大組件（這是 OpenAI 內部用、也是讀者最該帶走的東西）：

Harness 四件套：

  1. agents.md + docs tree（agent 的 operating loop 與知識庫）
  2. Tests + Lints（用測試與檢查碼把「品味」與「非功能需求」編碼進系統）
  3. Review Agents（matrix CI 跑專業 persona doc——frontendarchitect.md、reliabilityengineer.md、appsecengineer.md——做 virtual staff engineer review）
  4. Observability + UI control（讓 agent 用人類的方式 debug 與驗證 end-to-end）

▼ 圖：Harness 的四個組件與 agent 之間的關係

Harness 的四個組件與 agent 的關係

Mermaid 原始碼 
graph LR
    A[agents.md<br>+ docs tree]:::teal --> M[Codex Agent]:::coral
    B[Tests + Lints<br>編碼品味]:::steel --> M
    C[Review Agents<br>persona doc]:::steel --> M
    D[Observability<br>+ Computer Use]:::gold --> M
    M --> O[Production code<br>+ 更新後的 docs/tests]:::cream

    classDef cream fill:#F4F0E4,stroke:#537D96,color:#333
    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef steel fill:#537D96,stroke:#3A5A6E,color:#fff
    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff
    classDef gold fill:#FAB95B,stroke:#D4962A,color:#333

接下來逐個拆。

1. Harness 怎麼運作

agents.md：每個 repo root 都有的一張「給 agent 的家規」

Ryan 把 harness 想成「repo 內部教會 agent 你們團隊怎麼蓋軟體的環境」。

每個 repo 的 root 都有一份 agents.md，跑 Codex 時這份檔案永遠在 model 的 context 裡。它做兩件事：

關鍵在於：每次 run 的 execution plan 會被寫回 repo 變成 implementation history；design doc 從投影片和 Slack 搬進 repo；docs 跟 code 一同變動——如果 docs 失同步，tests 會 fail，強迫 agent 邊改 code 邊更新文件。

Rin 補一句：這對 PM 是個很實際的暗示——你過去寫在 Notion、Figma 留言、Slack DM 的決策，在這個世界裡都不算數，因為 agent 搜不到。你的 decision artifact 必須住在 repo 裡。

Tests 與 Lints：把「品味」變成編譯錯誤

這段是我整篇最喜歡的部分。Ryan 說的原句是：

「沒有那種 please remember I beg of you 的段落。」

意思是不用在 prompt 裡苦苦哀求 agent「請記得用 curly quotes」。他們把品味直接編碼進 tests 與 lints：

這個邏輯有個非常乾淨的 punchline：

「Model 是被訓練來讓 tests pass 的。每一個 failure message 就是一道指令。你不再用 Slack 吵品味——the suite is the style guide。」

Aakash 在原文裡接了一句很 growth 味的話：「在 growth role 我學到的硬道理是——如果一件事重要，你就要 measure it and enforce it。」這個 framing 在這裡點石成金——把 growth 的『可量化、可強制』原則，用到 code/docs 上。

▼ 圖：傳統 prompt 寫法 vs harness 編碼品味

傳統 prompt 寫法 vs harness 編碼品味

Mermaid 原始碼 
graph TD
    A[傳統作法<br>Slack 吵品味<br>+ 拜託 prompt 記得]:::cream --> X[Agent 可能忽略<br>下次又犯]:::coral
    B[Harness 作法<br>把品味寫成 test/lint]:::teal --> Y[Build fail<br>= agent 必修]:::teal

    classDef cream fill:#F4F0E4,stroke:#537D96,color:#333
    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff

Review Agents：當 staff engineer 變成 persona doc

CI 階段，他們會跑一個 matrixed job，把不同專業的 review agent 拉起來——每個 review agent 由一份 persona doc 定義：

review 結果回灌進 loop：實作 agent 用它修當下這個 change，團隊則順手更新 docs 或 tests，讓「這一類錯」下次不會再回來。

這裡藏著一個很 underrated 的洞察：單一錯誤被修不是終點，corpus 變強才是。每次 review 都讓 harness 多吸收一點 institutional knowledge——這是 Ryan 後面講「engineer 的價值是 leverage」的具體機制。

Observability + Computer Use：給 agent 一雙眼睛

最後，agent 需要能「看到」產品。

harness 讓 model 能在 local 起一個 observability stack（metrics、logs），像人一樣 debug。配上 GPT-5.5 的 computer use 能力，agent 可以點過整個 app、檢查 DOM、跑 end-to-end 流程。

規則只有一條：agent 必須用 user 走的路徑證明 feature 真的能動。

對 PM 來說，這句話的含義很赤裸——你的 acceptance criteria 必須長到 agent 用 computer use 跑得起來的形狀，不能再寫「用戶應該感覺良好」這種抽象目標。

2. Frontier Team 的極端實驗：1M lines of code，沒有人類打字

2025 年中，Ryan 的團隊跑了一個瘋狂實驗，回答這個問題：

Codex 能不能獨自完成一個新內部 agent 產品的全部 SE 工作？

實驗約束（記下這四條，這是整個案例的肌理）：

  1. 從空 repo 開始
  2. 蓋一個支援 OpenAI 內部「非工程 knowledge work」的 app
  3. agent 處理 on-call triage、internal tools、text-heavy workflow
  4. 沒有任何人能 type production code——engineer 只能改 harness

結果？

最關鍵的 working pattern：

「任何時候 agent 失敗，團隊不是跳進去手改 code，而是問：harness 缺了什麼，導致這個 failure？」

Codebase 改善的方式，不是工程師重寫，而是人類改善環境。

這個 working loop 本身就是答案——它示範了「不允許自己跳下去 code」是怎麼把人逼成 system designer 的。對台灣團隊有點啟發：很多時候 PoC 卡住，不是 model 不夠強，而是團隊太容易「我自己手改一下就好了」，於是 harness 永遠長不大。

▼ 圖：Frontier Team 的失敗處理迴圈

Frontier Team 的失敗處理迴圈

Mermaid 原始碼 
graph TD
    A[Agent 嘗試實作]:::teal --> B{成功?}:::cream
    B -->|是| C[Ship]:::teal
    B -->|否| D[問: harness 缺什麼?]:::coral
    D --> E[改 docs / tests / lints / review rules]:::steel
    E --> A

    classDef cream fill:#F4F0E4,stroke:#537D96,color:#333
    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef steel fill:#537D96,stroke:#3A5A6E,color:#fff
    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff

3. 三個角色的新工作描述

這是整篇最有 inspiration 的一段——它不是抽象呼籲，而是給 PM / Designer / Engineer 各一張具體的職務說明書。

PM 的新角色：讓 harness 看得懂的人

過去十年的 PM 是「客戶與工程之間的 human API」——寫 PRD、在 sprint planning 吵架、等待 typing 完成。typing 是別人的事。

Ryan 描述的 PM 不是這樣。

案例：2025 年末 Skills System

團隊想做一套 skills system，讓 agent 能學習並重用使用者在 data analysis 的偏好。在大多數公司，這會啟動一連串 product review、engineering estimate……

Ryan 團隊做了什麼？

  1. PM 寫一份 markdown PRD，定義 skills library：
    • agent 應該怎麼跟用戶 interview metrics
    • 怎麼儲存與重用這份 knowledge
    • 在產品介面如何呈現
  2. 團隊在 weekly meeting review 這份 PRD 一次
  3. 那個禮拜結束前，feature 上了，PM 「vibe 出來」的 tests 全部 pass

這之所以可行，是因為 business logic 已經 embedded 在有 high-fidelity fakes 的 modules 裡，而 PM 寫的 test 從產品端 exercise 了 behavior。

留給 PM 的兩個 audit question（請把它當作 muscle 來練）：

  1. 你下一個 feature，能不能寫成 PRD + tests + evals 這種 agent 能自己 run 起來的形狀？
  2. 如果你完全不能碰 IDE，你會怎麼改寫你的 spec？

我特別欣賞第二個問題——它是一個強制性的思想實驗。當你假設自己無法 typing，你才會發現自己過去多依賴「私下找工程師講一下就好」的灰色地帶。

Designer：Painted Door + Instrumentation

這段藏在原文中的故事很經典。

故事：早期一個 designer 想出某個 feature 的 demo，需要在 internal app 裡 schedule agent 跑。為了快速做出來，他把一個 backend-style cron 系統推到 frontend 去——scheduler 邏輯整個糊在 frontend JS 裡。

Ryan 看了一眼，知道團隊以後會後悔，直接 revert 了這個 change，然後立了一條 norm：

  • Designer 擁有 app 最前面的「painted-door 完整流程」——UI、互動模式、scheduling 怎麼呈現。
  • 門後面，backend 可以是一個 no-op + 埋點。先量點擊、量意圖、量 drop-off，再決定要不要投入工程資源。
  • Harness 根據 data，決定哪些 door 值得有 backend。

Designer 的 JD 因此變成：用高品味、高訊號的介面，給 harness 一個「最有可能值得蓋」的訊號。

這個 framing 對台灣的設計師有點刺：我們常常在 production code 上做 polish，但更高槓桿的能力或許是——做出 5 扇 painted door，讓系統幫你決定該開哪一扇。

Engineer：從 coding engineer 變成 harness engineer

這段對工程師可能最難受，但也最重要。Ryan 直接點明：

「Coding engineer 變成 harness engineer。你的價值是你為其他所有人創造的 leverage。」

他用了一個內部心智模型：

「想像你剛雇了一群叫做 Codex 的 intern。你的工作是 manage 他們。」

工程師的主要產出不是 commit，而是讓 N 個 concurrent agent 能同時工作的：tests、docs、CI rules、observability。

Ryan 也很誠實地說——這在情緒上很難。很多工程師（包含他自己）十幾年來都是用 commit 數和 LOC 衡量自己的貢獻。讓 model 來 typing，感覺像失去 craft。

但他的論點是——craft 移位了：

「現在的新技能是：誰能蓋出一套 harness，讓 GPT-5 成為這個產品、這家公司的強隊友？」

最後那句話我覺得很值得抄起來：

「Every engineer on the planet now has hundreds or thousands of concurrent hands on keyboards, modulo token budget.」

（地球上每位工程師，現在都有上百上千雙併發的手在鍵盤上——只看你 token 預算多大。）

▼ 圖：三個角色的新槓桿來源

三個角色的新槓桿來源

Mermaid 原始碼 
graph TD
    PM[PM]:::teal --> PMo[PRD + tests + evals<br>→ agent 能自己跑]:::cream
    DS[Designer]:::steel --> DSo[Painted door + 埋點<br>→ 給 harness 決策訊號]:::cream
    EN[Engineer]:::coral --> ENo[Tests/docs/CI/<br>observability<br>→ 讓 N 個 agent 並行]:::cream

    classDef cream fill:#F4F0E4,stroke:#537D96,color:#333
    classDef teal fill:#44A194,stroke:#2D7A6E,color:#fff
    classDef steel fill:#537D96,stroke:#3A5A6E,color:#fff
    classDef coral fill:#EC8F8D,stroke:#D4696A,color:#fff

4. 為什麼這對你很重要

Aakash 在文末拋了一個很乾淨的對比：

多數團隊用 AI 加速「function-level coding」，但 SDLC 其他環節保持不動。Ryan 描述的世界，是當你把整個系統圍繞「能做完整工作的 agent」重新設計——差別在於：你的團隊判斷力，有多少 embedded 在 harness 裡？

對應到三類讀者：

Rin 的觀點

讀完這篇我有兩個強烈感受。

第一個是「規則庫越老越值錢」的反直覺。

過去軟體業最受推崇的是「greenfield 從零打造」的工程師——能在白紙上畫出新世界的人。但 Ryan 的世界裡，最有價值的反而是 能把過去團隊踩過的坑、累積的品味、講不清楚的設計直覺，全部編碼進 harness 的人。

每一個 review agent 抓到的問題，都會反過來變成 docs/tests/lints 的更新——這意味著 harness 像一個有複利的資產，它越老越聰明。長期下來，公司的競爭力會藏在 harness 的厚度裡。在台灣，做了 5 年、10 年的成熟產品團隊，其實有機會用這個論述把「我們的歷史包袱」翻譯成「我們的 harness 資產」——前提是你願意把那些口耳相傳的品味，逐條編碼下來。

第二個是 PM「下一個 feature 不能碰 IDE」這個 thought experiment 很強。

它直接戳穿了一個我自己也常掉進去的陷阱：PM 寫 PRD 時其實留了很多 ambiguity，預設「跟工程師對齊一下就好」。但只要你想像「沒有人會幫我對齊」，PRD 就會被迫變得更具體、acceptance criteria 會更可驗證、edge case 會被逼出來寫清楚。

這不只是 AI 時代的技能——這根本就是 PM 該有的基本素養，只是被 AI 重新放大了它的重要性而已。

如果你是 PM，這週我會建議你做一個小實驗：挑你手上一個正在寫的 PRD，加上一個 「假設沒有人類能幫我寫 code」的限制，重寫一次。看看你會發現什麼。

原文中提到但本文未深入展開的話題

議題原文內容摘要
Six-month harness 計畫 one-pagerAakash 把 Ryan 的 6 個月 harness build-out 計畫做成 downloadable checklist（付費訂閱內容）
Aakash 的 AI tool stackDovetail、Arize、Linear、Descript、Reforge Build、Relay.app、Magic Patterns、Speechify、Bolt.new、Mobbin
其他 AI PM 相關集數Aparna Dhinakaran 談 Claude Code evals、Gabor Mayer 談 Full AI Dev Team、Dave Killeen 用 Claude Code 跑整個工作流
贊助商產品Product Faculty AI PM 證照、Bolt、Customer.io、Ariso、Pendo

相關筆記