非官方中文整理，與 Lauren Tan、Cursor、SpaceX 無關。每段引用都附原文連結，以原文為準。

Lauren（@poteto）的 Agent 工程學習筆記

整理日期：2026-10-14（2026-10-16 補上 pstack 0.15.25 的變化）。整理範圍：她 2026-03 到 2026-10-14 在 X 上的 456 則原創貼文、5 篇長文章，加上兩篇第三方整理的演講內容。

Lauren Tan，X 帳號 @poteto，以前在 Meta 做 React Compiler，2026 年 3 月加入 Cursor，現在在 SpaceX AI 做 Grok Bot。pstack 是她把自己的工程習慣寫成的一套 agent 技能包。

一、一頁看懂：她反覆在講的 7 件事

  1. 瓶頸是驗證，不是寫程式。 Agent 寫得很快，難的是確認它寫對了。先讓 agent 能自己打開 app、像使用者一樣操作並截圖錄影，才談其他。
  2. 先建立信任，再平行。 還不信任 agent 時開 100 個，只會更快產出爛程式碼（slop）。她說要「先深再廣」（go deep first）。
  3. 不要當人肉傳話筒（meat proxy）。 她一直問「我在這個流程裡哪裡是瓶頸？」：貼錯誤訊息、描述截圖、轉述客戶的話，每一個都該換成工具或 bot。
  4. 同一個錯不要糾正第二次，改環境。 有效程度由高到低：用架構讓錯誤不可能發生 → lint／測試讓 CI 擋下 → 寫成技能或規則 → 靠人審（她直接寫「ngmi」，意思是沒前途）。
  5. 程式碼庫就是 agent 的記憶。 Agent 會照著已經存在的東西模仿，所以一個暫時的 workaround 或過時註解會像病毒一樣擴散。她甚至建議刪掉大部分註解。
  6. 用程式碼規劃，不寫抽象計畫。 不相信長篇 Plan Mode，改成：讓 agent 用自己的話重述目標、做幾個原型比較、先寫 README 或型別簽名，再實作。
  7. 寫作就是思考。 她不讓 agent 替她寫任何東西。她認為能把意圖說清楚、知道正確的術語，是用好 agent 最關鍵的能力。

二、時間線：她的方法怎麼演變

三、核心觀念詳解

1. 驗證技能是基礎建設

她把「驗證技能」當成關鍵基礎建設，不只是一個技能。驗證技能讓 agent 能自己啟動 app、操作、截圖、錄影、抓效能數據，做完自己檢查，不必等人。

一個好的驗證技能有兩個部分：

功能地圖很快就會過時，所以她每天排程跑 /maintain-verification-skill 更新它。

「如果 agent 看不到自己工作的結果，它就不可能迭代。」（Matt Pocock 訪談）

她對驗證的期待，是 agent 交出能證明三件事的成果：

  1. 做對了。
  2. 符合她的意圖。
  3. 比讀整個 PR 容易審。

UI 工作通常就是影片加截圖。她也講明限制：驗證只是近似，還是可能錯，而且不是每個領域都容易驗證。

2. 信任階梯：先深再廣

她剛開始只敢同時看 1 到 5 個對話，每個都要盯、要一直糾正。她說這是最難走出去的階段，因為你看不到出口：不信任 agent 的成果，就不敢放手。

「還沒建立信任就平行跑 agent，是浪費大量 token，還會把更多 slop 塞進程式碼庫。」（How I Use Cursor）

平行的正確用法是「深」，集中在一兩個問題上：

信任越高，她越能往上一層管理。信任低就只能微觀管理每個 agent，「跟管人完全一樣」。

3. 不當人肉傳話筒：內圈與外圈

「人肉傳話筒」這個詞，是她在修 Cursor 效能時發明的：她自己在 agent 和 Chrome DevTools 之間手動抄數字。後來她發現更大的問題在外面：她一直親手把 Slack、Linear、X 上的回報搬給 agent。

她現在的架構分兩圈：

