沒什麼新鮮的，只是利用人工智慧進行研發的簡單案例。 （GPT-5.1 與 Opus 4.5 比較） 提供一些背景資訊： 我們有 2 個版本的 HVM 可以執行 SupGen： → HVM3：用於開發，互動速度達到 1.6 億次/秒 → HVM4：完善版，互動速度達到 1.3 億次/秒 也就是說，新版本更現代化，但速度稍慢，因為我們還沒有對其進行最佳化。 昨天，我啟動了兩個編碼代理：Opus 4.5 (ultrathink) 和 GPT-5.1-codex-max (xhigh)，並要求它們盡可能地優化新的 HVM4。 結果：幾個小時後，他們徹底失敗了。 連1%都不到。 然後我讓他們繼續嘗試。 他們又失敗了。一次又一次。持續了好幾個小時。 到了某個時候，他們乾脆放棄了。 他們甚至拒絕繼續嘗試。 GPT-5 寫道： > 我嘗試了多種旨在減少內存流量和提高吞吐量的結構性和底層更改，但每次嘗試要么破壞了構建，要么使性能倒退，要么未能超越 ~120 M itrs/s 的基準。 鑑於 clang-03 的限制以及此工作負載的記憶體密集型特性，我目前還沒有可行的方案能夠安全地將速度提升到 140 M itrs/s。繼續「不斷嘗試」很可能會導致效能下降，而不是真正提升。 所以我嘗試了不同的方法：這次，我將舊的 HVM3 目錄複製並貼上到 HVM4 中，並寫道： 這是新舊兩種 HVM 實作。舊版本包含一些新版本尚未實現的最佳化。你的目標是理解它們之間的差異，並將舊版中的所有最佳化移植到新架構中。 已發送給 Opus。 10分鐘後，我查看了終端。 每秒 1.9 億次交互 那真是……令人欣喜的一幕，因為這創下了該基準測試的絕對紀錄。我們從未在單核心 CPU 上見過如此接近的成績。 這更印證了我對法學碩士現況的看法： 他們的程式設計能力非常強。 → 他們在創新方面極為糟糕。 這兩個模型完全無法想到我們提出的想法，但一旦接受了解決方案，它們就能非常有效率地執行，閱讀和編寫大量程式碼，從而節省了大量時間。 HVM3 中最重要的最佳化現在已在新架構上實現，並創下了新的紀錄，而我完全不需要編寫任何程式碼。我只需要想到這個方法，它就完美地奏效了。 鄭重聲明，我已經完全停止使用 Gemini 3 了。我認為它是世界上最聰明的模型，但由於指令執行能力差、連接錯誤和延遲高，以及 Gemini CLI 性能不佳，它並不適合用於程式設計。 GPT-5.1-codex-max 還不錯，但速度很慢，而且我還沒見過它的性能超過 Opus 4.5，後者仍然是我所有工作的首選模型。我非常喜歡 Claude 模型在程式設計方面一貫的穩定性，而且我很高興能找到一個真正聰明的模型。
正在載入線程內容
正在從 X 取得原始推文，整理成清爽的閱讀畫面。
通常只需幾秒鐘，請稍候。