用 Codex 從單人模式走向多人協作 | DevDay 2026（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 OpenAI 開發者大會一場演講的後半段。講者分享他怎麼把 AI 助手從「自己一個人用」變成「整個團隊一起用」：讓它在雲端持續做事、共用同一份文件和工具。如果你已經習慣自己跟 AI 對話，這支片會讓你看到下一步：讓 AI 幫你把人和事串起來。

• 11:30 講者知道事情能在背景執行，因此改變了與團隊的工作方式；他也說自己比較喜歡跟真人講話的聲音，而不是 AI 的聲音
  ↳ 他知道 agent（能自己動手做事的 AI 助手）可以在背景繼續跑，你沒盯著它也在做事，所以改了和團隊合作的方式。他也坦白說，比起 AI 的聲音，他更喜歡聽真人說話。
• 11:30 開會時一有好點子（部落格文章、劇本、廣告、產品文案），他會直接在通話中下 prompt，例如請 dot 先起草，之後再一起審閱
  ↳ 開會時一冒出好點子，例如部落格文章或廣告文案，他會當場對 dot（他給自己 agent 取的稱呼）下 prompt（給 AI 的指令），請它先寫草稿，會後大家再一起看、一起改。
• 12:02 會議結束時，他除了分派 action items 給團隊，也分派更多給自己的 agent
  ↳ 會議結尾分配 action items（會後待辦事項）時，他不只派給同事，也派很多給自己的 agent，等於團隊多了一個會接工作的成員。
• 12:02 例：請 agent 用 Slack connector 傳訊息給兩個人，確認他們是否理解改了什麼，等對方回覆後再貼回主要 Slack 頻道
  ↳ 例如請 agent 用 Slack connector（讓 AI 代你在 Slack 工作聊天軟體發訊息的串接功能）私訊兩位同事，確認他們懂這次改了什麼，收到回覆後再貼回主頻道。
• 12:02 例：請 agent 用他的瀏覽器在線上聯絡四個人，請他們提供 feedback IDs
  ↳ 另一個例子：請 agent 用他的瀏覽器上網聯絡四個人，請對方提供 feedback IDs（每筆回饋的識別編號），方便之後追查。
• 12:36 這些都是很簡單的事，但他現在能信任 agent 會替他持續處理，不必事後再打開會議逐一交代；講者稱這是在 context 之上加入 persistence 的優勢
  ↳ 這些都是小事，重點是他相信 agent 會一直追到做完，不用會後翻紀錄一件件交代。他說這是在 context（AI 掌握的背景資訊）之上多了 persistence（持續做下去）。
• 12:36 對話也會發生在會議之外，這時 embodiment 很有幫助：與隊友的對話最終會變成雲端 agents 使用的 prompts
  ↳ 很多討論是平常聊天時發生的。這時 embodiment（讓 agent 有個像同事一樣的身分）很有用：你和隊友的對話，最後會變成交給 cloud agent（在雲端跑的 agent）的指令。
• 13:08 agent 有不同的 identity，更具 embodiment：在 Slack 或 Teams 裡可以直接 tag 你的 dot，請它後續跟進
  ↳ agent 有自己的 identity（身分帳號），所以在 Slack 或 Teams（微軟的工作聊天軟體）裡，可以像 tag 同事一樣 tag 你的 dot，請它接手後續。
• 13:08 例：和同事討論設計或開完會後，直接打「@JSON dot, please investigate」；講者說這讓他覺得自己像到處 tag 人的 CEO
  ↳ 例如討論完設計，直接打「@JSON dot, please investigate」叫它去查。他開玩笑說，這讓他覺得自己像到處點名交辦事情的 CEO。
• 13:08 可以有你的 dot、我的 dot，未來也會有 team dots；目標是讓 agent 在使用者所在的地方與他們互動
  ↳ 以後會有你的 dot、我的 dot，也會有整個團隊共用的 team dots。方向是讓 agent 到使用者本來就在的地方互動，人不用特地去找它。
• 13:39 他們未來會推出更多服務
  ↳ 他提到之後會推出更多相關服務，這段沒有講細節。
• 13:39 context 透過講者的聲音、同事的聲音、各種 plug-ins 和瀏覽器帶進來之後，下一步是整理資訊並保持最新
  ↳ 資訊會從很多地方進來：他自己說的話、同事說的話、各種 plug-ins（外掛，替 AI 增加能力的擴充功能）和瀏覽器。資訊收齊之後，下一步是整理好，並且一直保持最新。
