教 agent 向你的團隊學習（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這支影片的講者是 Warp 的 Petra。她用 Warp 自家的社群回覆小幫手 Buzz 當例子，講一件很多人都卡過的事：AI 做到八成好就上不去了，尤其是回訊息這種靠分寸和品味的工作。如果你常覺得 AI 寫的東西「差一點」，又不知道怎麼教它，這段會很有感。

• 00:27 講者 Petra 負責 Warp 的 developer experience，介紹 Warp 是執行、管理 agent 的地方，也可以在裡面使用 Cloud Code（照字幕原文）
  ↳ 講者 Petra 在 Warp 負責 developer experience，也就是對外介紹產品、經營社群、做內容。她說 Warp 是執行和管理 agent（會自己動手做事的 AI 助手）的工具，裡面也能用 Cloud Code（照字幕原文）。
• 00:57 這場演講透過 Warp 打造社群回覆小幫手 agent「Buzz」的經過，說明怎麼教 agent
  ↳ 整場用一個真實案例串起來：Warp 做了一個幫忙回社群留言的 agent，叫 Buzz。重點不在寫程式，而在怎麼「教」它把事情做好。
• 01:27 現場舉手調查：很多人做過 agent，也有不少人讓 agent 每天或每週執行，但仍在 production 上天天跑、而且很滿意的人少很多
  ↳ 做過 agent 的人很多，讓它定期跑的也不少。但真正放上 production（正式上線、每天在真實環境跑），而且用得滿意的人少很多。做得出來和敢放手用，是兩回事。
• 02:01 很多 agent 做到大約 80% 就卡住，大致能用但還不夠放手讓它上 production
  ↳ 很多 agent 卡在「八成好」：大部分時候能用，偶爾還是會出包。所以你不敢讓它自己上線，得一直有人盯著。
• 02:01 卡在 80% 可能比沒有 agent 更糟，因為會一直花時間微調、改 prompt
  ↳ 卡在八成反而麻煩。你會一直覺得「再調一下就好」，不斷改 prompt（給 AI 的指示文字），時間一直花卻看不到終點，可能比自己動手還累。
• 02:42 Buzz 負責監控 Warp 在社群上被提及的內容，協助決定怎麼處理
  ↳ Buzz 的工作是盯著網路上誰提到 Warp，再幫團隊決定每一則該怎麼處理。
• 03:12 使用者會來問問題、回報 bug、打聽新功能；回覆定調了產品、公司與社群的形象，但新創不想為此請一大批人
  ↳ 社群上有人來問問題、報 bug、打聽新功能。怎麼回，會影響大家對產品和公司的印象。但小新創沒本錢請一整組人專門回留言。
• 03:49 Buzz 幫忙判斷要回覆（例如有問題或產品回饋）、按讚（表示互動），還是略過（跟 Warp 無關、對方不期待回應，或在跟別人對話）
  ↳ Buzz 會先分三類：有問題或回饋就回覆；只需要表示「有看到」就按讚；跟 Warp 無關、對方沒在等回應，或人家在跟別人聊，就不插嘴。
• 03:49 決定要回覆時，Buzz 也會幫忙草擬訊息，不必從零開始寫
  ↳ 判斷要回覆時，Buzz 會先擬好一版草稿。人只要看過、修一修就好，不用對著空白框從頭想。
• 04:22 Buzz 大幅省下時間，讓小團隊能把心力放在高 ROI 的社群互動上
  ↳ 篩選和打草稿的時間省下來，小團隊就能把力氣留給最值得親自出手的互動。ROI 是投資報酬率，這裡指花同樣時間、效果最大的那些時刻。
• 04:22 Buzz 幾天內就做好，由大約 15 個 skill 組成，幾乎沒寫任何程式碼，全部是 skill file
  ↳ Buzz 幾天就做好，由大約 15 個 skill 組成。skill 是寫給 agent 的說明檔，教它某件事怎麼做。Buzz 幾乎沒寫程式，靠的全是這些檔案。
• 04:52 Buzz 串接 XAPI、Slack 等服務，和團隊其他成員及脈絡接在一起
  ↳ Buzz 串接 XAPI（抓取 X，也就是 Twitter 貼文的介面）和 Slack 等工具。所以它不是單打獨鬥，而是跟團隊成員和工作脈絡連在一起。
