大型語言模型可以，但不應該是編譯器

背景

這場討論源於一篇探討大型語言模型（LLM）是否應被視為編譯器的文章。作者認為，儘管 LLM 具備將自然語言描述轉化為程式碼的能力，但其本質上的不確定性與黑盒特性，使其在作為基礎開發工具時存在嚴重的可靠性風險。這引發了 Hacker News 社群對於編譯器定義、軟體工程的確定性需求，以及 AI 在開發流程中定位的激烈辯論。

社群觀點

社群討論的核心首先聚焦於「確定性」這一概念。許多開發者指出，編譯器的基本價值在於其行為的可預測性。當輸入相同的原始碼，編譯器必須產出位元級別一致的二進位檔案，這對於安全性驗證、供應鏈攻擊防護以及可重現構建至關重要。反觀 LLM，即便將溫度參數調至零，由於硬體並行運算的浮點數捨入誤差或推論框架的實作細節，仍難以保證輸出完全一致。有留言者形象地比喻，使用 LLM 當編譯器就像是用電鑽去釘釘子，雖然技術上可行，但工具的本質屬性與任務需求完全錯位。

然而，另一派觀點則挑戰了傳統編譯器必然是「確定性」的看法。部分資深工程師提到，現代的即時編譯器（JIT）或具有設定檔引導優化（PGO）功能的編譯器，其輸出的機器碼往往受到執行環境、啟發式演算法或硬體計數器的影響，並非絕對的位元一致。他們認為編譯器真正需要的是「語義閉包」，即輸出只要在語義上等價且正確即可，而不必追求字面上的一模一樣。但此觀點隨即遭到反駁，反對者認為 LLM 的問題不在於微小的二進位差異，而在於其輸出的「正確性」本身是機率性的，這種「憑感覺編碼」的模式與航空電子或金融系統所需的嚴謹性背道而馳。

討論中也出現了對軟體工程未來趨勢的擔憂與反思。有網友諷刺地表示，LLM 揭示了當今許多系統其實只需要「淺層的近似值」就能運作，這種追求開發速度而忽視可靠性的傾向，反映了技術極端主義者對系統穩定性的漠視。他們擔心這種「混沌開發」模式會被管理層擁抱，因為這能讓專案提前完成並節省昂貴的人力成本，即便代價是企業聲譽與系統安全。

最後，關於 LLM 在開發流程中的定位，社群達成了一種微妙的共識：與其將 LLM 視為編譯器，不如將其視為一名「中階程度的初級開發者」。開發者不應盲目信任其輸出的每一行程式碼，而是要像審查下屬工作一樣，建立完善的測試與驗證機制。正如一位留言者所言，人類大腦本身也是非確定性的，但我們透過嚴格的工程規範來約束這種不確定性；對待 LLM 也應如是，將其作為輔助工具而非取代基礎設施。

延伸閱讀

• Thinking Machines 網誌：探討如何克服 LLM 推論過程中的非確定性問題。
• Matt Pharr 的網誌文章：討論自動向量化為何不應被視為一種編程模型，並延伸探討可靠心理模型的重要性。
• ISPC 編譯器的起源：關於如何可靠地表達語義的技術背景。