怎麼把 coding agent 從「要盯著看」養成「敢自動合併」——verification、skill 與硬約束架構

1. 講者背景：從 Meta React 到 Cursor 0:00–2:47

Lauren Tan 自我介紹：在 Cursor 五個月，先前在 Meta React 團隊做 React compileri，更早在 Netflix 當過 tech lead 與工程經理兩年。她點出這次分享的主軸——在管理職與個人貢獻者之間來回的經驗讓她發現，管理人的技巧和「管理 agent」有大量相似之處。主持人補充今天也會聊到 Cursor 剛發表的 Grokbot。

推理因為開場必須先讓聽眾願意接受後面那些相當激進的主張（自動合併 PR、禁註解），所以作者先把資歷攤開，而且刻意把重點壓在「在管理職與個人貢獻者之間來回」這件事上，讓「管人的技巧和管 agent 的技巧高度重疊」這個類比在第一分鐘就先站住腳，之後每一段都可以直接引用它而不必再解釋。

• A管 agent 的技巧和管人的技巧高度重疊——整場的類比基礎→ 批判類比

AI 補充她提到的 React compiler 值得補一句：那是一個會自動幫 React 元件插入 memoization 的編譯器，本質上就是「把工程師本來要手動遵守的規則，交給工具強制執行」——這正好是本場後半段所有主張的原型。理解這點，就會明白她後面說「把 review 留言變成 lint 規則」並不是臨時想到的比喻，而是她一路以來的職業直覺。另外，她說自己在 Cursor 只待了五個月，這個時間長度在後面會反覆被拿來當刻度，因為她要證明的正是「這條學習曲線可以在幾個月內爬完」。

術語:individual contributori

2. 核心問題：你怎麼信任 agent 2:47–4:08

她把整場的主題定為「信任」。寫了很久程式的工程師對什麼是好工程有很多主見，但看到 agenti 亂猜、幻覺i、第一百次信誓旦旦說「我找到兇手了」卻抓錯問題，信任就流失了。沒有信任就發揮不出 agent 的價值。對應到管理：一個不信任下屬的經理，只能進入微管理模式，整天盯著別人的螢幕檢查有沒有把 bug 送上線。

推理因為上一段已經把管理與 agent 並列，所以作者接著挑出管理關係裡最根本的那一維——信任——當成整場的座標軸。她的論證是雙向的：往內看，寫程式久了的人有一套自己的工程標準，看到 agent 亂猜就會扣分；往外看，一個不信任下屬的經理只剩微管理一種模式。兩邊指向同一個結論：信任不是感受問題，而是決定你能用什麼工作模式的結構性限制。

• Eagent 第一百次篤定說「找到兇手了」卻抓錯：傷害不在答錯，而在答錯時語氣跟答對一樣→ 存＋演練

AI 補充她講的那個場景——agent 第一百次很有把握地說「我找到兇手了」但抓錯——真正的傷害不在於它答錯，而在於它答錯時的語氣和答對時一模一樣。用機器學習的話說，這是 calibration（信心校準）問題：一個會說「我不確定」的模型比一個永遠很篤定的模型好用得多，因為前者的輸出可以分流（確定的直接採用、不確定的人工看），後者則逼你每一次都得全部檢查。這一點值得特別記住，因為她後面所有的解法，本質上都是在替 agent 補上它自己給不出的那個「信心來源」：能跑起來、能驗證、有硬性的規則擋著。

3. 信任曲線：從盯著看到自動合併 4:08–6:00

她畫了一張不科學但很傳神的曲線描述自己的歷程。一年前大家還沒在用 agent 寫程式時，人只能深深待在迴圈裡，同時盯一兩個 agent、看每一行輸出、坐在旁邊一直下 prompt，沒辦法再平行下去——你連一個 agent 的輸出都不信任，怎麼可能開一百個。五個月下來她爬上了這條曲線，現在 agent 會自動合併i PR，早上起來已經有二十個 PR 落地，而且品質是好的。

推理因為上一段說信任決定工作模式，所以作者接著把「信任」與「模式」放到同一張圖的兩軸上，讓兩者的關係變成可以指認的位置而不是形容詞。她再用自己一年前與現在的兩個極端當錨點——一年前只能同時盯一兩個 agent、逐行看輸出；現在 agent 自動合併 PR，她早上起來直接在 main 上 review 二十個已落地的 PR——把這條曲線的起點與終點都填上具體行為。

• Ctrust curve：縱軸信任、橫軸能同時跑的 agent 數，左端逐行盯著看、右端 auto-merge 早上在 main 上事後 review→ 畫地圖

AI 補充截圖裡這張手繪圖（tldraw）值得逐項讀：縱軸寫的是 trust，橫軸寫的是 number of agents，刻度依序是 1 → 1 to 5 → 5 to 10 → 10 to 20 → hundreds → thousands，曲線在最左邊幾乎垂直往上竄，到 10 to 20 附近開始明顯轉平。這個形狀本身就是一個論點：真正吃力的是從 1 個走到十幾個 agent 那一段——那段要換到的信任增幅最大；一旦跨過去，往 hundreds、thousands 幾乎是水平延伸，邊際成本很低。換句話說，這不是一條「投入越多就線性拿越多」的曲線，而是一道門檻。她講「不能一次跳到一百個 agent」時，指的就是這個形狀，而不是單純的謹慎建議。

術語:trust curveiin the loopi

4. 產出曲線佐證這條路走得通 6:00–7:26

她秀出自己在 Cursor 的貢獻量圖表，說明它幾乎和信任曲線同形：剛加入的第一個月不熟程式庫、產出很低，隨著對 agent 越來越有信心，速度一路往上，上個月合併了一千個 PR，這個月才十二號就快八百個。她主動承認大家一定會質疑這些程式碼的品質，而這正是接下來要回答的問題——只要 agent 設定得好，別人也能到差不多的水準。

推理因為上一段的曲線缺乏外部佐證，所以作者接著把它疊到一個誰都能查的指標上——她個人的 commit／PR 產出量。論證方式是形狀比對：第一個月不熟程式庫、產出貼地，之後隨著對 agent 的信心上升，產出跟著陡升，上個月一千個 PR，這個月才十二號就快八百個。她接著主動把最尖銳的反問先講出來（這些程式碼品質如何？），把它轉成整場後半段要回答的題目。

