我覺得我對 Cursor 的新 Composer-1 編碼 LLM 太過輕視了。當然，它在某種意義上比 GPT-5 高效能和 GPT-5-Codex 差得多，因此在我架構和實施重要代碼項目時，我並不認為它在我的工作流程中有什麼位置。 另一方面，它的速度極快（我想知道他們是怎麼做到的；他們是使用 Groq 還是 Cerebras 硬體？還是因為模型這麼小且高效？不太確定），僅此一點就為當代碼不是那麼關鍵時，或當你開始一個新項目而不必擔心破壞現有代碼時，解鎖了許多新的工作流程和工作技術。 與任何版本的 GPT-5 相比，它的成本也便宜得多。速度更快且成本更低的組合在使用模型的方式上創造了一些質的差異，我之前並沒有完全意識到。當迭代的成本在時間和金錢上都如此低時，你可以進行更多次的迭代。 這降低了「一次性正確性」的價值；也就是說，像 GPT-5 Pro 這樣的模型能夠在第一次就正確完成即使是複雜的編碼任務而沒有錯誤的能力（儘管即使是那個模型在這個非常嚴格的測試中也經常失敗）。 但是如果你能夠關閉調試循環，並快速將錯誤/警告反饋到模型中，每次迭代的時間只需 20 秒到 1 分鐘（而使用 GPT-5 高效能時至少需要 5 到 10 倍的時間），那麼你可以快速解決它第一次出現的所有粗心錯誤（甚至是第二次、第三次或第四次出現的錯誤），並且仍然能比使用 GPT-5 更快地完成可運行的代碼。 如果你在瀏覽器中開發某些東西，你現在可以真正使用 Cursor 的新瀏覽器標籤來完全關閉循環，這是我在任何編碼工具中見過的這類實現中最好的（它遠遠超過了使用 Codex 或 Claude Code 的 Playwright MCP！）。我今天一直在使用這個提示，效果很好： 「使用瀏覽器標籤系統地探索這個應用程序，並以自然的方式使用界面；在這個過程中，注意開發控制台中的任何警告或錯誤。當你看到一個時，開始互動式和迭代地診斷和修復錯誤和問題，然後刷新應用程序並驗證錯誤或警告是否完全解決。在修復問題時，專注於確定錯誤的真正根本原因，而不是應用虛假的「創可貼」修復！」 然而，這種方法在概念和規劃階段真的會崩潰，因為你在思考要製作什麼以及以高層次的最佳方式實施它時。那裡，缺乏深入思考和探索可能會讓你走上難以恢復的錯誤道路。 當你正在處理的任務遠離常見編碼任務的「數據流形」時，這一點更加明顯。如果你正在製作另一個簡單的 CRUD 網站，那麼你可能不會注意到太多。如果你試圖在人工生命模擬或類似的奇怪事物中開辟新天地，你會注意到很多。 但有一種很好的混合方法運作得非常好：將最聰明的模型用於規劃，與這些快速且便宜的模型結合以產生迭代。 因此，在瀏覽器應用中使用 GPT-5 Pro 來制定計劃和初步實施，然後將其粘貼到 Cursor 中，開始迭代、修復和改進。它在修改現有強大基礎方面要比建立該基礎本身更好。 這一切真正閃耀的時刻是當你在一個有趣的新項目中玩耍和探索時，沒有截止日期或期望。在這種情況下，速度是一個真正的遊戲改變者。 這讓我想起了 IBM 在 80 年代早期進行的那項研究，該研究考察了計算機系統的延遲，發現當延遲低於某個魔法水平，比如 50 毫秒時，你會看到行為的巨大變化，因為人類大腦感知到它正在處理一個「實時系統」。 相反，當延遲超過即使是驚人適度的水平，比如 500 毫秒時，你會得到更少的參與，這在心理上是有壓力和令人沮喪的。當延遲飆升到幾秒鐘或更長時間時，人們往往會在心理上退出，並且很難保持參與。 看到編碼模型在幾秒鐘內做出反應並在 15 秒內進行 10 次編輯，與等待 5 分鐘讓 GPT-5 高效能有條不紊地處理某些事情，完全是不同的體驗。 ...