# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：lauren (@poteto) · 平台：X (Twitter) · 日期：2026-05-26

> 原始來源：https://x.com/poteto/status/2058975157503570132

## 中文摘要

# 我是如何使用 Cursor 的

有些心裡話我必須說。在面試 @cursor_ai 之前，我其實從未使用過 Cursor。

在 Meta 時，Claude Code (cc) 正處於爆發性成長期。我甚至為了個人專案，每個月付費訂閱了 200 美元的方案。我很喜歡它的簡潔，以及那種能快速進入工作狀態的感覺。但對我來說，卡關的地方在於我必須建立一套屬於自己的 skill，才能把 cc 變成我想要的任何工具。我甚至開始在它之上開發自己的 Agent 排程工具。

在現場面試期間，我用了兩天 Cursor 來完成面試專案。那是在 Cursor 3 發布之前，所以我使用的是 Editor Window。由於我使用 VS Code 已經很多年了，大部分的鍵盤快速鍵都還在我的記憶中，所以回到這個 IDE 並不困難。不過我不能說謊，前一兩個小時我確實很想念 CLI。用滑鼠點擊感覺簡直像原始人一樣。但有幾件事真的讓我印象深刻。

首先，當時我習慣使用的模型——Opus 和 Codex——感覺起來似乎更聰明。而且能隨時切換模型，並在專案的不同部分同時使用它們（Opus 負責前端，Codex 負責系統），這真的很棒。在面試前，我已經對「多模型對抗式審查（multi-model adversarial review）」讚不絕口，所以能在 UI 中原生實現這一點，感覺非常自然。更棒的是，能夠生成不同模型的子 Agent，讓我在同一個對話中取其精華。

其次，compaction（壓縮）速度快得驚人。身為 cc 的使用者，我習慣了壓縮過程需要花費好幾分鐘，所以我總是處於一種必須時刻警惕 context 和計畫用量的狀態。因此，看到 Cursor 的壓縮速度如此之快，我感到非常震驚。以至於我基本上根本不需要去查看自己用了多少 context。它就是能運作，而在 cc 中，我經常感覺模型在壓縮後會變得非常笨。

第三點我注意到的是，GUI 能提供的功能遠勝於 TUI。能直接在 Cursor 的瀏覽器中打開應用程式，並透過 Design Mode 進行設計變更，感覺非常直覺，這讓我開始思考，專用 UI 能讓 Agentic 程式開發變得多麼有效率。

## 用 Cursor 打造 Cursor

自從三月底加入以來，我主要致力於 Cursor 3 的 Agent Window，並將其作為我的日常主力工具。雖然我仍然認為 cc 是一個很酷的產品，團隊也很優秀，但我注意到它的簡潔往往會驅使人們想要在它之上建立自己的抽象層。在我上一份工作中，感覺好像每週都會發布一個基於 cc 的新內部排程工具。

@bcherny 談了很多關於「潛在需求（latent demand）」的概念：

> 「產品領域有一個非常古老的觀念叫潛在需求……你以一種可駭入（hackable）的方式構建產品，讓它足夠開放，以至於人們可以將其用於其他用途。然後你觀察人們如何濫用它，再針對這些需求進行開發。」

這正是重點所在！人們紛紛轉向排程工具，揭示了潛在需求：僅僅使用 CLI，會讓你這個「人類」成為唯一的排程者。

但我用過的每一個 Agent 工作流都關注錯了重點。在 GUI 中執行多個 CLI 完全搞錯了方向。我感興趣的方法是建立對 Agent 的信任。

作為一名曾經的工程經理，我很快意識到管理 Agent 的感覺，與建立一個人類工程團隊很相似。新進員工需要入職培訓，這樣他們才能理解程式庫，以及工作是如何完成的。他們加入時已經具備了從過去經驗中獲得的 skill：如何除錯、如何編寫高品質的程式碼和測試，以及如何溝通，等等。

Agent 就像是一群長期處於失憶和愚蠢狀態的新進員工。他們記不住你告訴他們的事，也從未真正學到新東西。但我們可以為他們配備規則、skill、工具和長期記憶，這可以模擬出那種效果。他們有能力但很笨，而且非常容易教導。我將他們的失敗模式視為教導他們我所知道的一切關於深入、嚴謹工程知識的機會。

因為當缺乏嚴謹性時，Agent 會諂媚地不惜一切代價寫出你要求的程式碼。而且天啊，他們確實能寫，也真的會寫出一大堆。天真的平行化只會讓他們更快地寫出垃圾程式碼。