• EGitHub 貢獻卡：3,159 commits，Jan '26 後衝到 750 附近、上月一千個 PR——只證明量，不證明品質→ 存＋演練

AI 補充截圖裡是她的 GitHub 貢獻卡片：帳號 poteto、3,159 commits、排名第 6，長條圖從 Jan '22 一路排到 Jul '26，前面幾年幾乎貼著底線，只有最右邊 Jan '26 之後那幾根竄到 750 附近，她還在上面手繪了一條虛線箭頭標出轉折。這裡有一個她沒點破但很關鍵的推論方向問題：這張圖本身只證明「產出變多」，不證明「因為信任 agent 才變多」，也不證明品質。她自己顯然知道，所以立刻把「品質」拿出來當成待答問題——這是她整場論證誠實的地方，也是接下來每一段的實際任務：不是再證明量，而是證明量的背後有東西撐著。

術語:pull requesti

5. 第一項技能：verification 7:26–8:50

她給出爬坡的第一個答案：工具箱裡最重要的能力是 verificationi——讓 agent 能真的把程式跑起來，取 CPU tracei、抓 heap snapshoti、開 iOS 模擬器，用使用者實際接觸產品的方式去實測。這件事才真正把迴圈閉起來。它不保證 agent 寫出好程式，但至少能保證寫出正確的程式，而這是能開始信任它的一大步。

推理因為上一段把品質變成待答題，所以作者接著直接點名她認為最關鍵的一項能力：讓 agent 能真的把程式跑起來、取 CPU trace、抓 heap snapshot、開 iOS 模擬器，用使用者實際接觸產品的方式去測。她的論證關鍵是那句限定詞——這不保證 agent 寫出「好」程式，只保證它寫出「正確」的程式。這個區分很重要，因為它把「品質」拆成兩個可以分別處理的問題，本段只負責前一半。

• Cverification：讓 agent 自己把程式跑起來、抓 trace、開模擬器實測——不保證「好」程式，只保證「正確」→ 畫地圖
• R四個例子涵蓋四層驗證：跑程式=正確性、CPU trace=效能、heap snapshot=記憶體、iOS 模擬器=實際介面→ 存＋回想

AI 補充「閉迴圈」這個說法值得展開：沒有 verification 時，agent 的迴圈是「改程式 → 結束」，正確與否要等人回報；有了 verification，迴圈變成「改程式 → 執行 → 觀察結果 → 再改」。差別不只是多一步，而是錯誤訊號的來源從人變成環境——環境不會累、不會不耐煩，也可以同時服務二十個 agent。這正好接回信任曲線的形狀：verification 是把橫軸從個位數推到十幾個的那個機制。另外她列的四個例子（跑程式、CPU trace、heap snapshot、iOS 模擬器）不是隨口舉的，而是涵蓋了正確性、CPU 效能、記憶體、以及使用者實際介面四個不同層次的驗證。

6. control glass：人不該是驗證瓶頸 8:50–12:04

她用自己的親身經驗說明沒有 verification 有多痛。剛進 Cursor 第一週就被調去救 agent window（內部代號 glass）的效能，她自己開 Chrome DevTools 抓 trace、截圖丟給 agent，agent 每次都很有把握地指認一個原因，改下去卻不是。她點破關鍵：沒有 verification skilli 時，你自己就是那個 verifier，也就是瓶頸——貼截圖、貼 console error、來回解釋，完全沒辦法平行化。於是她做了第一個 skill：control glass，教 agent 用 Chrome DevTools protocoli（或 Apple 的模擬器工具）自己操作應用程式、自己抓 trace。

推理因為上一段把 verification 講成抽象能力，所以作者接著把它的反面演一遍：她被丟去救 agent window（內部代號 glass）的效能，自己開 Chrome DevTools 錄 trace、截圖丟給 agent，agent 每次都很篤定地指認一個原因，改下去卻不對。她從這個經驗抽出一句精準的診斷——沒有 verification skill 時，你自己就是 verifier，也就是瓶頸——然後順著這個診斷做出 control glass，把「操作應用程式、抓 trace」這件事交還給 agent。

• E救 glass 效能第一週：自己錄 trace 貼截圖，agent 每次篤定指認卻改錯——沒有 verification 時你就是瓶頸→ 存＋演練
• Rcontrol glass skill：多實例不互相干擾，主 checkout 用 CDP 9222，worktree 各自 port→ 存＋回想
• Cskill：用 markdown 寫、教 agent 在特定情境怎麼做事的指令檔；每一個都是從一種失敗模式長出來的→ 畫地圖

AI 補充「你就是 verifier」這句話要跟上一段的閉迴圈連起來讀才完整：貼截圖、貼 console error、來回解釋，每一次往返都要消耗人的一次注意力，於是 agent 的數量上限就等於人的注意力除以每次往返的成本——這就是信任曲線左端為什麼那麼陡的機制層面解釋。截圖裡打開的正是這個 skill 的本體：`.cursor/skills/client/control-glass/SKILL.md`，標題寫著 Control Glass via Playwright，開頭一句話就說明用途——透過 CDP 驅動一個跑起來的 Cursor dev build，檢視 DOM、截圖、點擊、輸入、讀 accessibility tree、跑 JS、profile、節流 CPU／網路、串接 console 或網路輸出。特別值得注意的是它花了大量篇幅在講 worktreei 與主 checkout 的分流（主 checkout 用 CDP port 9222，worktree 必須帶 `--worktree` 用自己的 port 與獨立 user-data-dir，否則會污染使用者本人的登入狀態），還提供一個唯讀的 `doctor` 指令回答「這個實例值不值得驅動」。也就是說，一個好用的 verification skill 大半的內容不是「怎麼操作」，而是「怎麼在多個 agent 同時跑的時候不互相干擾」——這正是平行化的前提。左邊的檔案樹也透露了規模：control-glass 只是幾十個 skill 之一，旁邊還有 autofix-ui、bisect-glass-perf-regression、check-glass-perf-regression、cursor-startup-perf 等等。

術語:flame graphi

7. feature map：教 agent 怎麼走到功能 12:04–15:23

會操作還不夠。skill 做好之後 agent 能跑起 agent window 了，卻完全不知道它是什麼——有人說「左側欄很卡」「PR 分頁壞了」，agent 只能瞎點、到處 grep，體驗糟到她得在螢幕上畫箭頭。解法是 skill 裡附的 feature mapi：一份從使用者視角描述所有功能怎麼抵達的檔案，含子功能、鍵盤快捷鍵，甚至 CDP 選取元素用的 DOM 屬性。有了它，連「一張截圖加三個問號」這種極低品質的回報，agent 都能對應到實際功能。她的 P-Stack 外掛裡有 create verification skill，會掃過程式碼幫你建出初版 feature map，還有 maintain verification skill 負責維持更新。

