為什麼 Go 是 AI 輔助軟體工程的理想語言

從編寫轉向審查

軟體工程正在經歷一場根本性的轉變，AI agent 會生成大量的程式碼，將人類開發者的主要角色從編寫轉向審查、驗證與維護。在這個新範式中，語言的生產力不再以人類編寫程式碼的速度來衡量，而是以人類驗證 AI 生成的程式碼是否正確、安全且具備可維護性的效率來衡量。

Go 作為軟體工程平台

Go 的設計目標是一個端到端的平台，而不僅僅是一門程式語言，它提供了一套標準化的工具鏈，減少了不同專案之間的差異。這種一致性對於 AI agent 而言至關重要，因為在缺乏外部驗證的情況下，迭代式重構可能會導致效能下降。

整合式工具與生態系統的一致性

Go 提供內建的工具用於格式化 (gofmt)、測試與依賴管理。這種整合式方法確保了整個社群都統一採用語言增強功能，為大型語言模型 (LLMs) 建立了標準化的訓練數據，並減少了對複雜外部框架的需求。

可讀性與 Agent 人機工程學

Go 優先考慮可讀性而非編寫性，明確拒絕「語法魔術」與複雜的抽象。這種可預測性是 AI 輔助開發的效能倍增器，因為：

驗證速度： 標準化的格式與嚴格的結構允許人類審查者更快速地發現幻覺、邏輯缺陷或安全漏洞。
可預測的輸出： 透過限制表達相同邏輯的方式，Go 防止了 AI 生成支離破碎且語法混雜的程式碼。
訓練數據品質： 生態系統範圍內對單一風格的堅持，為模型訓練創造了更乾淨、更一致的數據。

可靠性與安全護欄

Go 的靜態型別系統與「內建完善」的哲學，為 agentic code 提供了必要的安全網，因為這類程式碼通常在結構邊界與型別一致性方面面臨挑戰。

編譯器驅動的自我修正

Go 的快速編譯速度允許 AI agent 在緊密的自我修正迴圈中運作。如果 agent 生成了幻覺的 API 呼叫或錯誤的型別，編譯器會立即拒絕它，讓 agent 在程式碼到達人類審查者之前就能進行精煉。

供應鏈安全

LLMs 經常根據其訓練數據建議過時或惡意的第三方依賴。Go 透過以下方式降低此風險：

全面的標準函式庫： 引導 AI 使用安全且由官方維護的套件，而非外部依賴。
完整性保證： Go checksum database 與 module mirror 可防止中間人攻擊與依賴項消失的問題。
漏洞掃描： 像是 govulncheck 之類的工具提供低雜訊、具備行動力的回饋，能精準地修補漏洞。

自動化驗證

原生 fuzz testing 與內建的測試框架允許 AI agent 在標準化的沙盒中，透過迭代方式強化其自身的邏輯，以應對不可預測的輸入。

長期可維護性與演進

隨著 AI agent 加速了程式碼庫演進的速度，架構漂移與技術債的風險也隨之增加。Go 透過長期耐用性的保證來解決此問題。

相容性承諾

Go 對向後相容性的承諾確保了為 Go 1.0 編寫的程式碼仍能與最新的工具鏈相容。這防止了其他語言中常見的「破壞性變更」週期，這意味著 AI 生成的程式碼在多年的系統演進中仍能保持有效性。

確定性的現代化

像是 gopls 與 go fix (包含 "modernizers") 之類的工具，允許將舊有的程式碼模式確定性地更新為目前的慣用法。AI agent 可以利用這些標準化工具來安全地重構專案套件，並在不破壞系統的情況下清理技術債。

運作可攜性

Go 編譯成單一、靜態的二進位檔，且不具備系統依賴。這簡化了 AI agent 作為系統管理員的角色，因為它們可以在不管理複雜建置環境的情況下，進行跨平台編譯。

社群觀點與反對意見

雖然官方立場強調 Go 的優勢，但開發者社群對其在 AI 時代的適用性提出了幾種批判性的反對觀點：

支持其他語言的論點

Rust： 一些開發者認為 Rust 的更嚴格的編譯器與更更具表達力的型別系統提供了比 Go 更強大的護欄，使它對 LLMs 而言更「理想」因為編譯器能在編譯時期而非執行時期捕捉更多錯誤。
Python/JavaScript： 其他人則指出，這些語言擁有龐大的訓練數據量與快速的迭代速度，是其主要優勢。

Go 的限制

冗長性： 批評者認為 Go 的冗長性可能使人類「見樹不見林」，在大量的樣板程式碼中隱可能히 hiding subtle logic errors in a sea of a boilerplate code. (Note: The user requested to preserve all Markdown formatting, but the translation of theAgent/Agentic code is-as is. Let's re-evaluate the translation of the sentence.)
冗長性： 批評者認為 Go 的冗長性可能使人類「見樹不見林」，可能在大量的樣板程式碼中隱藏細微的邏輯錯誤。
型別系統缺口： 一些使用者指出 Go 的型別系統允許存在無效狀態 (例如 nil pointers 與部分建構的 structs)，而更嚴格的型別系統可以防止這些問題。
結構化型別： 一種批評指出，結構化型別使得 LLMs 難以在不搜尋更多程式碼庫的情況下，判斷一個 struct 是否實作了某個 interface。

"Go 的冗長性與用許多行程式碼來表達簡單的事情，在大多數時候都對我不利。" — @CSDude

"我在 Zig 中進行 LLM 輔助編碼的體驗非常棒... 每個人最愛的語言都無法成為我們新 LLM 世界中的萬靈丹。" — @rudedogg