前 Meta LLaMA 團隊工程師 Peter Pang 在 2026 年 4 月發布了一份 3,500 字的實戰報告，用 CREAO 這家 25 人新創的真實數據，把「AI-First」從口號拆解成可複製的工程方法論。 核心數字：99% 的生產程式碼由 AI 撰寫，14 天內從零建立每天 3-8 次生產部署的節奏，部署頻率翻了十幾倍，用戶轉化率反而上升。這套方法沒用任何黑科技，全部工具開源，所有流程公開。
他的結論直接挑戰了目前業界主流做法：在既有流程上疊加 Copilot 之類的 AI 輔助工具，效率提升的天花板大概就是 10-20%。結構沒變，瓶頸就沒變。
AI 寫程式從來不是瓶頸
Pang 在文章裡提出了一個違反多數人直覺的觀察：AI 產出程式碼的速度從來不是效率瓶頸，上下游的人工流程才是。
他給了三組具體數據來說明這件事：
| 流程環節 | 人工耗時 | AI 耗時 |
|---|---|---|
| PM 撰寫詳細需求規格 | 約 2 週 | — |
| AI 撰寫對應功能程式碼 | — | 約 2 小時 |
| QA 完成一輪測試 | 約 3 天 | AI 部署只需 2 小時 |
問題很清楚：即使 AI 寫程式碼只要兩小時，只要有任何一個環節是人在拖，整體效率就受限於人的速度。PM 花兩週寫需求，QA 花三天測試，AI 那兩小時的速度優勢就被完全吃掉了。
CREAO 是一個 agent 平台公司，25 名員工裡有 10 名工程師。2025 年 11 月開始打造 agent 產品，兩個月前 Pang 從底層重新架構了整個產品和工程流程。他的背景是物理學博士，在 Meta 擔任 GenAI 技術主管時參與了 LLaMA 的規模化工作，之前待過 Apple AI 部門。
駕馭工程（Harness Engineering）：讓 AI 能獨立、安全、可靠地工作
Pang 沒有給工程師配更多 Copilot。他把全部精力投入一件事：建一整套讓 AI 能獨立作業的基礎設施。他稱之為「駕馭系統」（harness），這個概念在 2026 年 2 月被 OpenAI 正式命名。
OpenAI 在 2026 年 2 月 11 日發表了一篇技術報告，描述他們內部一個團隊如何在五個月內用 Codex agent 從空白 repository 建出超過 100 萬行程式碼，零手寫程式碼，速度大約是人工開發的 10 倍。OpenAI 的工程師 Ryan Lopopolo 在報告中指出，工程師的工作已經從寫程式碼轉變為「設計環境、表達意圖、建立回饋迴路」。
HashiCorp 共同創辦人 Mitchell Hashimoto 在 2026 年 2 月 5 日的部落格文章裡率先使用了「harness engineering」這個詞——概念是：每次 agent 犯錯，就設計一個機制讓它不再犯同樣的錯。
Pang 的做法跟 OpenAI 的報告方向一致，但他是在中小型團隊的場景下實踐的。以下是他建的駕馭系統架構：
統一 Monorepo
原本 CREAO 的程式碼分散在多個獨立系統裡，改一個功能可能要動三四個 repository。對人類工程師來說還能處理，對 AI agent 來說完全不透明——agent 看不到全貌，沒辦法推理跨服務的影響，也無法在本地跑整合測試。Pang 花了一週設計新架構，再花一週用 agent 重新架構整個程式碼庫，統一到單一 monorepo。目的只有一個：讓 AI 能看到所有程式碼。
全鏈路結構化可觀測
CloudWatch 是整套系統的中樞神經。所有服務都輸出結構化、可查詢的日誌，設了超過 25 個告警，自訂指標每天由自動化工作流查詢。如果 AI 讀不到日誌，就沒辦法診斷問題。
Claude 三階段 AI 程式碼審查
取代人工 code review，改用三輪 AI 審查：第一輪看程式碼品質（邏輯錯誤、效能、可維護性），第二輪掃安全性（漏洞、認證邊界、注入風險），第三輪查依賴套件（供應鏈風險、版本衝突、授權問題）。這三輪是審查閘門，不是建議。
六階段確定性 CI/CD
每個 pull request 必須通過六道關卡：型別檢查、linting、單元測試和整合測試、Docker 構建、Playwright 端對端測試、環境一致性檢查。沒有可選步驟，沒有人工覆寫。管線是確定性的，agent 可以預測結果和推理失敗原因。
Statsig Feature Flags + Kill Switch
功能上線後透過 Statsig feature flags 控制流量，配合一鍵 kill switch。出了問題，當天就能發現並回滾。Pang 文中提到的案例：某個功能上午 10 點上線，中午做完 A/B 測試，下午 3 點因為數據不好直接砍掉，下午 5 點上了改良版。三個月前，同樣的循環要六週。
自癒引擎
每天自動聚類生產環境的錯誤，自動建工單。能修復的問題自己解決，不需要人介入。
14 天的結果
用了 14 天把這套駕馭系統建完之後，CREAO 達到以下成果：
| 指標 | 數值 |
|---|---|
| 每日生產部署次數 | 3–8 次 |
| 程式碼 AI 產出比例 | 99% |
| 壞功能發現與回滾 | 當天 |
| 部署頻率變化 | 翻了十幾倍 |
| 用戶指標與轉化率 | 上升 |
| 團隊規模 | 25 人（10 名工程師） |
| 競爭對手團隊規模 | 100 倍以上 |
Pang 強調一個反常識的現象：部署頻率大幅增加的同時，用戶指標和轉化率反而上升了。這跟傳統認知裡「部署越快風險越高」的假設相反。原因在於 feature flag + 即時 A/B 測試 + kill switch 形成的安全網：快速部署不等於魯莽部署，每個功能都經過數據驗證才決定保留或撤回。
組織重構：工程師只剩兩種角色
這套系統上線後，CREAO 的組織分工被徹底改寫。不再有天天寫 CRUD 的工程師，人類只剩兩種角色：
架構師（一到兩人）：設計 SOP 和標準作業流程，教 AI 怎麼工作。建測試基礎設施、整合系統、分類系統。決定架構和系統邊界。定義什麼算「好」。更關鍵的是，他們批判 AI 的產出。當 agent 提出一個方案，架構師找漏洞：遺漏了哪些失敗模式？跨越了哪些安全邊界？累積了多少技術債？
Pang 說他的物理學博士對他最有用的訓練就是「質疑假設、壓力測試論證、找出遺漏」。批判 AI 的能力，比寫程式碼的能力更值錢。
驗證者（其他所有人）：負責判斷風險和品質。
他觀察到一個痛苦的現象：擁有深厚傳統技術功底的資深工程師，反而是轉型最困難的一群人。他們花兩個月才能完成的工作，AI 一小時就做完了。多年磨練的稀缺技能在新體系裡價值快速縮水，要接受這件事很難。Pang 沒有做道德判斷，只是描述他觀察到的事實：在這場轉型裡，適應力比累積的技術功力更重要。
不只是工程部門
Pang 的文章指出，如果只有工程部門用 agent 速度運作，而行銷、產品、客戶支持還是用人的速度，那人速的部門就會拖慢所有人。
CREAO 已經把 AI-native 工作流延伸到全公司：
- 社群媒體每日貼文：AI 編排並自動發布
- 健康報告和數據分析摘要：AI 從 CloudWatch 和生產資料庫自動產出
- 工程、產品、行銷、成長，全部跑在同一套 AI-native 工作流上
Pang 本人的時間分配變化可能是最直觀的指標：兩個月前，他有 60% 的時間花在管理人——對齊優先順序、開會、給回饋、指導工程師。現在這個數字降到 10% 以下。傳統 CTO 的做法是授權團隊做架構工作、訓練他們、委派任務。但如果系統只需要一兩個架構師，那他得自己先做。他從管理者變回了建造者，每天從早上 9 點寫到凌晨 3 點。
這對你意味什麼
Pang 給 19 歲的實習生的建議是：訓練批判性思維。學會評估論證、找漏洞、質疑假設。學什麼是好的設計。這些技能會隨時間複利成長。
他也明確說了：寫程式碼的速度每個月都在貶值。評估、批判、引導 AI 的能力每個月都在升值。產品品味變得重要。你能不能看一眼 AI 生成的 UI，在用戶告訴你之前就知道哪裡不對？你能不能看一個架構提案，找到 agent 遺漏的失敗模式？
他的最後一個建議很實際：如果你的 PM 流程比構建時間還長，從那裡開始改。在擴大 agent 之前，先把測試駕馭系統建好。
CREAO 的 AI-First 做法跟 Google、Microsoft 的 Copilot 模式有什麼不同？
Google 和 Microsoft 的 Copilot 模式是在現有開發流程上疊加 AI 輔助，幫工程師寫程式碼更快。Pang 認為這最多帶來 10-20% 的效率提升，因為結構沒變。CREAO 的做法是假設 AI 才是主要的程式碼構建者，然後把工程架構、CI/CD、測試流程、組織分工全部推倒重來。兩者的差別在底層假設：前者假設人寫程式、AI 輔助，後者假設 AI 寫程式、人批判。
什麼是駕馭工程（Harness Engineering）？
駕馭工程是 2026 年 2 月由 HashiCorp 共同創辦人 Mitchell Hashimoto 命名、OpenAI 在技術報告中系統化的概念。指的是設計讓 AI agent 能可靠工作的整套環境：約束條件、回饋迴路、文件、linter、生命週期管理。OpenAI 內部團隊用這套方法在五個月內從空白 repository 建出 100 萬行程式碼，速度大約是人工開發的 10 倍。核心觀念是：模型本身不是瓶頸，模型周圍的系統才決定 agent 能不能在生產環境可靠運作。
小團隊真的能用這套方法跟大廠競爭嗎？
CREAO 的案例顯示是可以的，但有前提。Pang 自己說競爭對手的人力是他們的 100 倍以上，他們靠的是重新設計流程而非增加人力。前提條件包括：願意統一到 monorepo、投入建設完整的 CI/CD 和可觀測基礎設施、接受組織分工被徹底改變。Pang 也坦承，轉型成本是真實的——員工焦慮、資深工程師抵觸、連續幾個月每天工作 18 小時。多數公司不願意承擔這些成本。
AI 產出 99% 的程式碼，品質怎麼保證？
CREAO 用的是多層駕馭系統：三階段 AI 程式碼審查（品質、安全、依賴），六階段確定性 CI/CD（每個 PR 必須全過），Statsig feature flag 控制上線流量，一鍵 kill switch 即時回滾，加上自癒引擎每天自動聚類錯誤和修復。品質保證的邏輯不是「寫得好就不用測」，而是「用確定性管線和即時回饋讓每一次部署都可驗證、可回滾」。
CTO 的角色在 AI-First 組織裡怎麼變？
Pang 的經驗是從管理者變回建造者。傳統 CTO 花大量時間在對齊優先順序、開會、指導團隊。AI-First 組織裡如果只需要一兩個架構師，CTO 需要自己做架構工作——設計 SOP、維護駕馭系統、寫程式碼。Pang 自己每天從早上 9 點工作到凌晨 3 點。管理時間從 60% 降到 10% 以下，但壓力更大。他說他反而更享受，因為在建東西而不是在對齊。
引用來源
- OpenAI — Harness engineering: leveraging Codex in an agent-first world
- Martin Fowler — Harness engineering for coding agent users
- InfoQ — OpenAI Introduces Harness Engineering: Codex Agents Power Large-Scale Software Development
Author Insight
我們團隊在協助客戶導入 Claude Code 和 Vibe Coding 工作流的過程中，觀察到 Pang 指出的同樣瓶頸。多數企業的問題不在 AI 寫程式碼的能力不夠，而在 AI 周圍的基礎設施沒跟上——CI/CD 管線沒辦法支撐高頻部署，可觀測性不足以讓 agent 自行定位錯誤，code review 流程還停在純人工階段。我們替幾家製造業和金融業客戶設計的做法是先從內容工程（Context Engineering）切入，把 CLAUDE.md 和專案規範文件標準化，然後逐步建立 CI/CD 護欄和自動化測試覆蓋率。完全推倒重來不是每家公司都承受得起，但從「讓 agent 能讀懂你的程式碼庫」這個起點開始，六到八週內就能看到明確的效率改善。Pang 這篇報告最值得帶走的觀念是：AI 效率的瓶頸在人的流程，不在模型的能力。先從最慢的人工環節下手，投資報酬率最高。
如果你的團隊正在評估 AI 開發流程轉型，或是想了解怎麼在現有架構上逐步建立駕馭工程基礎設施，歡迎跟 Tenten 團隊預約諮詢。
