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

🧑‍🏫 這段講的是：想讓 Codex（OpenAI 會寫程式的 AI）穩定寫出好程式，靠的不是每次提醒，而是把團隊的經驗和品質要求寫進專案，讓 AI 每次都讀得到。後半段由客戶 Basis 分享他們如何用同樣思路，讓小團隊做出大公司的產量。用 AI 卻覺得它老是不照規矩的人，很值得看。

• 24:23 把 agent 常犯的錯誤或不良行為，用靜態方式直接禁止；等於把「穩健工程」寫成程式碼，讓 AI 垃圾程式碼不可能進入 codebase。
  ↳ agent 是能自己動手做事的 AI，這裡指 Codex。codebase 是整個專案的程式碼。重點是不靠每次提醒，而是設成「寫錯就過不了」的硬規則，AI 亂寫的東西自然進不來。
• 24:53 每位新工程師對「高品質、正確的程式碼」有不同經驗；大家都把這些知識加進 codebase，每位成員的 agent 都能用到其他人的經驗。
  ↳ 每個工程師吃過的虧、在意的寫法都不同。大家把這些經驗寫進專案，就像共用一本手冊，你的 AI 也會照別人的經驗做事。
• 25:23 剛開始非常慢：Codex 不清楚講者的驗收標準，所以常要把任務拆得很細，先建立一些基本元件才能得到想要的結果。
  ↳ 一開始 Codex 不知道講者心中「怎樣才算做好」，只能把工作切成很小塊、一步步帶，先把基本元件做出來，效率很低。
• 25:23 投資這些基本元件後生產力提升：從一開始相當於一位工程師的四分之一到一半，變成每人相當於 3 到 10 位工程師的工作量。
  ↳ 基本元件做好之後差很多：起初一個人加 AI 只抵四分之一到半個工程師，後來每人能做出相當於 3 到 10 位工程師的量。
• 25:54 新成員加入反而讓生產力增加，因為有「知識累積飛輪」，能提升每位工程師 agent 的表現。
  ↳ flywheel（飛輪）指越轉越順的正循環。一般團隊人多反而變慢；這裡每個新人都把知識寫進專案，所有人的 AI 都跟著變強，所以人越多越快。
• 25:54 要得到可接受的程式碼，唯一方式是強制 agent 寫出來；因此必須在 repository 裡加入比以前多很多的 context。
  ↳ context 是 AI 做事時能參考的背景資料，repository 是存放專案程式碼的地方。AI 猜不到你的標準，要它寫出合格程式，就得把規範明白寫進去，量要比以前多很多。
• 26:26 例子：講者和資安團隊決定改用支援的推薦加密函式庫，但這決定只在兩個月前的 Slack 討論串裡、已被淹沒；新工程師因此加了新的 npm 套件，與工程慣例不一致。
  ↳ 加密函式庫是現成的加密工具程式；npm 套件是 JavaScript 常用的現成工具包。換工具的決定只留在兩個月前的聊天串裡，新人不知道，就裝了別的套件，跟團隊規定不合。
• 26:56 這不是工程師或 Codex 的錯，而是資訊沒被建進系統的限制中。講者回到 Slack 討論串，請 Codex 把限制加進 codebase 再重做變更，結果改用了正確的加密函式庫。
  ↳ 錯不在人也不在 AI，而在規則只存在聊天裡。講者叫 Codex 讀那串討論，把規則寫進專案再重做一次，這次就用對了。規則要放在 AI 看得到的地方。
• 26:56 團隊大量依賴 Slack、Linear 等整合／應用來分享 context，而且這樣做極度便宜。
  ↳ Slack 是工作聊天軟體，Linear 是追蹤待辦任務的工具。團隊讓 AI 直接從這些工具取得背景資料，比人工整理文件便宜省事太多。
• 27:27 講者讓 Codex 跑 5、10、15 分鐘後回來，就得到四個讓程式碼未來更好的 PR 建議。
  ↳ PR（pull request）是「我改了這些程式碼，請檢查後併入」的申請。講者只讓 Codex 自己跑十來分鐘，就拿到四個能改善未來程式碼的修改提案。
• 27:27 codebase 的 context 太多，塞不進 agent.mmd 檔（字幕原文）；光描述資安最佳實踐就佔 markdown 檔 250 行，「可靠程式碼」的定義也一樣多。
  ↳ agent.mmd（字幕寫法）是放在專案裡給 AI 讀的說明檔，用 markdown 這種簡單文字格式寫。光資安規範就 250 行，「可靠程式碼」的規範也一樣長，一個檔塞不下。