推理因為上一段做出的 skill 只解決了「怎麼驅動」，所以作者接著處理暴露出來的下一個失敗：有人回報「左側欄很卡」「PR 分頁壞了」，agent 只能瞎點、到處 grep，糟到她得在螢幕上畫箭頭指路。她的解法不是把 skill 寫得更聰明，而是補一份知識——feature map，把導航知識從她的腦袋搬進檔案。驗收標準也很具體：連「一張截圖加三個問號」這種極低品質的回報，agent 都要能對應到實際功能。

• Cfeature map：一個功能一個 md，從使用者視角寫「是什麼、怎麼抵達、怎麼用程式驅動」，讓爛回報也能對到功能→ 畫地圖
• Rfeature map README：只教「怎麼使用功能」不寫「怎麼實作」，因為程式碼變得比文件快——文件能長期存活的關鍵→ 存＋回想

AI 補充截圖裡的 feature map 比口頭描述具體得多，值得逐項看。它不是一個檔案而是一個目錄：`.cursor/skills/client/control-glass/references/features/`，一個功能一個 md（sidebar.md、notifications.md、pull-requests.md、terminal.md、settings.md、plan.md、named-agents.md、subscriptions.md、cdp-cookbook.md…），另外有一份 `cross-cutting-flows.md` 專門放跨功能的流程。README 開頭把定位講得很死：這些檔案教的是「怎麼使用一個功能」，不是「它怎麼被實作」，實作細節要去讀程式碼，因為程式碼變得比文件快——這一句其實是文件能長期存活的關鍵設計，把最容易過期的部分排除在外。它還定義了 baseline preconditions（dev build 要跑著、要已登入、sidebar 要可見、不能有 modal 開著）與 driving conventions（選取元素優先用 ARIA labeli 與 `data-component`、`data-action-id`、`data-message-*`、`data-tool-*`）。第二張截圖是 sidebar.md 的「How to get to it (user POV)」小節，密度高得驚人：Cmd/Ctrl+B 開關側欄、拖曳右緣調寬並可雙擊還原、隱藏後 hover 會出現 hovercard 預覽、Cmd/Ctrl/Alt+F 開自訂選單、Grouping 與 Ordering 的所有選項、Show/Filters 能切換哪些 metadata、以及 `glass_sidebar_archive_toggle` 這個 feature flag 開啟時行為會不同。看到這個密度才會理解她說的「教 agent 導航」是什麼等級的工作量——也才會理解為什麼她需要 create verification skill 自動產初版、maintain verification skill 持續更新，人手寫不可能跟得上。

8. P-Stack 是觀察失敗模式長出來的 15:23–19:09

P-Stacki（potato stack，玩笑地致敬 Y Combinator CEO Garry Tan 的 G-Stack）不是設計出來的，是長出來的：從 control glass 開始，每次觀察到 agent 的一種失敗模式，就把它變成一個 skill。她舉的例子是 agent 被問「這功能為什麼壞了」時信誓旦旦地斷言原因，但看 tool call 會發現它根本沒讀那段程式碼——於是就有了「不要猜、去把程式碼讀出來、多用 subagenti」這樣的 skill。她再次用管理類比：面對一個程式能力很強但零商業脈絡、五秒前才報到的新人，你教他的方式就是寫下來；skill 不過是 markdown，但足以把 agent 拉到更好的位置（有人稱為拉到不同的 latent spacei，白話說就是餵高品質的 token，讓它去 pattern match 更聰明的那一層）。

推理因為上一段的 feature map 是針對一種失敗的針對性補丁，所以作者接著把這個動作抽象化成方法：每觀察到一種失敗模式，就把它變成一個 skill。她舉的第二個例子和第一個形成對照——agent 被問「這功能為什麼壞了」時信誓旦旦地斷言原因，但翻 tool call 會發現它根本沒讀那段程式碼，於是就有了「不要猜、去把程式碼讀出來、多用 subagent」這樣的 skill。接著她再度動用開場那個管理類比收束：面對一個程式能力很強但零商業脈絡、五秒前才報到的新人，你教他的方式就是寫下來。

• P每觀察到一種失敗模式，就把它寫成一個 skill——P-Stack 不是設計出來的，是一次一個長出來的→ 練習
• E判斷 agent 在幻覺的依據不是「答案錯」而是「tool call 顯示它沒讀過那段程式碼」——過程指標→ 存＋演練

AI 補充這裡有一個推理上的關鍵細節值得單獨拉出來：她判斷 agent 在幻覺的依據不是「答案錯了」，而是「tool call 顯示它沒讀過相關程式碼」。這是一個過程指標而非結果指標，而過程指標的好處是可以在錯誤造成後果之前就發現——這也解釋了她後面為什麼堅持要打開所有 tool call、讀 agent 的思考區塊。至於 P-Stack 這個名字：P 是 potato（她的 Twitter 帳號 poteto），是在調侃 Y Combinator 執行長 Garry Tan 的 G-Stack，兩人同姓但沒有親戚關係。她提到的 latent space 說法則是社群裡的比喻性用語，實際機制比較樸素：模型是在既有的上下文條件下預測下一個 token，餵進高品質的內容會讓後續輸出的分佈往「寫這種內容的人會接著寫什麼」偏移——沒有真的移動到另一個空間，但實務效果確實像是換了一個更強的模式在對話。

9. 用 eval 當 skill 的單元測試 19:09–22:27

主持人問這些 skill 怎麼維護。她的答案是 evali——心智模型就是「agent 的單元測試」，不需要特別框架，自己就能寫。P-Stack 的 potato mode 裡有一份 eval playbook：由主協調 agent 先訂出這個 skill 該做到什麼的評分準則i，再派出一批 subagent，每個放在刻意命名得看不出是在被評測的目錄裡（agent 察覺自己被評測就會改變行為）。Cursor 支援很多模型，所以同一個 skill 可以跨模型評測，看它在你實際使用的模型矩陣上表現如何。她每次改 skill 都會跑一次。

