讓 AI 半夜自己合併 PR：靠的不是 prompt，是驗證

一個月 1000 個 PR，是怎麼辦到的

她早上起床，發現 AI 已經自己合併了 20 個 PR 進主幹。她事後一個一個看，品質還不錯。

說這句話的人是 Lauren Tan。她待過 Meta 的 React 團隊，2026 年在 Cursor 擔任工程師，負責新的 Agents Window 和 Grok Bot。她自己說，加入 Cursor 第一個月幾乎沒產出，上個月卻合併了大約 1000 個 PR。

這篇文章整理自她在 2026 年 8 月 12 日的線上工作坊「How Cursor Turned AI Agents Into Better Engineers」，主持人是 Lenny’s Newsletter 的 Colin Matthews。

先講結論：她的秘訣不是更厲害的 prompt，也不是更大的模型。她靠的是三件事：

讓 AI 能自己驗證自己的成果
把 AI 常犯的錯寫成可重複使用的 skill，並且測試這些 skill
把程式碼庫改造成「AI 想偷懶也偷不了」的樣子

不信任 AI，你就只能當保母

Lauren 用「帶團隊」來比喻。假設你是主管，卻不信任手下的工程師，你會怎麼做？你只能一直站在他背後盯著，確認他沒把 bug 推上線。這就是微觀管理。

用 AI 寫 code 也一樣。你不相信 AI 的輸出，就得看著它的每一步。結果是你同時只能顧一兩個 AI，根本開不了更多。連一個都不信，怎麼可能放心開一百個？

她畫了一條「信任曲線」：橫軸是能同時跑幾個 AI，縱軸是你對 AI 的信任。

曲線底部：一直盯著畫面、一直下指令、一次只能顧一兩個
曲線頂端：AI 自己接任務、自己驗證、自己合併，人事後再檢查

她花了大約五個月爬上這條曲線。她強調，這條路沒有捷徑，因為爬的是「你自己」對 AI 的信任。

第一步：讓 AI 自己動手驗證

Lauren 認為，和 AI 合作最重要的能力是「驗證」。意思是讓 AI 真的把程式跑起來，用使用者的方式操作它：打開 App、點按鈕、抓效能紀錄、開手機模擬器。

她特別區分兩件事：驗證不能保證 AI 寫出「好」的程式，但至少能讓它寫出「對」的程式。這是建立信任的第一步。

沒有驗證時，人就是瓶頸

她剛到 Cursor 的第一週，被派去處理 Agents Window 的效能問題，一週後就要上線。她不熟程式碼，AI 也不熟。

她截圖、下載效能紀錄丟給 AI。AI 很有自信地說「問題就在這裡」，結果修完發現根本不是。

整個流程變成這樣：AI 改 code，她開程式測試，再把截圖和錯誤訊息貼回去。人卡在中間，什麼事都只能一件一件來。

解法一：教 AI 操作應用程式

她做的第一個 skill 叫 Control Glass（Glass 是 Agents Window 的內部代號）。它教 AI 用程式控制應用程式：啟動測試版、點擊畫面、抓效能紀錄。她說這段程式本身不難，AI 自己就寫得出來。

解法二：給 AI 一張「功能地圖」

AI 會操作了，卻還是不知道產品長什麼樣子。有人說「左邊側欄很卡」，AI 不知道側欄在哪、怎麼點過去，只能在程式碼裡亂找。

所以她加了一份 Feature Map（功能地圖），寫清楚每個功能：

使用者要怎麼走到這個功能
它底下有哪些子功能
有哪些快捷鍵
用程式選取畫面元素時，要用哪個屬性

有了這張地圖，就算有人在 Slack 只丟一張截圖、打三個問號，AI 也能找到是哪個功能，自己去重現問題。

她開源的工具包 pstack 裡有兩個 skill 專門做這件事：一個幫你建立驗證 skill 和功能地圖，一個在產品改版後更新它們。

第二步：把 AI 的壞習慣寫成 skill，再測試 skill

skill 是給新人的入職手冊

Lauren 說，AI 就像一個程式很強、但完全不懂公司業務、五秒前才報到的新人。你要讓他上手，就得給他入職訓練。skill 就是這份訓練，本質上只是一份 Markdown 文件。

她沒有一開始就規劃好 pstack。她是一邊緊盯 AI，一邊記下它犯的錯。每發現一種錯，就寫一個 skill 來防止它。

例如她發現：AI 說找到 bug 原因時，從紀錄看，它根本沒讀過相關的程式碼。它是用猜的。於是她寫了一個 skill，要求 AI「別猜，先去查 code，多開幾個小幫手去找」。

用 eval 幫 skill 做單元測試

skill 寫好了，怎麼知道它真的有用？她的答案是 eval，她把它想成「給 AI 用的單元測試」。不需要特別的工具，pstack 裡有一份做法說明，流程大致是：

讓一個主控 AI 先定好評分標準
開好幾個 AI 分頭執行任務，各自在獨立的資料夾裡做
資料夾名稱刻意偽裝，不讓 AI 發現自己正在被考試，因為 AI 察覺被測試時會改變行為
找另一個模型當評審，避免同一個模型自己打自己分數
同一個 skill 換不同模型跑，看看效果是否穩定