• 04:52 挑戰：社群回覆需要判斷力和品味，包括何時說、說什麼、怎麼說，以及何時完全不要介入
  ↳ 難的是「分寸」：什麼時候開口、說什麼、用什麼語氣，甚至什麼時候乾脆別出聲。這些靠判斷和品味，沒有標準答案可以查。
• 05:24 Twitter 上一眼就看得出是 AI 生成的回覆會讓人不想互動；目標是做出更好、真正能深度經營社群的回覆
  ↳ 在 Twitter 上，大家一眼就認得出 AI 寫的罐頭回覆，通常會懶得理。他們要的不是這種，而是真的能跟人建立關係的回覆。
• 05:54 目標不是「勉強能貼」，而是讀起來像真人寫的，而且理解產品和公司的脈絡
  ↳ 標準定得很高：不是「貼出去不丟臉」就好，而是讀起來像一個懂產品、懂公司狀況的真人親手寫的。
• 06:24 常見做法是 agentic loop：agent 很擅長反覆嘗試，只要它能判斷自己有沒有達成目標
  ↳ 常見做法是 agentic loop：讓 agent 做、檢查、再改，一直重複到達標。前提是它要有辦法知道自己到底做對了沒有。
• 06:54 Ralph loop 之所以好用，是因為有外部檢查，讓 agent 知道自己是否達成特定目標
  ↳ Ralph loop 是其中一種做法。它好用的關鍵是有外部檢查（external check），也就是一個不由 agent 自己說了算的判準，明確告訴它有沒有達標。
• 06:54 外部檢查很適合寫程式：可以跑 unit test，或用 computer use、browser use 驗證
  ↳ 寫程式特別適合這招。可以跑 unit test（預先寫好、自動驗證程式對不對的小測試），也可以用 computer use、browser use（讓 agent 自己操作電腦或瀏覽器）實際看結果。
• 07:26 做法例如在瀏覽器確認、呼叫 API、下 curl 指令，看有沒有達到目標，沒有就繼續迭代
  ↳ 例如打開網頁看畫面對不對、呼叫 API（程式之間溝通的介面）看回傳內容，或下 curl 指令（在命令列送出網路請求的工具）測試。沒達標就繼續改。
• 07:26 需要判斷力、品味、沒有 unit test 的任務，很難建立這種 loop
  ↳ 但像回留言這種靠判斷和品味的事，沒有哪個測試能跑出「對」或「錯」，這種自動循環就很難建立。
• 07:26 社群回覆要做外部檢查，得實際發很多回覆，再觀察使用者反應、品牌觀感和旁觀者的看法
  ↳ 回覆好不好，真正的檢驗在發出去之後：當事人怎麼回應、品牌形象有沒有受影響、路過的人怎麼看。這得實際發很多則才會知道。
• 08:17 這類回饋迴圈複雜又漫長，沒辦法像 unit test 一樣設成 agent 的外部檢查
  ↳ 這種回饋又慢又雜，要等一段時間才看得出來。它沒辦法像測試那樣，很快給 agent 一個明確的是或否。
• 08:17 核心問題：怎麼把知識、判斷力和品味交給 agent，讓它處理人類懂得的細微差別與脈絡
  ↳ 所以真正的問題是：人腦裡那些說不太清楚的經驗、分寸和品味，要怎麼交給 agent，讓它也能看懂細微差別。
• 08:53 同樣的問題也出現在客戶回覆、Slack 訊息、code review 留言等需要判斷、無法用 unit test 驗證的任務
  ↳ 這不只是社群回覆的問題。回客戶信、寫 Slack 訊息、在 code review（同事互相檢查程式碼）留意見，都要看場合拿捏，也都沒辦法用測試驗證。
• 08:53 第一個嘗試是把 prompt 寫到位
  ↳ 他們的第一招很直覺：把 prompt 寫得夠完整、夠好。
• 09:25 做法：寫一個涵蓋所有需求的 prompt，再請 agent 找出矛盾、模糊和缺漏的地方，一起改進
  ↳ 先寫一份涵蓋所有需求的 prompt，再請 agent 反過來挑毛病：哪裡互相矛盾、哪裡講不清楚、哪裡漏掉了，然後一起改。
