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

🧑‍🏫 這段是 OpenAI 的工程分享，講者示範他們怎麼把團隊規則、做過的決定、甚至整間公司的背景資料，都放進 AI 讀得到的地方，讓 Codex（OpenAI 的寫程式 AI 助手）更好用。核心觀念是：AI 做得好不好，很大程度取決於你給它的資料夠不夠完整、清楚。就算你不寫程式，這套「把背景資料整理給 AI 看」的思路也用得上。

• 36:34 Satellite 是一個 MCP，把其他所有 MCP 包在一起，開發者只需串接一個 MCP，不用串五十個。講者說這只是這類做法的一個例子
  ↳ MCP（Model Context Protocol）是讓 AI 連接外部工具和資料的通用接口。Satellite 把很多個 MCP 收成一個總入口，開發者接一次就好，不用一個個接。講者強調這只是其中一種做法。
• 36:34 在產品程式碼庫裡，要讓 agent 真正有效，指令遵循度必須很高。Codex 很會遵循指令，因此你的文件與 context 也必須寫得更精確
  ↳ agent 是會自己分步驟完成任務的 AI。指令遵循度是指它照你的話做到多徹底。Codex 很聽話，所以你的文件寫得模糊或寫錯，它也會照著做錯，寫清楚就變得更重要。
• 37:04 Codex 很擅長事先蒐集 context。講者提到 Ryan 講過的漸進式揭露：面對任何程度的複雜度，模型都要能一路讀過這些揭露內容、蒐集 context 來完成任務
  ↳ context 是 AI 做事時能看到的背景資料。漸進式揭露是先給摘要，需要時再往下讀細節。不管任務多複雜，模型都要能順著這條路，自己把需要的資料找齊。
• 37:34 agent 也必須能在不確定的情況下做決策，Codex 很擅長這一點
  ↳ 現實中資訊常常不完整，agent 不可能每一步都停下來問人。講者認為 Codex 在資訊不足時，仍然能做出合理判斷，繼續往下做。
• 37:34 建立標準時著重 agents.md 檔：根目錄放一份，各模組也各放一份。只跟某個模組有關的資訊，放進該模組的 agents.md
  ↳ agents.md 是寫給 AI 看的說明檔。專案最上層放一份，寫整體規則；每個模組（負責某一塊功能的程式區塊）再各放一份，只寫那一塊才需要知道的事。
• 38:04 跨模組共通的資訊，則放進 skill
  ↳ skill 是一份可以重複使用的做事說明，AI 需要時才拿出來用。好幾個模組都會用到的知識或流程，就寫成 skill，不用每個模組各抄一份。
• 38:04 講者認為必須建立這些標準、把它們當成權威依據，並建立流程讓它們保持最新
  ↳ 規則寫了就要算數：人和 AI 都以它為準。另外還要有固定的更新流程，否則文件過時了，AI 照著舊規則做，反而會出錯。
• 38:34 示範一個叫「paper update」的 agent skill，用途是更新內部稱為「Paper」的東西。重點是 skill 的標題裡標明了擁有者（owner）
  ↳ 這裡示範一個叫 paper update 的 skill，用來更新內部工具 Paper。重點不在它的功能，而是 skill 的標題上直接寫了負責人是誰。
• 39:05 標明 owner 能清楚劃分每個 skill 的負責人。例如用 agent 檢查各 skill 的描述有沒有衝突時，知道 owner 就能在 Slack 上聯絡對方
  ↳ owner 就是負責人。skill 一多，說明可能互相矛盾。讓 AI 掃出衝突之後，看 owner 就知道該去 Slack（工作用的聊天軟體）找誰處理。
• 39:35 Paper 是他們自己做的內部工具，目標是把所有 context 都放進 repository。他們的 monorepository 叫 Arnold
  ↳ repository（簡稱 repo）是存放程式碼和修改紀錄的地方，monorepository 是把很多專案集中在同一個 repo。Paper 是他們自製的工具，目的是把背景資料都收進 repo。產品 repo 叫 Arnold。
• 39:35 Arnold 名稱的由來：根據 ChatGPT 的說法，Arnold 是 2023 年左右美國最常見的會計師名字
  ↳ 一個小彩蛋：這個名字是問 ChatGPT 來的。照它的說法，Arnold 是 2023 年前後美國最常見的會計師名字。