推理因為上一段的方法會不斷產生新的 skill，所以作者接著必須回答品質問題，而她選的心智模型是「agent 的單元測試」——這個類比一次解決兩件事：它說明 eval 該在什麼時候跑（每次改 skill 就跑），也說明它不需要什麼特殊框架（自己就能寫）。她接著描述 P-Stack 的 eval playbook 實作：主協調 agent 先訂出評分準則，再派出一批 subagent，每個放在刻意命名得看不出是在被評測的目錄裡，最後跨模型跑一輪看表現。

• Ceval：agent 的單元測試——主 agent 訂 rubric，派一批 subagent 在看不出被評測的目錄裡跑，跨模型看表現→ 畫地圖
• Aeval 是 skill 的單元測試：每次改 skill 就跑，不需要特殊框架→ 批判類比
• Reval 一定要一批 subagent 而不是跑一次：單次結果分不出「skill 改好了」和「這次運氣好」→ 存＋回想
• Rsubagent 的目錄要命名得看不出是在被評測：agent 有評測意識，察覺時行為會變→ 存＋回想

AI 補充「目錄要命名得讓 subagent 看不出自己在被評測」這個細節其實是整段最值得記住的一句，它承認了一件事：agent 有評測意識i，察覺自己被評測時行為會變，於是量到的分數就不是它平常的表現。這是 LLM 評測領域的真問題，跟人類的霍桑效應同構。順帶補一步她跳過的推論——為什麼 eval 一定要用一批 subagent 而不是跑一次就好：模型輸出有隨機性，單次結果無法區分「skill 改好了」和「這次運氣好」，要跑一批才有分佈可看。這也回頭解釋了上一段的 subagent 為什麼是必要零件。截圖是她整場的大綱頁（tldraw 手寫），三個 bullet 剛好就是這場的骨架：verification／high quality skills that teach agents to work like real software engineers: eg pstack／refactoring-rewriting architecture to be agent friendly，旁邊分別註記 evals! 與 (greenfield vs brownfield)。看這張圖可以確認 eval 在她的結構裡是掛在第二點下面的支撐，不是獨立的第四點；畫面上那個綠色的 UH 塗鴉則是與會者在共享畫面上亂畫留下的。

10. 當後座駕駛，再讓 eval 爬山 22:27–25:43

她坦承維護 skill 其實很難，需要品味與觀察力：你要很擅長當「後座駕駛」，像 pair programmingi 時看同事寫程式會忍不住問「為什麼不這樣做」。建立自己的 skill 的初期不能只當被動觀察者，要打開所有 tool call、讀 agent 的思考區塊，才看得到它在哪裡失敗，然後為那個點做一個 skill。驗證信不信得過也是同一個迭代迴圈：eval 可以產生分數，再用另一個模型的 judge agenti 交叉檢查避免偏誤，然後用 slash loop 一直跑到全部十分為止。control skill 就是這樣近乎放手地磨出來的。她順帶給出後面會再用到的比喻：現在的工程師更像餐廳主廚，不再自己煮每一道菜，而是帶著線上廚師與副主廚，工作是設計整個廚房環境、分派任務。

推理因為上一段的 eval 只能驗證既有 skill，所以作者接著補上產生 skill 的那一半——你要很擅長當「後座駕駛」，像 pair programming 時看同事寫程式會忍不住問「為什麼不這樣做」。她給的操作方式很具體：初期不能只當被動觀察者，要打開所有 tool call、讀 agent 的思考區塊，才看得到它在哪裡失敗，然後為那個點做一個 skill。接著她把兩半接起來：有了 eval 分數就能爬山——用另一個模型的 judge agent 交叉檢查避免偏誤，再用 slash loop 一直跑到全部十分為止。

• P迭代迴圈：當後座駕駛觀察 tool call → 寫 skill → eval 量分 → 換模型的 judge 打分 → slash loop 爬到滿分→ 練習
• Rjudge agent 換模型不是儀式：同一模型既寫又評，偏好風格會同時出現在兩邊，分數失去鑑別力→ 存＋回想
• A工程師像主廚：不再自己煮每道菜，而是帶線上廚師與副主廚、設計整個廚房環境→ 批判類比

AI 補充這段的結構其實是一個完整的迭代迴圈，值得畫出來：人工觀察 tool call 找出失敗模式 → 寫成 skill → 用 eval 量分 → 讓模型自己爬山改到滿分 → 回到觀察。人只出現在第一步和最後一步，中間可以全自動，這就是她說 control skill「近乎放手」磨出來的意思。judge agent 換一個模型也不是儀式：同一個模型既寫又評，它偏好的風格會同時出現在兩邊，分數就失去鑑別力——換模型是為了讓評分者的偏誤與被評者的偏誤不相關。要注意「爬到十分」有個天花板：分數只反映 rubric 寫了什麼，rubric 沒寫到的維度爬再高也不會變好，所以人的品味最終還是體現在 rubric 上。她順帶給出的主廚比喻——不再自己煮每道菜，而是帶著線上廚師與副主廚、設計整個廚房環境——是開場那個管理類比的升級版：從「管人」變成「設計環境」，這正好預告了她後面要談的架構約束。

術語:hill climbingi

11. 先在本地觀察，再放上雲端 25:43–29:05

被問到實際要怎麼開始，她建議先從本地做起，因為本地才觀察得到：讓 agent 把應用程式叫起來，你看著它怎麼呼叫 API、怎麼跟程式互動。但她自己幾乎全押在 cloud agenti 上——只要花一點時間把環境和這些 control / verification skill 設好，收益不只是讓你一個人變強，而是整個團隊、整間公司。她舉內部的 agent「Benny」為例：它接收所有 bug 回報，自動在雲端開一台桌面、在自己的電腦裡跑 Cursor，用同一套 control skill 操作應用程式去重現問題。畫面上這次的結果是 Benny 成功重現了 bug、但確認 main 上已經修好，只要再出一版就行——這些資訊完全不用她花一小時陪著 agent 查。

推理因為上一段強調人要親眼看到 agent 在哪裡失敗，所以作者接著推出「從本地開始」——本地才觀察得到：讓 agent 把應用程式叫起來，你看著它怎麼呼叫 API、怎麼跟程式互動。但她立刻補上自己的實際重心：她幾乎全押在 cloud agent 上，因為只要花一點時間把環境和這些 control／verification skill 設好，收益不只是讓你一個人變強，而是整個團隊與整間公司。她用內部 agent「Benny」把這個複利講成一個具體畫面。

