讓 AI 代理值得信任：驗證、硬性約束與慣例式架構
一句話重點：要放心讓 AI 代理寫程式，必須先讓它能實際驗證自己的成果，再用 CI、lint 等硬性約束與慣例式架構取代人工審查，信任才能逐步累積到讓代理自動合併 PR。
關鍵觀點
- 信任是整場分享的主軸：信任不足時只能緊盯少數代理、無法平行化，也不該一下子啟動大量雲端代理，否則只是浪費 token；她花 5 個月爬上信任曲線，才做到代理自動合併、醒來已有 20 個 PR 進主線。
- 驗證是信任的起點：沒有驗證技能時人就是瓶頸，所以先教代理實際操作應用程式（control glass 技能與功能地圖），再用 eval 當作技能的單元測試持續改進，之後才擴展到雲端的 Benny 自動重現錯誤回報。
- 工程師的角色像主廚：不再親手做每道菜，而是設計環境、分派工作；起點是本機，因為能看著代理如何操作，信任建立後才放大到雲端與自動合併。
- 約束要能硬性執行才可靠：Dune 禁用 useEffect 與程式碼註解、以 CI 檢查 main 與 renderer 的匯入邊界，並以「最短路徑就是最佳路徑」的慣例式架構引導代理；rules、skills 與 bugbot 只是軟性補充，每次靠人工審查才發現的問題都該轉成 lint 或 CI 規則。
- token 花費是投資報酬率問題：前期重構（超過 600 個 PR）花很多 token，但換來最笨的代理也能做好，連 PM、設計師都能安全貢獻；不過她任職的實驗室 token 不受限，不能要求每個人照做。
分段摘要
0:25AI 壓力與規格優先的第一次實驗
她認為 AI 最好的用法是當成一起寫程式的夥伴，而不是取代寫程式或外包思考。許多工程師因為想被看成善用 AI，承受每週要交 100 個 PR 的壓力；她自己的經驗是，用 AI 雖然省下寫程式的時間，卻花更多時間審查與修正。她也試過先讓 AI 寫規格、審過規格再開發的流行做法。
▶ 從這裡看1:25信任、長期累積的看法與曲線
主軸是信任：資深工程師累積了許多看法，看到代理亂猜、產生幻覺，還信誓旦旦說找到問題根源，信任就會流失，而信任不足就無法發揮代理的價值，如同不信任下屬的經理只能微管理。回到約 1 年前還沒什麼人用代理寫程式的時候，只能緊盯少數幾個代理、無法平行化；過去 5 個月爬上信任曲線，現在代理會自動合併 PR，醒來就有 20 個 PR 已進主線且品質不錯。她的貢獻圖與這條曲線相互對應：第 1 個月產出低，上個月合併的 PR 數量相當驚人，本月 12 日前已近 800 個。
▶ 從這裡看
5:55驗證是最重要的能力
在代理工作流程中，她認為最重要的技能是驗證：代理要能真的執行程式碼、抓 CPU trace 或 heap snapshot、開 iOS 模擬器，像使用者那樣實際操作並測試。這能讓迴圈閉合；雖然不保證寫出好程式碼，至少能寫出正確的程式碼，是建立信任的一大步。
▶ 從這裡看
7:25Cursor 經歷與教 Agent 看畫面
她 5 個月前加入 Cursor，原本要進雲端代理團隊，但因為有 React 經驗，被派去支援同為 React 應用的 agents window。第 1 週她自己看 Chrome DevTools 的火焰圖看不懂，代理也看不懂，只會信心滿滿地亂指原因；沒有驗證技能時，人就成了瓶頸，得自己複製截圖與錯誤訊息給代理。於是她做出 control glass 技能（Glass 是 agents window 的內部代號），教代理透過 Chrome DevTools Protocol 或 Apple 的模擬器工具操控應用程式。但代理能操作卻不知道視窗裡有哪些功能，因此需要額外的功能地圖。
▶ 從這裡看
11:40功能地圖、Pstack 與技能評測
功能地圖列出各功能如何操作到、鍵盤快捷鍵與 CDP 用的選取屬性，讓代理即使面對品質很差的回報（例如只有截圖加問號）也能對上功能；Pstack 外掛附有建立與維護驗證技能的功能。Pstack 的名字是調侃 Y Combinator 執行長 Gary Tan 的 GStack（兩人同姓但無關），並非預先規劃，而是從觀察代理失敗模式、逐一寫成技能累積而成。技能本質是 markdown，等於在教毫無背景的新人。維護技能靠 eval，也就是代理的單元測試：協調代理訂評分標準、派出多個子代理（刻意不讓它們知道正在被評測），再由不同模型的裁判代理交叉檢查，並可持續迴圈直到滿分 10 分。但她坦言維護技能很難，需要品味與觀察。
▶ 從這裡看22:35主廚比喻：從本機導入到雲端代理
她用主廚比喻角色轉變：工程師不再親手做每道菜，而是設計廚房環境、分派工作給團隊。導入從本機開始，因為可以看著代理啟動 CLI 或桌面應用、如何呼叫介面來操作；她自己則主要押注雲端代理，名為 Benny 的代理會接手所有錯誤回報，在雲端桌面執行 Cursor，用同樣的控制技能重現問題，例如回報顯示錯誤能重現但主線已修好，只需再發佈新版。這讓整個團隊都受益，但必須先建立信任，別一下子啟動大量雲端代理而浪費 token。
▶ 從這裡看27:15回顧與不盲目信任
訪談者回顧路徑：先建立驗證技能確認程式碼至少正確，在本機建立信任後擴展到雲端、讓代理自己接手回報並提交 PR，最後才是自動合併、再到主線審查。她同意，並說這條路沒有捷徑，因為信任取決於個人標準，也不希望任何人盲目信任她；外掛能加速上手，但鼓勵大家改造出自己的技能組，把自己的工程標準寫進技能並驗證代理確實遵守。
▶ 從這裡看
29:35重寫之爭與程式碼漂移
她主張重寫值得考慮：既有專案若已有框架、慣例與護欄，代理已能做得相當不錯，因為大公司為了照顧能力最弱的工程師，早就建好這些限制；新建專案則是最大的風險，也是最大的機會。以全新開發的 Grockbot 為例，完全靠 vibe coding、人沒讀過程式碼時沒有任何護欄，代理會用最方便的方式解決任務，程式碼久了就失控。她因此花了超過 600 個 PR 把 Grockbot 重構成新架構，現在幾乎不再看程式碼；這花了大量 token，但讓設計師、PM 等非工程人員也能放心加功能，因為 CI 有大量約束，代理吸收了寫程式的麻煩。
▶ 從這裡看35:25規模化強制執行與 PR 大小
被問到 CI 與 PR 大小，她說沒有硬性上限，大小從約 50 行起跳，視內容可以大很多，例如刪除大量檔案的 PR 幾乎都是刪除。她仍要求代理把工作拆成多個 PR，讓每個 PR 只描述單純的小變動，git 歷史就是豐富的脈絡，也方便回退，不會出現 40000 行的 PR 不知道塞了什麼。順帶一提，Grockbot 與 Cursor 的虛擬化是由新函式庫 Pretext 驅動。
▶ 從這裡看
38:15Dune 與慣例式架構
Dune 是 Grockbot 架構的內部代號，可想成給 Electron 應用用的 Next.js，專為代理寫程式而設計。它的 CI 檢查多到很煩：禁用 useEffect，也禁用程式碼註解，因為她發現 99% 的時間代理寫的註解都是與程式無關的歷史敘述。Electron 的 renderer 要維持 60 fps，每幀必須在 16 毫秒內完成，一旦不小心把重運算帶進 renderer 就會卡頓，所以把這些經驗寫進框架成為硬性失敗：分開 electron main 與 electron renderer 目錄，CI 檢查依賴圖，禁止跨目錄匯入。她認為最強的強制層是慣例式架構，因為代理愛複製既有模式；例如單一功能的所有程式碼放在同一個目錄，約 80% 的工作大致都封裝在內。
▶ 從這裡看
43:35最短路徑、邊界與軟性規範
她的首要原則是最短路徑就是最佳路徑，因為代理愛走捷徑，不如讓最快的做法就是最好的做法；這套框架只是一組想法與原則，不會開源。強制分成多層：CI 檢查、針對觀察到的壞模式寫的 lint、編譯器診斷都會讓 CI 變紅，是硬性約束；rules、skills 與 bugbot 較軟，代理仍可能忘記，只能疊加、不能單靠它們，否則程式碼遲早變垃圾。技術選擇也重要，例如 Rust 編譯器嚴格，只要禁止 unsafe 區塊，編譯通過就能有一定信心。若每次都靠人在程式碼審查指出限制，就是壞味道，應該改成 lint 規則、CI 失敗，或乾脆從根本消除問題。
▶ 從這裡看49:45Token 投資報酬與產品同步
對工程主管來說，token 是投資報酬率問題：前期重構程式碼與建立約束要花大量 token，但如果代理負責寫程式，就不必長成 10000 人的工程組織；這些事她單打獨鬥在代理時代之前要花好幾年，因此取捨是雇人，還是花 token 讓最笨的代理也能做好。她也坦言自己任職的 AI 實驗室 token 不受限，不能要求每個人照做。被問到產品等部門如何跟上，她認為 Grockbot 是關鍵：介面像 iMessage，讓非技術人員輕鬆使用代理，PM 與設計師甚至直接提交修正，她審查後覺得完美就直接蓋章通過，顯示 Dune 架構的嚴格約束讓非專家也能高水準貢獻。
▶ 從這裡看