大型語言模型在使用者先定義驗收標準時表現最佳

背景

這篇文章探討了大型語言模型（LLM）在撰寫程式碼時，往往傾向於產出「看起來合理」而非「絕對正確」的結果。作者以一個 Rust 重寫的 SQLite 專案為例，指出雖然該程式碼能編譯且通過測試，但在執行基本的主鍵查詢時，效能竟然比原始 SQLite 慢了兩萬倍，主因在於模型未能理解底層索引邏輯，導致查詢退化為全表掃描。

社群觀點

Hacker News 的討論圍繞著 LLM 的本質限制與使用技巧展開。許多資深開發者認為，LLM 產出效能低下的程式碼並不令人意外，因為模型本質上是基於機率預測文本，而非理解電腦科學的底層原理。有留言指出，LLM 在處理視覺化任務或未曾見過的創新邏輯時表現極差，例如嘗試讓模型繪製複雜的紋章圖案時，它往往會陷入長達一小時的無效嘗試。這反映出模型雖然擁有龐大的知識庫，卻缺乏真正的推理能力與對「正確性」的定義，其產出的程式碼更像是對訓練資料中現成片段的拙劣模仿。

然而，另一派觀點則為 LLM 辯護，認為這並非工具的失敗，而是使用者未能在提示詞中定義清楚的驗收標準。支持者主張，如果要求模型實作一個資料庫卻不要求效能基準，模型自然會選擇最簡單的實作路徑。他們將 LLM 比喻為洗碗機，雖然洗滌時間可能比人工長，但其低廉的勞動力成本仍具備極高價值。更有經驗的開發者分享了「代理式編碼」的技巧，強調應先讓模型建立架構文件，並在不更動程式碼的情況下反覆討論計畫，直到使用者滿意驗收標準後才開始生成。

爭論的焦點也延伸到開發者的資歷如何影響工具表現。社群普遍共識是，LLM 在資深工程師手中能大幅提升生產力，因為資深人員具備審查程式碼與識別潛在效能陷阱的能力；相反地，初級工程師若過度依賴 LLM，可能會產出大量看似專業卻難以維護的垃圾程式碼。此外，有人擔心 LLM 的訓練資料充斥著過往低質量的部落格文章，這導致模型在面對現代化或高效能需求時，容易給出過時且低效的建議。

最後，部分留言對未來持樂觀態度，認為目前的缺陷只是暫時的。隨著強化學習技術的進步，未來模型可以透過自動生成的測試與基準測試進行自我演化，從而學會區分「合理」與「高效」的差異。目前我們正處於技術轉型的陣痛期，開發者必須學會從單純的撰寫者轉變為嚴格的審查者與架構設計師。

延伸閱讀

• Frankensqlite：文中提到的 Rust 版 SQLite 重寫專案。
• Simon Willison 的部落格：關於 LLM 生成 SVG 圖形（如鵜鶘騎腳踏車）的演進觀察。
• METR 的隨機研究與 GitClear 的儲存庫分析：關於 LLM 產出錯誤模式的大規模數據研究。