別被「5 分鐘做出 App」的說法誤導：Cursor 深度實戰

轉錄網路素材並翻譯成繁體中文，連結置底。

在今年 8 月，我第一次嘗試使用 Cursor，並對它的表現留下深刻印象，於是寫了一篇簡介文章。之後不久，我將日常工作環境從 GitHub Copilot + JetBrains 全面轉換成付費版的 Cursor。經過幾個月下來，整體體驗相當順暢。

在使用的過程中，我常向同事和朋友推薦 Cursor，不過他們仍然常提一些問題，例如：

• 與原生的 ChatGPT 或 Claude 相比有何優勢？Cursor 的強大之處主要是因為 Claude Sonnet 3.5 嗎？
• 與 GitHub Copilot 有何不同？為什麼它的價格是後者的兩倍？
• Cursor 只適合用來從零開始快速製作小專案嗎？
• Codeium 最近推出的 Windsurf，看一些部落客的影片感覺更順暢，要不要換用它？
• Coding Copilot 只適合初學者嗎？
• 在 AI Copilot 浪潮下，我們要如何繼續提升程式實力？還是說最終我們都會被 agents 完全取代？

這些問題十分常見。我發現最好的回答方式是透過實際「邊寫程式邊展示」。在今年的 10 月 24 日程序員日（Programmer’s Day），我在公司內部做了一場展示，透過動手示範帶大家感受 Cursor 的優勢和使用技巧。只不過當時用的是公司內部的程式碼，因此不便直接分享。

這篇文章稍作調整後，分享給更廣大的讀者，讓大家了解 Cursor 以及 AI 編碼助理的魅力和實用經驗。

Cursor 的簡介與定位

Cursor 是一家由一群年輕的 MIT 學生在 2022 年創立的公司。當時市場上已經有 GitHub Copilot，而且佔有相當可觀的市佔率。Cursor 在最初釋出時，我簡單試用後覺得功能比較陽春，似乎只是把 ChatGPT/Claude 的「聊天產碼」整合到 VSCode 裡，沒什麼突破性的創新。

但後續它的發展遠遠超出了大部分人的想像。我們可以先回顧一下當時的市場情形：

1. 針對專業開發者，GitHub Copilot 擁有明顯優勢。它幾乎以一己之力驗證了「程式編寫助手（Coding Copilot）」這個產品類型的市場定位（PMF），並達到 1 億美元的 ARR。再加上 GitHub 與 VSCode 都屬於微軟旗下，且微軟與 OpenAI（GPT-3.5、Codex 等當時領先的程式碼模型）合作非常密切，GitHub Copilot 可說是佔盡天時地利人和。
2. 針對非程式開發者，像是 ChatGPT、Claude 或 Replit 等產品握有最大的流量入口。針對一次性需求或 Demo 專案，直接用這些工具就很夠用，也看不出要把這些功能「搬進 VSCode」的好處。

所以，Cursor 憑什麼想要重新改造微軟的 IDE，還用已經跟微軟深度整合的 OpenAI 模型來跟這些大廠競爭呢？

在實際使用 Cursor 並閱讀它的創辦團隊訪談後，我大致瞭解了它們的幾個犀利且明確的切入點：

1. Cursor 的焦點非常清晰：專業開發者。 它並不打算跟 ChatGPT、v0、Bolt 這些工具搶同一批目標用戶。事實上，Cursor 與這類工具背後的願景可能有根本性差異（例如「未來程式員是否還會存在」之辯）。若使用者無法分辨兩者差異，往往就不是 Cursor 想要服務的對象。
2. 核心洞見：程式編寫不只是「補全」，也需要「編輯」。 也就是包含刪除、插入等操作。這聽起來在今日是常識，但在當時幾乎所有 Coding Copilot 工具都只有簡單的自動補全。就算到現在，Cursor 的「Tab」體驗還是相當獨特，只不過現在 Windsurf 已經開始模仿了。
3. 將編輯思維擴大： Cursor 不是只在聊天介面產生程式碼，而是能直接將產生的程式碼應用到整個檔案，甚至多個檔案，並使用 Diff 的方式完成合併工作。這種工作流程展現了他們對「開發者日常需求」的深刻理解。
4. 小團隊的快速迭代 vs. 大公司的慣性： 即使像 GPT 這樣的大模型，在從 3 → 3.5 → 4 的過程中也有很大突破，但 GitHub Copilot 的使用體驗並沒有相應地跟上大幅改變。大公司常有產品迭代節奏慢的問題，而 Cursor 團隊就能以更快的速度去探索和釋放模型帶來的可能性。