## 如果你想走得快，先走得深

我確實認為 Agent 排程可以做得很有成效。但我們需要「深度優先」。

我將開源 pstack，這是我每天用來構建 @cursor_ai 時所使用的一套個人 skill 和工程原則。我早在個人專案中就開始開發這些 skill 的早期版本，並從那時起不斷完善它們。

在這裡取得：https://cursor.com/marketplace/cursor/pstack

```markdown
/add-plugin pstack
```

這些 skill 已經成為 Cursor 團隊最常使用的 skill 之一，所以我很高興能與大家分享。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779764967149-iaHJCrmz1bsAAjAOnjpg.jpg)

pstack 教導 Agent 使用多個模型來變得更加嚴謹。我將我觀察到的所有失敗模式都轉化為了 skill。這個 plugin 的核心是 `/poteto-mode`，這是一個高階 skill，能為 Agent 提供針對特定任務的正確操作手冊（playbook）。目標不是最大化程式碼行數（LOC），而是相反：用最少的程式碼產生最大的影響。

這種嚴謹性是透過模仿資深工程師解決問題的方式來實現的。例如，除錯的一個好方法是對問題空間進行二分搜尋。你先針對可能發生的情況提出一些假設，然後系統地排除它們，直到你能更接近真正的根本原因。如果很難重現，你可能會嘗試人工強制觸發該錯誤。或者你可能會嘗試加入檢測程式碼或 console logging，以在程式執行時檢查狀態。

這些步驟形成了一套操作手冊，Agent 可以利用它來徹底除錯問題，而不是盲目猜測（如果你讓他們猜，他們很樂意這麼做）。pstack 附帶了許多 skill 和操作手冊，讓你以同樣的嚴謹程度進行軟體工程。我目前擁有的操作手冊包括：

- Skill 撰寫與評估 (evals)

- 自主工作

- 錯誤修復與執行時期鑑識

- 功能開發

- 視覺一致性與原型設計

- 以及更多

每當你需要嚴謹性時，請在你的 prompt 前加上 `/poteto-mode`。例如：

```markdown
/poteto-mode 這個 PR 有個細微的 bug，即使在閒置狀態下，捲軸每 750ms 也會偏移。先重現，然後修復並驗證。
/poteto-mode 即使我們已經做了虛擬化，一個大列表還是需要一兩秒才能載入。執行 CPU 追蹤並告訴我原因。
/poteto-mode 在功能旗標（feature flag）下建立一個小功能。驗證它確實有效。
/poteto-mode 建立兩個 Markdown 渲染器的原型，以便我們進行比較。為每個原型生成一個 Agent。
/poteto-mode 將這些 skill 作為 plugin 開源。確保沒有內部資訊洩漏，在暫存目錄中工作，先向我展示依賴關係圖。
/poteto-mode 我要去睡覺了。即使 CI 不穩定也要把 stack 提交上去。我希望早上起來一切都已合併。
/poteto-mode 當這個旗標開啟時，列間距太高了。第二張圖片是正確的。請重現並修復直到它符合預期。
```

你也可以選擇按需呼叫其他 skill：

- `/how`：你想要一個關於子系統實際運作方式的逐步解說。

- `/why`：你想知道為什麼某個東西要這樣設計。它會使用你可用的 MCP 並行查詢每個證據類別（原始碼控制、問題追蹤器、長篇文件、即時聊天、基礎設施可觀測性、錯誤追蹤、分析資料倉儲）。

- `/architect`：你即將編寫跨越函式邊界的程式碼，並希望先確定型別和資料結構。

- `/arena`：你想要對同一件事進行 N 次平行嘗試，然後擷取每個嘗試中最好的部分。

- `/interrogate`：你想要讓不同的模型對某個東西進行對抗式審查。

- `/tdd`：你正在修復一個 bug。先寫失敗的測試，然後再寫修復程式碼。

- `/unslop`：你正在清理任何 AI 產生的垃圾內容。讓它們說人話。

- `/reflect`：你希望在長對話後持續改進你的 skill。

- `/figure-it-out`：正在做一些不尋常的事？為該任務設計一套嚴謹、可審計的操作手冊。

- `/show-me-your-work`：你想要一個可審查的決策軌跡。將決策記錄到一個你可以 commit 的 TSV 檔案中。

最後，你可以用 `/automate-me` 建立自己的模式 skill。它會挖掘你最近的對話紀錄，根據你的工作方式草擬一個「your-mode」skill，並在底層透過 pstack 進行路由。