• EBenny 收到「切換 panel focus 會打開空白側欄」的回報，在前一個 commit 重現、修正版消失：自動做了一次小 bisect→ 存＋演練

AI 補充這裡有一個容易被略過的因果鏈：本地與雲端的差別不只是機器在哪，而是「誰在看」。本地是為了讓人看得到 agent 的行為以便寫 skill；雲端是等 skill 夠好之後，把人從觀察位置上撤下來。所以這個順序不是保守建議，而是前一段那個迭代迴圈的必然結果。截圖是 Benny 在 Slack 的 #glass-oncall-assistant 頻道裡的一則回覆，把複利講得很清楚：原始回報來自 tyson，是一段自然語言描述加一段螢幕錄影——「切換 panel focus 會一直打開空白的 apps 側欄，即使我明確關掉它；另外如果 focus 在文字輸入框就不會打開」。Benny 的回覆標題是 Reproduced but already fixed on main，下面兩行結論：在前一個 commit 上重現成功、在修正後的版本上消失，並附上 view cloud agent 連結可以回看它做了什麼。值得注意的是它做的不只是「重現」，而是在兩個 commit 上各跑一次做了對照——這等於自動完成了一次小規模的 bisect，而這正好需要前面那個 control skill（能操作應用程式）加上 feature map（知道 apps 側欄在哪、怎麼觸發 panel focus）才做得到。

12. 沒有捷徑：信任要自己長出來 29:05–32:19

她強烈勸阻跳級：還在曲線底部就想一次開一千、一萬個雲端 agent，只會燒掉大量 tokeni 又很貴。主持人幫忙收斂成一條路徑——先做 verification 讓 agent 至少能產出正確的程式，本地信得過之後再擴到雲端讓它自動接收訊號、回一個 PR，最後才是自動合併、在 main 上事後 review。她補充這條曲線本質上是「你個人對 agent 的信任程度」，沒有捷徑；P-Stack 這類外掛能加速，但她明確不鼓勵盲目信任她，比較好的做法是 fork 一份改成自己的。因為每個人的工程標準不同，重點是把你在意的東西編碼成 skill，並且能驗證 agent 真的照做。

推理因為上一段展示的成果會誘發跳級，所以作者接著明確勸阻：還在曲線底部就想一次開一千、一萬個雲端 agent，只會燒掉大量 token 又很貴。主持人幫忙把整場收斂成一條可執行的路徑——先做 verification 讓 agent 至少能產出正確的程式，本地信得過之後再擴到雲端讓它自動接收訊號、回一個 PR，最後才是自動合併、在 main 上事後 review。她確認這條路徑，並強調曲線的本質是「你個人對 agent 的信任程度」，沒有捷徑；P-Stack 這類外掛能加速，但她明確不鼓勵盲目信任她，比較好的做法是 fork 一份改成自己的。

• E跳級的失敗不是「agent 做不出東西」而是「你沒能力判斷對錯」：瓶頸從輸入端移到輸出端，吞吐量沒變卻多付 token→ 存＋演練

AI 補充「為什麼不能跳級」值得補一個她沒明說的機制層面理由：跳級的失敗不是「agent 做不出東西」，而是「做出來的東西你沒能力判斷對錯」。一千個雲端 agent 產出的一千個 PR，如果沒有 verification 與硬約束，最後還是回到你一個人身上逐一審查——瓶頸只是從輸入端移到輸出端，總吞吐量沒變，卻多付了大量 token。這也是她那句「這條曲線是你個人的信任程度」的實際含意：曲線量的其實是你的判斷能力，不是 agent 的能力。她說「fork 一份改成自己的」而不是照用，理由也在這裡——別人的 skill 編碼的是別人在意的工程標準，用它得到的信任是借來的，撐不住你自己的判斷。

13. 真正的風險是沒有護欄的綠地專案 32:19–36:33

她轉到第三塊：重寫與重構。業界普遍勸人不要重寫，但她認為要看情況，而且判斷標準跟直覺相反。既有的 brownfieldi 專案其實處境不錯——大公司的基礎建設本來就是為「團隊裡能力最弱的工程師」設計的：框架、慣例、護欄i、限制權限，避免實習生把正式資料庫清掉；這些護欄現在剛好讓 agent 也不容易闖禍。真正的最大風險（同時也是最大機會）是綠地專案i：Grokbot 這種快速 vibe code 出來的原型，人根本沒在讀程式碼，等於完全沒有護欄，agent 拿到任務就挑最方便的方式解決，久了程式庫會朝她在推文裡說的「organic architecturei」失控生長——你看不懂它，agent 也只是照著一堆捷徑在堆。

推理因為前面兩塊（verification、skill）都在改變「agent 怎麼工作」，所以作者接著轉向改變「agent 在什麼環境裡工作」。她的論證從一個反直覺的觀察開始：業界普遍勸人不要重寫，但要看情況，而且情況跟直覺相反。既有的 brownfield 專案處境其實不錯——大公司的基礎建設本來就是為「團隊裡能力最弱的工程師」設計的：框架、慣例、護欄、限制權限，避免實習生把正式資料庫清掉；這些護欄現在剛好也擋住 agent。真正的最大風險同時也是最大機會，是綠地專案。

• Cguardrail：限制貢獻者能做什麼、讓錯誤做法難以完成的機制——大公司為最弱工程師設計的護欄剛好也擋住 agent→ 畫地圖
• Corganic architecture：沒人設計、由 agent 一次次選最方便的捷徑堆出來的結構，你看不懂、agent 也只是照著堆→ 畫地圖
• A「在 AI slop 之前我們就有 human slop」：agent 就是幾萬人 monorepo 裡「能力不均的貢獻者」的一員→ 批判類比

AI 補充這段最有力的一句其實是她的玩笑話「在 AI slop 之前，我們就有 human slop」——它拆掉了「程式碼品質下降是 AI 造成的」這個預設，把問題改寫成規模問題：幾萬人的 monorepo 早就面對過「大量能力不均的貢獻者同時改同一份程式碼」，而大公司的答案不是要求每個人都變強，是把標準做進工具裡。她的推論就是把 agent 直接放進「能力不均的貢獻者」這個位置——這一步是整場後半段的樞紐。反過來看綠地專案為什麼危險也就清楚了：Grokbot 這種快速 vibe code 出來的原型，人根本沒在讀程式碼，等於完全沒有護欄，agent 拿到任務就挑最方便的方式解決，久了會長成她所謂的 organic architecture——不是被設計出來的，是被一堆捷徑堆出來的，你看不懂它，agent 也只是照著堆。截圖捕捉到的是她正要去翻那則推文、把大綱頁留在畫面上的瞬間，剛好可以看到第三個 bullet 的原文：refactoring/rewriting architecture to be agent friendly，旁邊註記 (greenfield vs brownfield)——也就是這一段的完整標題。

