我覺得我對 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 高效能有條不紊地處理某些事情，完全是不同的體驗。 無論如何，玩這個東西真的非常有趣。對我來說，它比任何視頻遊戲都更有趣和吸引人。

剛剛閱讀了Yann LeCun和Randall Balestriero的新LeJEPA論文。我一直很好奇Yann最近在做什麼，特別是考慮到他對LLMs的所有批評（我不同意這些批評，因為我認為LLMs會持續改進，並且會很快帶我們進入ASI）。 無論如何，X上已經有幾個關於這篇論文及其介紹的討論串。簡而言之，這是一種有原則、理論上有根據且簡約的自我監督學習方法，取代了防止模式崩潰的複雜雜亂的臨時性、粗糙的啟發式方法，而模式崩潰是自我監督學習的禍根。 這是模型出錯的地方，開始將所有輸入映射到幾乎相同的嵌入或狹窄的嵌入子空間，將問題的所有豐富性壓縮成一個病態簡單且錯誤的對應。 新方法的第一個支柱是他們證明了各向同性高斯分佈獨特地最小化最壞情況下的下游預測風險。 當我讀到這一點時，我立刻想到了CMA-ES，這是當你無法訪問你試圖最小化的函數的梯度時，最佳的黑箱優化算法，但只能進行（昂貴/緩慢的）函數評估。 Nikolaus Hansen自1996年引入CMA-ES以來一直在研究它。我一直對這種方法感到著迷，並在2011年用它成功地高效探索深度神經網絡的超參數，而不是進行低效的網格搜索。 無論如何，我提到這一點的原因是因為這種方法與LeJEPA的核心之間存在著驚人的平行和深刻的聯繫。 CMA-ES說：從各向同性高斯開始，因為它是給定方差約束下的最大熵（最少偏見）分佈。然後調整協方差以學習問題的幾何形狀。 LeJEPA說：保持各向同性高斯，因為它是對未知未來任務的最大熵（最少偏見）分佈。 兩者都認識到，在不確定性下，各向同性是最佳的，原因有三： 最大熵原則；在所有具有固定方差的分佈中，各向同性高斯具有最大熵；即，它做出最少的假設。 沒有方向性偏見；所有方向的方差相等意味著你不會預先承諾任何特定的問題結構。 你獲得最壞情況的最佳性；在所有可能的問題幾何中最小化最大遺憾。 那麼，區別在哪裡？這取決於適應的時機。CMA-ES可以在優化過程中進行適應；它開始是各向同性的，但隨著學習特定的優化地形而變得各向異性。 相比之下，LeJEPA必須保持各向同性，因為它正在為尚未見過的未知下游任務做準備。 這種平行表明LeJEPA正在將優化理論中的基本原則應用於表示學習。它本質上是在說： “黑箱優化的最佳搜索分佈也是轉移學習的最佳嵌入分佈。” 這是有道理的，因為這兩個問題都涉及導航未知的地形；對於CMA-ES來說，這是未知的優化地形；對於LeJEPA來說，這是未知的下游任務空間。 這種差異讓我想知道：我們能否有“自適應LeJEPA”，它從各向同性開始，但在我們知道下游任務後調整其嵌入分佈，類似於CMA-ES在優化過程中的適應？這就像是為特定任務家族進行元學習的正確各向異性。 無論如何，我想分享我的想法。看到這些不同領域之間的聯繫真是令人著迷。黑箱優化社群一直與深度學習社群相對獨立，並且那裡的交叉授粉不多。 這是有道理的，因為如果你有梯度，你不使用它就太瘋狂了。但這之間有著強烈的聯繫。

你可以利用 codex 和 GPT-5，將一個真正漂亮、流暢、原生用 Swift 編寫的 iOS 應用程式開發到大約 95% 的程度。但當你想把它放到 AppStore 時，就需要設置簽名的證書和其他所有這些東西。 在那個時候，你就無法再從命令行以程式化的方式做所有事情，必須開始在 Xcode 的 GUI 中進行操作，這簡直是一場噩夢。 UI 模式糟糕透頂，你需要猜測每樣東西的位置。即使 AI 告訴你一步一步該怎麼做，在這個混亂且糟糕的介面中找到東西也是一個巨大的認知負擔。 Apple 應該真的暫停所有其他開發工具的工作，直到他們擁有一個完全完整、良好文檔（在一個 markdown 文件中！）的 CLI 和 API，這可以被 AI 編碼代理用於創建和發布應用程式的所有相關工作。