> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # 「自我改進的 AI」是行銷詞：解碼 Warp 的 agent 迴圈，真正在改進的是那道人類核准關卡 - URL: https://growthhackers.tw/blog/warp-self-improving-agent-review-gate/ - Published: 2026-09-04T01:00:00.000Z - Updated: 2026-09-04T01:00:00.000Z - Description: Anthropic 官方案例說 Warp 做出了「會自我改進」的 agent。我把它拆完，還去查了它連出去的公開範例，結論跟標題不太一樣：真正在改進的不是 AI，是那道人類核准關卡。這篇拆給台灣電商：怎麼把公司的判斷變成可以看 diff、要簽名才能改的檔案，以及為什麼回饋要挑人，不是越多越好。 - Author: Lewis wang - Tags: AI agent, Agent Skills, AI 治理, AI 導入, 電商經營 先問你一個問題。 你公司那份客服應對規則、退換貨判斷準則、或是商品上架的文案規範，上一次是誰改的？什麼時候改的？為什麼改？ 我猜大部分人答不出來第三題。運氣好一點的，答得出前兩題。 這件事聽起來跟 AI 沒關係，但它其實就是你導入 AI agent 之後，半年內一定會撞上的那面牆。 Anthropic 最近發了一篇客戶案例，主角是 Warp，那家做 AI 終端機（terminal，工程師用來打指令的黑底視窗）的公司。標題叫 [How Warp builds self-improving agents on Claude](https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude?ref=growthhackers.tw)，講他們怎麼做出「會自我改進」的 agent。 我把它從頭到尾拆完，還去查了它連出去的那個公開範例。 結論跟標題不太一樣。 ## 你以為缺的是「會學習的 AI」 先講 Warp 是誰。2020 年創立，創辦人 Zach Lloyd。Anthropic 那篇官方案例宣稱的數字是：募資 7,300 萬美金、80 萬名月活躍開發者、Fortune 500 裡有 56% 在用、平台上累計跑過 1,000 萬次 Claude Code 任務。這些都是廠商自報，你參考就好。 有意思的是他們的起點。 Warp 內部做了一個「code review agent」，自動幫工程師審程式碼。結果工程師很不爽，嫌它給的意見沒用、品質差。 一個做 AI 開發工具的公司，自家的 AI 被自家工程師嫌棄。 他們第一時間的反應，跟你我會做的一模一樣：手動去改 prompt（提示詞）。哪次審爛了，就回去把提示詞補一句。後來又去補 AGENTS.md，那是給 agent 看的背景說明檔。 有用嗎？有一點。夠嗎？完全不夠。 因為問題根本不在提示詞寫得好不好。 Warp 團隊最後抓到的病灶是這句話：**回饋在 session（一次對話、一段執行脈絡）結束的那一刻就消失了。** 工程師今天在某個 PR（Pull Request，工程師送出程式碼變更、讓同事審查的流程）底下罵了一句「這個變數命名建議是錯的，我們的全域變數有自己的命名慣例」，這句話有沒有價值？價值高得不得了。那它去哪了？它躺在那則留言裡，然後 agent 下一次執行，完全不知道有這回事。 這就是我在台灣電商現場看到的同一件事，只是換了場景。 你的客服主管每天在後台看對話紀錄，心裡罵過幾百次「這句話不能這樣講」。你的行銷開完檢討會，會議紀錄寫了三頁。你的資深員工腦袋裡裝著一整套「什麼時候可以通融、什麼時候不行」的判斷。 這些東西，有哪一份是你的 AI 讀得到的？ ## Decode：兩層 skill，中間夾一個人 Warp 的解法簡單到有點反高潮。三段。如果「Agent Skills」對你還是全新名詞，可以先看我整理過的[這篇入門](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)，一句話講就是：把團隊知識寫成 AI 讀得到的檔案。 **第一段，inner skill（內圈技能）。** 一份檔案，裝領域知識和做事的指示。PR 一開，agent 讀這份檔案去審程式碼。 **第二段，人的回饋。** 人在原地留言。可以只是按個讚，但 Zach 講得很白，越具體越好：「你建議改這個變數名稱，但我們的慣例是這種全域變數要用那種命名方式。」這種回饋才告訴 agent 下次怎麼做對。 **第三段，outer skill（外圈技能），他們叫 improver skill（改進者技能）。** 一個觀察者 agent，不是每次任務都跑，是排程跑。它把累積的人類回饋撈出來，比對「agent 建議了什麼」跟「人怎麼回應」，然後提出一個**小幅度、聚焦的修改**，去改第一段那份檔案。 到這裡都還算常見。關鍵在下一句。 Warp 官方稿的原文是：這些更新「reviewable, approvable, and mergeable」。可以審查、可以核准、可以合併。 它會開成一個 PR。人去看、去批准、去合併。**合併之後，下一次 inner skill 才會繼承這個改進。** Anthropic 那篇文章自己寫了一句我認為全文最值錢的話：「That final human step closes the loop and keeps a person in control of what actually changes.」最後那個人類步驟閉合了迴圈，讓人保持在「到底什麼被改了」的控制權上。 看懂了嗎？ 在「規則要不要改」這件事情上，AI 只做兩件事：讀回饋、寫一份修改建議。 決定要不要改的，從頭到尾都是人。 所謂「自我改進的 agent」，改進的其實是一份**被人簽名核准過的檔案**。模型本身沒有變聰明，變的是它下一次執行前會讀到的那份知識。 ![兩層 skill 自我改進迴圈：執行、回饋、提案、PR、人類核准，核准後才回到執行](https://growthhackers.tw/content/images/2026/08/warp-inline-two-layer-loop-v1.png) 兩層 skill 自我改進迴圈：執行、回饋、提案、PR、人類核准，核准後才回到執行 ## 這就像白板跟食譜手冊的差別 我用餐廳來打個比方，這是這篇最重要的一個概念。 餐廳後場通常有兩種東西。一種是牆上那塊白板，寫著「今天九層塔不新鮮少放一點」。誰都能寫，天天在變，下週沒人記得上週寫過什麼。 另一種是那本食譜手冊。要改配方，得經過主廚同意，改完全店照做。 Warp 那份 best practice 表格第一條就在講這件事，講得比我清楚： **Skills 是程序性的、穩定的，是「怎麼做 X」，跟單次執行無關，要改就是刻意去改。Memory（記憶）是 agent 在推論當下自己寫進去的，而且永遠不會停止改變。** 白板是 memory。食譜手冊是 skill。 ![記憶像雜亂的白板，技能像要簽名核准才能改、還有版本的食譜手冊](https://growthhackers.tw/content/images/2026/08/warp-inline-whiteboard-vs-cookbook-v1.png) 記憶像雜亂的白板，技能像要簽名核准才能改、還有版本的食譜手冊 我看過太多公司把這兩個搞混。興沖沖打開 AI 的記憶功能，以為「讓它自己記」就等於「它會越來越懂我們」。 結果半年後那個記憶庫變成什麼？變成那塊白板。塞滿矛盾的、過期的、某個人某天隨口講的東西，沒人知道哪一條還算數，也沒人敢刪。 以前你的 SOP 是一份 Word 檔，三年來每個人都往裡面加東西，沒人敢刪。現在你有 AI 了，如果沒設計好，你只是把那份沒人敢刪的 Word 檔，換成一個沒人看得懂的記憶庫。 ## 最反直覺的一條：回饋要挑人 如果你問我，這篇來源裡最違反台灣電商直覺的，是這一條。 大部分老闆聽到「回饋迴圈」的第一個念頭是什麼？「那我把所有客服對話、所有客訴、所有評價全部丟進去讓 AI 學。」資料越多越好嘛。 Warp 的答案是相反的。 那份表格裡有一題問「回饋是錯的怎麼辦」，答案第一句就是：**假設它一定會是錯的（Assume it will be）。** 接下來三個處方：不要讓 agent 照單全收，要給它能自我檢查的背景；**過濾誰的意見算數**；人要留在過濾端或最終審查端。 另一題講得更狠。如果你的領域沒辦法用程式自動驗證對錯，那就**限定領域專家，不要打開閘門**（don't open the floodgates）。 Zach 補了一刀：品質大於數量。一個資深的人給的一段詳細、帶領域知識的回饋，價值可能勝過一堆讚跟倒讚，因為二元的讚**不會告訴你為什麼**。 翻成台灣電商的語言： 你那個 AI 客服的話術，要不要收五個客服、三個行銷、老闆娘、還有你表弟的意見？ 不要。指定一個人，或兩個。寫下名字。 ![回饋漏斗：大量雜訊回饋經過「誰的意見算數」這道濾網，只留下少量高品質訊號](https://growthhackers.tw/content/images/2026/08/warp-inline-feedback-funnel-v1.png) 回饋漏斗：大量雜訊回饋經過「誰的意見算數」這道濾網，只留下少量高品質訊號 我在雨傘產業那七年，最深的體會之一就是這個。換季怎麼備貨、哪種客訴可以退、百貨檔期的規則怎麼跟專櫃講，這些判斷從來沒寫下來過，全靠口頭交代。誰講的算數？看那天誰在現場。等到最懂的那個人離職，整套判斷就跟著走了，剩下的人只能重新踩一遍坑。 那時候我以為那是「傳產沒制度」。後來看多了才知道，這跟產業一點關係都沒有。 ## 我去查了那個範例 repo，發現一件事 Anthropic 那篇文章說，Warp 的 issue triage agent（問題分類代理）「示範了這套自我改進技能框架」，並且連到 GitHub 上一個公開的[範例專案](https://github.com/warpdotdev/warp-agents-demo-github-issue-triage?ref=growthhackers.tw)（repo，也就是公開的程式碼倉庫）。 我把那個 repo 的檔案清單整個拉出來看了。截至我查核的時候，main 主分支上只有一個 `auto-issue-triage.yml` 的 GitHub Actions 設定檔、一個很小的 TypeScript 範例程式、README 跟幾個設定檔。 沒有 skill 檔案。沒有 improver skill。沒有文章裡提到的那支 Python 腳本。 而且那個 repo 已經被封存（archived），main 分支的最後一次 commit 停在 2025 年 12 月 17 日，比這篇文章早了八個月。 這不代表有人在唬爛。文章自己就寫了，改進迴圈的外圈跑在「Oz」上面，那是 Warp 自家的 agent 編排平台。Warp 在 2026 年 4 月[開源了他們的客戶端](https://www.warp.dev/newsroom/2026/4/28/warp-open-sources-its-agentic-development-environment?ref=growthhackers.tw)，Oz 本身維持專有。 所以事情是這樣：**公開範例給你的是一個 GitHub Action 的骨架，不是文章描述的那整套 inner skill 加 improver skill 迴圈。** 這證明不了我的論點，但它很好地提醒了一件事。 你抄得到的是機制，抄不到的是制度。那道「誰有權核准」的關卡、那份「誰的意見算數」的名單，本來就不存在於任何一個 GitHub repo 裡。它存在於你公司的權責設計裡。 還有一個細節。Warp 那個開源專案的創始贊助商（founding sponsor）是 OpenAI，官方新聞稿跟[多家報導](https://www.helpnetsecurity.com/2026/04/30/warp-open-source-client/?ref=growthhackers.tw)都提到 GPT 模型參與了該專案的自動化改進。這跟 Anthropic 說 Warp 用 Claude Platform 衝突嗎？不衝突，兩件事可以同時成立。但它提醒你：**廠商案例研究是選過的切面，不是中立的技術報告。** 而這反過來讓這套機制更值得抄。因為它跟你用哪一家的模型，完全沒有關係。 ## 那會不會又是在空轉燒 token？ 我之前寫過[解碼 Langfuse 自我改進實驗那篇](https://growthhackers.tw/blog/ai-self-improvement-target-function/)，結論是自動優化的價值大半在第一輪就給你了，之後就是報酬遞減、空轉燒 token。那 Warp 這套為什麼不會撞到同一面牆？ 差別在**有沒有新資訊進來**。Langfuse 那種是 AI 對著一個固定的目標函數自己跑自己修，跑到後面沒有新東西可學，當然遞減。Warp 這套，每一輪都被灌進外部的、新的、帶著理由的人類判斷。 所以我給你一條判斷標準，可以直接拿去驗你手上任何一個「AI 自動優化」提案： **這一輪迴圈，有沒有新的人類判斷進來？沒有的話，它就是在空轉。** ## 行動建議：這週就能動手的四件事 先說清楚：外圈那個「自動撈回饋、自動產生修改建議」的部分，你多半需要工具或工程協助。但下面四條的低科技版，用 Google 文件、Notion 加一個 LINE 群組就能跑起來，這週就能動。 ► **第一：挑一件「每週都在重複、而且有人會嫌」的事。** 客服的退換貨判斷、商品上架文案、廣告素材審核，三選一就好。有人會嫌很重要，那代表你有現成的回饋來源。 ► **第二：把它寫成一份檔案，不是寫在腦袋裡。** 寫原則，不要寫規則。Zach 的原話是「把 skill 寫成在指導一個聰明人，不要寫成在寫程式」，而且要解釋**為什麼**，AI 才有辦法舉一反三。六個欄位就夠：適用情境、判斷原則、反例、例外、最後核准人、版本日期。想知道怎麼寫不會越寫越肥，看我整理過的[技能地獄那篇](https://growthhackers.tw/blog/writing-great-agent-skills/)。 ► **第三：指定誰的回饋算數，然後寫下名字。** 不是全公司，是一到兩個最懂的人。回饋要在他本來就在的地方留：客服後台、LINE 群組、Notion 頁面。格式固定五格：AI 原本怎麼答、哪裡錯、應該怎麼說、為什麼、案例連結。Zach 說「低摩擦才能讓訊號持續流動」，你要他多開一個表單填，這件事三週後就會死掉。 ► **第四：每週固定一個時段，人去看一份「建議修改清單」。** 這是整套的心臟。清單只有四欄：新增、修改、刪除、不採納的理由。AI 提案，人核准，核准了才生效。**永遠不要讓 AI 直接改生效版。** 二十分鐘就夠了，但這二十分鐘不能省。順便讓 agent 把「這件事我做不到」也回報進來，失敗一樣是訊號，這個我在[另一篇](https://growthhackers.tw/blog/ai-agent-failure-feedback-loop/)拆過。 ## 幾個你可能會問的問題 **Q：Agent Skills 跟 AI 的記憶功能差在哪？該用哪個？** A：Skill 是程序性、穩定的知識，「怎麼做 X」，要改是刻意去改，適合放公司規範、判斷準則、SOP。Memory 是 agent 執行當下自動寫入的，一直在變，適合放單次任務的暫存脈絡。公司的判斷標準請放 skill。Anthropic 的 [skill 撰寫指南](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices?ref=growthhackers.tw)還給了一個硬標準：SKILL.md 本文控制在 500 行以內，超過就拆檔。 **Q：要不要讓 AI 自動修改自己的規則？** A：不要。這是整篇最該記住的一句。 **Q：怎麼知道整套系統真的有變好？** A：用你本來就在看的指標。Warp 看的是合併時間、貢獻者人數、成本。換成電商就是客服平均處理時間、二次進線率、退貨率。不要另外發明一套只有 AI 看得懂的分數。 ## 最後 以前公司的競爭力，藏在幾個資深員工的腦袋裡，他們離職就帶走。 現在你有機會把那些判斷寫下來、版本控管、讓它在每一次 AI 執行時都被載入。 但這件事的門檻從來不是技術。是你敢不敢明講「這件事誰說了算」。 會贏的不會是模型最強的那家公司。 是最早把「誰說了算」寫下來的那家。 **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。