術語:vibe codingi

14. 投資約束，換來不用讀程式碼 36:33–40:45

結論是新程式庫一開始就要有很強的約束。她自己花了六百多個 PR 把整個 Grokbot 重構到新架構（內部代號 Dunei），代價是大量 token，換到的是現在幾乎不再看程式碼、早上醒來二十個 PR 已經合併也不擔心有人半夜合進效能退步。她強調這不只利己：設計師、PM 甚至 GTM 的人都能安全地為 Grokbot 加功能。被問到 PR 大小，她說沒有硬上限，從五十行到上千行都有，但她會鼓勵 agent 把工作拆成多個 PR——git 歷史是很豐富的脈絡來源，每個 PR 原子性地描述一件事，出問題時才好定位與回退i，而不是一個四萬行的 PR 裡誰也不知道混進了什麼。

推理因為上一段判定綠地專案的風險來自缺乏約束，所以作者接著給出對應的處方與代價：新程式庫一開始就要有很強的約束，而她自己是花了六百多個 PR 把整個 Grokbot 重構到新架構 Dune 才補上這件事。她把收穫講得很具體——現在幾乎不再看程式碼，早上醒來二十個 PR 已經合併也不擔心有人半夜合進效能退步——並且強調這不只利己：設計師、PM 甚至 GTM 的人都能安全地為 Grokbot 加功能。被問到 PR 大小時她順勢補上一個原則：沒有硬上限，但鼓勵 agent 把工作拆成多個 PR。

• E六百多個 PR 把 Grokbot 重構到 Dune：現在幾乎不看程式碼，早上二十個 PR 已合併也不怕半夜混進效能退步→ 存＋演練
• RPR 沒有硬上限但鼓勵拆：git 歷史是脈絡來源，不讀程式碼時 revert 是唯一安全網，混五件事的 PR 會讓它失效→ 存＋回想

AI 補充「不看程式碼」聽起來像放棄品質，但她的邏輯其實是把檢查的位置換了：品質不是在 review 時檢查，而是在架構與 CI 裡先擋掉，人只在事後抽驗。這一步只有在下一層的約束真的夠硬時才成立，所以這段本質上是在替後面的內容押注。至於拆 PR 的理由她講得很精準——git 歷史是很豐富的脈絡來源，每個 PR 原子性地描述一件事，出問題時才好定位與回退，而不是一個四萬行的 PR 裡誰也不知道混進了什麼。這個理由在 agent 時代反而更重要：當你不讀程式碼，git 歷史就是你唯一還讀得動的東西，而 revert 也就成了你最後的安全網；如果一個 PR 混了五件事，revert 就會連帶砍掉四件無辜的修改，安全網等於失效。

15. Dune 的硬約束：連註解都禁 40:45–44:59

她描述 Dune 的 CI 有多煩：什麼都檢查。React 最大的地雷是 useEffecti，所以 Dune 直接禁用，CI 會失敗並罵你——Dune 的心智模型大致是「給 Electron app 用、專為 agent 撰寫而設計的 Next.js」。更讓人挑眉的是她連程式碼註解都禁了，因為九成九的情況 agent 寫的註解是在記錄無關的歷史，例如把她針對某個 PR 的一句「這裡不要這樣寫」寫成程式碼裡的永久全域規則。原則是：agent 做不好的事情，就全部禁掉。另一個實例是 Electron 的行程隔離——renderer 執行緒要在 16 毫秒內畫完一幀才有 60 FPS，一旦不小心把計算重或 IO 多的程式碼拉進 renderer 就會掉幀、卡頓i；agent window 就因為隔離做得差而反覆退步。

推理因為上一段把「強約束」講成一句原則，所以作者接著用具體條文證明她說的強是什麼等級。她的例子是有梯度的：先講一個工程師會點頭的（React 最大的地雷是 useEffect，所以 Dune 直接禁用，CI 會失敗並罵你），再講一個會讓人挑眉的（禁止程式碼註解），最後給出貫穿這些條文的原則——agent 做不好的事情，就全部禁掉。她再用 Electron 的行程隔離說明這些條文是從哪裡來的：renderer 要在 16 毫秒內畫完一幀才有 60 FPS，一旦把計算重或 IO 多的程式碼拉進 renderer 就會掉幀，而 agent window 就因為隔離做得差而反覆退步。

• RDune 的硬約束：禁 useEffect（CI 失敗）、禁程式碼註解；原則是 agent 做不好的事全部禁掉→ 存＋回想
• E禁註解的理由：agent 會把你對某個 PR 的一句「這裡不要這樣寫」寫成程式碼裡的永久全域規則→ 存＋演練

AI 補充禁註解這條的理由值得完整重述，因為它不是討厭註解，而是一個關於「脈絡層級」的觀察：agent 會把她針對某個 PR 的一句「這裡不要這樣寫」寫成程式碼裡的永久全域規則——它分不清「這次的指正」和「永遠的規則」。這其實是同一個病的另一種症狀：agent 對脈絡的時效性沒有概念，就像它會把過期的 skill 當成現行規則一樣。順帶補一個她口語上跳過的技術細節：Electron 的 main 與 renderer 嚴格說是兩個獨立的行程（process）而非執行緒，各有自己的事件迴圈，靠 IPC 溝通——這個區別正好是重點所在，因為「行程隔離」的價值就在於一邊卡住不會直接凍住另一邊；她說「隔離做得差」指的是程式碼在 import 層被意外拉到 renderer 那一側，而不是 OS 層的隔離失效。16 毫秒這個數字則是 1000/60 的結果，它是硬性的物理預算，所以任何一個超過它的長任務都會直接被使用者看見。

術語:foot gunirenderer processimain processi

16. 分層防線：硬的擋、軟的補 44:59–48:46

