我需要說點心裡話。在面試 @cursor_ai 之前，我其實從來沒用過 Cursor。
在 Meta 的時候，Claude Code 正迅速崛起。我甚至為了自己的 side project，自費訂閱了每月 200 美元的方案。我喜歡它的簡單，以及那種能快速感受到生產力的感覺。但對我來說，瓶頸在於開發一套屬於自己的技能，讓 cc 幾乎能變成我想要的任何東西。我甚至開始在上面開發自己的 Agent 協調器工具。
在現場面試的兩天裡，我使用了 Cursor 來建構面試專案。那時 Cursor 3 還沒發布，所以我用的是編輯器視窗。我已經使用 vscode 很多年了，大部分快捷鍵都還在我的「上下文」裡，所以重新回到 IDE 並不困難。不過，我得老實說，在最初的一兩個小時裡，我確實很懷念 cli。用滑鼠點擊感覺有點原始。但有幾件事真的讓我印象深刻。
首先，我當時習慣使用的模型——Opus 和 Codex——感覺起來更聰明。而且能夠隨時切換模型，並在專案的不同部分同時使用它們（Opus 處理前端，Codex 處理系統），這點非常棒。在面試之前，我已經在大力推崇多模型 adversarial review，所以能在 UI 中原生做到這一點，感覺非常自然。更棒的是，還能產生不同模型的子 Agent，讓我在同一個對話中兼顧兩者的優點。
第二，壓縮速度快得驚人。作為 cc 用戶，我習慣了壓縮需要好幾分鐘，所以我總是時刻注意著我的上下文和計畫使用量。因此，當我看到 Cursor 的壓縮速度時，我完全驚呆了。快到讓我基本上從不需要去查看自己用了多少上下文。它就是這麼順暢地運作，而在 cc 中，我常常覺得壓縮後模型就變得超級笨。
第三，我注意到 GUI 能比 TUI 提供更多功能。能夠直接在 Cursor 的瀏覽器中打開你的應用程式，並使用 Design Mode 進行設計修改，感覺非常直觀，也讓我思考，專門打造的 UI 能如何讓 Agent 編碼更有效率。
用 Cursor 打造 Cursor
自從三月底加入以來，我主要專注於 Cursor 3 的 Agent 視窗，並將其作為我的日常開發工具。雖然我仍然認為 cc 是一個很酷的產品，團隊也很棒，但我注意到它的簡單性往往會驅使人們想要建立自己的抽象層來包裝它。在我上一份工作中，感覺每週都會有一個基於 cc 的內部協調器工具被宣布。
@bcherny 經常談論「潛在需求」這個概念：
「產品領域有一個非常古老的概念叫做潛在需求……你以一種可被破解、足夠開放的方式打造產品，讓人們可以把它用在其他用途上。然後你觀察人們如何『濫用』它，再針對那些用途進行開發。」
就是這樣！人們趨向於使用協調工具，正說明了潛在需求：使用 cli 只會讓你——人類——成為協調者。
但我用過的每個 Agent 工作流程都聚焦在錯誤的事情上。在 GUI 中執行多個 CLI 完全搞錯了重點。我感興趣的方法是建立對 Agent 的信任。
作為一名前工程經理，我很快意識到管理 Agent 的感覺類似於建立一個人類工程團隊。新進員工需要入職培訓，以便他們了解程式碼庫，也了解工作是如何完成的。他們加入時已經具備了從過去經驗中獲得的技能：例如如何除錯、如何撰寫高品質的程式碼和測試，以及如何溝通。
Agent 就像是不斷處於失憶和愚蠢狀態的新進員工。它們不記得你告訴它們的事，也從未真正學到任何新東西。但我們可以用規則、技能、工具和長期記憶來裝備它們，這可以近似於學習。它們有能力但很笨，而且非常可教。我將它們的失敗模式視為機會，教會它們我所知道關於進行深入、嚴謹工程的一切。
因為當缺乏嚴謹性時，Agent 會諂媚地不擇手段去寫出你要求的那段程式碼。而且，天啊，它們可以而且會寫出大量的程式碼。天真的平行化只會讓它們更快地寫出垃圾。
欲速則不達，先求深度
我確實認為 Agent 協調可以有效地進行。但我們需要先深入。
我正在開源 pstack，這是我每天用來建構 @cursor_ai 的個人技能和工程原則集。我從 side project 就開始開發這些技能的早期版本，並一直改進至今。
在這裡取得：https://cursor.com/marketplace/cursor/pstack
這些技能已經成為 Cursor 團隊最常使用的技能之一，所以我很興奮能與大家分享。
pstack 教導 Agent 使用多個模型來變得更嚴謹。我將觀察到的所有失敗模式都轉化成了技能。這個外掛的核心是 /poteto-mode，這是一個更高階的技能，能為 Agent 提供針對特定任務的正確劇本。目標不是最大化程式碼行數，而是相反：用最少的程式碼產生最大的影響。
這種嚴謹性是透過像經驗豐富的工程師一樣處理問題來實現的。例如，一個很好的除錯方法是二元搜尋問題空間。你從一些關於可能發生什麼事的假設開始，然後嘗試系統性地排除它們，直到你能更接近真正的根本原因。如果難以重現，你可能會嘗試人為強制觸發這個錯誤。或者你可能會嘗試添加儀器或控制台日誌來檢查程式運行時的狀態。
這些步驟形成了一個劇本，Agent 可以用它來徹底除錯問題，而不是猜測——如果你允許，它們很樂意猜測。pstack 附帶了許多技能和劇本，讓你能以同樣的嚴謹程度來處理軟體工程。我目前有以下方面的劇本：
- 技能創作與評估
- 自主工作
- 錯誤修復與運行時取證
- 功能開發
- 視覺一致性與原型設計
- 以及更多
每當你需要嚴謹性時，就在提示詞前加上 /poteto-mode。例如：
你也可以選擇性地按需呼叫其他技能：
- /how：你想要了解某個子系統實際運作方式的逐步解說。
- /why：你想要知道某個東西為什麼要這樣建構。它會使用你可用的 MCP，並行查詢每個證據類別（原始碼控制、問題追蹤器、長篇文件、即時聊天、基礎設施可觀測性、錯誤追蹤、分析資料倉儲）。
- /architect：你即將撰寫跨越函數邊界的程式碼，並希望先確定類型和資料結構。
- /arena：你想要對同一件事進行 N 次平行嘗試，然後從中選取最佳部分。
- /interrogate：你想要讓不同的模型對某件事進行對抗性審查。
- /tdd：你在修復一個錯誤。先撰寫會失敗的測試，再寫修復程式碼。
- /unslop：你在清理任何類型的 AI 寫作。讓它們說人話。
- /reflect：你希望在長時間對話後持續改進你的技能。
- /figure-it-out：正在做不尋常的事？為該任務設計一個嚴謹、可稽核的劇本。
- /show-me-your-work：你想要一個可審查的決策軌跡。它會將決策記錄到一個你可以提交的 tsv 檔案中。
最後，你可以使用 /automate-me 來製作你自己的模式技能。它會挖掘你最近的對話記錄，根據你的工作方式草擬一個 your-mode 技能，並在底層透過 pstack 路由。
pstack 適用於任何 Agent 編碼工具，但在像 Cursor 這樣的多模型工具中效果尤其好。許多技能都使用多模型工作流程來利用每個模型的獨特優勢和劣勢。這是 Agent 協調，但應用的是深度優先而非廣度優先。
Agent 的瓶頸在於驗證。Agent 可以快速撰寫大量程式碼。確保所有程式碼都正確是極其困難的。當你能夠做到這一點時，真正的 Agent 平行化，就像軟體的黑暗工廠，或許就成為可能。
但首先，我們需要深入且嚴謹。我認為我們可以透過提高信任度來達到這個目標。
試試 pstack，並讓我知道你的想法。
禪與軟體維護的藝術
這些技能幫助我在撰寫程式碼時更有信心。但現在維護程式碼成了惡夢，因為 Agent 寫了所有程式碼。錯誤、效能問題和功能請求仍然需要時間來處理。而且現在程式碼量多太多了！
我在 Cursor 內部大量使用 Cursor 自動化功能。它們是雲端 Agent，可以排程執行，或響應 Slack 頻道中的新訊息等事件來運行。其中一個例子是我的機器人 Benny。我給了他和我 pstack 中一樣的技能。
Benny 仍在開發中，但我的目標是盡可能自動化軟體維護流程。想法是這樣的：如果我們現在有信心能用 pstack 以良好的確定性「一次搞定」問題，確保 PR 品質很高，那麼我們當然也可以自動化回饋流程。
這個工廠從分類開始：收集員工關於錯誤報告的資訊。我們大量內部試用 Cursor，因此從員工那裡獲得很多關於候選版本的意見回饋。Benny 能理解圖片和影片附件，使用 pstack 技能探索程式碼庫，並在重現步驟不明確時與報告者聊天以獲取資訊。
這是錯誤報告流程中很重要的一部分。如果沒有明確的重現步驟和對問題所在的理解，Agent 只能猜測解決方案。我們需要讓它們清楚地了解問題發生的確切位置和方式。
分類完成後，Benny 會建立一個工單，內容包含他從程式碼、近期錯誤回歸的 git 歷史、Slack 中關於同一錯誤的其他訊息，甚至 Notion 中關於功能應如何運作的設計和產品決策中發現的結果：這是一個錯誤，還是本來就設計成這樣？
工單提交後，另一個 Benny 機器人會使用我創建的另一個技能 /orchestrate 來接手。
首先，他嘗試透過電腦使用來重現問題。Cursor Cloud Agents 可以在雲端運行 Cursor 本身，它們與桌面互動、點擊東西並發送鍵盤輸入。在內部，這使用了更多我製作的技能，透過 CDP 或等效協議以程式方式控制我們的產品。
這使我們能夠證明錯誤報告是否可以重現。如果它能持續重現錯誤，他就會嘗試修復它。如果是效能問題，Benny 可以獲取前後的 CPU 追蹤和堆積快照。子規劃器會產生更多工作人員，使用 pstack 技能驗證修復，並根據工單檢查修復是否完成。
在此運行中，會產生額外的工作人員來錄製前後的影片，最後一個工作人員會開啟 PR 供審查，並在描述中包含該影片。
這一切都還在進行中，還有大量工作要做，但我對於擁有一隊 Agent 在我睡覺或做其他事情時，能幫助我充滿信心地修復錯誤感到興奮。讓程式碼審查變得可擴展是另一個重要領域，我認為 Cursor 將推出一些很酷的新功能來提供幫助。
但建立你自己的軟體工廠的關鍵是信任。除非你能信任一個 Agent 從頭到尾擁有問題的所有權，包括驗證，否則你無法自動化你的流程。當你使用像 pstack 這樣能為你的 Agent 提供更多工程深度的外掛來提高信任度時，你就可以開始處理更具挑戰性的問題。試圖平行化你還不信任的 Agent，是對 token 的巨大浪費，並會在你的程式碼庫中引入更多垃圾。
感謝閱讀！