• 40:05 Paper 裡可以清楚看到每個 skill 的 owner 與 workflow，確保沒有把垃圾加進程式碼庫、內容確實有更新，而且有人在審閱、閱讀這些 skill
  ↳ 在 Paper 裡可以一眼看到每個 skill 的負責人和運作流程。這是在把關：不讓沒用的內容塞進來，確認內容有持續更新，也確認真的有人在審閱。
• 40:36 Codex 最近新增了 subagent 支援，他們用得很頻繁。其中一個專門負責落實標準：Codex 先做 review，再呼叫 standards reviewer subagent 補抓漏掉的標準問題
  ↳ subagent 是主 AI 可以叫來處理特定工作的小幫手。他們設了一個「標準審查員」：Codex 先自己檢查一遍，再請這個小幫手專門比對團隊規則，把漏掉的抓出來。
• 41:07 還有一個 subagent 負責「照看」pull request，讓 Codex 能把這件事委派出去
  ↳ pull request 是把程式修改送出去、請人審核後再合併的申請。另一個 subagent 專門盯這些申請的後續進度，Codex 就能把這類瑣事交出去。
• 41:07 講者認為，Codex 已經很擅長、但你想更有把握的 workflow，適合獨立成專門的 subagent，讓 Codex 去呼叫
  ↳ 判斷原則是：Codex 本來就做得不錯、但你希望更穩的工作，就獨立成專門的 subagent。讓它專心做這一件事，主 Codex 需要時再呼叫它。
• 41:07 讓 agent 能自行驗證自己的工作非常重要
  ↳ AI 做完事要能自己檢查結果對不對，不能全部等人來幫它驗收。
• 41:37 Codex 適合長時間工作，也擅長用工具與 context 確認自己做得好。所以要提供它把事情做好的方法，包括能快速跑測試來自我檢查
  ↳ Codex 能連續工作很久，也會用工具確認成果。所以要先幫它準備好檢查方法，例如能很快跑完的測試（自動檢查程式是否正常的小程式），讓它可以邊做邊驗。
• 41:37 講者喜歡「以測試驅動開發」的 workflow：除了產品規格，也列出一份測試清單（可由 Codex 產生）說明變更意圖，讓 Codex 在交回前確認各使用情境都能運作
  ↳ 交代任務時，除了寫要做什麼，再附一份「怎樣才算做對」的測試清單，這份清單也可以請 Codex 幫忙列。它交回成果之前，就會逐一確認各種使用情況都能正常運作。
• 42:08 當 Codex 把程式都寫好、任務也做得很好時，決策就會成為速度的主要瓶頸
  ↳ 當寫程式不再是慢的那一步，真正拖慢速度的就變成人要做的決定，例如要選哪個方案、規格怎麼定。
• 42:42 為了加快決策，他們採用 dotnotes：工作中做了決策（例如告訴 Codex 應該改用某種做法），Codex 就把當次 session 的決策記在 dotnotes 裡，dotnotes 屬於 repository 的一部分
  ↳ dotnotes 是 repo 裡的一個筆記資料夾。工作中你做了某個決定，例如叫 Codex 換一種做法，Codex 就會把這次對話裡的決定記下來，跟著程式碼一起保存。
• 42:42 dotnotes 可以想成 commit message，差別在於 Codex 隨時都能寫，不必等到建立 commit
  ↳ commit 是把一次修改存成一個版本，commit message 是附在上面的修改說明。dotnotes 跟它很像，差別是 Codex 隨時都能寫，不用等到存版本時才補。
• 43:12 dotnotes 為每個 commit 留下完整的決策歷史，可當作「歷史除錯器」。回頭看舊 commit 時，查 notes 資料夾就知道當初為什麼這樣實作
  ↳ 這樣每個版本背後的決定都有紀錄。日後翻到舊版本，想知道「當初為什麼這樣寫」，打開 notes 資料夾就查得到。講者稱它為「歷史除錯器」。
• 43:12 存放在 repository 裡的規格文件也極為重要
  ↳ 規格文件是寫清楚產品要做成什麼樣子的文件。講者強調，把它存在 repo 裡極為重要。
• 43:42 講者示範為 Paper 做的「hero」產品規格範例。他指出在 GitHub 上看規格不一定方便好讀，也很難留言
  ↳ 他拿 Paper 的一份重點產品規格當例子。GitHub（存放與協作程式碼的網站）雖然也能看規格，但讀起來不一定順，也不方便針對內容留言討論。
• 43:42 他們在內部的 Paper app 做了一個功能：可以直接在程式碼庫裡協作撰寫規格
  ↳ 所以他們在 Paper 裡加了一個功能，讓大家可以一起撰寫規格，而內容實際上就存在程式碼庫裡。