• 13:39 講者過去的 automations 和工作流程都只能在自己的本機運作
  ↳ 他坦承，以前做的 automations（設定好就會自動跑的流程）和工作流程，全都只能在他自己的電腦上跑。
• 14:09 只放在本機的問題：一是團隊無法參與貢獻；二是現在雲端 agents 好很多，他卻用不上這些成果
  ↳ 只放在自己電腦上有兩個問題：同事沒辦法一起加東西、一起改；而且雲端 agent 現在進步很多，他電腦裡的成果卻接不上去。
• 14:09 講者認為 agents 在單一 source of truth 上協作，是軟體工程生產力大幅提升的原因；知識工作還沒有做到這點
  ↳ 他認為寫程式的效率大增，是因為 agents 都在 single source of truth（大家以它為準的唯一資料來源）上一起工作。一般知識工作還沒有這種共同的底本。
• 14:39 做調查時，他會請 agent 依照既有的 template 在 space 裡建立新頁面，再分享給團隊和他們使用的 agents
  ↳ 做調查時，他請 agent 照現成的 template（範本）在 space 裡開新頁面，再分享給同事和他們的 agents。space 是團隊和 agents 可以共用的線上文件空間。
• 14:39 講者把 space 當成放在雲端的 local memory vault，只要交代 dot 持續追蹤並更新資訊，內容就會保持最新
  ↳ 他把 space 當成搬到雲端的記憶庫，原本只存在自己電腦裡的筆記現在放到雲端。只要交代 dot 持續追蹤、更新，內容就會一直是最新的。
• 15:09 他原本用 markdown 檔，因為 directories 和 agent MD files 很好用：各 automation 在不同 thread 執行，agent MD files 能確保寫入的內容人看得懂、引用正確、格式符合需求
  ↳ 他以前用 markdown 檔（用簡單符號標格式的純文字檔）加資料夾，再搭配 agent MD files（寫給 agent 看的規則檔）。各個自動流程分開跑，靠規則檔讓寫入的內容好讀、引用正確、格式對。
• 15:09 page automations 從 page instructions 開始，等於能替文件定義 agent MD files
  ↳ 在 space 裡，page automations（綁在某一頁的自動流程）從 page instructions（寫給這一頁的指示）開始設定，等於替每份文件寫一份專屬的規則檔。
• 15:39 agent MD file 可以規定 custom artifacts、embedded HTML 和視覺化內容是否由 agent 更新，讓所有同事的 agents 都能參與而不會弄得一團亂
  ↳ 這份規則可以講清楚哪些自訂內容、內嵌的 HTML（網頁格式）或圖表可以讓 agent 更新。這樣每個同事的 agent 都能進來幫忙，也不會把內容改亂。
• 15:39 例：這個 space 的 automation 很簡單，幾個 dots 負責更新 Slack 貼文、閱讀留言，整理已收集到的 feedback IDs
  ↳ 舉例來說，這個 space 的自動化很單純：幾個 dots 分工，有的負責更新 Slack 貼文，有的讀留言，有的把收到的 feedback IDs 整理起來。
• 16:10 automations 除了能設在 dot 層級，也能設在 page 層級，或設在 ChatGPT 裡建立的 team 層級
  ↳ automations 可以設在三個層級：某個 dot、某一頁，或在 ChatGPT 裡建立的整個 team。看這件事歸誰管，就設在哪一層。
• 16:10 財務團隊例：每週分析報告由雲端 agent 更新文件，並連接所有在雲端啟用的服務
  ↳ 財務團隊的例子：每週分析報告由 cloud agent 自動更新文件，而且它接上了所有在雲端開通的服務。
• 16:10 工程例：整理所有 pull requests 和專案範圍、找出 DRI，用單一頁面檢視所有待 merge 的項目
  ↳ 工程的例子：整理所有 pull requests（工程師送出、等人審核的程式修改）和專案範圍，找出 DRI（一般指直接負責人），用一頁看完所有等著合併的項目。
• 16:10 研究例：追蹤長時間執行的實驗
  ↳ 研究的例子：讓 agent 追蹤要跑很久的實驗，人不用一直守著。
• 16:42 講者用這套方式委派大部分 Dev Day 工作，包括這場演講與投影片更新、會場外的攤位（字幕記為 boosts）、mod retro
  ↳ 他說 Dev Day（OpenAI 開發者大會）大部分的工作都這樣交辦，包括這場演講和投影片更新、會場外的攤位（字幕寫成 boosts），還有 mod retro。
