SpaceX 的 AI 工程師 Lauren Tan，也就是最近很火的 poteto。在一場演講裡說她一個人一個月就合併了 2500 張 PR。如果你不是技術背景，可以把一張 PR 想像成你完成工作的一份結案報告。過去一般人一天能搞定兩三個小案子，效率就很驚人了；現在配合 AI，一天搞個十幾二十個也算是非常厲害。但她是一天平均可以處理八十幾個案子，甚至有天早上她醒來打開電腦，發現已經有 20 個 PR 是 AI 趁她睡覺時自己做完、檢查完然後提交出去的。
聽到這裡你可能會想，怎麼可能？因為我們自己平常在用 AI 通常還是得一直盯著它、幫它審核產出，怎麼敢讓它不經過你就直接把你做的東西提交出去？其實 Lauren 把她這整套做法開源了，並取名叫 pstack。相信不少人都有聽過，所以今天這集我們就來拆解這位最前沿的工程師到底是怎麼用 AI 的。看看她的工作心法和 pstack，能給我們一般人跟 AI 協作帶來什麼啟發。
如果你看過之前我們聊 Matt Pocock 的 skill，我也會把這兩套放在一起比一比，讓你知道你究竟利用 AI 開發應該選哪一個。先簡單介紹一下 Lauren 是誰：她過去待過 Netflix、Meta、Cursor 這類頂尖科技公司，現在則是在馬斯克的 SpaceX AI 團隊負責做 Grok Bot。我特別提她的背景，是因為她本身就是一位標準很高的資深工程師，所以她一個月合併的這 2500 張 PR 不是隨便讓 AI 亂生出來的垃圾，而是真的能進到大廠產品裡的程式碼。
但問題來了，就算她再厲害，一天八十幾張 PR，不要說自己親手寫了；就算叫她一張一張用肉眼檢查，時間也絕對不夠用。那她到底是怎麼做到的？我們可以從她最近開源的這套 pstack 工作流裡面推敲看看。把 pstack 拆開來看裡面裝了哪些東西、怎麼設計的，就能知道她的工作流到底是怎麼搭起來，為什麼效率可以這麼高。
pstack 這包工作流程裡面有將近六十個 skill。在看這些 skill 怎麼幫她拉高效率之前，我先花幾秒鐘講一下這套工具怎麼裝、怎麼啟動，讓你對它的運作方式有個基本概念。安裝方法一如既往的簡單：直接把 pstack 的 GitHub 連結丟給你的 Claude Code 或 Cursor，叫它幫你安裝就結束了。裝好之後，第一步要先跑一次 /setup-pstack。
這個 skill 是用來幫你做初始化設定的。它會先偵測你手上有什麼模型可以用，然後幫 pstack 裡面的每一個工作角色分配適合的模型。為什麼一開始要先做這件事？因為 Lauren 的核心觀念是：不同模型有各自的強項跟成本，不應該從頭到尾只用同一個模型。所以在她的預設設定裡，像寫程式、跑測試、分頭找資料這種耗體力的活，會全部派給便宜又快的 Grok。
而需要深度思考的，像是架構設計、寫文案，或是當裁判下判斷，才交給像是 Claude Opus 這類的前沿模型。完成這個初始設定之後，你可能會想：裡面有將近六十個 skill，我哪記得住什麼時候該用哪一個？其實不用擔心。因為這六十個裡面有二十四個是寫給 AI 遵守的底層工程原則，講白話就是他們是給 AI 閱讀的，不用你自己操作。
而剩下的三十幾個工具型 skill，雖然你隨時可以單獨打指令呼叫；但平常工作你只需要記一個總管指令叫做 /poteto-mode。/poteto-mode 本質上就是一個用來調度其他 skill 的工地主任，裡面內建了二十三本不同任務的標準作業手冊。你啟用它之後，它會根據你現在是要修 bug、做新功能還是改效能，自動翻開對應的手冊。
一步一步把適合當下場景的 skill 叫出來幹活。/poteto-mode 整套流程主要分成前期規劃、中期實作、後期驗收三個階段。要衝出一個月 2500 張 PR，前面的規劃跟實作追求的是讓 AI 一次做對、減少返工；而後面的驗收解決的是 agentic coding 裡面很重要的 verification，講白話就是怎麼讓 agent 檢查並驗證自己的產出，讓人類不用自己來。
我們就順著這三個階段先從動手前的規劃開始看起。「先規劃再動手」的概念已經盛行一段時間了。通常我們會開 Plan Mode，叫 AI 先寫一份計畫書給我們審核；或是先畫個 prototype，等確認沒問題了 AI 再根據這份計畫去實作。但 Lauren 在 pstack 裡對這個規劃階段做了更進一步的升級，因為一般的 Plan Mode 不會去挖那麼深的背景資訊。
它通常只是把附近的幾個檔案看一看，就湊出一份計畫開始做；但比較好的做法是：在規劃之前我們必須先徹底搞懂系統到底是怎麼運作的，以及當初為什麼要那樣設計。這就帶出了她在 pstack 裡對規劃的兩個核心 skills：/how 跟 /why。先講 /how，顧名思義就是先搞清楚現有的系統是怎麼運作的。如果 AI 只看眼前這一個檔案就開始規劃，很容易跟原本的架構衝突或是自己重複造輪子。
所以 /how 會在規劃前強迫 AI 先把相關的模組讀透、建立全局觀，才准開始想怎麼改。但光知道系統現在怎麼跑還不夠，還得知道當初為什麼要這樣寫；這就是 /why 在做的事。程式碼本身只會顯示結果，不會顯示歷史。很多時候系統裡有一段看起來很繞、很奇怪的寫法，其實是前人踩過某個大坑為了防呆才加上去的保護機制。
如果 AI 在規劃時不知道這段歷史，就會自作聰明把它改掉，結果讓舊的 bug 重新爆炸。所以 /why 這個 skill 會在動手前自動去翻手邊有的 context，比方說 Git 的修改紀錄、工單系統、Notion 文件甚至 Slack 的聊天紀錄，把當初為什麼這樣設計的前因後果全部挖出來。確保之後的改動不會讓以前想要防範的問題復發。
另外在規劃階段還有一個我自己很喜歡的小工具叫 /sharpen。因為我們平常叫 AI 做事下的 prompt 常常都很不精鍊，比如只打一句「幫我讓這個網頁跑快一點」，這樣產出來的結果通常都不太好。但如果你叫一般的 AI 幫你優化這個 prompt，它最常犯的毛病又是幫你亂加戲、塞一堆你當初沒要求的周邊功能把任務範圍越搞越大。
為了解決這個問題，在把任務交給 /poteto-mode 之前就可以先用 /sharpen 幫你升級 prompt。/sharpen 的設計目標很明確：它不發散你的需求，而是專注把你原本要做的這件事往深處做透。當你打 /sharpen 它會從頂尖專家的視角幫你重構這個 prompt。第一，它會要求 AI 重新思考你原先的需求：如果是這個領域的頂尖老手接到這個任務，有哪些關鍵步驟是他一定會做但你剛剛沒提到的？
第二，當 AI 要做判斷的時候必須從第一性原理出發直接去看最底層的原始碼或第一手源頭資訊，而不是看已經被消化過的二手文件來確保判斷不會被過時或失真的資訊誤導。第三，則是鎖定這個領域的專業人士會用什麼具體的工具與方法來完成這件事；以及最後要用什麼客觀方式來證明這件事是真的做對了。
把這幾個面向補齊之後，/sharpen 就會把你原本簡單的一句話重寫成一份含有明確驗收條件而且足夠有專業深度的 prompt，交還給你確認。你看過覺得沒問題了再送出去給 AI 搞定。前面的規劃之後，就進入第二階段：中期實作。如果你有看過我們之前介紹 Matt Pocock 的影片，應該記得他有一套專門規範 AI 怎麼設計架構、怎麼寫程式的 skill。
而在 pstack 裡面也有相對應的設計：首先在動工前，pstack 裡面有一個叫 /architect（也就是建築師）的 skill。它的核心精神就跟蓋房子一樣：先畫好格局圖才准動工砌磚頭。/architect 規定 AI 先不准寫裡面的細節，要先從使用者未來會怎麼用這個功能倒推先把整個系統的外框跟分工定下來。而且它的設計標準也蠻有趣的：/architect 預設下一個來接手的 AI 只會看眼前打開的那一個檔案，照抄最近的例子走最省力的捷徑。
所以好的架構必須做到就算下一個 AI 只看局部無腦照抄，改出來的結果對整個系統也還是對的。而這裡比較特別的是 /arena 這個比稿 skill：在畫這張格局圖的時候，它會在背後自動呼叫 /arena，把同一個題目同時丟給不同家的模型各自設計再交叉比對，把各家的亮點融合在一起。等確認這張集結各家優點的骨架沒問題了才讓負責寫程式的 AI 順著這個外框把裡面的程式碼真正實作出來。
最後到了真正動手寫程式的時候，它也會像我們在 Matt Pocock 那集介紹過的一樣強制使用 /tdd（也就是測試驅動開發）的 skill。因為如果讓 AI 先寫程式再補測試，萬一程式寫錯了它為了交差會直接生出一個配合錯誤邏輯的假測試來騙你說檢查通過。所以 /tdd 就是用來防作弊的：在寫任何一行程式之前 AI 必須先把檢查對錯的測試定死。
因為這時候功能還沒寫，測試一跑絕對會失敗亮紅燈；等到紅燈出現了才准 AI 動手寫程式碼，直到紅燈變成過關的綠燈為止。程式寫完之後就進入整套系統最關鍵的第三階段：後期的審核與驗證。要理解 Lauren 怎麼做到一個月合併 2500 張 PR，最核心的關鍵就在這裡。因為現在用 AI 寫程式已經非常快了，真正的瓶頸其實卡在檢查：也就是你敢不敢讓 AI 寫的 code 正式上線。
要跨過這個瓶頸無非就是從兩個地方著手：第一，大幅加快你自己審核 PR 的速度；第二，乾脆把審核從合併前拿掉但還能確保產出不會出包。我們就順著這兩個方向看 Lauren 在 pstack 裡是怎麼設計的。先看第一個方向：怎麼把審核一張 PR 的速度拉到最快？平常我們審核 AI 寫的 PR 會比較花時間，因為我們心裡都在擔心三件事：第一你說改好了新功能真的會動嗎？
第二你改了這裡影響範圍有多大會不會把別的地方弄壞？第三裡面的程式碼品質好不好有沒有藏著低級漏洞？在 pstack 裡 Lauren 用三個 skill 逼 AI 在交出 PR 之前就自己把這三件事證明完。首先是第一關：證明新功能真的會動，靠的是 /create-verification-skill。我們從最根本來想：為什麼以前 AI 改完程式非得要人類自己打開 App 點點看？
因為 AI 只看得懂程式碼，它根本不知道這個 App 要怎麼啟動、某個功能的按鈕在畫面哪裡、點完之後看到什麼畫面才算成功。而 /create-verification-skill 的本質就是讓 AI 先去把整個專案讀透，自動寫出一份怎麼像真人一樣操作並檢查這個 App 的標準 SOP。只要建立好這份 SOP，以後 AI 每次改完程式碼就能自己打開 App 照著真實使用者的路徑點一遍，並把操作過程錄成影片或截圖直接當作它已經完成而且你的 App 沒被改爆的證據。
接著第二關是評估這次修改的影響範圍有多大，這時候就輪到 /blast-radius（也就是檢查爆炸半徑）上場了。當你一天要審幾十張 PR，你不可能每一張都花一樣的時間細看；所以 /blast-radius 存在的目的就是先幫你標出這張 PR 的風險高低。如果爆炸半徑很小只改到一個獨立的小角落，你掃一眼就結束了；但如果爆炸半徑很大動到了好幾個功能共用的底層邏輯，你就知道這張 PR 必須特別小心也值得你多花一點時間。
確認了外在的功能會動、也看清了爆炸半徑之後，第三關就是確保裡面的程式碼品質。靠的是 /interrogate（交叉審問）。為了讓人類不用費盡心思去盯每一行 code，AI 在開出 PR 之前必須先過這一關。很多人讓 AI 幫忙審程式碼喜歡叫同一個 AI：「現在請你扮演資深專家來挑毛病。」但 Lauren 直接點破同一個模型不管換幾個角色，它的盲點還是一模一樣漏掉的地方永遠會漏掉。
所以 /interrogate 的做法是把改好的程式碼同時丟給不同家族的模型去審，比如讓 Claude 跟 Grok 一起抓漏。這樣一來 Claude 沒看出的死角 Grok 能幫你抓出來；而且如果某個地方連兩家不同模型都異口同聲警告有問題，那就代表這絕對不是誤判。AI 必須在交件前先把這些漏洞徹底修掉，不過也要提一下這樣的做法就是一定會消耗掉你比較多 token。
所以預算比較緊的朋友可能要慎重考慮，我四個月前也有出一部關於 cross model review 的影片。雖然現在的做法有稍微調整但背後是一樣的理念，有興趣的朋友可以去看看。經過這三關之後當一張 PR 送到 Lauren 面前時裡面的程式碼已經被不同模型交叉洗過一輪，而且 PR 裡面也直接擺好了修改前後的操作影片跟爆炸半徑的實測數據。她根本不用自己把程式拉下來跑，只要打開 PR 頁面看一眼敘述、截圖或操作影片。
幾十秒鐘就能確認這張 PR 有沒有做對然後按下核准。搞定了第一個方向讓審核速度變快之後接下來第二個方向更關鍵：如果要像 Lauren 一樣半夜睡覺時讓 AI 自己合併 20 張 PR，也就是把人類在合併前按確認這一步徹底拿掉。那要怎麼確保系統不會亂來？這就要講到 /poteto-mode 裡面專門為過夜工作設計的全自動模式。
當 Lauren 睡前開啟這個模式丟給 AI 一排任務清單之後，AI 就會自己從寫程式、開 PR、跑完前面那三關檢查一路自己按下合併，全程不等人。但既然沒有人類按確認了為了防止 AI 自己放水 Lauren 在這裡設下了一條最硬的鐵律：寫這張 PR 的 AI 永遠沒有權力核准自己的 PR。道理就是球員不可以兼裁判。
在全自動模式裡每當一張 PR 準備要合併系統就會呼叫另一個叫 /swarm 的 skill，另外派出十個左右從頭到尾沒參與寫這段程式的獨立驗收 AI。同時在雲端把 App 打開各自像這個 App 的使用者一樣到處點擊測試找有沒有東西被弄壞。只有當這群獨立裁判全部蓋章通過系統才會自動把這張 PR 合併進主線。
看到這裡你可能會問：如果連合併都全自動了，那 Lauren 隔天早上醒來的工作是什麼？其實她還是在把關 AI 的產出並且觀察 AI 的工作流程哪裡有問題好去修正系統環境。只是到了這個階段她不再一張一張全看，而是改成抽樣檢查。但問題是 AI 一整晚跑了這麼多任務她要怎麼在幾分鐘內知道該抽查哪幾張？又怎麼看出 AI 半夜在哪個環節卡關？
這就要靠 /show-me-your-work 這個 skill。因為 AI 半夜解問題不會每次都一次寫對，可能先試了 A 寫法失敗才退掉改用 B 寫法。如果只看最後合併的程式碼你根本不知道它中間踩過什麼坑；所以這個 skill 規定 AI 必須邊做邊填一張決策紀錄表，把昨晚試過哪個做法失敗、最後為什麼這樣改以及怎麼驗證的全部一行一行記下來。
而且在隔天早上交給 Lauren 之前系統還會先派另一家不同模型的 AI 去核對這張表，直接把昨晚驗證不夠扎實或改法有風險的地方標記出來。這樣她早上醒來只要看表格上被標記出來的重點就能馬上挑出有風險的 PR 來抽樣檢查，同時一眼看出 AI 的工作流程哪裡有漏洞直接去補強環境。如果在復盤過程中發現 AI 一直被同一顆石頭絆倒，她就會開始補強環境。
大部分人遇到 AI 犯錯直覺反應是在 prompt 或 AGENTS.md 裡加一條規定叫它下次注意。但 Lauren 認為這種做法沒什麼用，因為寫在 AGENTS.md 裡的文字屬於軟規則：AI 就算讀了聊幾句之後還是會忘記。她每看到 AI 犯一次錯問自己的問題永遠是：要怎麼改系統環境才能讓這個錯從物理上就不可能發生？
所以在 pstack 裡面她做了一個專門用來改造環境的 skill 叫做 /correct。當你發現 AI 老是犯同樣的錯只要跑一次 /correct，它就會去翻過去的修改紀錄跟退件原因幫你把這些錯誤轉化為系統的防呆機制。比如 AI 天生最愛照抄現有程式碼，她就確保在專案裡的每一件事情只有一種標準寫法讓 AI 能抄的全都是正確範本。同時她把容易出事的老毛病寫成 Linter 檢查規則接上 CI 自動閘門。
像在寫前端 React 介面的時候如果用 useEffect 這種寫法非常容易出現讓畫面卡死的 bug。
她就在專案裡新增 Linter 規則，直接禁用。只要 AI 敢寫出來，CI 的自動檢查就會立刻亮紅燈把它擋下來。AI 就一定得再根據這個錯誤去修正成正確的寫法，才能完成任務。至於把規則寫進 AGENTS.md 則是最後萬不得已的手段，因為這種軟規則就算 AI 沒照做，你也不會知道。這樣做的好處，不只是讓 AI 少犯錯。Lauren 說，因為整個環境已經被她改造到想寫錯都很難。現在他們團隊裡連不懂深度開發的產品經理跟設計師，都能自己叫 AI 改功能、送出 PR。而且她打開看一眼通常就能直接核准。
把 Lauren 的這整套 pstack 攤開來看，從前期規劃、中期實作、後期驗證到最後的修正環境，你就會明白為什麼它的效率跟品質可以同時拉到這麼高。一方面，它在產出階段善用不同模型的強項；不管是設計架構時的比稿，還是寫完後的交叉審問，都是靠多模型各取所長、互相挑錯，先把單次產出的品質拉到極致。接著又把後面的自動化驗證跟防呆環境做到極致，確保每一張交出去的 PR 都經得起考驗。這時人類才敢真正放手。
不過，光靠 pstack 把單一任務做好，還不足以解釋她怎麼做到一個月合併 2500 張 PR。因為平均下來一天要產出八十幾張 PR，她既不可能自己同時盯八十個對話框，也不可能每天自己想出八十個任務。要撐起這間二十四小時自動運轉的 AI 工廠，她在 pstack 外圍還搭了兩套機制：一套負責平行派工，一套負責自動進單。先講平行派工，她就像一個經營十幾間分店的老闆，電腦裡同時開著十幾個專案。
比如一個專案專門管桌面版的速度，一個專案專門修使用者回報的 bug。每個專案裡都有一個不寫程式的總管 AI，只負責看全局、把大任務拆小，再派給底下的工人 AI 去寫。最後交給前面說的驗收團去自動審核跟合併。再來是自動進單，也就是讓工作自己找上門，分成對外跟對內兩條線。對外，她用 Grok Bot 二十四小時盯著 Slack、X 和 email 上的使用者回報。
但你想想看，一般使用者回報問題通常都很模糊，可能只丟一張截圖加一句「畫面卡住了」。這種訊息是沒辦法直接交給寫程式的 AI 去做的。所以 Grok Bot 在中間扮演的角色，就是把這些模糊的抱怨轉化成 AI 能執行的標準任務。每當看到新回報，它會先去翻程式碼跟工單紀錄，確認這是哪個模組的問題、是不是已經有人報過了。接著直接在雲端打開 App 照著操作一次，確認這個 bug 真的能重現，而且在最新主線上還沒被修掉。
最後才把問題出在哪段程式、怎麼重現，以及壞掉的截圖證據打包成一張清楚的任務單，直接發訊息丟給負責那個專案的總管 AI 去派工修復。至於對內，她則是派了專門的巡邏 AI，每天在整份程式碼裡掃描壞寫法。但規定它不准看到就自己亂修，而是先記進一份清單。過幾天她看一次清單，常常會發現上面記的十個問題背後其實是同一個根本原因。
這時候再交給總管 AI 一次派工處理掉，比派十個 AI 各自瞎忙有效率得多。我認為自動進單對很多 builder 來說會是解決開發瓶頸的一個好方法，畢竟現在開發速度越來越快。一個團隊的運營端還有行銷端可能也會要求工程端有更多的彈性，很多團隊也不再跑 Scrum 了，而是直接私訊開發者問問題或者發需求。如果有 Lauren 這樣的進單機制，或許可以省掉我們不少時間。如果你有類似的痛點，不妨深入研究一下 Lauren 的做法。
但是聽到這裡，你或許會覺得 Lauren 這麼完整且瘋狂的體系離你很遙遠。但她剛起步的時候，跟我們絕大多數一般人一樣，都是自己守在電腦前面、一步一步盯著 AI 做事。Lauren 剛進 Cursor 的第一週，被臨時調去救一個下禮拜就要上線、但跑起來超卡的新功能。因為對程式碼還不熟，她一開始的做法也是自己打開軟體測試、截圖、複製錯誤訊息貼給 AI。等 AI 改完，她再打開來測一次。
她後來形容那時候的自己就像一個人肉轉接頭，因為 AI 看不到自己做出來的結果，只能靠人類夾在中間幫忙轉述。而只要人類還卡在中間當這個轉接頭，你就永遠不可能同時開很多個 AI。其實大部分人的起點都是一樣的，但拉開差距的關鍵在於：你有沒有一直思考 AI 到底可以怎麼幫你完成工作，好讓你把自己不斷往工作流程的後面移動？
她在演講裡把這個過程畫成了一條信任曲線。你對 AI 的信任度越高，你同時能放出去工作的 AI 數量就越多。但這份信任必須一階一階往上爬，完全沒有捷徑，就跟你當主管帶新人一模一樣。剛帶一個新人的時候，你還不放心他，只能站在他身後盯著他每一步怎麼做。這時候你頂多只能帶一兩個人；要等到你確認他懂規矩、也會自己檢查了，你才有辦法把事情放心交出去，同時管理一整個團隊。
把這條信任曲線拆開來看，其實就是她一步步把自己的工作往後移的四個階段。第一階是全程緊盯，也就是她剛進 Cursor 時當人肉轉接頭的狀態：AI 每寫完一段你就要看一次，隨時下指令糾正。現在絕大多數人都在這一階。第二階是 AI 自己驗收，當她寫出了驗證 skill，讓 AI 交件時自己附上截圖跟影片證據。她就不用再當轉接頭，工作開始往後移到看證據判斷到底對不對。
第三階是 AI 自己接單，當問題回報進來，外圍的機器人跟總管 AI 會自己去重現、自己派工修好。她只需要在最後看結果，直到第四階才是 AI 自動合併：只要獨立驗收團檢查全過，系統就直接合併。把她自己的工作徹底退到最後一步，也就是隔天早上再來抽查跟改善環境。Lauren 爬上第四階其實花了非常大的力氣，光是為了把她負責的專案重新整理成前面說的防呆架構，她就先花了六百多張 PR 在打地基。
她自己也老實說，第一次在睡前放手讓 AI 整晚自己跑、自己合併的那天，她其實超害怕半夜把整個系統弄垮。結果隔天醒來發現一切正常，從那之後她反而睡得比以前更香了。所以她也一再提醒大家：千萬不要在信任地基還沒打好的時候，就學別人一次開十幾個 AI 平行跑。那樣做只會讓你用十倍的速度產出垃圾，還會白白燒掉一堆 token。換句話說，一個月 2500 張 PR 並不是你今天裝了 pstack、明天就會出現的魔法，而是把驗證跟環境一步步建好之後的自然結果。
聊到這裡，如果你有看過我們之前介紹 Matt Pocock 那套 skill 的影片，把這兩套放在一起比一比，你可能會好奇：那我平常開發到底該選哪一套？表面上看，這兩套都在做開發自動化，但它們把力氣花在完全不同的地方。在 Matt 的工作流裡，核心重心放在動工前的人機對齊以及合併前的人類把關。他會先用 grill-me 讓 AI 不斷向你提問，把你腦袋裡模糊的想法問清楚，寫成 to-spec 規格書、拆好任務卡才准動工。
等寫完之後，再用 PR 把證據整理好交給人類在合併前做最後確認。整套流程預設人類守在一頭一尾，而且用單一模型就能順順跑完。同時 Matt 也很在意模型的 context 狀況，所以整套跑下來的 token 用量我覺得相對很低。但 Lauren 的 pstack 則是為了一天處理八十張 PR 這種極端規模設計的，所以她的核心重心是把人類介入壓到最低，並把最多的資源砸在動工後的多模型自動驗收。
在她的規則裡，只要一個問題能靠 AI 自己讀程式碼查清楚，或是自己寫個小版本實際跑出數據來比較，就一律不准停下來問人類。而在程式寫完之後，她更是不惜狂燒 token：同時派多家模型交叉挑錯、再派十幾個獨立 AI 實機驗收，直接代替人類合併。把人類徹底推到合併後的事後抽查。所以這兩套其實沒有誰比較好，而是看你現在面對的是什麼問題以及你偏好的工作模式。
如果你正在做從 0 到 1 的新功能，腦中的想法還很模糊。這時候你到底想要什麼只有你自己知道，AI 跑再多測試也猜不到。那可能更適合 Matt 的方法：讓 AI 來拷問你，幫你把規格定下來。相反的，如果你的專案已經有龐大的歷史程式碼，需要大量修 bug、重構或改效能。這時候重點是不能把舊系統改壞，那 pstack 自動挖歷史、多模型比稿跟嚴格的實機驗收用起來就會更舒服。
就像 Lauren 本人在 X 上說的，這兩套其實可以完美互補：前期還不確定方向時，先用 Matt 的 skill 幫你想清楚自己到底要什麼；等目標明確了，再交給 pstack 嚴格的驗證流水線把東西落地。不過如果你剛開始想導入這類工作流，我還是建議一般人先從 Matt 的模式起步。因為 Lauren 這種敢讓 AI 自動合併的做法，前提是你已經建好了一整套自動驗證跟防呆環境，又有足夠的 token 預算。
對大多數人來說，先走 Matt 的路：在動工前對齊需求、合併前親自看過證據，才是最穩健的起點。而且過程中只要你不懂就問，也會有不少的學習和成長機會。Lauren 則是讓我們看到了大家在說的軟體工廠到底會長什麼樣子。那如果我們一般人也想朝這個方向走，具體該從哪裡開始？我把 Lauren 給新手的建議整理成了六個步驟。每一步都有一個過關標準，你確認做到了，再往下一步走。
第一步是先用一個 AI 觀察它怎麼失敗。她給新手的建議其實非常保守：一開始先不要急著裝任何大禮包，包括 pstack 也先不用裝。你先用一個 AI 處理日常工作，仔細觀察它最常在哪裡出包。每次你開口糾正它，就把那句話記下來。等你能夠清楚講出它最常犯的三種錯誤，再進入下一步。第二步是把你的糾正變成規則：把剛剛記下來的錯誤寫進 AI 每次都會讀的說明檔裡，比如 CLAUDE.md。
但如果這條規則能用系統檢查或 hook 自動攔截，就絕對不要只寫在文件裡。做到同一種錯誤不再出現第二次就算過關。第三步，也是最關鍵的一步，叫作「交件一定要附證據」。以後不管叫 AI 做什麼，都不准只聽它口頭說做好了。做網頁就叫它自己打開瀏覽器點一遍、截圖給你看；整理資料就叫它列出核對過哪幾筆、怎麼核對的。直到你不用親自打開檔案，光看它附上的證據就能判斷對不對，這一步才算練成。
第四步是開始同時開兩三個 AI 並把做跟審分開。當你在上一步練成光看證據就能快速驗收之後，你終於有餘裕同時開兩三個互不相干的任務平行跑了。從這一步開始，你要練習不要讓同一個 AI 球員兼裁判：當負責寫的 AI 交出成果跟證據之後，先派另一個不同模型的 AI 幫你挑過一輪毛病。沒問題了再由你親自按下合併，做到同時開三個 AI 你都還照顧得過來、而且交回來的東西大部分不用重做，這一步就算過關。
第五步則是嘗試睡前交代任務但停在合併之前。當白天同時顧幾個 AI 已經很穩了，你就可以試著在睡前交給 AI 一個長任務。不過因為人不在電腦前，為了防止 AI 半夜跑偏或瞎忙，你睡前必須把完成條件定義成非黑即白、AI 自己能判斷過或不過的標準。比如「把畫面改好看一點」這叫無法判斷；但在手機螢幕上不用左右滑、每個按鈕都點得到，這就判斷得了。同時也要設定好停損點：規定它如果卡住太久就停下來寫出原因。
最關鍵的是，這個階段只允許 AI 自己存檔跟開好 PR，還不准它自己合併上線。像是合併、發布、刪資料或對外發訊息這種比較難以挽回的動作，一律留給隔天早上的自己。第六步就是當你連續幾個早上醒來發現它半夜準備好的 PR 都不需要你幫忙收拾殘局、看一眼就能直接合併時，你就可以正式邁向最後一步：開啟自動合併並讓工作自己找上門。
到了這一步你才真正放開最後一道鎖：規定只要獨立驗收 AI 檢查全過，系統就能直接自動合併。你隔天早上只做抽樣檢查；同時你也可以設定排程讓 AI 定時去巡你的信箱、表單或工作群組，看到新問題就自己重現、自己修好並合併。完成屬於你的全自動工作流。在這六個步驟裡面，前面四步是最花時間但也最值得投資的基本功。不過如果各位有按部就班走完，你得到的不是 pstack 或者 grill-me，而是屬於你自己的工作流。
而這個東西才是最香也最有成就感的。看完 Lauren 的整套做法，你會發現讓 AI 全自動完成工作並不是一個你今天下載安裝、明天就能直接開啟的功能，而是當你爬到信任階梯最頂端時才看得到的風景。在 AI 時代驚人的產量是信任的結果，而這份信任是靠著扎實的驗證與環境一點一滴換來的。非常感謝看到這邊的各位，我一直相信他山之石可以攻錯，所以會儘量用白話拆解國內外一些優質的 AI 使用技巧。
希望對你有所幫助！如果你不知道，我有經營一個 AI 實戰營，裡面會有我的實戰心得分享還有各種資源。比方說針對這支影片我就整理了如何混搭 Matt 和 Lauren 的 skill；除此之外我也寫了一個提示詞，幫你評估自己究竟用 AI 的方法處於 Lauren 說到的六步中的哪一步。我會把以上內容都放到影片下方資訊欄，感興趣的朋友可以自取。那以上就是今天的內容，各位喜歡的話記得幫我按讚、追蹤加分享，這是我持續創作下去的動力。我們下次見。