她修 bug 的自動化流程有四段，每一段都可以喊停：

  1. 分類：判斷這是不是 bug，或其實是設計如此。
  2. 重現：要重現兩次，並截圖錄影。
  3. 修正：寫測試、做能證明的最小修正、跑修正前後對照，開 draft PR。
  4. 驗證：重現時發現已經有人開了 PR，就幫它跑前後對照確認。

「每一段都可以停下這條產線，這些都是有用的結果，因為它們讓爛成果不會流到下一段，那裡修正會貴得多。」（Loops You Can Trust）

她也提醒：若外圈接在一個還沒鎖好的程式碼庫上，自動化只會放大爛 PR。

4. 糾正一次就改環境，不要改 agent

「每次你介入糾正 agent，都要想怎麼讓這件事徹底消失。價值由高到低： 1. 用更好的架構或資料結構，讓問題根本不可能發生 2. 變成 lint 規則或測試，讓 CI 擋下 3. 變成技能或規則 4. 靠人審程式碼抓（ngmi）」 （2026-08-16）

演講裡她再細分成五層，並強調技能和規則屬於「指引」：agent 會忘記讀，所以不能當成唯一的關卡。人審的用途是發現缺口，發現後要把它往上推到架構或 lint。同一類審查意見一直出現，就代表它還卡在最弱的那一層。

她把這個角色叫做「園丁」：每拔掉一根雜草，就把它變成規則，讓它長不回來。

「很容易掉進微觀管理 agent 的陷阱，而不是修正塑造它行為的環境。」（/correct 發表文）

/correct 技能就是做這件事：發現你一直為同樣的錯誤糾正 agent 時，它會找出模式，用架構、型別、檢查來修。

2026-10-15 的更新把幾條原則改寫成講理由（版本號仍是 0.15.25，從 commit 99743e9 起）。舊版是硬規則，例如規定用哪種寫法、禁止哪種寫法；新版改成說明背後的想法，讓 agent 碰到原文沒寫到的情況也能自己判斷。（#633）

5. 程式碼庫就是記憶

「你要知道的兩件事：1. 給 agent 驗證自己工作的方法。2. 你的程式碼庫就是記憶。先別管規則和技能，那些之後再加。」（2026-10-12）

Agent 喜歡延伸已經存在的東西。所以你看過的每個小毛病、每個 agent 犯過的壞模式，都要變成約束，不然它們會像病毒一樣重複出現。

她為 Grok Bot 做了一個內部框架 Dune：每個功能一個資料夾，lint 嚴格到只剩一種寫法。她說這樣人寫起來很綁手，但對 context 很少的 agent 正好，連 PM、設計師都能交出及格的程式碼。Dune 讓她的 agent 開始自己合併 PR。

「重構程式碼庫、選擇有強型別和編譯器診斷的技術棧，影響遠大於 AGENTS.md 和調技能。最好的規則寫在程式碼裡。」（organic architecture）

刪註解：一個看起來無害、解釋暫時 workaround 的註解，是程式碼庫最糟的病毒之一。Agent 會拿它當捷徑，很快到處都是 hack。/no-comments 會清掉沒用的註解，保留真的該存在的（例如瀏覽器怪癖），再從根本解決背後的問題。（2026-10-13）

6. 用程式碼規劃

她開玩笑說「我不相信規劃」，真正意思是她用程式碼規劃。大部分 Plan Mode 對實作細節寫太多，其他地方又寫太少。

她的做法：

  1. 讓 agent 用自己的話重述：不直接說她要什麼，而是讓 agent 讀完 Slack 討論串後，用白話重述它認為的根本問題。這樣做有三個好處：
    • 把雜亂的對話壓縮成結構化的問題。
    • 馬上抓到誤解。
    • 不會被她自己可能錯的假設帶偏。
  2. 讓 agent 教你：/teach 讓 agent 解釋它要做什麼、為什麼、取捨是什麼。她發現這對 agent 也有幫助，因為逼它真的去讀程式碼，而不是自信地亂說。
  3. README 先行：做共用套件時先寫教學文件，從使用者角度倒推 API。
  4. 做原型比較：把 2 到 3 個版本放在切換器後面，用驗證技能截圖、量測，讓她選。她說「原型就是用程式碼規劃」。
  5. /architect：多個不同模型各自畫出型別和函式簽名，再由另一個模型評審。實作中發現設計錯了（例如到處需要 any 或強制轉型），就整個丟掉重來。

