Build Hour：API 與 Codex（第 2/5 段）

🧑‍🏫 這段是 OpenAI 的 Build Hour 直播，示範 Codex app 怎麼同時開好幾份工作、設排程自動做事，還現場做了一個工具，替程式專案評「AI 好不好接手」。後半段分享一個約一百萬行、全部由 Codex 寫成的內部產品。重點是人的角色從「自己寫」變成「定規則、設環境、做判斷」。

• 12:11 worktree 讓你在另一個資料夾工作，不干擾其他分支的變更；用好幾個螢幕、十幾個 tmux 分頁的人，就是用 worktree 做平行工作
  ↳ worktree 會把同一個專案再開一個資料夾，各自在不同分支（branch，一條獨立的修改線）上改，互不干擾。tmux 能在終端機開很多分頁，同時開十幾頁的人就是靠 worktree 平行做事。
• 12:11 講者認為，讓 codebase 能搭配 worktree 運作，是走向高層次工程思考的一步，也讓同時處理多份程式碼變得便宜許多
  ↳ codebase 指整個專案的程式碼。專案如果能同時在好幾個 worktree 裡跑，人就從一行行自己寫，變成同時派好幾件事出去再挑結果，而且多開一份幾乎不花成本。
• 12:11 Codex app 有 push 功能：在 worktree 裡點一下就能把變更推到本機分支，也能點一下送回 worktree
  ↳ push 是把修改推送到別的地方。Codex 在 worktree 改完後，一鍵就能把結果搬回你電腦上的分支；還要再改，也能一鍵送回 worktree，不用自己打 git 指令。
• 12:41 Codex app 內建完善的 git 支援，可直接在 app 裡 commit 與 push，也能用你慣用的 IDE 開啟檔案
  ↳ git 是記錄程式每次修改的版本管理工具，commit 是存一個版本點。這些都能在 app 裡直接按。想自己細看時，也能用慣用的 IDE（寫程式的編輯軟體）打開檔案。
• 12:41 app 內建工具包含 terminal（看執行狀況）與 diff panel（看變更內容）
  ↳ terminal 是打指令、看程式跑出什麼訊息的視窗。diff panel 會把改前改後標色對照，一眼就看出 Codex 動了哪裡，不用自己逐行比對。
• 13:11 這段對話的短短幾分鐘內，已寫出 8,200 行程式碼
  ↳ 講者只聊了幾分鐘，Codex 就在背景寫完 8,200 行。重點不在行數，而在人不用一直盯著，工作照樣在跑。
• 13:11 左側有 skills 與 apps；講者喜歡開箱即用的 skills，也可以自行安裝 apps
  ↳ skills 是預先寫好的做事方法，Codex 需要時直接拿來用。apps 是串接外部服務的連接器，例如 Google Calendar，需要哪個就自己裝。
• 13:11 Google Calendar app 的啟示：可以用 Codex 自動化寫程式以外的工作；講者做了工具來管理行事曆和時間
  ↳ Codex 不只能寫程式。接上 Google Calendar 後，它可以幫你看行事曆、安排行程，講者就拿它來管理自己的時間。
• 13:41 講者認為自動化（automation）是 Codex app 最大的優勢：按固定排程執行指令，聽起來簡單，實際上很強大
  ↳ automation 就像設定固定時間的提醒：指定每天或每小時，讓 Codex 自動執行一段你寫好的指示。重複的檢查工作不用每次開口，就會一直有人在做。
• 14:11 自動化例子：讓 Codex 定期檢查所有開啟中的 PR，確認可以 merge、彼此不衝突；Codex 很擅長解決 merge conflict
  ↳ PR（pull request）是「我改好了，請併進主程式」的申請，merge 就是合併。好幾個人改到同一處會打架，這叫 merge conflict。可以讓 Codex 定時巡過所有 PR、把衝突處理掉。