這些教訓被編碼進框架並變成硬失敗：Grokbot 裡實際有 electron main 與 electron renderer 兩個目錄，CI 會檢查相依圖i，確保沒有跨目錄的錯誤 import。她把防線分成幾層：最強的是架構本身——agent 最愛照抄既有模式，所以把建立功能的方式弄得非常制式，一個 feature 的所有程式碼（entry point、transcript card 等等）都放在同一個目錄，agent 不必四處 grep，八成的工作都封裝在那裡。她的關鍵原則是「最短路徑就是最好的路徑」：agent 本來就愛抄捷徑，那就把捷徑設計成正確解。往下是靜態分析i、CI 檢查、大量針對觀察到的壞模式寫的 lint、編譯器診斷，這些會讓 CI 變紅；再往下的 BugBoti 規則、skill、風格指南則是軟的，agent 會忘記、不見得每次照做，可以疊上去但不能當唯一防線。

推理因為上一段列出的規則種類太雜（架構、CI、lint、註解、目錄），所以作者接著給出組織方式：把防線分層，最強的是架構本身——agent 最愛照抄既有模式，所以把建立功能的方式弄得非常制式，一個 feature 的所有程式碼（entry point、transcript card 等等）都放在同一個目錄，agent 不必四處 grep，八成的工作都封裝在那裡。她從這裡導出關鍵原則「最短路徑就是最好的路徑」：agent 本來就愛抄捷徑，那就把捷徑設計成正確解。往下是靜態分析、CI 檢查與 lint，再往下的 BugBot 規則、skill、風格指南則是軟的。

• Cco-location／最短路徑就是最好的路徑：一個 feature 的所有程式碼放同一目錄，把 agent 愛抄的捷徑設計成正解→ 畫地圖
• R五層防線：codebase、static analysis、rules/BugBot、skills、style guide；前兩層讓 CI 紅→ 存＋回想

AI 補充第一張截圖上她手寫的清單就是這段的骨架，按強度排序：1. codebase、2. static analysis (lint/compiler/ci)、3. rules/bugbot、4. skills、5. "style guide"。第二張截圖拍到分界的說明與上方的 Dune 文件，資訊量更大。文件先列出 agent 的行為傾向當作前提（選擇最短且能編譯的路徑、避免刪除看不到呼叫端的程式碼、即使與系統不變量衝突也照著被要求的實作走），再從這些傾向推出 Dune 的五條規則：一、慣例路徑要比捷徑需要更少決策；二、被禁止的相依要機械性地失敗；三、每個持久狀態只有一個明顯的寫入者；四、新的產品工作是加獨立的檔案，而不是在共用根目錄長分支；五、例外必須窄、必須明講，而且要當成架構變更來審。文件還列出五個「公共名詞」（Feature、Entrypoints、Transcript cards、Client、Host），並規定 Dune 住在 `sand/dune`、應用程式住在 `sand/src`，Dune 永遠不 import 應用程式的程式碼。把這些和第一條原則對讀就會發現整套設計是同一個念頭：不是要求 agent 別抄捷徑，而是先觀察它會抄哪些捷徑，再把那條捷徑改成正解。至於分界線，她講得很直白——前兩層會讓 CI 變紅，屬於硬約束；第三到五層 agent 會忘記、不見得每次照做，可以疊上去但不能當唯一防線，否則程式庫遲早變成一團垃圾。這正好回頭解釋了前面兩段：她敢不看程式碼，是因為她信的是第一、二層，不是第四層的 skill。

術語:AGENTS.mdico-locationi

17. 選技術棧，也把 review 變成規則 48:46–51:08

既然要靠硬約束，技術選型就變重要。她舉 Rust 重新變紅的原因：編譯器夠嚴格、有 borrow checkeri 要應付，只要確保 agent 不寫 unsafei 區塊，能編過大致就能信它是對的——這種信心讓人類工程師不必自己去檢查。反過來，最糟的位置是「困在 code review 之地」：程式庫的不變量i全靠人讀程式碼、逐條留言來維持。她的判準很直接：每次你必須這樣留言，都該視為一種壞味道，並問自己怎麼把它變成一條 lint 規則i、一個 CI failure，或乾脆從根本上讓這個問題不可能發生。

推理因為上一段的結論是要靠會讓 CI 變紅的硬層，所以作者接著指出這一層的上限其實由技術棧決定。她舉 Rust 重新變紅的原因：編譯器夠嚴格、有 borrow checker 要應付，只要確保 agent 不寫 unsafe 區塊，能編過就有一定程度的信心——這種信心讓人類工程師不必自己去檢查。反過來，最糟的位置是「困在 code review 之地」：程式庫的不變量全靠人讀程式碼、逐條留言來維持。她的判準因此非常直接：每次你必須這樣留言，都該視為一種壞味道，並問自己怎麼把它變成一條 lint 規則、一個 CI failure，或乾脆從根本上讓這個問題不可能發生。

• P每次你必須在 PR 上留言糾正，就是壞味道：問怎麼把它變成 lint 規則、CI failure，或從根本讓它不可能發生→ 練習
• RRust 例子的限度：編譯器保證記憶體安全與型別正確，不是邏輯正確；「編過就不用驗證」會跟 verification 矛盾→ 存＋回想

AI 補充「code review 之地」這個診斷值得跟前面的信任曲線接起來看：靠人 review 維持的不變量，維持成本正比於 PR 數量，所以它會在你想往曲線右邊走的時候率先崩潰——這正是為什麼她把「還在靠 review 留言」視為結構性問題而不只是效率問題。她給的三段式處方也有明確的優先序，而且和上一段的分層完全對應：變成 lint 規則（第二層）、變成 CI failure（第二層）、或讓問題根本不可能發生（第一層，最強）。要注意 Rust 的例子在推理上有個限度：編譯器保證的是記憶體安全與型別正確，不是邏輯正確——能編過的 Rust 程式一樣可以算錯答案。她真正的論點應該讀成「編譯器擋掉的那一類錯誤，人就不必再檢查了」，而不是「編過就不用驗證」；否則會和她自己排第一位的 verification 相矛盾。

術語:code smelli

18. token 成本：這筆投資的 ROI 51:08–53:59

有人問這一切對 token 預算正常的人是否現實。她坦白自己在 AI 實驗室、token 無上限，不會說每個人都該照抄，但認為不破產也做得到，而對工程主管來說這是 ROIi 問題：前期重構、補齊約束確實很燒 token，但如果世界正走向由 agent 寫掉大部分程式碼，你會希望團隊保持精簡而不是變成一萬人的工程組織、背上大量規劃與溝通成本。她對 agent 價值的定義是「讓你做到以前做不到的事」：以一個人之力在程式庫裡建立並落實這種等級的約束，在前 agent 時代要花好幾年。而真正的判斷是——花錢請人來做，還是花 token 把程式庫整理到連最笨的 agent 都能寫好？做到之後，非旗艦等級的模型也能寫出很好的程式碼。