評分有了，還可以讓 AI 反覆修改 skill，直到每一項都拿到滿分。她說，連驗證用的 skill 本身，也是這樣磨出來的。

這件事需要品味

她坦白說，維護 skill 很難，需要大量觀察。她的建議是：一開始要當一個很囉唆的「後座駕駛」，像結對寫程式時一直問同事「你為什麼不這樣寫？」。去看 AI 呼叫了哪些工具、它在想什麼，找出它在哪裡出錯，再把那個錯寫成 skill。

她用主廚來比喻工程師的新角色：你不再自己煮每道菜，而是設計廚房、安排工作站，讓廚師們煮得好。

先在自己電腦上練，再放到雲端

Lauren 建議從自己的電腦開始。因為在本地，你看得到 AI 怎麼操作你的程式、卡在哪裡。

等到信任建立了，再把 AI 放到雲端跑。這時候前面做的驗證 skill 會帶來很大回報，因為受益的不只你一個人，而是整個團隊。

她舉了一個叫 Benny 的 AI 為例。每收到一份 bug 回報，Benny 就在雲端開一台電腦，執行 Cursor，用同一套 skill 去重現問題。有一次它重現成功，還順便確認主幹上已經修好了，只差發新版。這原本要花人一小時查清楚。

但她也提醒：不要從曲線底部一下跳到頂端。如果你連一個 AI 都還不放心，就一口氣開一百個雲端 AI，只會產出一堆爛 PR，白白燒掉大量 token。

主持人 Colin 把這段旅程整理成四步：

先做驗證，確保 AI 寫的東西至少是對的
在本地建立信任
擴展到雲端，讓 AI 自己接 bug 回報、交回 PR
最後才讓 AI 自動合併，人在主幹上事後檢查

第三步：把程式碼庫改造成 AI 偷不了懶

大公司的老專案，反而比較安全

她在 Meta 時發現，大公司的程式碼品質其實沒有想像中好。她開玩笑說：「AI 製造垃圾之前，人類早就在製造垃圾了。」

但大公司有很多框架、慣例和權限限制，用來防止能力最弱的新人闖禍，例如不讓實習生刪掉正式資料庫。這些護欄剛好也能管住 AI。

全新專案最危險

用 AI 快速做出來的新專案（大家常說的 vibe coding），完全沒有護欄。AI 每次都挑最方便的解法。久了之後，程式碼會長成她所說的「有機架構」：一團為了抄捷徑而長出來、人看不懂、越來越失控的東西。

Cursor 的新產品 Grok Bot 一開始就是這樣做出來的，原型階段沒人讀過程式碼。她花了 600 多個 PR，把整個產品重構到一套新架構，內部代號 Dune。重構完之後，她說自己已經不太需要看程式碼了。

Dune 立下的規矩

規則	為什麼
禁止使用 React 的 `useEffect`	這是 React 最容易出錯的地方
禁止寫程式註解	AI 寫的註解幾乎都在記不相干的往事，例如把她對某個 PR 的抱怨寫成永久規則
主執行緒和畫面執行緒的程式分開放，CI 檢查有沒有互相引用	防止耗時的運算被誤放進畫面執行緒，造成畫面卡頓
同一個功能的程式碼集中在同一個資料夾	AI 不用到處找，大部分工作在一個資料夾裡就能完成
每種元件都有固定的建立方式	AI 很愛照抄現有的寫法，慣例越一致越好

背後的核心原則只有一句：最短的路，就是最好的路。 AI 天生愛抄捷徑，那就把捷徑設計成正確的做法。

CI 會因此變得很囉唆，寫起來很煩。但煩的部分由 AI 吸收，人不用承受。

硬規則和軟規則

她把維持品質的手段分成兩類：

硬規則（違反就會讓 CI 失敗）：程式碼的架構本身、靜態檢查、編譯器
軟規則（AI 可能會忘記）：規則文件、skill、AI 程式碼審查、寫作風格指南

她兩種都用，但不會只靠軟規則。她直言，只靠軟規則的程式碼庫，變成垃圾只是時間問題。這也是 Rust 重新流行的原因之一：編譯器很嚴格，程式能編譯過，大致就能信任。

每一則 review 留言，都是一個警訊

她認為最糟的狀態，是靠人在 code review 時一條一條提醒「這裡不能這樣寫」。每次你想留這種留言，都該問自己：

能不能把它變成一條 lint 規則？變成 CI 失敗？或者乾脆讓這種錯誤不可能發生？

PR 要多大？

沒有硬性上限，從 50 行到上千行都有。但她會要求 AI 把工作拆成多個小 PR。她把 git 紀錄當成很重要的脈絡來源，每個 PR 只做一件事，出問題時也容易找到、容易撤回。

錢和人：值得嗎？

token 不是無限的

很多觀眾問：一般人沒有無限 token，做得到嗎？

Lauren 承認，她在 AI 公司上班，token 用不完，不建議大家照抄她的做法。但她認為這是一筆投資報酬率的帳：