• 14:41 另一位講者最常用的自動化是 Slack 管理：檢查工作流程、從 Slack 更新待辦清單
  ↳ 另一位講者主要用自動化管 Slack（工作用的聊天軟體）：定時看訊息裡的工作進度，把該做的事整理進待辦清單，不用自己一則則翻。
• 14:41 OpenAI 同事的用法：抓最新 PR 檢查潛在 bug，或看過去 24 小時的 Git 歷史，替今天的會議做摘要
  ↳ 同事有兩種用法：一是定時看最新的 PR，先抓出可能的 bug；二是讀過去 24 小時的 Git 修改紀錄寫成摘要，開會前就知道昨天大家改了什麼。
• 15:11 Codex 完成任務後自己跑了 linting、測試與 build，而且一次就做出要求的 app
  ↳ linting 是自動檢查程式寫法有沒有違規或可疑的地方，build 是把程式組成能執行的成品。Codex 交件前自己跑完這些檢查和測試，而且一次就做出要求的 app。
• 15:11 這個 app 的用法：輸入 GitHub repository 與自訂指示，它用 hosting shell 分析 repo，依 7 項「agentic clarity」指標評分
  ↳ repo 是一個專案的程式碼庫，GitHub 是存放 repo 的網站。貼上 repo 和指示後，app 會在雲端的指令環境讀專案，用 7 項「agentic clarity」指標，評它對 agent（會自己動手做事的 AI）夠不夠清楚。
• 15:41 拿上週開源的 Symfony repository（與安全工程主題一起釋出）來測，並指示模型只評估 elixir 資料夾
  ↳ 測試對象是上週開源的 Symphony 專案（字幕拼作 Symfony）。為了聚焦，他們要求模型只評 elixir 這個資料夾，其他部分不看。
• 16:11 現場示範出錯：缺少 OpenAI 模型設定，需要補上環境變數後重跑
  ↳ 現場跑失敗了，原因是沒告訴程式要用哪個 OpenAI 模型。環境變數是放在電腦環境裡、讓程式讀取的設定值，補上後重跑就好。
• 16:41 講者稱讚 agent 傾向可設定化（configurability），很有「12-factor app」的風格
  ↳ configurability 指把會變動的東西做成可調整的設定，而不是寫死在程式裡。12-factor app 是業界常見的一套軟體設計原則，其中一條就是設定要跟程式分開。講者覺得 agent 寫程式自然有這種習慣。
• 17:11 Symphony（字幕也拼作 Symfony）的出發點：只要 Codex 周圍護欄夠多，它就能穩定產出人類工程師與 agent reviewer 都會接受的程式碼
  ↳ Symphony 的前提是：只要給 Codex 夠多護欄（測試、規則、審查這類限制），它就能穩定寫出人類工程師和 agent reviewer（負責審程式的 AI）都會放行的程式。
• 17:11 Symphony 的做法：把人類從 terminal 流程中移除，改成在 Linear 定義任務；Symphony 是 orchestrator，推動工作在 ticket 佇列中前進
  ↳ 人不再坐在終端機前下指令，而是在 Linear（專案任務管理工具）開工作單（ticket）。Symphony 擔任 orchestrator，也就是總調度，把一張張單子往前推進。
• 17:42 Symphony 讓 Codex 在 worktree 部署程式碼、送審、與 CI 及 agent code reviewer 互動，前面的限制都滿足後才找人介入
  ↳ CI 是程式一送出就自動跑測試和檢查的流程。Symphony 讓 Codex 在 worktree 改程式、送審，並回應 CI 和 AI 審查員的意見，這些全部過關後才請人來看。
• 17:42 人因此能專注在難的事：排定工作優先順序、審查，確保工作為產品帶來價值
  ↳ 省下來的時間，人拿去做機器不擅長的事：決定先做哪件、最後把關，並判斷這些修改對產品到底有沒有價值。