pstack 適用於任何 Agentic 程式開發工具，但在像 Cursor 這樣支援多模型的工具中效果特別好。許多 skill 使用多模型工作流，以利用每個模型獨特的優勢和劣勢。這就是 Agent 排程，但它是「深度優先」而非「廣度優先」的應用。

Agent 的瓶頸在於驗證。Agent 可以快速編寫大量程式碼。確保所有程式碼都正確無誤是非常困難的。當你能做到這一點時，真正的 Agent 平行化，就像軟體界的「黑暗工廠（dark factory）」一樣，或許就有可能實現。

但首先，我們需要深入並保持嚴謹。我認為我們是透過提高信任度來達成目標的。

試試 pstack，並讓我知道你的想法。

## 禪與軟體維護的藝術

這些 skill 幫助我在編寫程式碼時更有自信。但現在有了 Agent 編寫所有程式碼，維護程式碼簡直是一場噩夢。Bug、效能問題和功能需求仍然需要時間來處理。而且現在程式碼量多得驚人！

我在 Cursor 大量使用 Cursor 自動化功能。它們是雲端 Agent，可以被排程，或在回應 Slack 頻道中的新訊息等事件時執行。其中一個例子是我的機器人 Benny。我給了他我在 pstack 中擁有的相同 skill。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779764967162-iaHJD3PDda4AA7ptnjpg.jpg)

Benny 仍在開發中，但我的願景是盡可能自動化軟體維護流程。想法是這樣的：如果我們現在有信心透過 pstack 大多數情況下能「一次搞定」問題，並且對 PR 品質有相當程度的把握，那麼我們肯定也能自動化回饋流程。

這個工廠從分類（triage）開始：從員工那裡收集關於 bug 回報的資訊。我們經常在內部使用 Cursor（dogfooding），所以我們會從員工那裡收到許多關於發布候選版本（release candidates）的回饋。Benny 可以理解圖片和影片附件，使用 pstack skill 探索程式庫，並與回報者聊天，以獲取不清楚的重現步驟。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779764967154-ediaHJD5REboAA3WFjpg.jpg)

這是 bug 回報流程中很重要的一部分。如果沒有清晰的重現步驟和對故障原因的理解，Agent 只能猜測解決方案。我們需要讓他們清楚地了解問題到底在哪裡以及如何發生。

分類完成後，Benny 會根據他從程式碼、最近 bug 回歸的 git 歷史紀錄、關於同一 bug 的 Slack 訊息，甚至是 Notion 中關於功能應如何運作的設計與產品決策中找到的資訊，來建立一張工單：這是一個 bug，還是原本就設計成這樣？

工單建立後，另一個 Benny 機器人會使用我建立的另一個名為 `/orchestrate` 的 skill 來接手。

首先，他嘗試透過電腦使用（computer use）來重現問題。Cursor Cloud Agents 可以在雲端執行 Cursor 本身，在那裡他們與桌面互動、點擊東西並發送鍵盤輸入。在內部，這使用了我製作的更多 skill，透過 CDP 或類似協定以程式化方式控制我們的產品。

這讓我們能夠證明 bug 回報是否可以重現。如果能穩定重現該 bug，他就會嘗試修復它。如果是效能問題，Benny 可以取得修復前後的 CPU 追蹤和堆疊快照（heap snapshots）。子規劃器（subplanners）會生成更多工作者（workers），使用 pstack skill 驗證修復結果，並根據工單檢查修復是否正確。

在此執行過程中會生成額外的工作者，拍攝修復前後的影片，最後由一名工作者開啟 PR 進行審查，並在描述中附上影片。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779764967298-iaHJD6hgsaAAARV7Ijpg.jpg)

這一切仍在進行中，還有很多工作要做，但我很興奮能擁有一支 Agent 團隊，在我睡覺或做其他事情時，幫助我自信地修復 bug。讓程式碼審查變得可擴展是另一個大領域，我認為 Cursor 即將推出一些很酷的功能來提供協助。

但建立你自己的軟體工廠的關鍵在於「信任」。除非你能信任一個 Agent 能端到端地負責一個問題，包括驗證，否則你無法自動化你的流程。當你使用像 pstack 這樣能賦予 Agent 更多工程深度的 plugin 來提高信任度時，你就可以開始解決更具野心的問題。試圖平行化你還不信任的 Agent，只會浪費大量的 token，並將更多垃圾內容引入你的程式庫。

感謝閱讀！

## 標籤

Skills, Claude Code, Cursor, IDE, Agent, Cursor, Anthropic, Claude, Meta