• 44:12 示範留言「test comment for Codex」，這則留言會直接寫進程式碼庫。所有留言、決策、互動與規劃都發生在程式碼庫內
  ↳ 他示範留一則給 Codex 的測試留言，這則留言會直接存進 repo。也就是說，討論、決定、規劃全都留在 Codex 讀得到的地方。
• 44:42 這樣做的原因呼應 Ryan 說的：把一切搬進程式碼庫，盡量擴充 context，讓 Codex 擁有協助決策與實作任務所需的一切
  ↳ 理由很單純：Codex 只能根據它看得到的東西做判斷。把資料都搬進 repo，它手上的資訊越完整，就越能幫忙做決定、完成任務。
• 44:42 講者提醒不要只停在程式碼庫。他們把「context 放在程式碼庫」視為整個公司脈絡的問題，不只是產品程式碼的問題
  ↳ 這個思路不只適用在寫程式。他們把整間公司的背景資訊，都當成要收進 repo 的東西，不只是整理產品程式碼而已。
• 45:12 公司有兩個 repository：Arnold 是產品的 monorepository；Atlas 是存放全公司脈絡的 monorepository，收的是產品 repo 以外的內容
  ↳ 兩個 repo 有分工：Arnold 放產品程式碼，Atlas 放產品以外的全公司資訊。
• 45:42 Atlas 裡有公司的營運原則（也放在招募頁面上），並標明 owner。這樣請 Codex 協助規劃時，它能讀取公司資訊來幫忙做決策
  ↳ 舉例來說，Atlas 裡存了公司的營運原則（也公開在徵才頁面上），一樣標明負責人。請 Codex 幫忙規劃時，它就能參考這些公司資訊，協助做決定。
• 46:12 講者表示，一旦意識到這點就能做更多事，接著示範：因為先前用過 app，這次改用 Codex 的命令列介面
  ↳ 想通「公司資訊也能給 AI 讀」之後，能做的事就更多了。接下來改用命令列介面示範，也就是用打文字指令的方式操作 Codex，而不是用 app 的畫面。
• 46:45 他在個人空間有個 skill 叫「start my day」，會跑他的晨間例行流程：抓取過去 24 小時的 context、更新各種東西等
  ↳ 他在個人空間做了一個叫「start my day」的 skill，負責跑他每天早上的例行流程：整理過去 24 小時的相關資訊，並更新各種資料。
• 46:45 講者沒有實際執行這個 skill，因為執行後會顯示部分資訊
  ↳ 他現場沒有實際執行這個 skill，因為一執行就會在畫面上顯示部分資訊。
• 47:15 這個 skill 做得好，是因為它能取得所需的全部 context：來自他的個人筆記、公司 repository，以及 Arnold
  ↳ 它好用的關鍵在於資料來源齊全：他的個人筆記、公司的 repo、產品的 Arnold，它全都讀得到。
• 47:15 接著進入 Q&A，大約剩 10 分鐘
  ↳ 接下來進入觀眾問答，大約剩 10 分鐘。
• 47:45 Q：怎麼用 Codex 做簡報？A：雖然可以讓它用 Python 做 PowerPoint，但這份簡報只是 HTML。他口述了想要的所有 context，請 Codex 做成 HTML
  ↳ 他這份簡報其實是網頁（HTML 是網頁的格式），不是 PowerPoint。雖然也能叫 Codex 用 Python 做出 PPT，但他是把想講的內容用口說交代給 Codex，請它直接做成網頁。
• 47:45 他請 Codex 查出 OpenAI 用的是哪些字型，並找相似的字型來用
  ↳ 外觀部分，他請 Codex 查出 OpenAI 用的是哪些字型，再找長得類似的字型來用。
• 48:15 講者說 Codex 非常擅長用 React 快速產出一堆單頁投影片，而且做得不錯
  ↳ React 是製作網頁介面的常見工具。講者說 Codex 用它能很快做出一頁一頁的投影片，品質也不錯。
• 48:15 下一題觀眾提問：從管理角度看有沒有檢查點或回溯選項？有沒有計畫推出共享討論串之類的協作功能？（本段在此結束，尚未回答）
  ↳ 有觀眾問：從管理角度來看，有沒有存檔點可以退回先前的狀態？會不會推出多人共用同一串對話之類的協作功能？這段到這裡結束，還沒有回答。

依講者的做法，跨多個模組共通的資訊應該放在哪裡？