• 16:42 講者的目標是不被 Slack 分心，因為有些事情會很晚才進來
  ↳ 他的目標是不要一直被 Slack 打斷，因為有些訊息很晚才進來，不必每次都由他親自守著回。
• 16:42 流程三步：取得 context、用 automations 讓事情持續推進、把結果分享給團隊
  ↳ 整套流程就三步：先把 context 收進來，再用 automations 讓事情自己往前推，最後把結果分享給團隊。
• 17:12 理想中的 space 包含：事件時間軸、報告、線上收集的 feedback IDs，以及各段對話的連結與引用，讓大家知道該相信哪些資訊
  ↳ 他心中理想的 space 會有事件時間軸、報告、從線上收來的 feedback IDs，以及每段對話的連結和引用。有出處，大家才知道哪些資訊可以相信。
• 17:12 有了假設之後，可以把雲端 agent 指向這個 space，讓它重現問題、調查問題並嘗試解決
  ↳ 對問題有了初步猜測後，就可以讓 cloud agent 讀這個 space，照裡面的資料重現問題、查原因，甚至試著修好。
• 17:12 團隊也可以決定對外溝通內容，通知大家服務已恢復
  ↳ 同一份資料，團隊也能拿來決定對外怎麼說，例如發通知告訴大家服務已經恢復。
• 17:42 理想狀態是沒有人需要當「黏著劑」，大家能做出更有根據的決策，不必手忙腳亂去搞清楚問題何時處理好
  ↳ 理想狀態是沒有人需要當「黏著劑」，也就是到處傳話、拼湊資訊的那個人。大家看同一份資料做決定，不用慌亂地追問問題到底修好了沒。
• 17:42 值班過的人都知道 pull request 不是最終產出，之後還有 postmortems、簡報、部落格文章
  ↳ 值過班、處理過系統出包的人都知道，送出修好的 pull request 還不算結束，後面還要寫 postmortems（事後檢討報告）、做簡報、寫部落格文章。
• 17:42 你可能已經有溝通或設計用的 skills，但這些大多是以指令為主的 plugins
  ↳ 你可能已經有一些溝通或設計用的 skills（教 AI 做某類工作的指令包），但它們大多只是「一串指示」形式的 plugins。
• 18:12 如果把 rules 和 automations 看成讓工作持續推進、保持最新的方法，plugins 和 extensions 就是下一步
  ↳ 如果 rules（規則）和 automations 是讓工作持續推進、保持最新的方法，那 plugins 和 extensions（擴充功能）就是再往前一步。
• 18:12 plugins 可分享、可更新、有版本控管，改進後可以廣泛發布給整個團隊
  ↳ plugins 的好處是可以分享、可以更新，而且有版本控管，每一版都有紀錄、可以追溯。誰改進了，就能一次發給整個團隊用。
• 18:12 透過 plugin extensions 可以直接在 Codex app 裡建立自訂介面，讓 Codex app 成為所有工作的駕駛艙
  ↳ 透過 plugin extensions，可以在 Codex app（OpenAI 的 AI 寫程式工具）裡做出自己需要的操作畫面，讓這個 app 變成處理所有工作的駕駛艙。
• 18:12 他們的 meetings 產品和 code review 產品都是用同一套元件、以 plugins 形式打造
  ↳ 他們自家的會議產品和 code review（程式碼審查）產品，都是用同一套元件、以 plugins 的形式做出來的。
• 18:42 經常做網站的人，現在有更好的工具支援 log in with ChatGPT 和連接 connectors
  ↳ 常做網站的人，現在有更好的工具，可以讓網站支援「用 ChatGPT 帳號登入」，也能連接各種 connectors（串接外部服務的接口）。
• 18:42 網站現在也能提供帶驗證機制的 MCP servers
  ↳ 網站現在也能提供有驗證機制的 MCP servers。MCP 是讓 AI 連接外部工具和資料的通用規格；加上驗證，就能確認是誰在使用。
• 18:42 透過 WebMCP，可以打造人和 AI 能一起使用的工具
  ↳ 透過 WebMCP，可以做出人和 AI 都能一起操作的工具，同一套工具人能用，AI 也能用。