「我從不對抽象計畫做對抗式審查。Agent 會開始幻想理論上的風險、發明複雜的邊界情況，防範永遠不會發生的問題。」（Complete Guide Pt.2）

「抽象計畫只給你進度的錯覺。」

她的常犯錯誤清單：

7. 先做槓桿（Build the Lever）

大量遷移不要開幾百個 agent 硬做，那樣會有幾百份要驗證的改動。正確做法：

  1. 第一個單位親手做，學會做法。
  2. 讓 agent 把機械性的部分寫成 codemod（自動改程式碼的腳本）。
  3. 再寫一個檢查器證明輸出正確。

「我看到 agent 一直手動做同一件事，就讓它寫出它希望自己有的工具或技能。之後每次執行都能繼承。」

她用 StyleX 遷移得到的教訓：一個 40 萬行的 PR 雖然像素完全一致，實際使用還是抓到很多問題。於是她改成每天遷移一個元件、每個 PR 都很小、附大量截圖。

「在價值最低的階段抓出缺陷。一個小元件檢查失敗很便宜，大遷移合併後才發現回歸很貴。」

能用腳本確定完成的步驟就用腳本。Agent 只用在模糊的部分：選假設、解讀證據、判斷何時需要人。

8. 審查改成抽查

她管好幾條產線，像連鎖餐廳的主廚，不可能嚐每一道菜。所以她抽查，有問題就改流程。Agent 自己合併 PR，她早上看 main 上合併了什麼。Matt Pocock 把這叫做「抽樣而不是阻擋」。

「你不會想落到再也不嚐自己做的菜的地步。」

她偏好「米其林廚房」這個比喻，不用「軟體工廠」：廚房不是生產線，主廚雖然不親手做每道菜，還是要為端出去的東西負責。

9. 數量重要嗎？她的立場轉變

她以前覺得 PR 數量是虛榮指標，現在改口說「數量確實重要」，前提是品質能維持。她的論點是：每個人現在都能當「寫程式機器」，如果你用了 agent 產量還跟以前一樣，該停下來想想為什麼。

但她也承認，2,500 個 PR 很多是「園藝」性質的小修正，full autopilot 每個 PR 配 10 個驗證 agent 也很燒 token。

10. Bot 團隊怎麼開始

「你不用急著做很多 bot。主 bot 單獨就很能幹，我甚至建議先用一個 bot 做所有事，之後才為了專業分工和整理加新 bot。」（2026-10-07）

她用 Dr Eggbot 設計所有 bot。Eggbot 會每週檢查排程有沒有沒用或太貴的，每天掃過各 bot 的對話找摩擦（被糾正、誤解、「不是我要的」），再建議新增技能、bot 或排程。（2026-09-02）

四、常用 prompt 小抄（原文照抄）

對齊目標

追進度

理解程式碼

做功能

修 bug

設計

效能

整理程式碼庫

五、pstack 技能速查（照她自己的說明）

六、建議閱讀順序

  1. 〈Loops You Can Trust〉（2026-06）：最完整講她的哲學和來龍去脈。用早餐工廠比喻，讀起來最順。原文
  2. 〈The Complete Guide to pstack Pt.1〉：驗證技能怎麼做。原文
  3. 〈The Complete Guide to pstack Pt.2〉：研究、規劃、原型、架構。實用 prompt 最多。原文
  4. 〈How I Use Cursor〉（2026-05）：pstack 的起點和 Benny bot。原文
  5. 演講影片〈how i shipped 2,500 PRs〉（約 38 分鐘，她說可以開 2 倍速）：https://x.com/poteto/status/2102050467505430555
  6. Matt Pocock 訪談（約 1 小時，信任階梯、米其林廚房、抽查）：https://www.youtube.com/watch?v=MN9dGgmLyso
  7. 〈Coding is dead, long live Coding〉：短篇，心態類。

七、資料來源與限制