「自我改進的 AI」是行銷詞：解碼 Warp 的 agent 迴圈，真正在改進的是那道人類核准關卡

先問你一個問題。

你公司那份客服應對規則、退換貨判斷準則、或是商品上架的文案規範，上一次是誰改的？什麼時候改的？為什麼改？

我猜大部分人答不出來第三題。運氣好一點的，答得出前兩題。

這件事聽起來跟 AI 沒關係，但它其實就是你導入 AI agent 之後，半年內一定會撞上的那面牆。

Anthropic 最近發了一篇客戶案例，主角是 Warp，那家做 AI 終端機（terminal，工程師用來打指令的黑底視窗）的公司。標題叫 How Warp builds self-improving agents on Claude，講他們怎麼做出「會自我改進」的 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」對你還是全新名詞，可以先看我整理過的這篇入門，一句話講就是：把團隊知識寫成 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」，改進的其實是一份被人簽名核准過的檔案。模型本身沒有變聰明，變的是它下一次執行前會讀到的那份知識。

這就像白板跟食譜手冊的差別

我用餐廳來打個比方，這是這篇最重要的一個概念。

餐廳後場通常有兩種東西。一種是牆上那塊白板，寫著「今天九層塔不新鮮少放一點」。誰都能寫，天天在變，下週沒人記得上週寫過什麼。

另一種是那本食譜手冊。要改配方，得經過主廚同意，改完全店照做。

Warp 那份 best practice 表格第一條就在講這件事，講得比我清楚：

Skills 是程序性的、穩定的，是「怎麼做 X」，跟單次執行無關，要改就是刻意去改。Memory（記憶）是 agent 在推論當下自己寫進去的，而且永遠不會停止改變。

白板是 memory。食譜手冊是 skill。

我看過太多公司把這兩個搞混。興沖沖打開 AI 的記憶功能，以為「讓它自己記」就等於「它會越來越懂我們」。

結果半年後那個記憶庫變成什麼？變成那塊白板。塞滿矛盾的、過期的、某個人某天隨口講的東西，沒人知道哪一條還算數，也沒人敢刪。

以前你的 SOP 是一份 Word 檔，三年來每個人都往裡面加東西，沒人敢刪。現在你有 AI 了，如果沒設計好，你只是把那份沒人敢刪的 Word 檔，換成一個沒人看得懂的記憶庫。

最反直覺的一條：回饋要挑人

如果你問我，這篇來源裡最違反台灣電商直覺的，是這一條。

大部分老闆聽到「回饋迴圈」的第一個念頭是什麼？「那我把所有客服對話、所有客訴、所有評價全部丟進去讓 AI 學。」資料越多越好嘛。

Warp 的答案是相反的。

那份表格裡有一題問「回饋是錯的怎麼辦」，答案第一句就是：假設它一定會是錯的（Assume it will be）。

接下來三個處方：不要讓 agent 照單全收，要給它能自我檢查的背景；過濾誰的意見算數；人要留在過濾端或最終審查端。

另一題講得更狠。如果你的領域沒辦法用程式自動驗證對錯，那就限定領域專家，不要打開閘門（don't open the floodgates）。

Zach 補了一刀：品質大於數量。一個資深的人給的一段詳細、帶領域知識的回饋，價值可能勝過一堆讚跟倒讚，因為二元的讚不會告訴你為什麼。

翻成台灣電商的語言：

你那個 AI 客服的話術，要不要收五個客服、三個行銷、老闆娘、還有你表弟的意見？

不要。指定一個人，或兩個。寫下名字。

我在雨傘產業那七年，最深的體會之一就是這個。換季怎麼備貨、哪種客訴可以退、百貨檔期的規則怎麼跟專櫃講，這些判斷從來沒寫下來過，全靠口頭交代。誰講的算數？看那天誰在現場。等到最懂的那個人離職，整套判斷就跟著走了，剩下的人只能重新踩一遍坑。

那時候我以為那是「傳產沒制度」。後來看多了才知道，這跟產業一點關係都沒有。

我去查了那個範例 repo，發現一件事

Anthropic 那篇文章說，Warp 的 issue triage agent（問題分類代理）「示範了這套自我改進技能框架」，並且連到 GitHub 上一個公開的範例專案（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 月開源了他們的客戶端，Oz 本身維持專有。

所以事情是這樣：公開範例給你的是一個 GitHub Action 的骨架，不是文章描述的那整套 inner skill 加 improver skill 迴圈。

這證明不了我的論點，但它很好地提醒了一件事。