推理因為上一段的處方在成本上並不中性，所以作者接著必須正面處理它，而她的回答分成兩層。第一層是誠實揭露立場：她在 AI 實驗室、token 無上限，不會說每個人都該照抄，但認為不破產也做得到。第二層是把問題重新框架成 ROI：前期重構、補齊約束確實很燒 token，但如果世界正走向由 agent 寫掉大部分程式碼，你會希望團隊保持精簡，而不是變成一萬人的工程組織、背上大量規劃與溝通成本。她並給出對 agent 價值的定義——讓你做到以前做不到的事，而不是把 token 灑在每一件小事上。

• A花錢請人 vs 花 token 把程式庫整理到最笨的 agent 都能寫好：月成本 vs 一次性資本支出→ 批判類比

AI 補充她真正的判斷句是那句對照：花錢請人來做，還是花 token 把程式庫整理到連最笨的 agent 都能寫好？這個對照之所以有力，是因為它把兩邊放進同一個單位（錢），而且兩邊的性質不同——請人是持續的月成本，重構是一次性的資本支出，而且一旦做完，後續每一個 agent、每一位新同事都免費受益。用她自己的話說，以一個人之力在程式庫裡建立並落實這種等級的約束，在前 agent 時代要花好幾年。這裡還藏著一個回頭生效的推論：程式庫整理好之後，非旗艦等級的模型也能寫出很好的程式碼——也就是說，投資在環境上可以換到模型層級的降級空間，而模型成本是持續性的。換句話說，這筆一次性支出的回報不只是產能，還包括長期單位成本的下降。

19. Grokbot：非工程師的 Cursor 時刻 53:59–57:46

她補充剛發表的 Grok 4.6：更聰明、benchmarki 很好，而每 token 成本與 4.5 相同，等於同樣價錢買到更多智慧；他們刻意在成本與智慧的 Pareto frontieri 上找甜蜜點，而不是造最大的模型。回到組織問題：Cursor 原本只有 agent window、CLI、IDE，都是開發者取向的 power user 工具，非工程職能用起來並不愉快。Grokbot 的介面像 iMessage，很好上手也很好玩，可以給 agent 取名字、一個帳號一個 agent，用很自然的方式做編排i；PM 可以請 agent 摘要「Lauren 昨晚做了什麼」，也開始自己送出修 bug 的 PR，她 review 完常常直接蓋章。

推理因為上一段把 ROI 建立在「更便宜的智慧」上，所以作者接著順勢補上剛發表的 Grok 4.6：更聰明、benchmark 很好，而每 token 成本與 4.5 相同，等於同樣價錢買到更多智慧；她並解釋這是刻意的取捨——在成本與智慧的 Pareto frontier 上找甜蜜點，而不是造最大的模型。接著她回到組織問題：Cursor 原本只有 agent window、CLI、IDE，都是開發者取向的 power user 工具，非工程職能用起來並不愉快；Grokbot 的介面像 iMessage，很好上手也很好玩，可以給 agent 取名字、一個帳號一個 agent，用很自然的方式做編排。

• EPM 用 iMessage 般的 Grokbot 直接送修 bug 的 PR，她 review 完常直接蓋章：介面決定誰進得來，架構決定能不能合→ 存＋演練

AI 補充「這是非技術者的 Cursor 時刻」這個說法的分量在於它指出了一個常被忽略的瓶頸：限制非工程師使用 agent 的往往不是能力，而是介面預設了太多開發者的心智模型（檔案樹、終端機、diff）。把互動改成聊天串、把 agent 擬人化成一個有名字的同事，需要學的東西就從「工具怎麼用」變成「怎麼跟人交代事情」——後者他們本來就會。她舉的兩個實例剛好一收一發：PM 可以請 agent 摘要「Lauren 昨晚做了什麼」（消費資訊），也開始自己送出修 bug 的 PR（生產程式碼），而她 review 完常常直接蓋章。截圖這時其實還停在她的 Dune 文件與那張分層清單上——她講 Grokbot 時沒有換畫面。這個巧合反而很說明問題：能讓 PM 送出的 PR「直接蓋章」的，不是 iMessage 般的介面，而是畫面上那五條 Dune 規則與兩層硬檢查。介面決定誰進得來，架構決定他們送出來的東西能不能合。

20. 收尾：嚴格架構讓更多人能貢獻 57:46–59:41

她把兩條線收在一起：PM 與設計師能直接送出合格的 PR，正說明 Dune 那些嚴格約束撐住了——嚴格不是為了刁難人，而是讓不是工程專家的人也能高水準地貢獻，整個 Grokbot 團隊因此跑得很快。最後是問答收尾與致謝，並歡迎大家在 Twitter 上私訊她繼續問。

推理因為上一段的現象（PM 與設計師直接送出合格的 PR）需要一個解釋，所以作者在收尾時把它當成證據反推：這正說明 Dune 那些嚴格約束撐住了。於是全場的價值主張在最後翻轉了一次——嚴格不是為了刁難人，而是為了讓不是工程專家的人也能高水準地貢獻，整個 Grokbot 團隊因此跑得很快。最後是問答收尾與致謝，並歡迎大家在 Twitter 上私訊她繼續問。

AI 補充這個收尾把整場的兩條線接成一個閉環，值得回頭確認一次它的完整形狀：信任 → verification 讓 agent 能自證 → skill 把失敗模式編碼 → eval 讓 skill 可被量測 → 架構與 CI 把最重要的規則硬化 → 因為規則是硬的，人不必讀程式碼 → 因為不必讀程式碼，非專家也能貢獻 → 更多人能貢獻，投資才划算。最後這一環特別關鍵，因為它把「嚴格約束」從成本項改寫成擴張項：一般人直覺會認為嚴格的規範會勸退貢獻者，她的經驗剛好相反——當唯一那條路被設計成最短的路，不熟悉這個程式庫的人反而更容易走對。這也回答了整場最初那個問題「你怎麼信任 agent」：信任的對象從來不是模型本身，而是那個讓錯誤難以發生的環境。