• 19:12 講者認為下一階段的重點不是用更多 agents 或 tokens，而是投資這套系統，讓 automations、plugins、skills 在團隊間共享，成為團隊共同的責任
  ↳ 他認為下一步不是堆更多 agents 或 tokens（AI 計算用量的單位），而是投資這套系統，讓 automations、plugins、skills 在團隊間共用，由大家一起負責維護。
• 19:12 講者提問：如何替團隊建立 agentic infrastructure、成為公司的 plugin hero？他認為來參加 Dev Day 的人大概就是這個角色
  ↳ 他問觀眾：要怎麼替團隊建立 agentic infrastructure（讓 agent 工具能共享的基礎系統），當公司裡的 plugin hero？他認為來 Dev Day 的人大概就是這個角色。
• 19:44 這不只適用於工程，講者也用 dots 和 space 管理製作拍攝、和團隊做內容規劃等事情
  ↳ 這套方法不只工程能用。他也用 dots 和 space 管理影片拍攝製作，以及和團隊一起規劃內容。
• 19:44 拍攝上市影片時他在片場很忙亂，dot 會在休息時間更新進度；他會給 dot 一些有挑戰性的任務，讓它想辦法自己排除阻礙
  ↳ 拍上市影片時他在片場忙翻了，dot 會趁休息時間更新進度。他也會丟比較難的任務給 dot，讓它自己想辦法解決卡住的地方。
• 20:14 有 10 分鐘空檔就讀更新，其他人也看得到；也能依回饋與核准流程修改網站或文件
  ↳ 有 10 分鐘空檔他就看一下更新，其他人也看得到同一份進度。他也能照回饋和核准流程，讓 agent 去改網站或文件。
• 20:14 時間很少時，他直接打電話給 dot，用語音作為更快的溝通方式
  ↳ 時間真的很趕的時候，他會直接打電話給 dot，用講的比打字快。
• 20:14 內容規劃例：與創意團隊、行銷團隊在 Slack 或會議中腦力激盪，dot 讓他對想法負責到底
  ↳ 內容規劃的例子：和創意、行銷團隊在 Slack 或會議中腦力激盪時，dot 會幫他把想法追到底，不會講完就不了了之。
• 20:45 因此他做了更多 skills、plugins 和網站來做 prototyping；有好點子就直接喊出來，之後 dot 會傳來網站或簡報，提出廣告或上市流程的做法
  ↳ 所以他做了更多 skills、plugins 和網站來做 prototyping（快速做出樣品試試看）。點子一說出口，dot 之後就會傳來網站或簡報，提出廣告或上市流程的做法。
• 20:45 講者說這幾個月來，automations 第一次替他把注意力找回來
  ↳ 他說這幾個月來，automations 第一次替他把注意力找回來，不再被瑣事切得零零碎碎。
• 21:16 結果是他能和同事多合作、想得更大、更有野心；團隊越能接手他的工作並往前推，他越覺得自己又在團隊裡工作了
  ↳ 結果他能和同事多合作，想得更大、更有野心。團隊越能接手他的工作往前推，他越有「又回到團隊裡一起工作」的感覺。
• 21:46 他說 2026 年很容易覺得自己帶著 coding agent 就能一路工作到凌晨 3 點，但他覺得那樣不好玩；他加入公司是為了和優秀的人一起解決問題
  ↳ 他說 2026 年很容易以為自己帶著 coding agent（寫程式的 AI 助手），就能一個人做到凌晨 3 點，但他覺得那樣不好玩。他來這家公司，是想和厲害的人一起解決問題。
• 21:46 講者引用一句話：希望 AI 幫他洗衣服、洗碗，讓他能創作藝術，並說自己正慢慢看到這件事發生
  ↳ 他引用一句話：希望 AI 幫忙洗衣服、洗碗，讓人有空去創作藝術。他說自己正慢慢看到這件事發生。
• 22:16 過去幾個月他有更多時間投入研究、創意、產品和行銷，比過去一個人「待在洞穴裡」時更開心
  ↳ 過去幾個月，他有更多時間投入研究、創意、產品和行銷，比以前一個人悶著頭做事開心很多。
• 22:16 結語：鼓勵觀眾親自試用這些工具，並在工作中帶入更多協作
  ↳ 結語：他鼓勵大家親手試試這些工具，並在工作裡多帶進一些協作，不要只是一個人跟 AI 埋頭苦幹。

講者說 plugins 具備哪些特性，讓改進可以廣泛發布給整個團隊？