這些策略值得借鏡：透過明確的聚焦、深度理解開發者需求，並且快速迭代，小團隊也能夠挑戰像 GitHub Copilot 這樣的龐然大物。

Cursor 的工作流程

既然 Cursor 的定位是專業開發者，我們就更進一步看看它在哪些情境特別加分，以及它和其他工具有何不同：

1. 同時適合新手與資深開發者。 無論你是初學者還是老手，都能透過 Cursor 大幅提升工作效率。尤其是有經驗的工程師，不要因為自認技術強就小看這種全新範式。
2. 特別優化「維護既有專案」。 大部分專業開發者每天花的時間主要在維護和迭代中型或大型專案，而不是每天都在從零開始做新專案。很多網路教學影片都在示範「從頭打造一個應用」，這其實跟現實的開發工作流程差距很大，也沒能突出 Cursor 與 Claude Canvas 那種「一鍵生成小專案」的差異。
3. 現階段模型的能力限制。 目前的模型還無法用幾行指令就完整實作大型專案的某個功能。若過度依賴「聊天式開發」，往往成功率不高。更好的方法是把 Cursor 視為你的「配對程式搭檔（pair programming copilot）」，而不是「實習生程式員」。

實際工作中的 Cursor

以下介紹幾個 Cursor 功能，如何提升日常工作的效率：

1. Cursor Tab

這是目前最具特色的功能。簡單來說，它會「預測」你下一步可能想改的程式碼，然後自動幫你填上。以下舉幾個例子：

範例 1：把 print 改成 logger

某天陽光普照的早上，你和你的程式搭檔在修改程式碼：先前原型開發時使用了很多 print，現在要上線了，得全部改成 logger，不同訊息還要切不同等級。

你可以直接在 Cursor 裡面按 CMD + L，在 Chat 裡敘述需求，請 Cursor 幫你把整個檔案的 print 改成 logger。但也可以透過程式碼「隱喻式地」表達需求。例如，你可以先在檔案裡加上：

pythonCopy codeimport logging

logger = logging.getLogger(__name__)

# 下面是原有程式碼 ...

然後你只要改動第一個 print，Cursor 作為你的程式搭檔，就能「推測」你想要把剩下的 print 改成 logger，並自動補出合適的日誌等級。你只要一直按 Tab 就能快速套用到所有地方。

這比你開 Chat 視窗、打一句完整需求、等待產生 Diff、再套用、再審核，流程更短，也更無縫。因此，在很多場景下，透過示範（示例程式碼）或簡單註釋來「表達意圖」，往往更快。

範例 2：增加函式參數

這是另一個常見的情境：你想給某個函式新增一個參數，還要同時改動它的所有呼叫點（Call Site），外加新增一些註解或改動程式流程。你可以打自然語言請助手做，但其實很多時候只要在原檔案裡直接新增參數，Cursor 就能推測你的意圖。

例如 Cursor 官方網站範例：在一個 class 的 __init__ 裡加了 dropout 參數，Cursor 不只會把本檔要用到該參數的地方全數調整，也會修改整個程式碼庫裡所有呼叫 LSTMModel 的位置，補足初始化的部分。

這讓很多小規模的重構（Refactor）工作變得輕鬆，超越了單純的 IDE Refactor 工具所能做到的程度。

與 GitHub Copilot 的差異

也許你用過其他 Completion 工具（如 Copilot），也會嘗試靠「多打一點字」或「少打一點字」、調整游標位置來暗示它生成你想要的程式碼。
Cursor Tab 則是把「刪除部分程式碼」或「移動游標位置」這些手動步驟自動化了，因而在「使用者上手」層面更智能。光是這個提升，就讓 Cursor 在日常開發流程裡比一般工具好用很多。

2. Inline Chat

在 Cursor 裡，你可以用 CMD + K 叫出「內嵌聊天」視窗，對應游標所在位置或選取的程式碼進行互動。這比側邊欄的 Chat 多了兩個好處：

1. 編輯上下文更直接。 Inline Chat 天生就知道你選了哪段程式碼，或目前游標在哪個函式裡，特別適合做「編輯型」的互動。
2. 可以平行處理。 你可以一次開好幾個 Inline Chat，同時處理多處調整，不用等某個 Chat 回答完再去另一個 Chat。

我個人通常在以下情況會用 Inline Chat：

• 模板類程式碼生成： 像是根據檔案裡的其他範例，快速寫一個新的 API、DB 操作、資料模型等。這屬於低複雜度的程式碼，Cursor 處理起來省時又省力。
• 對選取程式碼加註解： 我可以選好某段程式碼，請 Cursor 幫我補註解，或檢查是否有可疑的地方。
• 改名函式/變數： 選取函式或變數名稱，請 Cursor 幫我想更好的命名。
• 寫複雜終端機指令： 例如 Docker、git 等等，也可喊 Cursor 幫忙。或許這樣一來，就不再需要 Warp？