• 18:12 人只要對現成的 PR 說 yes 或 no，Symphony 就會幫忙 merge
  ↳ 送到人手上的已經是整理好的 PR，人只要決定要或不要，合併的動作由 Symphony 處理。
• 18:12 評分結果：Symfony repo 在「agent readability」拿到 B
  ↳ 評分結果出來，Symphony 在 agent readability（agent 讀不讀得懂、好不好接手）拿到 B，表示還有改進空間。
• 18:12 指標一：部署自主性——能否從零架好 repo？需不需要外部知識或額外指令才能運作？
  ↳ 指標一是部署自主性：agent 能不能從零把專案架起來跑。如果要靠某個人腦中的知識或額外交代才跑得起來，agent 就會卡住。
• 18:45 指標二：任務進入點——agent 能否輕鬆執行 make、build、lint 等指令
  ↳ 指標二是任務進入點：常用動作有沒有清楚的入口。make 是把常用指令打包成一句的工具，build、lint 打一句就能跑，agent 就不用猜該怎麼做。
• 18:45 指標三：驗證工具——能否輕鬆驗證 agent 做的變更；無法衡量結果，就很難判斷工作是否完成
  ↳ 指標三是驗證工具：有沒有測試之類的方法確認改得對不對。結果量不出來，agent 和人都很難判斷工作到底完成了沒。
• 18:45 指標四：linting 與格式化——這次有找到 linter，但對模型來說，linter 在哪、怎麼用可能不夠明顯
  ↳ 指標四看 linting。linter 就是做 linting 的檢查工具。這個專案其實有，但放在哪、怎麼用沒寫清楚，模型可能找不到或不會用。
• 19:16 linting 可能是最簡單又最有效的改善方式：模型能以極低成本自我檢查；新增規則就能輕鬆提升 codebase 效率，Codex 很擅長做這件事
  ↳ 改善 linting 最划算：模型跑一次檢查幾乎不花成本，就能自己抓錯。想規範什麼，加一條規則就好，而寫規則這件事 Codex 也很拿手。
• 19:16 其他指標：有沒有給 agent 用的地圖，讓它知道東西在哪；文件是否結構化，附錄是否有決策紀錄
  ↳ 其他指標包括：有沒有一份給 agent 的「地圖」，說明東西放在哪；文件有沒有條理；附錄有沒有記錄當初為什麼這樣決定，讓 agent 知道來龍去脈。
• 19:46 畫面上可看到 container、host shell 在背景執行的 log
  ↳ container 是一個隔離的小型執行環境，host shell 是在裡面跑指令的介面，log 是執行紀錄。畫面上可以看到這些在背景一步步執行。
• 20:16 實作上是把請求送到 Response API，指定模型與 skill ID；skill 裡含有指標相關的所有知識
  ↳ 技術上，app 把請求送到 Response API（呼叫 OpenAI 模型的介面），並指定模型和 skill ID（某個 skill 的編號）。評分指標的相關知識都寫在那個 skill 裡。
• 20:16 團隊很重視安全：不能直接開放完整網路存取，而是指定 shell 可連線的網域白名單
  ↳ 團隊很重視安全，不讓 shell 想連哪就連哪，而是列一份 whitelist（白名單），只准連指定的網域，其他一律擋掉。
• 20:16 講者喜歡 container API 抽象層次高，提供安全的預設值，讓 agent 有空間工作，同時守住必要的安全標準
  ↳ container API 是用來建立這種隔離環境的介面。抽象層次高，代表很多細節已經幫你處理好，預設值就是安全的。agent 有空間做事，也守得住安全標準。
• 20:46 講者認為 agent 本來就會照它的方式行事，我們要確保把它放在正確的環境裡
  ↳ agent 會照自己的方式做事，你很難一步步控制它。人該做的是把環境、權限和規則設好，讓它在對的範圍裡工作。
