ClawLabs：一起打造開源 | DevDay 2026（第 2/3 段） ☕ Buy me a coffee

🧑‍🏫 這段是 OpenAI DevDay 2026 的開源專案分享。講者示範團隊把人和 agent（能自己動手完成任務的 AI 助手）放在同一個 server 上一起工作，彼此的過程都看得到。內容包括 dashboard、自動化，以及兩種讓 agent 長期幫忙做事的方式：loop 和 goal。很適合想知道「AI 寫程式的團隊實際怎麼分工」的人。

• 11:38 新常態下，團隊成員可以互相學習，而且能更早抓到錯誤
  ↳ 「新常態」是指人和 agent 都在同一個團隊 server 上工作，彼此的過程都看得到。這樣大家能互相偷學做法，也能在問題變大之前先發現。
• 12:08 情境示範：講者看到 Roboclaw 的 pull request，有人把表格改小，跟自己把表格改大的工作衝突了
  ↳ pull request（PR）是把自己的修改提出來，請別人看過再合併。示範中，同事在 PR 裡把表格改小，講者自己卻正在把表格改大，兩邊方向衝突。
• 12:08 以前可能會直接傳一則不太客氣的訊息給對方；現在可以點進對方的 work session 看他做了什麼
  ↳ 以前遇到這種事，很多人第一反應是傳訊息質問。現在可以先點開對方的 work session（他和 agent 工作的完整紀錄），看清楚他做了什麼、為什麼這樣做。
• 12:39 點進 session 後發現 Victor 沿用了講者的 session，也有 ping 講者
  ↳ 點開才發現，Victor 是接著講者原本的 session 繼續做，也有 tag 講者通知。所以他不是亂改，而是在銜接講者的進度。
• 12:39 從 session 中看出 Victor 對 CI 時間不滿意；講者認為現行工作方式跟不上新時代的需求
  ↳ CI（持續整合）是每次改程式就自動跑一輪測試的流程。Victor 嫌它跑太久。講者藉此指出，現在改程式的速度快很多，舊的測試流程反而拖慢大家。
• 13:12 講者認為現行 CI 已經不合理。他正在用 codecs（字幕原文）實驗，想靠 intelligence 判斷哪些測試子集真正有用，細節留待另一場演講
  ↳ 講者的想法是不必每次都跑全部測試，而是讓 AI 判斷這次改動真正需要跑哪些測試。他正在用字幕寫作 codecs 的工具實驗，細節留到另一場演講。
• 13:12 往上看完整內容後，講者發現 Victor 其實是拿他的成果再修好，衝突就此化解
  ↳ 把整段紀錄看完，才知道 Victor 是拿講者做好的成果再修好，不是推翻它。因為過程透明，誤會還沒吵起來就解決了。
• 13:46 團隊把 server 當成一個「地方」而不是一個 app，因為做專案不只是寫程式；sidebar 上有許多 app，包括 dashboard 和 plug-in
  ↳ 他們把 server 當成大家一起上班的「地方」，因為做專案不只是寫程式。側邊欄（sidebar）放了各種 app，像 dashboard（集中看數據的畫面）和 plug-in（外掛小工具）。
• 14:16 這些工具以前分散在不同 server、GitHub Actions、資料庫和 repository，講者自己都搞不清楚有哪些，也不方便團隊參與更新
  ↳ 以前這些工具散在不同主機、GitHub Actions（GitHub 的自動化流程）、資料庫和 repository（放程式碼的倉庫）。連講者都記不清有哪些，其他人更難參與更新。
• 14:16 例子：講者做了追蹤 CI 時間的 dashboard，想調整時直接跟 agent 說「make this blue」，dashboard 就會隨時更新
  ↳ 講者做了一個追蹤 CI 跑多久的 dashboard。想改外觀不用自己寫程式，只要跟 agent 說「改成藍色」，畫面就會跟著更新。
• 14:46 多數 dashboard 的本質是：一個產生 artifact 的 session，加上一個更新該 session 的 automation，而 artifact 裡面就是程式碼
  ↳ 拆開來看，大多數 dashboard 是這樣組成的：一段 session 產出 artifact（成品，裡面其實就是程式碼），再加上一個 automation（自動化排程）負責叫那段 session 更新它。
