Strive-Wang

By

王柏升

·

從 OpenAI Codex 的 5,367 個 commits 看 AI 時代的軟體開發工作流（一）：寫得快，真的有轉化成有效建設嗎？

文章探討了AI在軟體開發中的應用，強調快速寫程式碼是否能轉化為有效的建設。Codex團隊的實驗顯示，雖然程式碼…

AI 寫 code 變快，這件事大家都同意。但我最近一直在想另一個問題——寫得快，真的有轉化成有效建設嗎？

一位工程師與機器人合作，在充滿程式碼的環境中，強調AI的速度與效率，並提及技術負擔和工作流的挑戰。

我說的有效建設是：可維護的程式碼、能持續迭代的系統、不會在三個月後變成技術債的東西。不是 demo、不是 prototype、不是「我用 AI 一晚上做了個 X」這種一次性的東西。

這個問題其實沒人能簡單回答。但如果有一個團隊真的在用 AI 大量寫 production code，把他們的工作流攤開來看，至少能看到一個樣本——「有效的 AI 開發」實際上長什麼樣。

OpenAI 最近發了一篇 Harness engineering，講三人團隊用 Codex 從零寫了百萬行程式碼，完全沒人手寫。讀起來很驚艷，但那是實驗室——我們很難從一篇文章判斷這百萬行的「有效性」如何。我想看的是 production：那些每天用 AI 寫 code、產品已經上線、被真實用戶使用的團隊，工作流長什麼樣。

剛好 codex 這個 repo 是公開的（github.com/openai/codex）。做 Codex 這個產品的團隊，自己當然也用 Codex 寫 code。這個 repo 等於是「用 AI 開發 AI 工具、並且真的上線運作」的真實樣本。

從 2025-04-16 到 2026-04-14，321 天、5,367 個 commits。我把整個歷史拆開分析。

結論先說：他們的速度確實很快——但更值得注意的是，他們的「工作流紀律」比一般傳統團隊還要嚴格。他們的快不是放任出來的，是紀律建立出來的。

觀察一：他們合得勤到嚇人

工作日每天合進 main 的 PR 數量：

  • 中位數：19 個
  • IQR（中間 50%）：9 到 29 個
  • P90:40 個

換句話說，平均每 25 分鐘就有一個 PR 進 main。

這個頻率對應 DORA（DevOps Research and Assessment）定義的 Elite 團隊標準。但 19 PR/天還是震撼，超過絕大多數傳統團隊。

如果只看這個數字，會覺得「啊果然 AI 加速了」。但下一個觀察告訴我們，故事不是這麼簡單。

觀察二：但每個 PR 都很小

我從 5,367 個 commits 中均勻抽樣 196 個來看每個 PR 的修改規模：

  • 修改檔案中位數：5 個
  • 新增行數中位數：118 行
  • 淨變更中位數：65 行

90% 的 PR 都在 19 個檔案、920 行新增以內。

這個數字逼近 Google 內部對 changelist 大小的建議下限。換句話說，他們的 PR 比一般傳統團隊還小。

這跟「AI 寫得快所以 PR 會塞更多」的直覺完全相反。為什麼？

為什麼是拆小，不是塞大？

這個對比揭示了一個關鍵的事——AI 改變的不是「打字速度」，而是「工作流瓶頸的位置」。

傳統開發：

寫 code（慢）→ review（快）→ merge

打字是瓶頸，所以一個 PR 攢比較大，值得開一次 review。

AI 加入後：

寫 code（快）→ review（沒變快）→ merge

瓶頸從「寫」轉移到「review」。Reviewer 的認知頻寬沒變——還是只能一次理解 200 行的邏輯——但你的產出多了好幾倍。

如果還用舊模式開大 PR，reviewer 變成新瓶頸，team velocity 不會更快反而會塞車。更糟的是，沒被仔細 review 的 AI 程式碼會直接變成技術債——三個月後沒人記得它在幹嘛、為什麼這樣寫。這就是「寫得快但沒有轉化成有效建設」的典型場景。

Codex 團隊的解法是：拆得更細，但合得更勤。每個 review 都在 reviewer 的認知預算內，靠頻率把總吞吐量拉上去。

這不是工程師寫得多努力。是工作流被 AI 重新校準過。

一張關於AI如何改變程式開發流程的資訊圖，顯示傳統開發與AI介入後的步驟對比，包括程式碼撰寫、審查及合併的過程，並提到提高效率和改進review的方式。

觀察三：99.8% 的 commit 都來自 PR

順手檢查了一件事——這 5,367 個 commits 裡有多少是從 PR squash merge 來的？

答案是 5,355 個，99.8%。

剩下 12 個是什麼？兩個 Initial commit、一個叫 w 的東西、幾個早期測試。換句話說，自從這個 repo 認真營運之後，main 上沒有一個 commit 不是來自 PR。

這件事對 AI 時代特別關鍵：AI 寫的 code 沒有特權通道。Codex 自己生出來的 PR、人類寫的 PR、AI 輔助寫的 PR——走完全相同的流程。Branch protection、required CI、code review、squash merge，一個都不能少。沒有「這是 AI 寫的，先放一馬」這回事。

當 AI 變成 PR 的主要產出來源，「先放一馬」是非常誘人的。畢竟 AI 寫了那麼多東西，逐一 review 很慢。但 Codex 團隊的選擇相反——正因為 AI 產出多，每一個 PR 才更需要被嚴格驗證。否則你不是在「用 AI 加速建設」，你是在「用 AI 加速累積債務」。

三個觀察拼起來告訴我什麼

把這三個觀察放在一起看，「有效的 AI 工作流」長相開始浮現：

維度傳統AI 加入後（Codex repo）
寫 code 速度慢（瓶頸）快
一個 PR 大小中-大變小（中位數 5 檔/118 行）
合 PR 頻率一天幾次變高（中位數 19/天）
Review 流程必要但有彈性更必要、更剛性
Main 守紀鬆緊看團隊必須極嚴（99.8% 線性）

換句話說，AI 沒有讓工作流變寬鬆，反而讓它變得更嚴格、更小步、更頻繁。

這反直覺，但仔細想又合理：當「寫 code」這個瓶頸消失，原本被它遮蔽的其他瓶頸（review、紀律、流程）就暴露出來。如果不正視這些新瓶頸，AI 的速度會讓技術債累積得比建設還快。

回到開頭的問題——「寫得快真的有轉化成有效建設嗎？」

從 codex 這個 repo 看到的答案是：不會自動轉化。需要一套配得上速度的紀律：拆得更小、合得更勤、流程更嚴。否則 AI 加速的不是建設，是技術債。

這只是表面

這篇講的還是「速度 + 大小 + 紀律」這種表面數字。從 git 歷史再往下挖，我發現幾個更有意思的東西：

  • 他們的版本號其實不在 main 上（main 永遠是 0.0.0）
  • 大型重構是用「絞殺者模式」分階段推，跨好幾個月
  • 有一份叫 AGENTS.md 的檔案，同時給人類和 AI 讀的規範文件——這個概念以前不存在
  • Issue triage 是寫死在 prompt 裡的決策樹，由 AI 自動跑

這些東西組合起來，不只是「AI 輔助開發」，而是一種 AI 原生工作流——AI 不是工具，是工作流的一等公民。

接下來幾篇會一個個拆開講「有效建設」這個主題的不同面向。下一篇先講一個技術細節：為什麼 OpenAI Codex 的 main 分支版本永遠是 0.0.0？

Tags:

, ,

發表留言