• 27:57 例子：網路程式碼要加 retry 和 timeout 大家都知道，但仍常沒加就進 production，Codex 產生的程式碼也一樣會這樣。
  ↳ 網路連線可能失敗或卡住：retry 是失敗後自動重試，timeout 是等太久就放棄。大家都懂要加，卻常漏掉就上了 production（給使用者用的正式環境），AI 也會犯一樣的錯。
• 27:57 做法：記錄這些非功能性需求，在 agents.mmd 給 agent 如何達成可靠性最佳實踐的指引。
  ↳ non-functional requirements（非功能性需求）不是「功能做什麼」，而是「穩不穩、安不安全」這類品質要求。做法是把它們寫下來，在說明檔裡教 AI 怎麼做到。
• 28:28 再用一個注重可靠性的 code reviewer 在 PR 上留言，主要撰寫 agent 被強制讀取，讓系統收斂到規則上；字幕說這在可靠性上比人來做更有效率。
  ↳ code reviewer 是檢查程式碼的角色。另設一個專抓可靠性問題的 AI 在 PR 上留意見，寫程式的 AI 必須讀了照改，來回幾輪就會貼齊規則。講者說這比人來檢查更有效。
• 28:28 Codex 很有耐心，願意接受任意多次 code review；人可能會不耐煩、沒多想就 merge 到 master branch，所以結果程式碼品質很高。
  ↳ merge 是把修改併進去，master branch 是專案的主線版本。人被退件幾次會煩，可能隨便就併進主線；Codex 不會煩，退幾次都照改，品質因此撐得住。
• 28:58 擴展性例子：一位產品導向的新工程師不滿 Codex 無法有效 smoke test 關鍵使用者路徑的變更。
  ↳ smoke test 是改完後快速點一遍關鍵流程，確認沒壞。有位重視產品的新人不滿：Codex 改完程式，沒辦法好好確認使用者最常走的那幾條路還正常。
• 28:58 解法：讓 Codex 掃描所有使用者功能，寫出技術需求、手動 QA 計畫，並描述這些路徑對應的使用者需求。
  ↳ 解法是讓 Codex 把產品所有功能掃一遍，寫成三樣東西：技術需求、手動 QA（品質測試）的檢查計畫，以及每條流程是為了滿足使用者什麼需求。
• 29:28 再交給專門的 review agent 審每個 PR 並產生手動 QA 計畫，Codex 再用它來端到端驗證變更是否可行、符合 app 功能。
  ↳ review agent 是專門審 PR 的 AI。它為每個 PR 產生手動測試計畫，Codex 再照計畫從頭到尾（end-to-end）實際跑一遍，確認改動能用、也符合產品功能。
• 29:28 這類知識過去只存在 Slack 或對話裡，一直沒時間寫下來、編進 repository；現在產生成本很低，算是文件的新路徑。
  ↳ 這些「產品怎麼運作、該怎麼測」的知識，以前只在聊天和口頭裡，沒人有空寫成文件。現在叫 AI 產生幾乎不花成本，寫文件變成很容易的事。
• 29:59 若要 Codex 成為團隊有效成員，它必須知道產出可 merge 的高品質程式碼所需的一切；要讓 agent 結果一致，關鍵在非功能性需求。
  ↳ 想讓 Codex 像真正的同事，它就得知道團隊對「能併進去的好程式」的所有要求。講者認為，AI 表現穩不穩，關鍵在那些品質類規範。
• 30:33 講者偏後端基礎架構與架構，缺乏讓 Codex 寫出好 React 程式碼的知識；聘請前端架構專家後，他把知識寫進 codebase，hooks 開始拆到獨立檔案。
  ↳ React 是做網頁畫面的常見工具，hooks 是 React 裡處理畫面邏輯的寫法。講者擅長後端，不懂前端的好寫法；請來前端專家把經驗寫進專案後，AI 開始把程式拆得乾淨。
• 31:04 開始出現可透過 state snapshots 輕鬆測試、彼此組合良好的小元件，檔案變小，agent 更容易載入 context。
  ↳ state snapshots 是把畫面某一刻的狀態存下來比對，方便測試。之後 AI 寫出的元件小、好測、能互相拼裝；檔案變小，AI 讀進來也比較不吃力。
• 31:04 每位新工程師把更多專業編進 codebase，讓 coding agent 更有效率。
  ↳ 每多一個人把專長寫進專案，所有人的 AI 都會更會寫程式。個人經驗不再只留在自己腦中。
• 31:04 建議一：去看 Codex repository，許多做法已經實作在裡面；clone 下來，請 Codex 解釋結構並教你團隊使用的最佳實踐。
  ↳ 影片建議去看 Codex 的 repository，很多做法已經用在裡面。clone 是把整個專案下載到自己電腦；下載後直接問 Codex 這專案怎麼組織、用了哪些好習慣。