• 15:16 因為迭代速度太快，講者覺得這已經不太像 software，提出「jellyware」這個說法
  ↳ 改一個工具只要講幾句話就完成，變動快到不像傳統那種寫好就固定的軟體。所以講者把 software 改叫 jellyware（jelly 是果凍）。
• 15:16 社群 dashboard 追蹤的數字包括：PR 數量、回報的 issue 數量、合併的數量
  ↳ 社群 dashboard 看三個數字：收到多少 PR、有多少 issue（使用者回報的問題）、最後合併了多少。用這些數字掌握開源社群的參與狀況。
• 15:47 Daily Claw 會整理 server 上合併的內容，做成一份報紙；有時寫得不錯，但很多時候錯得離譜。講者強調做東西要有樂趣
  ↳ Daily Claw 會把 server 上合併的改動整理成一份「報紙」。內容有時不錯，但常常錯得離譜。講者不太在意，他強調做東西本來就要好玩。
• 15:47 slop meter：agent 很容易產生越來越多程式碼而陷入糟糕狀態，所以要一直推 agent 去清理；有了這個 dashboard 後，大家的意識提高了，數據也往好的方向走
  ↳ agent 很容易越寫越多，最後亂成一團。slop meter 就是盯著這種過量、粗糙程式碼的儀表。有了它，大家會記得叫 agent 去清理，數據也確實變好了。
• 16:19 以上這些都只是 HTML plugin；另外也有真正以程式碼寫成的，例如 reports，可以看每個人的活躍度、commit 數、Discord 活躍程度
  ↳ 前面那些其實都只是一頁 HTML（網頁格式）的小外掛。也有真正寫成程式的，例如 reports，可以看每個人的活躍度、commit（提交修改）次數和 Discord 發言量。
• 16:49 meetings 功能：原本付費使用的會議軟體被改成一個 prompt，用 Luna 摘要逐字稿，開會時 agent 會加入 Discord
  ↳ 原本付費的會議軟體，被換成一段 prompt（給 AI 的指令）。開會時 agent 會加入 Discord，再用字幕寫作 Luna 的工具摘要逐字稿。
• 17:19 agent 現在還能回話：接上 GPT live 後，可以問 agent 工作相關問題或開啟新工作。因為代表 server 的是同一個 identity、同一個掌握全局的 main session，所以效果很好（今天未示範）
  ↳ 接上字幕所說的 GPT live 後，agent 能直接回話，可以問它工作上的事或派新任務。效果好的原因是它代表整個 server，用的是同一個掌握全局的 main session。今天沒有示範。
• 17:50 server 上有線上成員的檢視畫面，可以看到誰在線、誰在執行工作；Victor 重做了講者原本做的 sidebar 小檢視
  ↳ 有一個畫面能看到誰在線上、誰正在跑工作，就像看同事在不在座位上。講者原本做的側邊欄小視窗，被 Victor 重做了一版。
• 18:21 可以直接看到別人怎麼和 agent 互動：Victor 產出了大量設計迭代，甚至做了整個 editor 來微調，後來還有其他人加入一起協作
  ↳ 你能直接看到別人怎麼跟 agent 溝通。Victor 讓 agent 產出大量設計版本，還做了一整個編輯器來微調，後來其他人也加入一起改。
• 18:52 這些視覺化在「codec set」（字幕原文）裡也能用；講者說還卡在 CLI 就等於卡在 2025 年
  ↳ 這些視覺化畫面在字幕寫作「codec set」的工具裡也能用。CLI 是打字下指令的黑底視窗；講者的意思是，如果還只在 CLI 裡跟 agent 互動，就已經落伍了。
• 19:24 講者提到有些公司會在視訊通話裡開 terminal 跟 agent 對話，並表示有更好的做法
  ↳ 他提到有些公司會在視訊會議裡開 terminal（打指令的視窗）跟 agent 對話。他認為有更好的做法，也就是像這樣把協作放到團隊 server 上。
• 19:24 更大的願景：打造一個會幫我們寫軟體的 agent，通往「software factory」；不過有些工作仍需要親手和 agent 互動
  ↳ 更大的目標是做出一個會自己寫軟體的 agent，也就是一座「軟體工廠」（software factory）。但他也承認，有些工作還是得人親手跟 agent 互動。