你抄得到的是機制，抄不到的是制度。那道「誰有權核准」的關卡、那份「誰的意見算數」的名單，本來就不存在於任何一個 GitHub repo 裡。它存在於你公司的權責設計裡。

還有一個細節。Warp 那個開源專案的創始贊助商（founding sponsor）是 OpenAI，官方新聞稿跟多家報導都提到 GPT 模型參與了該專案的自動化改進。這跟 Anthropic 說 Warp 用 Claude Platform 衝突嗎？不衝突，兩件事可以同時成立。但它提醒你：廠商案例研究是選過的切面，不是中立的技術報告。

而這反過來讓這套機制更值得抄。因為它跟你用哪一家的模型，完全沒有關係。

那會不會又是在空轉燒 token？

我之前寫過解碼 Langfuse 自我改進實驗那篇，結論是自動優化的價值大半在第一輪就給你了，之後就是報酬遞減、空轉燒 token。那 Warp 這套為什麼不會撞到同一面牆？

差別在有沒有新資訊進來。Langfuse 那種是 AI 對著一個固定的目標函數自己跑自己修，跑到後面沒有新東西可學，當然遞減。Warp 這套，每一輪都被灌進外部的、新的、帶著理由的人類判斷。

所以我給你一條判斷標準，可以直接拿去驗你手上任何一個「AI 自動優化」提案：

這一輪迴圈，有沒有新的人類判斷進來？沒有的話，它就是在空轉。

行動建議：這週就能動手的四件事

先說清楚：外圈那個「自動撈回饋、自動產生修改建議」的部分，你多半需要工具或工程協助。但下面四條的低科技版，用 Google 文件、Notion 加一個 LINE 群組就能跑起來，這週就能動。

► 第一：挑一件「每週都在重複、而且有人會嫌」的事。 客服的退換貨判斷、商品上架文案、廣告素材審核，三選一就好。有人會嫌很重要，那代表你有現成的回饋來源。

► 第二：把它寫成一份檔案，不是寫在腦袋裡。 寫原則，不要寫規則。Zach 的原話是「把 skill 寫成在指導一個聰明人，不要寫成在寫程式」，而且要解釋為什麼，AI 才有辦法舉一反三。六個欄位就夠：適用情境、判斷原則、反例、例外、最後核准人、版本日期。想知道怎麼寫不會越寫越肥，看我整理過的技能地獄那篇。

► 第三：指定誰的回饋算數，然後寫下名字。 不是全公司，是一到兩個最懂的人。回饋要在他本來就在的地方留：客服後台、LINE 群組、Notion 頁面。格式固定五格：AI 原本怎麼答、哪裡錯、應該怎麼說、為什麼、案例連結。Zach 說「低摩擦才能讓訊號持續流動」，你要他多開一個表單填，這件事三週後就會死掉。

► 第四：每週固定一個時段，人去看一份「建議修改清單」。 這是整套的心臟。清單只有四欄：新增、修改、刪除、不採納的理由。AI 提案，人核准，核准了才生效。永遠不要讓 AI 直接改生效版。 二十分鐘就夠了，但這二十分鐘不能省。順便讓 agent 把「這件事我做不到」也回報進來，失敗一樣是訊號，這個我在另一篇拆過。

幾個你可能會問的問題

Q：Agent Skills 跟 AI 的記憶功能差在哪？該用哪個？

A：Skill 是程序性、穩定的知識，「怎麼做 X」，要改是刻意去改，適合放公司規範、判斷準則、SOP。Memory 是 agent 執行當下自動寫入的，一直在變，適合放單次任務的暫存脈絡。公司的判斷標準請放 skill。Anthropic 的 skill 撰寫指南還給了一個硬標準：SKILL.md 本文控制在 500 行以內，超過就拆檔。

Q：要不要讓 AI 自動修改自己的規則？

A：不要。這是整篇最該記住的一句。

Q：怎麼知道整套系統真的有變好？

A：用你本來就在看的指標。Warp 看的是合併時間、貢獻者人數、成本。換成電商就是客服平均處理時間、二次進線率、退貨率。不要另外發明一套只有 AI 看得懂的分數。

最後

以前公司的競爭力，藏在幾個資深員工的腦袋裡，他們離職就帶走。

現在你有機會把那些判斷寫下來、版本控管、讓它在每一次 AI 執行時都被載入。

但這件事的門檻從來不是技術。是你敢不敢明講「這件事誰說了算」。

會贏的不會是模型最強的那家公司。

是最早把「誰說了算」寫下來的那家。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。