LLM 寫出的不是正確程式碼，只是「看起來像對的程式碼」：一篇深度閱讀筆記

本篇文章更新時間：2026/03/08
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。

LLM 程式碼的真相：為什麼「看起來對」遠遠不等於「真的對」

編輯前言：這篇文章值得一讀，因為它不是在談 LLM 寫程式會不會寫錯，而是揭露「LLM 的正確程式碼其實常常只是看起來合理」的根本問題，尤其在效能、邏輯與架構層面更是如此。本篇筆記整理自原文 Your LLM Doesn't Write Correct Code. It Writes Plausible Code。

核心觀點 (Key Takeaways)

• LLM 生成的程式碼常常完全可編譯、通過測試、架構看似正確，但在真正使用下卻可能是兩萬倍慢的錯誤實作。
• 這種問題不是程式碼長得不好，而是 LLM 只在乎語意上的「看起來合理」而非技術上的「實際正確」。
• 使用 LLM 的最大風險是：沒有能力驗證輸出的人，最容易被 plausible code 欺騙。

深入解析

原文聚焦在一個由 LLM 產生的 SQLite Rust 重寫版本。乍看之下，它具備：

• 正常編譯
• 正確讀寫 SQLite 格式
• 支援 MVCC、C API
• 各模組（parser、planner、B-tree、pager…）俱全

看起來像真的 SQLite。然而，一個最簡單的 benchmark「100 次 primary key 查詢」暴露出驚人差距：

SQLite：0.09 ms
LLM 重寫版：1,815.43 ms（慢 20,171 倍）

原文細讀 source code 後，辨識出核心問題不在語法，而在「搜尋策略」。SQLite 的 INTEGER PRIMARY KEY lookup 會走 B-tree（O(log n)），但 LLM 寫出的版本永遠選 full table scan（O(n)）。

“LLMs optimize for plausibility over correctness. In this case, plausible is about 20,000 times slower than correct.”

其結果是：每個 WHERE id = N 的查詢都會掃整張表。

此外還有第二個大問題：插入（INSERT）未包 transaction 時，每筆都做一次 fsync —— 導致 100 筆 inserts 等於 100 次磁碟同步。

更多「看似合理但致命」的實作

原文列出一系列「表面上安全、實務上災難」的選擇：

• 每次查詢都 clone AST、重新編譯
• 每次讀取都重新分配 4KB buffer（破壞 zero-copy）
• 每次 autocommit 都重新載入 schema
• 每條語句都新建 VDBE、transaction、memory DB
• fsync 而不是 fdatasync（效能差 1.6~2.7 倍）

每個選擇單看皆合理，但放在高度敏感的資料庫 hot path 裡，累積變成千倍級的效能崩壞。

原文強調：SQLite 的快，是 26 年 profiling 交換來的，不是 C 語言魔法。

第二個案例：用 82,000 行 Rust 解決一行 cron job

作者觀察同一開發者另一個專案：為了解決 target/ 資料夾佔滿磁碟空間，LLM 生成了一套龐大的「磁碟管理系統」：

• 82k 行 Rust
• 192 個 dependency
• Bayesian scoring engine、PID controller、Dashboard…

但真正需要的，只是一行：

*/5 * * * * find ~/*/target -type d -name "incremental" -mtime +7 -exec rm -rf {} +

筆者心得與啟發

原文最核心的提醒是：LLM 的失敗常常不在語法，也不在測試，而在「邏輯與效能的本質」。它生成的是「符合需求文字描述」的 code，而非真正符合 domain invariant 的系統。這對工程師其實是深刻的警訊。

我最強烈的感受是：LLM 的程式碼不屬於你，除非你理解得足以拆解它。

這篇文章讓我重新思考，使用 LLM 時，真正的能力不是「寫 prompt」，而是：

• 我是否知道什麼才叫做 correctness？
• 我是否能辨識效率與演算法上的錯誤？
• 我是否能為 LLM 設定可衡量、明確的 acceptance criteria？

換句話說，LLM 不會取代工程師。真正被取代的是「不理解自己在寫什麼的人」。

如果沒有專業判斷，只靠 LLM 寫出的 code —— 那並不是開發，而是「盲目 token 生成」罷了。

最終，文章給出一句非常值得記住的提醒：

The vibes are not enough. Define what correct means. Then measure.

這是我讀完後最深的共鳴：LLM 能讓我們更快，但前提永遠是 —— 我們知道什麼才叫做「對」。