Hacker News
This article discusses the potential and limitations of Large Language Models (LLMs) in acting as compilers, arguing that while they can generate code, they should not be treated as such due to fundamental differences in their underlying mechanisms and reliability.
AI 生成摘要
這篇文章探討了大型語言模型（LLMs）作為編譯器的潛力和局限性，認為儘管它們可以生成程式碼，但由於其底層機制和可靠性的根本差異，不應將它們視為編譯器。
這場討論源於一篇探討大型語言模型（LLM）是否應被視為編譯器的文章。作者認為，儘管 LLM 具備將自然語言描述轉化為程式碼的能力，但其本質上的不確定性與黑盒特性，使其在作為基礎開發工具時存在嚴重的可靠性風險。這引發了 Hacker News 社群對於編譯器定義、軟體工程的確定性需求，以及 AI 在開發流程中定位的激烈辯論。
社群討論的核心首先聚焦於「確定性」這一概念。許多開發者指出，編譯器的基本價值在於其行為的可預測性。當輸入相同的原始碼，編譯器必須產出位元級別一致的二進位檔案，這對於安全性驗證、供應鏈攻擊防護以及可重現構建至關重要。反觀 LLM，即便將溫度參數調至零，由於硬體並行運算的浮點數捨入誤差或推論框架的實作細節，仍難以保證輸出完全一致。有留言者形象地比喻，使用 LLM 當編譯器就像是用電鑽去釘釘子，雖然技術上可行，但工具的本質屬性與任務需求完全錯位。
然而，另一派觀點則挑戰了傳統編譯器必然是「確定性」的看法。部分資深工程師提到，現代的即時編譯器（JIT）或具有設定檔引導優化（PGO）功能的編譯器，其輸出的機器碼往往受到執行環境、啟發式演算法或硬體計數器的影響，並非絕對的位元一致。他們認為編譯器真正需要的是「語義閉包」，即輸出只要在語義上等價且正確即可，而不必追求字面上的一模一樣。但此觀點隨即遭到反駁，反對者認為 LLM 的問題不在於微小的二進位差異，而在於其輸出的「正確性」本身是機率性的，這種「憑感覺編碼」的模式與航空電子或金融系統所需的嚴謹性背道而馳。
討論中也出現了對軟體工程未來趨勢的擔憂與反思。有網友諷刺地表示，LLM 揭示了當今許多系統其實只需要「淺層的近似值」就能運作，這種追求開發速度而忽視可靠性的傾向，反映了技術極端主義者對系統穩定性的漠視。他們擔心這種「混沌開發」模式會被管理層擁抱，因為這能讓專案提前完成並節省昂貴的人力成本，即便代價是企業聲譽與系統安全。
最後，關於 LLM 在開發流程中的定位，社群達成了一種微妙的共識：與其將 LLM 視為編譯器，不如將其視為一名「中階程度的初級開發者」。開發者不應盲目信任其輸出的每一行程式碼，而是要像審查下屬工作一樣，建立完善的測試與驗證機制。正如一位留言者所言，人類大腦本身也是非確定性的，但我們透過嚴格的工程規範來約束這種不確定性；對待 LLM 也應如是，將其作為輔助工具而非取代基礎設施。