• 20:46 這個 app 是一次性、一口氣用 vibe coding 做出來的例子；更有趣的問題是如何把它擴展成更大的專案
  ↳ vibe coding 指憑感覺、一口氣叫 AI 把東西做出來。這個評分 app 就是這樣做的一次性作品。講者認為更值得想的，是專案變大後要怎麼延續。
• 21:16 講者介紹「control engineering」：團隊做了約五個月的專案，嚴格規定沒有人可以親手寫任何一行程式碼
  ↳ 講者介紹 control engineering：團隊做了約五個月的專案，嚴格規定沒有人可以親手寫任何一行程式，全部交給 Codex 寫。
• 21:50 成果是目前內部上線的產品，約一百萬行程式碼，100% 由 Codex 撰寫
  ↳ 成果是一個已經在內部上線的產品，約一百萬行程式碼，100% 由 Codex 撰寫。
• 21:50 工程師不能靠敲鍵盤推進工作，必須退一步從系統層面思考，如何讓 agent 團隊把事情做完
  ↳ 不能靠自己敲鍵盤推進進度，工程師的工作就變成設計整套系統：怎麼分工、怎麼檢查、怎麼立規則，讓一群 agent 自己把事做完。
• 21:50 agent 看世界和程式碼的方式與人類不同；團隊因此發展出一套模式來改善 coding agent 的產出，讓程式碼能反覆 merge
  ↳ agent 理解程式的方式跟人不一樣，人覺得理所當然的事它未必知道。團隊因此累積出一套做法，讓 agent 的產出穩定到可以一再合併。
• 22:21 面對「AI garbage」質疑：程式碼現在比以前便宜得多；講者認為「AI garbage」其實是「我不喜歡的程式碼」的行話
  ↳ 有人批評 AI 寫的都是垃圾。講者回應：程式碼現在便宜多了，說「AI garbage」，很多時候只是「我不喜歡這段程式」的另一種說法。
• 22:52 如果說得出不喜歡程式碼的哪裡，下一步就把它記進文件、專門的 review agent、測試或 linter
  ↳ 重點是把「不喜歡」講具體。說得出哪裡不好，就把它寫成規則，放進文件、專門審查的 agent、測試或 linter，以後交給機器自動把關。
• 22:52 把這些非功能性需求寫進 codebase，就能從源頭避免這類程式碼出現
  ↳ non-functional requirements（非功能性需求）指功能以外的要求，例如寫法一致、好維護。把這些寫進專案，不好的寫法一開始就進不來。
• 23:22 例子：coding agent 傾向為局部方便做最佳化，導致 codebase 出現同一段 routine 的多份複本
  ↳ 例如 agent 常圖眼前方便，需要某段小功能（routine）時就在手邊再寫一份，不去找現成的，結果同樣的功能散落成好幾份複本。
• 23:22 實例：限制並行（字幕作 limited competitiveness）的輔助函式有太多份，但只有一份有接上 OpenTelemetry stack 做 instrumentation
  ↳ 實例：限制同時執行數量的輔助函式有好幾份，但只有一份接上 OpenTelemetry（開源的監控追蹤工具），做了 instrumentation，也就是記錄運作狀況，其他份都沒有。
• 23:52 解法：寫一條 linter，禁止這個函式以任何形式定義在標準（canonical）非同步工具套件以外的地方
  ↳ 解法是寫一條 linter 規則：這個函式只准放在官方指定（canonical）的那個非同步工具套件裡，在其他地方定義就報錯，逼大家共用同一份。
• 23:52 這是憑感覺寫的 eslint 規則，但讓 Codex 詳盡寫出正反案例的測試，就能保證 100% 覆蓋率；講者說這就是在 codebase 中實踐系統思考
  ↳ eslint 是 JavaScript 常用的 linter。這條規則是憑感覺寫的，但讓 Codex 把該擋和不該擋的例子都寫成測試，就能確保規則被完整測到。講者說，這就是在專案裡實踐系統思考。

講者團隊做了約五個月、規定沒有人親手寫程式碼的專案，最後的內部產品約有多少行程式碼？