3. Chat

側邊欄的 Chat 是最常見的形式，與 ChatGPT、Claude 等產品的介面類似。但 Cursor 身為一個 IDE，對已有專案的理解和上下文掌握遠勝於一般聊天工具。以下列出幾個常見場景：

場景 1：重構或功能修改

假設你正在重構程式碼：改動了某個模型層，連帶需要修改呼叫這個模型的檔案、調整一些比較複雜的邏輯。若你用 ChatGPT，大概是：

1. 手動收集上下文（包含模型改動、當前檔案、需求），貼進 ChatGPT。
2. ChatGPT 生成新的程式碼，然後你再複製回 IDE。
3. 用 Diff 工具檢查缺改、錯改或多改的問題。
4. 有問題再貼回 ChatGPT，反覆進行。

流程非常煩瑣且容易出錯。反觀 Cursor：

1. 可以直接用 @ 指定檔案、資料夾或定義讓 Cursor 參考。
2. 產生完成後一鍵套用，Cursor 直接幫你對當前檔案打 Patch，並以「Pull Request 式」的方式呈現 Diff，方便審閱。
3. 有問題就可以追問，或重新開個聊天 Session，再引入同樣的資訊。
4. 接受修改後，若出現 Lint/測試不通，還能用 AI Fix 或在終端機點擊「Debug with AI」自動把錯誤資訊傳給 Chat 進行修補。

範例：自動修正錯誤
如下圖所示，在終端機裡跑 mypy 做檢查後發現兩個錯誤，只要點一下「Debug with AI」，就會自動把錯誤訊息推給 Cursor Chat，Cursor 生成程式碼修補 Diff，套用後就修好了，非常方便。

場景 2：產生單元測試

無論你是先寫測試（TDD）或先實作再補測試，都可以把這部分工作交給 Cursor 來快速建立測試模板（包含依賴、Mock 等），然後一步步增加涵蓋的場景。

產生好測試後，直接執行測試。若出錯，依然可以與 Debug with AI 結合，迅速修正。

場景 3：效能優化

這是官方網站的範例，用來優化一些 Rust 程式碼。實務上，如果你想請 Cursor 快速掃描整個檔案並在效能、穩定性或安全性方面提供建議，也可以直接在 Chat 裡說明需求。

場景 4：整合網路搜尋

平時除錯或學習新框架時，我們可能會用 devv、phind、Perplexity 等做技術領域的搜尋。同樣地，你可以直接在 Cursor Chat 裡用 @Web 執行網頁搜尋，抓到最新且更豐富的知識，結合專案程式碼提供更精準的解法。例如，你可以請它幫忙把專案從 Poetry 遷移到 UV：

這樣一來，一些傳統需要繁雜網路搜尋的場景（例如環境配置、套件安裝、鑑別疑難雜症），現在都可以在 Cursor 完成。

此外，還有類似的 @Docs 功能，特別在一些大型升版不相容時很好用（例如 Pydantic 1.x → 2.x）。語言模型對 Pydantic 1.x 可能很熟，但你專案裡用到的卻是 2.x，新版文件可以透過 @Docs 引入，讓 Cursor 產出更正確的程式碼。

場景 5：Code Review

早期版本裡有一個獨立的「Code Review」標籤，但新版本中似乎升級成「Bug Finder」，並按次數付費。不過，你仍可以在 Chat 裡用 @Git 讓 Cursor 幫忙審閱程式碼或找出潛在問題，只不過可能需要更多提示才能得到更好的結果。

4. 其他上下文的生成

在 Chat 裡使用 @，有非常靈活的上下文控制方式，幾乎就像跟真人程式搭檔溝通。除了上述功能，還有：

• @Recommended：自動推薦關聯的上下文匯入。
• @Codebase：導入整個程式碼庫，供 Cursor 全面瞭解專案或搜尋特定功能實作。
• @Notepad：雖然用途不算高，但可以用來記錄一些開發計畫或需求，之後在特定程式碼裡再引用。
• @Lint errors：自動修復 LSP（語言伺服器）報出的錯誤。

這些靈活的上下文操作，都是 Cursor 團隊對程式員日常工作深刻洞察的體現，也區隔了它與一般聊天工具。

另外，也可以在 Chat 裡上傳設計圖給 Cursor 處理。不過因為大型模型在圖片推理上的能力目前還有限，所以此功能暫時比較不實用。

