@balajis 關於 「驗證差距」 的好文章。 你可以把它看作是創造中有兩種模式。借用 GAN 術語： 1） 生成和 2） 歧視。 例如，繪畫 - 您繪製畫筆筆觸 （1），然後您看了一會兒，看看是否改進了繪畫 （2）。這兩個階段幾乎穿插在所有的創造性工作中。 第二點。區分在計算上可能非常困難。 - 圖像是迄今為止最簡單的。例如，圖像生成器團隊可以創建巨大的結果網格，以確定一張圖像是否比另一張更好。感謝你大腦中為非常快速地處理圖像而構建的巨大 GPU。 - 文本要難得多。它是可流覽的，但你必須閱讀，它是語義的、離散的和精確的，所以你還必須推理（尤其是代碼中的SP）。 - 音訊可能更難，因為它強制了一個時間軸，所以它甚至無法流覽。您被迫花費串行計算，並且根本無法並行化它。 可以說，在編碼中，LLM 已經摺疊 （1） 到 ~instant，但對解決 （2） 的作用很小。一個人仍然必須盯著結果並區分它們是否好。這是我對 LLM 編碼的主要批評，因為他們隨意地在每個查詢中吐出太多代碼，複雜度任意，假裝沒有第 2 階段。獲取那麼多代碼既糟糕又可怕。相反，LLM 必須積極與您合作，將問題分解為小的增量步驟，每個步驟都更容易驗證。它必須預測 （2） 的計算工作並盡可能減少它。它必須真正關心。 這讓我想到了非編碼人員對編碼的最大誤解。他們認為編碼就是編寫代碼 （1）。事實並非如此。這是關於盯著代碼 （2） 的。將其全部載入到您的工作記憶體中。來回踱步。考慮所有邊緣情況。如果你在我“程式設計”時隨機發現我，我可能只是盯著螢幕看，如果被打斷，我真的很生氣，因為它的計算非常費力。如果我們只得到更快的 1，但我們沒有同時減少 2（這是大多數時候），那麼顯然編碼的整體速度不會提高（參見阿姆達爾定律）。