Transformer 基礎的大型語言模型（LLMs）像是 GPT、Claude 和 Gemini 等，越來越常被拿來當作程式開發的助手。你可以讓它寫函數、生成單元測試，甚至幫你除錯。但它真的「懂」程式碼嗎？能不能像人類一樣進行有效的 debug 呢？
本篇文章從工程實務角度，談談目前 LLM 在程式開發，特別是 debug 任務上所面臨的幾個核心限制。這不只是模型還不夠「強」，而是目前技術本身就有一些難以突破的瓶頸。
沒有真正的邏輯推理能力
當我們在 debug 時，通常會思考：這段程式碼的執行結果是什麼？會怎麼影響接下來的流程？這就是邏輯推理的過程。人類能一步步推演，理解程式碼間的相互關係和影響。
現有的大型語言模型是靠大量文字資料學習「語言模式」，它們生成回答的方式更多是基於統計和模式匹配，而不是嚴謹的邏輯推演。換句話說，模型不是真的「理解」程式碼的邏輯，而是「猜」哪段文字最有可能出現。這種缺乏真正推理的能力，使得模型在面對複雜邏輯和跨段關聯時，難以準確找出錯誤。
注意力分配不均，容易忽略關鍵上下文
即使是支援長上下文的模型，例如可以處理十萬 token 的版本，它們的注意力分布仍然是「不平均」的。根據 Stanford 大學於 2023 年發表的論文 《Lost in the Middle: How Language Models Use Long Contexts》 中的研究與實測觀察，模型往往更偏好頭段與尾段的內容，對中間區段的關注力最弱，這種現象也被稱為中間遺忘效應（Middle Drop-off）。
而在 debug 任務中，錯誤的根源常常藏在中段的邏輯細節裡。例如某個變數的初始值在前段定義，中段經過幾次變換，尾段才報錯。如果模型無法「平等」關注整段程式碼，那它很可能看不到關鍵訊息，自然也就很難給出準確的判斷。這也意味著：就算我們把整個檔案餵進去，模型也不一定能真正「看到」錯誤的來龍去脈。
無法像人類一樣理解程式碼的用途與執行過程
或許你會問：「模型不是可以解釋一段程式碼嗎？它不是看懂了嗎？」事實上，模型能解釋程式碼，只表示它記得這段語法或常見用途，但不代表它真的「理解」程式碼的執行過程。這兩者有本質上的不同。
人類工程師在閱讀程式碼時，會在腦中模擬它的執行流程，預測變數的變化、條件分支的走向，甚至預想它在極端輸入下的行為。這是一種動態的理解。
而目前的語言模型是靜態的。它只能看程式碼，無法真正模擬執行。就算搭配編譯器跑出結果，它也只是「知道了答案」，卻無法像人類一樣理解這段程式「為什麼」會得出這個結果，或它背後的設計意圖。這使得模型無法有效執行 debug 的工作，因為 debug 的本質是去「還原出錯的過程」，並且找出邏輯的錯誤，最後進行修正。
總結
大型語言模型在程式碼生成的任務上已經展現出強大潛力，但在面對複雜的 debug 任務時，仍有一些重要的限制需要克服。了解這些限制，有助於我們更合理地使用這些工具，並期待未來的技術進步。它有以下三大限制：
- 缺乏真正的邏輯推理能力：模型是靠模式匹配在生成文字，並不具備像人類一樣逐步推演邏輯、理解程式碼之間關係的能力，因此難以處理需要邏輯推理與跨段關聯的錯誤診斷。
- 注意力分配不均：模型容易忽略中段關鍵邏輯，導致錯誤被跳過。
- 無法理解程式碼執行過程：模型即使能解釋程式碼，也無法模擬程式碼的運行來精準 debug。