5. Composer

許多部落客都推薦這個功能，它主要是把 Chat 的「單檔編輯」延伸成「多檔同時編輯或創建」。坦白講，在 0.43 版之前，我個人用得相對少，因為現今模型在「跨多檔、複雜專案」的精確生成能力還不夠（如果你有不錯的案例，也歡迎分享）。

所以可以概括說：需求越簡單，就越可能用 Tab；需求稍微複雜，就用 Inline Chat；再進階就用 Chat；最複雜才用 Composer。這是一條漸進軸。

值得一提的是，Windsurf 推出後，人們發現 Composer 的 Agent 邏輯太簡單，導致結果不佳；Windsurf 的 Cascade 雖然執行「思考」過程更久，但往往能得到更好的結果。Cursor 也很快在 0.43 版加入了 Composer 的 Agent 模式。

現在的 Composer 結合了多步的上下文讀取、檔案讀取、執行指令（終端機）、收集回饋並決定下一步，類似 ReAct agent 的工作流程。前面幾個示範也都可以看到，Cursor 其實在各個環節都植入 AI，只要透過 Agent 把這些能力串起來，也算順理成章。

以前也有人用 Composer 做非程式領域的事情，如把個人筆記用 markdown（像 Obsidian）放在本地，再用 Composer 做「AI 驅動的檔案搜尋和問答」。但在新版裡，我沒能重現類似效果，好像更專注於程式開發了。不過也不用擔心，因為在 Chat 裡的 @Codebase 也能實現類似功能。

6. 其他小技巧

• cursorrules 檔
  這算是給專案寫的「全局知識庫」。可以放一些專案技術棧的說明（框架版本、套件版本等），以及專案特定的程式風格、命名規範、錯誤處理或安全相關要求等。
  可以到 cursor.directory 找些範本來改，應用在自己專案裡。

AI 助力下的程式思維

從上述的介紹來看，Cursor 已經幫我們分擔了日常工作中不少「低複雜度」的事，例如：

• 對各種程式語言或框架都能寫出慣用寫法；就算不熟悉某框架，也能快速上手。
• 它能掌握你專案裡常用的程式碼風格，專案越有架構、程式碼越可讀，Cursor 幫到的忙就越大。
• 執行程式碼、處理錯誤訊息、嘗試修復、做搜尋…… 這些重複又瑣碎的流程也能大幅增效。

用「心流理論（Flow Theory）」來看：

• 一方面，Cursor 幫你完成「太簡單而無聊」的打字工作，減少重複性勞動；
• 另一方面，透過大型模型的知識量結合程式碼庫（RAG 技術），幫你補足技術空白，減少因陌生技術或老舊程式碼帶來的焦慮。
• 整體來說，就像有位虛擬程式搭檔在身旁，讓你能更專注在創造力與思考上。

要在 AI 時代更好地利用這類工具，我們的工作重心會逐漸往「設計」和「驗證」階段移動：

• Cursor 作為「虛擬搭檔」，跟人類一樣需要看得懂你寫的程式碼，才能給出更好的建議。因此，在 AI 時代，寫「清晰易讀的程式碼」變得更重要。
• 良好的程式結構 讓 @ 指令能快速找到對應檔案或模組，也讓 AI 更容易搜尋到所需資訊。因而像「良好命名」、「單一職責」等原則在 AI 時代更有價值。
• AI 與人的認知模式差異很大。 若你正從事與大型模型（LLM）相關的應用，就會更清楚 AI 是怎麼「理解」程式碼的。譬如，你可能會在註釋裡多寫一些案例或思路，盡量避免複雜的多跳（multi-hop retrieval）邏輯。偶爾也能詢問 AI「它理解這段程式嗎」，或請它用你的程式作任務，以此了解它的推理方式（就像在做 Prompt 最佳化）。
• 隨著 AI 生成程式碼的速度與能力越來越強，如何有效審閱與驗證程式碼將成為新的瓶頸。一方面測試自動化更重要；另一方面，Cursor 這類產品也可能在 Code Review 階段提供更多協助。

當然，這些只是一些初步想法，也歡迎大家一起交流討論。

其他 AI 程式工具的比較

這裡簡單列一下其他 AI 程式工具：

1. OpenAI Canvas、Claude Artifacts：
   這些面向更廣泛的人群，主要針對「一次性」的程式碼生成或 MVP 開發。與 Cursor 針對既有程式碼的深度整合、IDE 工作流相比，重點不一樣。