前期重構、加規則，確實要燒很多 token
但另一個選擇是請一個高薪工程師，花好幾年做同樣的事
環境整理好之後，不需要最頂級的模型，一般模型也能寫出好程式
團隊可以保持精簡，不必變成上萬人的工程組織

不寫程式的人也能貢獻

主持人問：工程師產出這麼快，產品經理跟得上嗎？

她的回答是，Grok Bot 的介面像傳訊息一樣，不寫程式的人也用得順手。產品經理會叫 AI 整理她昨晚做了什麼。有些產品經理甚至自己修 bug、送 PR，她看過之後直接核准。

她認為這證明 Dune 架構撐得住：規則夠嚴格，不是工程專家的人也能做出高品質的貢獻。

先別急著照抄：幾個要打折扣的地方

這場分享很有啟發，但有幾點要冷靜看：

她的條件很特別。 token 無上限、自家產品、新專案，本人又是 React 核心等級的工程師。一般團隊很難複製。
「對」不等於「好」。 她自己也說，驗證只能保證程式是對的。讓 AI 自動合併、人事後再看，等於把品質把關挪到後面，前提是 CI 的規則夠完整。
PR 數量不是價值。 一個月 1000 個 PR 是產量，她沒有談缺陷率、撤回次數，或對使用者的實際影響。
考試標準也可能被考壞。 評分標準是 AI 自己定的，反覆修到滿分，也可能只是學會了應付這份考卷。
夾帶宣傳。 分享中穿插了 Cursor、Grok Bot 和新模型 Grok 4.6 的介紹，讀的時候要有意識。

一般團隊明天就能開始做的事

不需要無限 token，也能從她的做法裡挑幾件來試：

給 AI 一條指令，讓它能自己把程式跑起來、自己跑測試
寫一份簡單的功能地圖：每個功能在哪、怎麼走到
下次發現 AI 又犯同樣的錯，把它寫成一個 skill 或規則檔
下次在 code review 想留「不要這樣寫」，先想想能不能改成 lint 規則或 CI 檢查
新專案一開始就定好資料夾結構和寫法慣例，別等到失控才重構

結語

Lauren 的故事，表面上是一個人一個月交 1000 個 PR。但真正的重點是：她把力氣從「盯著 AI」，轉到「打造一個讓 AI 不容易犯錯的環境」。

能自己跑的驗證、測試過的 skill、讓錯誤寫法根本過不了的 CI，這三件事加起來，才是信任的來源。AI 時代，寫程式的速度已經不是瓶頸，驗證能力才是。

給 RD 的提醒：測試思維已經是基本功

仔細看 Lauren 的做法，會發現它其實是一套測試工程，只是換了說法：

Lauren 的說法	換成測試的語言
讓 AI 自己把程式跑起來驗證	自動化的端對端測試、效能測試
功能地圖	測試導覽圖，告訴測試的人每個功能怎麼走到
用 eval 測試 skill	給 AI 的單元測試，還要防止「考試作弊」
把 review 留言變成 lint 和 CI	把人工檢查變成自動化的品質關卡

她能放手讓 AI 半夜合併 PR，靠的不是相信 AI，而是相信自己設計的檢查機制。這正是測試的本行。

為什麼 RD 不能再把測試丟給別人

第一，瓶頸換位置了。 以前寫程式慢，測試跟得上。現在 AI 幾分鐘就能寫出幾百行，一天能開好幾個 PR。如果還要等 QA 一個一個看，整條流程就卡死在驗證這一關。

第二，RD 的價值換位置了。 打字寫程式，AI 已經做得又快又便宜。RD 剩下最有價值的工作，是判斷「這樣到底對不對」，以及設計出能自動回答這個問題的機制。

第三，AI 也會寫測試，但誰來檢查這些測試？ AI 寫的測試常常只測最順利的情況，或者測了等於沒測，看起來綠燈一片，其實什麼都沒保證。沒有測試能力的 RD，根本分辨不出來。

什麼是測試思維

測試思維不是「寫完再跑一下看看」，而是一種習慣性的懷疑：

動手前先問：怎樣才算做對？要怎麼證明？
不只想正常的路，也想邊界、例外和奇怪的輸入
AI 說「找到問題了」，先問證據在哪
同一個錯第二次出現，就想辦法讓它變成自動檢查

RD 該補哪些技能

測試設計技法：邊界值、等價類、決策表、狀態轉換，用來決定「該測什麼」
自動化測試：單元、整合、UI 測試，讓驗證可以不靠人重複執行
探索式測試：在規格沒寫到的地方，主動找出問題
靜態檢查與 CI：把團隊的規矩寫成機器會執行的規則
效能與可觀測性：會看效能紀錄、記憶體快照和系統指標

過去這些常被當成 QA 的專業。在 AI 寫大部分程式碼的時代，它們變成每個 RD 的基本功。會寫程式的人越來越多，會證明程式是對的人，才是稀缺的人。

來源

原始分享：SpaceX AI engineer, Lauren Tan。https://www.youtube.com/watch?v=I_oMJk6barY