Build Hour：API 與 Codex（第 5/5 段）
🏦 台灣Pay 銀行轉帳 💙 PayPal
Q&A：Codex 的瀏覽器自動化、commit、架構設計、skills 管理、working tree 示範與後續活動
- 48:46 Codex 可以在瀏覽器裡做自動化。Playwright skill 已經推出一段時間，最近又新推出 interactive Playwright skill，進一步強化 Codex 操作瀏覽器的能力
- 54:49 示範 working tree：選擇新的 working tree，請 Codex 把 plan.md 改短，並關掉字幕所說的 scheduling mode、設成低優先度，讓它跑得更快
- 60:22 接下來的兩場活動：3 月 24 日談 agent capabilities，4 月 15 日談 GPT realtime 1.5
💡 你可以怎麼用：把你常交代 AI 的規則（例如多久存一次版本、說明怎麼寫）整理成一份檔案放進專案資料夾，讓每次對話都照同一套做事。請它改網頁時，直接要它用瀏覽器截圖檢查，改到畫面正確為止。
看全部 47 條重點
🧑🏫 這段是 OpenAI Build Hour 最後的問答，講者分享用 Codex 寫程式的實戰做法，例如讓 AI 自己開瀏覽器檢查畫面、自己存版本，以及怎麼整理專案才能放心把工作交給 AI。如果你想讓 AI 不只幫忙寫程式，還能可靠地獨立完成任務，這段很實用。
- 48:46 Codex 可以在瀏覽器裡做自動化。Playwright skill 已經推出一段時間，最近又新推出 interactive Playwright skill，進一步強化 Codex 操作瀏覽器的能力↳ Playwright 是一套能用程式操控瀏覽器的工具；skill 是給 Codex 的能力包。有了它，Codex 能自己開網頁、點按鈕、看結果，新推出的互動版能力更強。
- 48:46 講者自己做前端時，如果某個區塊沒有渲染出來或對齊不正確，會叫 Codex 用 Playwright 不斷迭代、截圖，直到確定正確為止↳ 前端就是使用者看到的畫面。講者發現某塊沒顯示或沒對齊時，會讓 Codex 自己開瀏覽器、截圖、修改，一輪輪改到正確，不用自己一直重新整理檢查。
- 49:16 有觀眾問到 shared streams，講者表示不確定↳ 有觀眾問 shared streams，講者坦白說不確定，這題沒有答案。
- 49:16 關於回溯（rollback）：app 裡所有變更都以「準備 commit 的檔案」呈現，所以要取消這些準備好的檔案很容易↳ rollback 是把改壞的東西退回去。Codex 的改動會先列成「準備存檔」的檔案清單，你覺得不對，直接取消這些檔案就好。
- 49:16 可以直接叫 Codex，或在 agent 的指示裡加上，讓它邊做邊 git commit 所有變更；這套框架建好之後就能自己運作↳ git 是記錄程式版本的工具，git commit 就是幫目前進度存一個版本快照。agent 是能自己動手完成任務的 AI。你可以要它每做一段就存一次，寫進指示後它會自動照做。
- 49:46 講者會讓 Codex 自己 commit，並給它指示，說明對 commit message、進度和 commit 粒度（granularity）的期望，效果不錯↳ commit message 是每次存檔附的說明，granularity 指每次存檔包多大範圍。講者會寫清楚期待，例如多久存一次、說明要寫什麼，Codex 照做的效果不錯。
- 49:46 問題：從 AI pair programming 走到把工作完全委派給 agent，哪些設計模式能讓 agent 可靠到能用在 production？↳ pair programming 原指兩人一起寫程式，這裡指你和 AI 邊聊邊寫；production 是正式上線給真人用的環境。問題是：程式要怎麼設計，才能放心全交給 agent？
- 50:16 回答：採用相當嚴格的架構模式，就像有一千或一萬名工程師的公司會有的那樣，包括責任分離、多層次的套件結構、業務領域高內聚、封裝與邊界分離↳ 答案是把程式結構管得像大公司一樣嚴：每塊各管各的事、相關功能集中在同一區、內部細節包起來不外露，區塊之間界線分明。
- 50:16 這有助於 context 管理：只處理一組業務邏輯時，agent 可以把別的部分當成不透明的介面，並依賴該介面的不變條件（invariants）↳ context 是 AI 當下讀進來的資料，塞太多會出錯。結構切乾淨後，agent 改 A 區時只要知道 B 區保證做到什麼（invariants），不必讀懂 B 的內部。
- 50:47 例子：核心業務邏輯中的任務彙整函式如果能接受對推論（inference）的依賴注入，agent 就不必深入理解推論那一塊，藉此限制 agent 需要載入的 context 量↳ inference 指呼叫 AI 模型產生結果；依賴注入是把要用的東西從外面遞進來，而不是寫死在裡面。這樣 agent 改彙整邏輯時，不必搞懂呼叫 AI 那一塊。
- 50:47 這跟文件使用的 progressive disclosure 是同一種模式；把 codebase 整理得井然有序，當作 prompt 的程式碼也能遵循相同模式↳ progressive disclosure 是先給簡介、需要時才展開細節。程式碼本身也是 AI 要讀的 prompt（指令），整理得有層次，AI 就能先看概要再往下鑽。
- 51:17 兩位講者都同意，因為這個原因，他們做的重構比五年前多很多↳ refactoring 是不改功能、只整理程式結構。為了讓 AI 好讀好改，他們現在比五年前更常回頭整理程式碼。
- 51:17 問題：團隊怎麼管理 agent 指示？每個工程師各自一套，還是共用並納入版本控制？怎麼同步新增或改善指示？↳ version control 是記錄檔案每次修改、讓多人同步的機制。問題是：給 agent 的指示是每人自己寫一套，還是全隊共用一份、有人改了大家都同步？
- 51:47 講者團隊把所有東西都放在 codebase 裡，個人專屬的 agent 或 skill 很少，把這當成讓代表團隊工作的所有 agent 規模化的方式↳ codebase 指整個專案的程式碼庫。講者團隊把 agent 指示和 skill 都放進專案裡一起管，幾乎沒有私人版本，讓每個人的 agent 都照同一套做事。
- 51:47 團隊只收集了幾個相當通用的 skill：建立 PR、修改並部署、建立 commit、做 code review、分析提案計畫的架構，就這些而已↳ PR（pull request）是提出修改、請人審核後再合併；code review 是審查程式碼。他們只做了這幾個通用 skill，涵蓋日常開發流程。
- 52:18 想給 agent 的其他能力，會放進這些 skill 的參考文件、scripts，或 repo 本身的文件和測試裡↳ 其他想讓 agent 會的事，不另做新 skill，而是放進 skill 附的參考文件、scripts（可執行的小程式），或專案本身的文件和測試裡。
- 52:18 好處是把知識從個別成員的腦袋裡拿出來，放到每個人的 agent 都能受益的地方↳ 原本只有資深同事知道的眉角，寫進專案後，每個人的 agent 都讀得到，不會因為某人請假或離職就失傳。
- 52:48 團隊每天開 30 分鐘的會。因為程式碼產出速度很快、工程師又和程式碼很疏離，可能過好幾週才發現底層架構模式變了，所以安排同步協作時間很合理↳ AI 寫程式很快，人又不再逐行看程式，架構可能被悄悄改掉、好幾週後才發現。所以團隊每天花 30 分鐘開會對齊方向。
- 53:18 Mitch 表示 Basis 團隊做法差不多，但他們把許多前端和後端標準放在 skills 裡，另外也有給人看的文件，這些文件對 agent 也有用↳ Mitch 是另一位講者，Basis 是他的團隊。他們把前端和後端（伺服器那一側）的規範寫成 skill，寫給人看的文件也順便讓 agent 參考。
- 53:48 Mitch 團隊有一個前端 skill，Codex 只要碰到前端程式碼就會呼叫它，裡面有很多連結，依工作內容指向前端的不同部分↳ Codex 只要改到畫面相關的程式，就會自動叫出前端 skill。這個 skill 像一份目錄，依任務類型指到對應的細節說明，不用一次全部讀完。
- 53:48 另一位講者的做法：把任務相關的知識都移到文件階層裡，skill 則專注於高層次的運作模式↳ 另一種分工：某個任務該知道的知識寫進分層的文件裡；skill 只講大方向的做事流程，例如先看什麼、怎麼檢查。
- 54:19 例如他們有一個「master review」skill，使用者可以用它把 agent 導向特定文件；除此之外，它只是 Codex 執行任務的一般模式↳ 例如「master review」skill 主要讓使用者指定 agent 該去看哪份文件，其餘只是 Codex 平常做事的步驟，沒有塞太多專門知識。
- 54:49 示範 working tree：選擇新的 working tree，請 Codex 把 plan.md 改短，並關掉字幕所說的 scheduling mode、設成低優先度，讓它跑得更快↳ working tree 是從同一個專案另開一個獨立的工作資料夾。示範中開了一個新的，請 Codex 把 plan.md（計畫文件）改短，並關掉字幕所說的排程模式、設成低優先度，讓它跑快一點。
- 54:49 建立新 working tree 後，Codex 自己知道要先讀 plan.md，再去找要編輯哪個檔案（因為之前有好幾個封存的檔案）↳ 新工作區開好後，不必交代太細，Codex 會自己先讀 plan.md 了解狀況，再判斷該改哪個檔案，避開舊的封存檔。
- 55:19 現有的 diff 不會自動搬進新的 working tree，本機的變更和這個 working tree 是分開的，所以可以在這個分支獨立工作↳ diff 是「改了哪些地方」的差異紀錄。原本資料夾裡還沒存的修改，不會跟著搬進新工作區，兩邊互不干擾。
- 55:19 也有選項可以把本機變更帶過去；預設則是取得 master 分支或任何指定分支的乾淨副本↳ branch（分支）是從主線岔出去的另一個版本，master 通常就是主線。新工作區預設拿乾淨的主線或指定分支，也可以選擇把手上的修改帶過去。
- 55:49 改完後可以建立分支，或晚點再建；若在獨立分支上工作，它會詢問是否要把變更推到本機環境↳ 改好後可以馬上開分支保存，也可以晚點再決定。如果是在獨立分支上做，Codex 會問你要不要把成果帶回原本電腦上的工作區。
- 55:49 working tree 讓你同時在硬碟上擁有多個工作目錄、各自對應 repo 的不同分支，不必重複 clone；相關指令很複雜，Codex app 會代勞↳ clone 是把整個專案再複製一份。working tree 讓你不必複製，就能同時開好幾個資料夾各做不同分支；原本的指令很難記，App 會代勞。
- 56:19 示範結果：working tree 裡做的變更不會反映到主線上↳ 示範結果確認：新工作區裡的修改，主線那邊完全沒變，證明兩邊真的是分開的。
- 56:19 問題：既然有 progressive disclosure，是否該啟用所有 skill、需要時再呼叫？講者認為可以↳ 問題是：既然 skill 平常只顯示簡介、用到才展開，那是不是全部打開也沒關係？講者認為可以。
- 56:19 值得花心思寫 skill 開頭簡短、有品質的描述，它就像預告，讓模型判斷要不要呼叫這個 skill↳ skill 開頭的簡短描述就像商品標題，模型靠它決定要不要點進去用。寫得清楚精準，該用的時候它才會被叫出來。
- 56:49 流程是從描述可用能力的簡短片段，進到模型必須遵循的詳細指示↳ 運作順序是：模型先看到一排簡短的能力說明，挑中某一個後，才去讀完整的詳細步驟並照著做。
- 56:49 他們有一個 Codex subagent，專門產生多個 subagent 來測試不同 skill：給出各種指示範例，看 skill 有沒有被觸發，藉此半測試開頭描述是否有效↳ subagent 是主 agent 派出去做子任務的小 agent。他們讓一個 subagent 再派出多個，用各種講法下指令，看 skill 有沒有被觸發，藉此檢查描述寫得好不好。
- 57:19 Ryan 很喜歡用 Figma skill，可以把團隊其他成員的工作成果接起來，把那些 context 帶進 Codex↳ Ryan 是另一位講者。Figma 是設計師畫介面的工具；Figma skill 讓 Codex 直接讀設計稿，把設計師的成果接進開發流程。
- 57:50 他們也用類似方式，透過 Slack 把 context 加進 codebase↳ 同樣地，他們透過 Slack（團隊聊天工具）把討論裡的資訊帶進專案，讓 agent 也看得到。
- 57:50 問題：有沒有替 brownfield 應用程式建立 Harness 的 bootstrap 機制，例如文件管理、共通規則與慣例？↳ brownfield 指已經有既有程式的舊專案；Harness 指講者打造、讓 agent 穩定工作的整套環境；bootstrap 是快速起步的方法。問題是舊專案怎麼導入？
- 57:50 回答：他們仍在積極摸索怎麼把這些技巧用在既有的 codebase 上，也樂意和社群合作找出有效做法↳ 講者坦白說，套用到舊專案的方法還在摸索，沒有現成公式，歡迎大家一起交流。
- 58:20 一般做法：把 repo 拆成獨立的業務邏輯領域、加上介面，並撰寫高品質的在地文件，記錄負責該程式碼的成員會查的最佳實踐↳ 大方向是：把專案依業務拆成獨立區塊、區塊之間定好介面，再在各區旁邊寫好說明，內容就是負責那塊的同事平常會查的做法。
- 58:20 在會變動的程式碼旁邊建立獨立的文件子樹，並沿用他們提出的同一套結構↳ 文件直接放在對應的程式旁邊、跟著程式一起更新，結構沿用他們分享的那套分層方式。
- 58:50 另外，把所有能開的 linter 都打開↳ linter 是自動檢查程式寫法、抓出問題或不合規範之處的工具。能開就全開，等於幫 AI 多設幾道自動關卡。
- 58:50 所有 skill、展示過的 metrics 和範例 app 的程式碼都會放在 GitHub 上的 Build Hours repository，可以看到他們怎麼讓模型評估這些提示用的 MD 檔↳ GitHub 是放程式碼的平台，repository 是專案存放處，metrics 是評估指標。skill 和範例都會公開在上面，可以看他們怎麼讓模型評估那些指示檔。
- 59:21 相關連結會在會後的下一封 email 寄出↳ 會後寄出的下一封 email 會附上相關連結。
- 59:21 Mitch 建議看看這些檔案，了解 codebase 的可靠性、安全性與前端元件架構長什麼樣子↳ Mitch 建議直接去讀那些檔案，看可靠性、安全性和前端元件實際上怎麼整理，當成參考範本。
- 59:21 Mitch 建議團隊聚在一起，在白板上快速畫出你們心中「好」的結果有哪些重點，可以是相當通用的原則↳ Mitch 建議團隊一起在白板上列出「我們心中好的程式長什麼樣」，不用寫很細，大原則就好。
- 59:51 例如「安全的程式碼擁有不會被誤用的安全介面」這種論點就值得記下；在 codebase 加幾個包含這些核心原則的檔案，之後就更容易逐步擴充↳ 例如「安全的程式要有不會被用錯的介面」這種原則就值得寫下。先放幾個寫著核心原則的檔案進專案，之後要慢慢補充就容易了。
- 60:22 接下來的兩場活動：3 月 24 日談 agent capabilities，4 月 15 日談 GPT realtime 1.5↳ 接下來兩場：3 月 24 日講 agent 的能力，4 月 15 日講 GPT realtime 1.5。
- 60:22 在主頁面可以看過去場次的錄影，也可以報名之後的場次↳ 在主頁面可以看過去場次的錄影，也能報名之後的場次。
📘 術語
Playwright skill（Playwright 技能）：讓 Codex 在瀏覽器中做自動化，可反覆截圖檢查前端畫面是否正確
interactive Playwright skill（互動式 Playwright 技能）：剛推出的新 skill，進一步強化 Codex 操作瀏覽器的能力
rollback（回溯／復原）：所有變更以準備 commit 的檔案呈現，因此很容易取消
git commit（提交變更）：可以指示 Codex 邊做邊 commit，並規定 commit message 和粒度
granularity（粒度）：指每個 commit 的大小與切分程度，講者會給 Codex 相關指示
pair programming（結對程式設計）：字幕把它和「完全委派給 agent」對比，作為人機協作的前一個階段
separation of responsibilities（責任分離）：講者採用的嚴格架構模式之一，有助於 agent 管理 context
cohesion（內聚）：講者要求業務領域高內聚，是讓 agent 可靠的架構原則之一
encapsulation（封裝）：和邊界分離並列的架構原則，讓 agent 不必理解其他部分的細節
opaque interface（不透明介面）：agent 不需了解內部，只需依賴其不變條件的介面
invariants（不變條件）：介面保證成立、agent 可以依賴的性質
context management（上下文管理）：限制 agent 需要載入的 context 量，嚴謹的架構有助於此
progressive disclosure（漸進式揭露）：文件使用的模式：先給簡短描述，需要時再進到詳細指示
refactoring（重構）：因為這些架構要求，團隊做的重構比五年前多很多
version control（版本控制）：觀眾問 agent 指示是否共用並納入版本控制，講者團隊全放在 codebase
skill（技能）：給 agent 的能力模組，例如建立 PR、commit、code review
PR（合併請求）：講者團隊通用 skill 之一就是「建立 PR」
code review（程式碼審查）：講者團隊的通用 skill 之一
working tree（工作樹）：同時擁有多個對應不同分支的工作目錄，不必重複 clone repo
branch（分支）：working tree 預設取得 master 或指定分支的乾淨副本
diff（差異／變更內容）：既有的 diff 不會自動搬進新的 working tree
clone（複製 repo）：有了 working tree 就不必把 repository 複製好幾份
subagent（子代理）：他們用一個 Codex subagent 產生多個 subagent 來測試 skill 是否被觸發
brownfield（既有系統）：指已經存在的 codebase，講者仍在摸索怎麼套用這些技巧
linter（程式碼檢查工具）：講者建議把所有能開的 linter 都打開
interactive Playwright skill（互動式 Playwright 技能）：剛推出的新 skill，進一步強化 Codex 操作瀏覽器的能力
rollback（回溯／復原）：所有變更以準備 commit 的檔案呈現，因此很容易取消
git commit（提交變更）：可以指示 Codex 邊做邊 commit，並規定 commit message 和粒度
granularity（粒度）：指每個 commit 的大小與切分程度，講者會給 Codex 相關指示
pair programming（結對程式設計）：字幕把它和「完全委派給 agent」對比，作為人機協作的前一個階段
separation of responsibilities（責任分離）：講者採用的嚴格架構模式之一，有助於 agent 管理 context
cohesion（內聚）：講者要求業務領域高內聚，是讓 agent 可靠的架構原則之一
encapsulation（封裝）：和邊界分離並列的架構原則，讓 agent 不必理解其他部分的細節
opaque interface（不透明介面）：agent 不需了解內部，只需依賴其不變條件的介面
invariants（不變條件）：介面保證成立、agent 可以依賴的性質
context management（上下文管理）：限制 agent 需要載入的 context 量，嚴謹的架構有助於此
progressive disclosure（漸進式揭露）：文件使用的模式：先給簡短描述，需要時再進到詳細指示
refactoring（重構）：因為這些架構要求，團隊做的重構比五年前多很多
version control（版本控制）：觀眾問 agent 指示是否共用並納入版本控制，講者團隊全放在 codebase
skill（技能）：給 agent 的能力模組，例如建立 PR、commit、code review
PR（合併請求）：講者團隊通用 skill 之一就是「建立 PR」
code review（程式碼審查）：講者團隊的通用 skill 之一
working tree（工作樹）：同時擁有多個對應不同分支的工作目錄，不必重複 clone repo
branch（分支）：working tree 預設取得 master 或指定分支的乾淨副本
diff（差異／變更內容）：既有的 diff 不會自動搬進新的 working tree
clone（複製 repo）：有了 working tree 就不必把 repository 複製好幾份
subagent（子代理）：他們用一個 Codex subagent 產生多個 subagent 來測試 skill 是否被觸發
brownfield（既有系統）：指已經存在的 codebase，講者仍在摸索怎麼套用這些技巧
linter（程式碼檢查工具）：講者建議把所有能開的 linter 都打開
✏️ 小考一題
講者說他的團隊每天會開多長的同步會議，原因是程式碼產出速度太快、架構變化不容易察覺？
A. 15 分鐘B. 不開每日會議，只開每週會議C. 60 分鐘D. 30 分鐘看答案
答案：D。[52:48] 講者說：「We have a 30-minute meeting every day」
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