2. GitHub Copilot、Codeium、Supermaven 等 IDE 外掛產品：
   在程式自動補全的體驗上，仍與 Cursor 有顯著差距。Cursor Tab 像是個專門的模型，技術門檻也許不算高，但不知為何 GitHub Copilot 一直沒有跟進。
   而在聊天能力上，GitHub Copilot 缺乏像 Cursor 這樣靈活的上下文控制。
3. 「Agent」類產品（如 devin、replit、bolt、v0）：
   若太泛用，目前看來效果比較有限。若聚焦某些垂直領域（例如前端程式碼生成），可能還好，但大都侷限在「快速 Demo」階段，也牽涉更大範圍：未來 AI 是否會取代程式員。
4. Windsurf：
   目前最大的問題是自動補全功能還不夠成熟，很多功能（如 Python LSP）尚未完善，穩定性也不如 Cursor。不過它價格比較便宜，值得關注。
5. 開源替代方案（如 aider、cline）：
   這類工具有「隨用隨付」的優點，但完成度和易用性暫時與 Cursor 有明顯落差。
6. JetBrains AI：
   由於 JetBrains 在 Java 生態裡的用戶黏性極高，不少人無法輕易轉到 VSCode。但就市場反饋來看，JetBrains AI 的效果並不理想，連帶 GitHub Copilot 在 JetBrains 裡的體驗也不及 VSCode。

總結

到 2024 年 12 月為止，如果你對嘗試新工具的意願不排斥，Cursor 是個相當不錯的選擇。若你本來是 JetBrains 用戶，轉到 VSCode 也不算太困難：

• 可依據不同語言安裝對應的推薦外掛，VSCode 在前端、Python、Rust、Go 等領域都有相當完整的支援。
• 建議重新熟悉一下 VSCode 的快捷鍵（或安裝 IntelliJ IDEA Keybindings 外掛）。
• 不再有 Double Shift 全域搜尋，可以改用 CMD + P、CMD + T、SHIFT + CMD + F 等。
• VSCode 的圖形化 Git 操作相比 JetBrains 弱一些，但應付基礎需求足夠。
• 高度可配置化讓它非常靈活，但也有些小地方需要適應。

若想更詳細的轉換教學，可以上網找更專門的文章。

未來展望

從 Cursor 的角度來看，未來可以往兩大方向演進：Agent 架構與程式工作流程。雖然本文已很長，但我再簡述幾點可能的發展：

1. 語音整合： 把 Cursor 當作真人搭檔的話，若能提供「即時語音輸入、語音敘述程式碼」，體驗將更自然。
2. 更有效率的 Code Review： 隨著 AI 生成程式碼更快、更多，怎麼審閱就成了難題。目前的 Code Review 方式還略顯笨重，未來應該有更友好的呈現方式。
3. 架構設計輔助： 未來是否能幫忙做「架構級」的理解和建議？第一步可能要讓 Cursor 可以更「分層次」地理解程式，而不只是一股腦地給上下文。
4. 程式員職業前景：
   • Cursor 顯然想成為專業程式員的高階工具，相信程式員職業會長期存在，不會馬上被 AI 取代。使用門檻較高，因為它更適配當前的開發流程。
   • 像 Devin、Magic.dev 這些則好像比較偏「通用的程式碼 Agent」，也許最終可以取代人類程式員？這代表另一種可能——未來是否「人人都能製作自己的應用」或「只需要產品經理」？
   • 類比我第一次用 MidJourney、Suno 時，一度以為未來人人都能成為「數位藝術家」。但很快我發現，自己其實沒有那種「創作衝動」。看過他人作品後，我也常不知道我想產出什麼，最後只是在寫文章時用它做封面。
   • 同理，我對程式員未來的看法也類似：程式編寫的門檻或許會大幅下降，但仍屬較少數人才會主動思考要做應用。也許更多的「垂直領域產品」，會內建 AI 生成程式碼的功能，讓特定領域的人也能快速搞出一個小應用。

原文為中文，地址：https://mp.weixin.qq.com/s/JVb7-4a2XOFhfeJusaxvFg

關鍵詞： 人工智慧、教學指南、Cursor、程式碼編輯、Windsurf、討論

相關文章

• 9 Outstanding Ways Artificial Intelligence Can Transform Retail
• Mozilla releases an online editing tool – Popcorn Maker
• How Artificial Intelligence is Changing the Future of Web Design & Development
• Former Microsoft Executive Vice President Qi Lu joins Baidu
• The Best Video Editing Software for Windows 7
• Turn browser into notepad with one line of code
• PHP Apache MySQL Set-up Note
• HeartBleed: Should C be blamed for the HeartBleed bug?
• Some useful code editors for developers
• What can we do about Facebook?