我覺得我之前對 Cursor 的新 Composer-1 編碼語言學習模型 (LLM) 評價過低了。當然，它肯定比 GPT-5 High Effort 和 GPT-5-Codex 差，所以從這個意義上講，在設計和實現重要的程式碼專案時，我並不認為它適合我的工作流程。 另一方面，它的速度非常快（不知道他們是怎麼做到的；他們使用的是 Groq 還是 Cerebras 硬體？是因為模型非常小巧高效嗎？不確定），僅此一點就解鎖了許多新的工作流程和工作技巧，適用於代碼並非至關重要，或者當你開始一個新項目而不必擔心破壞現有代碼的情況。 它也比任何版本的 GPT-5 便宜得多。速度更快、成本更低的雙重優勢，使得模型的使用方式發生了質的飛躍，而我之前並沒有充分意識到這一點。當迭代的成本（無論從時間或金錢方面）都如此之低時，你就可以進行更多的迭代。 這降低了「一次性正確性」的價值；也就是說，像 GPT-5 Pro 這樣的模型能夠一次性正確完成複雜的編碼任務而不出現任何錯誤（儘管即使是該模型也經常在這個非常嚴格的測試中失敗）。 但是，如果你能夠閉合調試循環，快速將錯誤/警告反饋給模型，並且每次迭代只需 20 秒到 1 分鐘（而不是像使用 GPT-5 那樣投入大量精力至少需要 5 到 10 倍的時間），那麼你就可以快速解決它在第一次（甚至第二次、第三次或第四次錯誤）中犯的所有低級錯誤，並且仍然比可完成的 GPT-5 低級錯誤。 如果你正在瀏覽器中進行開發，現在可以使用 Cursor 的全新瀏覽器標籤頁功能，真正實現完整的閉環開發。就我目前見過的所有編碼工具而言，這絕對是此類功能的最佳實現（遠勝於 Codex 的 Playwright MCP 或 Claude Code！）。今天我一直在使用這個提示，效果顯著： 「使用瀏覽器標籤頁系統地探索此應用程式，並以自然的方式使用介面；同時，請留意開發者控制台中的任何警告或錯誤。一旦發現，請開始互動式地、迭代地診斷和修復錯誤和問題，然後刷新應用程式並驗證錯誤或警告是否已完全解決。修復問題時，請專注於確定錯誤的真正根本原因，而不是應用虛假的「創可貼式修復」！ 然而，這種方法真正的缺陷在於概念和規劃階段，在這個階段你需要從宏觀層面思考要做什麼以及如何最好地實現它。缺乏深入思考和探索會讓你一開始就走上一條難以挽回的歧途。 當你的任務偏離常見編碼任務的「資料流形」時，這一點就更加明顯了。如果你只是在做一個簡單的CRUD網站，那你可能不會太在意。但如果你嘗試在人工智慧生命模擬或其他類似領域開闢新天地，你就會對此深有體會。 但有一個很好的混合方法，效果非常好：將最聰明的規劃模型與這些快速且廉價的迭代模型結合。 所以，先用瀏覽器應用程式裡的 GPT-5 Pro 制定計畫和初步實施方案，然後貼到 Cursor 裡，開始迭代、修復和改進。它更擅長修改現有的堅實基礎，而不是從零開始建立基礎。 當你在一個全新的專案中，以輕鬆有趣的方式探索和嘗試，而沒有截止日期或預期目標時，這一切的優勢就真正顯現出來了。在這種情況下，速度至關重要。 這讓我想起了 IBM 在 20 世紀 80 年代初進行的一項關於電腦系統延遲的研究，該研究發現，當延遲低於某個神奇的水平（例如 50 毫秒）時，行為會發生很大的變化，因為人腦會感知到它正在處理一個「即時系統」。 反之，即使延遲超過一個出乎意料的適中水平，例如 500 毫秒，用戶參與度也會大幅下降，而且會讓人感到精神疲憊和沮喪。當延遲飆升到幾秒鐘甚至更長時，人們往往會精神恍惚，難以集中註意力。 看到編碼模型在幾秒鐘內做出回應，並在不到 15 秒內快速完成 10 次編輯，這與等待 GPT-5 高努力值模型 5 分鐘有條不紊地完成某項任務完全是兩種不同的體驗。 總之，玩這個東西真的太有趣了。對我來說，它比任何電子遊戲都更有趣、更吸引人。
正在載入線程內容
正在從 X 取得原始推文，整理成清爽的閱讀畫面。
通常只需幾秒鐘，請稍候。