• 19:54 講者跑很多 loop 來監控回饋並自動 land 修正；這些 loop 分散在不同機器上，有時會停掉或需要調整，連在哪台機器都不確定，所以 loop 需要維護
  ↳ loop 是一直重複執行的自動化工作。講者跑很多 loop 監看回饋，再自動把修正 land（正式合進程式碼）。但它們散在不同電腦，會停掉、需要調整，也要有人維護。
• 20:27 人的價值在於 taste（品味）。品味很難描述，常常只是一種感覺，講者不想完全交給 agent
  ↳ 人的價值在 taste（品味），也就是判斷什麼好、什麼不對勁。這常常說不出理由，只是一種感覺，所以講者不想全交給 agent。
• 20:27 一個人跑太多 loop 在團隊中行不通，所以正逐一把 loop 移到 team server，讓其他人也能學習；最終團隊要維護的是那個打造軟體的 agent
  ↳ 一個人自己顧一堆 loop，在團隊裡行不通。所以他正把 loop 一個個搬到 team server，讓別人也看得到、學得到。最後團隊要維護的，是那個打造軟體的 agent。
• 20:58 監控 loop 會掃描 Discord、Twitter、GitHub；講者寫了小型 CLI，讓 agent 容易取得大量資料，再把資料分類
  ↳ 監控用的 loop 會去 Discord、Twitter、GitHub 找使用者回饋。講者寫了小型 CLI 工具，讓 agent 能輕鬆撈到大量資料，再分類整理。
• 20:58 以 update issue 為例：agent 讀報告並調查 → 開新的 test box 重現錯誤 → 能明確重現就提出修正 → 驗證是否修好 → 由另一個 agent 審查 → 自動 land
  ↳ 以更新問題為例：agent 讀回報、調查 → 開新的 test box（測試用環境）重現錯誤 → 能明確重現才修 → 確認修好 → 另一個 agent 審查 → 自動合進去。
• 21:30 loop 和 goal 的差別：loop 是持續不斷地檢查；講者另有一個 performance loop
  ↳ loop 和 goal 不一樣。loop 沒有終點，就是持續巡邏檢查，例如講者另外有一個專門盯效能的 performance loop。
• 21:30 team server 每天都會發布新版本，update loop 偵測到後會拍 snapshot，檢查有沒有問題
  ↳ 例如 team server 每天都會發新版本。update loop 偵測到新版本後，會拍一個 snapshot（當下狀態的完整留存），檢查有沒有出問題。
• 21:30 用 slash goal 下的任務，是朝一個明確的終點狀態推進
  ↳ goal 是用 /goal 指令下的任務，有明確終點。你先講清楚「最後要變成什麼樣子」，agent 就一步步往那裡推進。
• 22:02 goal 實例：一點一點把 codebase 從同步 SQLite 遷移到非同步資料庫存取；目前仍用 SQLite，但隨著 server 成長，正考慮讓資料庫本身可替換
  ↳ SQLite 是一種輕量資料庫。「同步」指每次讀寫資料都要等它做完才繼續；他們要一點一點改成「非同步」，也就是不必乾等。這也是為了以後能更換資料庫。
• 22:02 這個 goal 已經跑了 18 天，仍在講者本機的 codecs（字幕原文）上執行，至今已 land 超過 100 個 PR
  ↳ 這個 goal 已經連續跑了 18 天，目前還在講者自己電腦上的工具裡執行，至今合進了超過 100 個 PR。這種又長又瑣碎的大工程，正適合交給 goal。
• 22:33 長期目標：每個專案都有一個 agent，擁有自己的 memory、automations、goals、loops，講者只要下高層指令，它就會維護並改進軟體
  ↳ 長期理想是每個專案都配一個 agent，有自己的記憶、自動排程、goal 和 loop。人只要下大方向的指令，它就自己維護並改進軟體。
• 22:33 回頭看現場觀眾做了什麼：有 release radar，還有一個遊戲
  ↳ 回頭看現場觀眾用這套環境做了什麼：有一個叫 release radar 的工具，還有人做了一個遊戲。
• 23:03 講者提到可以讓 agent 來玩遊戲，認為現在 agent 可能玩得更好，因為這些都支援 Kua（字幕原文）
  ↳ 講者說可以讓 agent 來玩這個遊戲，現在 agent 可能玩得比人好。他給的原因是這些東西都支援字幕寫作 Kua 的功能，影片沒有進一步解釋。

講者提到那個「把 codebase 從同步 SQLite 遷移到非同步資料庫存取」的 goal，目前的狀況是？