Cursor 是一個 AI 程式編輯器，直覺的反應是：喔，又一個 AI 產品，好喔。
但有趣的不是「AI 會寫程式」。有趣的是 AI 住在哪裡。
大多數 AI 寫程式的 demo 感覺還是像支線任務。開一個瀏覽器分頁。貼一段程式碼。求助。把答案複製回來。修 import。重複到分頁變成一鍋粥。
Cursor 的出發點好得多：模型應該坐在編輯器裡面、檔案旁邊，也就是工作本來就在發生的地方。
聽起來是小事。這不是小事。
編輯器就是 context window
開發者不是在孤立的程式片段裡寫程式。真正的工作散落在各個檔案、命名慣例、詭異的專案歷史、記憶模糊的決策，以及那個沒人想碰的 helper function 裡。
編輯器外面的聊天框可以幫忙，但它永遠缺席那個房間。
住在編輯器裡的 AI，更有機會理解真正的工作面：
- 目前的檔案
- 周圍的程式碼
- 專案結構
- 眼前的那個錯誤
- 答案該落地的位置
這很重要，因為寫程式不只是生成文字，而是把正確的變更放進一個既有系統，同時不讓明天變得更糟。
模型離專案越近，使用者就越不需要淪為剪貼簿操作員。
行內協助勝過大陣仗
這套工作流程最好的版本不是「請幫我生成整個 app」。
還不是。老實說，也許永遠都不是。
最好的版本更小、更持續：
- 解釋這個檔案
- 重寫這個函式
- 找出這個 state 從哪裡來
- 把這個粗糙的想法變成一個 patch
- 讓這個錯誤沒那麼邪門
- 給我看測試該長什麼樣
這種協助貼合開發者原本的移動方式。它不是一場盛大的儀式，而是在摩擦點上的輕輕一推。
這就是為什麼 Cursor 感覺不同於一個套了程式碼佈景的聊天機器人。編輯器可以變成對話的介面，但這場對話錨定在程式碼上，而不是漂浮在旁邊。
可怕的部分是信任
明顯的風險：生成的程式碼可以看起來正確，卻悄悄做錯事。
這在程式領域比在一般文章裡更糟，因為錯的程式碼能通過氛圍檢查。它排版漂亮。它有 import。它用了自信的命名。它感覺像進度——直到某個邊界情況吃掉你一整個下午。
所以紀律必須跟著工具改變：
- 讀 diff
- 跑測試
- 問為什麼，不只問是什麼
- 保持小變更
- 不要因為神祕程式碼出現得快就接受它
編輯器裡的 AI 只有在讓開發者更有效、而不是更昏沉的時候才有用。
這條線接下來會很重要。
這指向一個更大的轉變
如果說 ChatGPT 讓 AI 感覺像一個通用文字介面，Cursor 則暗示了下一個產品模式：把 AI 直接嵌進工作台。
不是另一個目的地。不是一個要專程拜訪的聊天機器人。而是工具內部的一層，工作的脈絡本來就在那裡。
對程式來說，那是編輯器。
對設計來說，也許是畫布。
對營運來說，也許是收件匣或內部儀表板。
對研究來說，也許是那疊文件。
共同的模式很簡單：把模型放到使用者亂糟糟的脈絡本來就住的地方。
那才是突破口。不是因為 AI 神奇地正確，而是因為回饋循環變短了。問、改、看、修。同一個房間，少掉複製貼上的爛泥。
初步判決
Cursor 感覺還很早期，但方向清晰到不行。
程式編輯器一直是開發者把意圖翻譯成可運作軟體的地方。如果編輯器現在能理解更多專案、建議變更、解釋陌生的程式碼、幫忙塑造 patch，那麼編輯器就不再只是一個打字的地方。
它變成一個協作介面。
這不會消除對品味、測試、架構和判斷力的需求。真要說的話，它讓這些東西更重要了。程式碼出現得越快，知道什麼不該被接受就越重要。
不過，形狀已經很清楚：寫程式的協助大概不會永遠住在另一個分頁裡。
它住在 diff 所在的地方。
回溯補記。Cursor 普遍被報導為在 2023 年 3 月公開上線；參見 Contrary Research 等公司沿革摘要：https://research.contrary.com/company/anysphere 以及 TechCrunch 2023 年 10 月的種子輪報導：https://techcrunch.com/2023/10/11/anysphere-raises-8m-from-openai-to-build-an-ai-powered-ide/