• 31:34 建議二：X 上很多人把 Harness engineering 部落格的連結給 repo 裡的 Codex，要求「make my codebase more agent-friendly」，得到好結果，提升自主性、品質與長時間任務的執行。
  ↳ X 是前身為 Twitter 的社群平台。有人把 Harness engineering 那篇部落格丟給 Codex，叫它「讓專案更適合 AI 工作」，結果 AI 更能自己做事、品質更好、長任務也撐得住。
• 32:04 核心轉變：從在鍵盤上打程式碼，轉為更高層次的 orchestration；這就是 Symfony（字幕原文），也是 repository 名稱的由來。
  ↳ orchestration 是指揮調度：不再自己一行行打程式，而是分派、監督 AI 做事。字幕寫作 Symfony，講者說他們 repository 的名字就是從這個概念來的。
• 32:34 進入「客戶焦點」單元，來賓是 Basis 共同創辦人 Mitch。
  ↳ 接著換客戶分享：Basis 的共同創辦人 Mitch 上場，講他們公司實際怎麼做。
• 33:04 Mitch 請 Codex 做了一份簡短簡報；他認為 Basis 在 codebase 與公司層面的做法都和 Harness 工程很像，而且 Codex 用途不只寫程式。
  ↳ Mitch 的簡報是叫 Codex 做的，本身就說明 Codex 不只能寫程式。他認為 Basis 在程式碼和整間公司的做法，都跟前面講的 Harness 工程很像。
• 33:35 Basis 基本上是給會計師的 agency platform（字幕原文），最近完成 Series B 募資，專注讓公司極快速前進。
  ↳ Basis 是做給會計師用的平台（字幕寫 agency platform）。Series B 是新創公司常見的第二輪較大規模募資。他們的重點是讓公司動得非常快。
• 34:05 野心太大，短時間內要達到所需規模，實際上不可能雇那麼多人；所以公司和 codebase 要做到像大十倍公司的產能。
  ↳ 他們目標很大，短期內需要的人力根本請不到，所以策略是靠 AI 讓公司和程式碼做出「大十倍公司」的產量，而不是靠加人。
• 34:37 這需要重大思維轉變：從直接做任務轉為管理（呼應 Symphony 團隊的說法）；這轉變很複雜，不同人速度不同。
  ↳ 最難的是腦袋要換：從「我自己做」變成「我管 AI 做」，跟 Symphony 團隊講的一樣。這轉變不簡單，有人轉得快、有人轉得慢。
• 34:37 若 agent 表現不好，不論工程、業務或技術支援都很難轉變；agent 寫不好程式碼，就很難說服人「讓 agent 寫就好」。
  ↳ 如果 AI 本身做得爛，不管工程、業務還是客服，都不會想交給它。要人放手，前提是 AI 真的做得好。
• 35:07 要改變思維，為 agent 而不只是為人打造產品：讓 agent 能 self-verify，並能理解人傳達的不同意圖。
  ↳ 所以產品要設計成 AI 也能用，不只給人用：self-verify 是 AI 能自己檢查做對沒，另外它要能聽懂不同人用不同說法表達的需求。
• 35:37 在產品 codebase 或大公司裡需要協作能力，避免某人對 agent 行為的偏好蓋掉另一人的偏好。
  ↳ 人一多，每個人對 AI 怎麼做事都有偏好。要有協作機制，不然某人的設定會蓋掉另一人的，AI 的行為就變來變去。
• 35:37 codebase 層面需要：明確的程式撰寫標準、把標準轉成高品質 context、保持 context 更新的流程、易於維護的內部設定。
  ↳ 程式碼這端要備齊四件事：清楚的寫程式標準、把標準整理成 AI 好用的資料、持續更新這些資料的流程、好維護的內部設定。
• 36:07 若開發工具都沒有 MCP 或與 agent 整合的方式，agent 就無法測試自己的工作，也無法用和開發者相同的工具。
  ↳ MCP 是讓 AI 連接外部工具的一種標準接口。如果開發工具都接不上 AI，它就沒辦法自己測試成果，也沒辦法跟工程師用同一套工具。
• 36:07 例如 Basis 做了一個叫 Satellite 的東西，是一個單一的 MCP（字幕在此段落截斷）。
  ↳ 舉例來說，Basis 做了一個叫 Satellite 的東西，是單一一個 MCP。字幕在這裡截斷，詳細用途要看下一段。

講者說，在投資建立基本元件之後，團隊使用 Codex 的生產力變成怎樣？