• 09:55 結果 prompt 變成一張「發生 X 就做 Y」的規則清單
  ↳ 改到最後，prompt 變成一長串「遇到 X 就做 Y」的條文，像一本規定手冊。
• 09:55 規則清單的問題：回覆聽起來像機器人；一遇到新狀況就壞掉，因為規則太脆弱、缺乏彈性
  ↳ 照條文回話，聽起來就像客服機器人。而且只要碰到條文沒寫到的情況，它就不知道怎麼辦，因為規則寫死了，沒有彈性。
• 10:25 轉而思考怎麼跟新進成員說明：跟 agent 合作很像帶新人
  ↳ 於是他們換個角度：如果要教的是新同事，你會怎麼講？跟 agent 合作，其實很像帶新人。
• 10:25 帶新人不會只丟規則，而是說明怎麼思考、怎麼做決定、怎麼推理，以及跟社群互動的目的
  ↳ 帶新人不會只丟一本規定給他。你會解釋自己怎麼想、怎麼做決定、背後的理由是什麼，還有經營社群到底是為了什麼。
• 10:25 原則範例：使用者抱怨時不要防衛心重，要友善、有同理心，展現產品開發者的樣子，而不只是處理支援請求的人
  ↳ 例如：有人抱怨時別急著辯解，要友善、有同理心，讓對方感覺是做產品的人在聽他說話，而不只是客服在處理案件。
• 10:58 把 agent 從規則清單改成依原則運作後，skill file 縮短到原本的五分之一左右，效果一樣甚至更好
  ↳ 把規則清單改寫成原則之後，skill file 只剩原本大約五分之一長，效果卻一樣，甚至更好。
• 11:42 原則在新狀況下更有彈性，agent 更能據此推理，所以檔案更短、產出更好；這是第一個有效的做法
  ↳ 原則教的是思考方式，遇到新狀況時 agent 能自己推想該怎麼做。規則只告訴它「若 X 則 Y」，原則則說明「為什麼」。這是第一個真正有效的方法。
• 11:42 但結果還是沒好到可以原封不動直接發出去
  ↳ 不過雖然有進步，產出的回覆還是需要人修過，沒辦法直接照發。
• 12:18 下一步照一般工程流程：測試、評估結果、修正看到的問題
  ↳ 下一步照工程師平常的流程走：實際測試、檢查結果、把發現的問題修掉。
• 12:18 實際做法：收集一批要分類的貼文，讓 agent 給出建議的處理方式或回覆
  ↳ 他們找來一批真實貼文，讓 agent 對每則給出建議：要回覆、按讚還是略過。要回覆的，就附上草稿。
• 12:53 講者逐一給回饋：哪裡好、哪裡不好、自己會怎麼改寫、為什麼不該回，累積成一組人類回饋，再請 agent 據此改進
  ↳ 講者一則一則批改：哪裡好、哪裡不行、她會怎麼寫、為什麼這則不該回。累積一批意見後，再請 agent 根據這些意見改進自己。
• 13:24 結果 agent 又回頭加規則，例如「使用者遇到某問題時，第一句絕不要提價格」，只適用單一案例，無法套用到多數情況
  ↳ 結果 agent 又走回老路，把意見變成很窄的新規則，例如「使用者遇到某問題時，第一句絕不提價格」。這只救得了那一則，換個情況就沒用。
• 13:55 更好的學習應該像「使用者在抱怨產品時，不要推銷產品的其他部分」這樣，更有彈性
  ↳ 比較好的做法是把教訓往上抽一層，例如「使用者在抱怨時，別趁機推銷其他功能」。這樣就能套用到很多類似的場合。
• 13:55 結論：要教 agent 換一種學習方式，也就是讓 agent 學會怎麼學習，並再次參考帶新人的方式
  ↳ 結論：問題不在有沒有給回饋，而在 agent 怎麼消化回饋。要教它學會「怎麼學」，方法一樣可以參考怎麼帶新人。

Warp 團隊把 Buzz 從「規則清單」改成「原則」後，skill file 的長度變成原本的多少？