AI 時代，該怎麼選程式語言？

在許多系統開發與工程教育脈絡中，C/C++ 曾長期佔據核心位置。後來主流答案逐漸分散，Java、C#、Python、TypeScript、Go 各自崛起，也都一度被期待成為下一個中心。

到了 LLM 時代，這個問題又被拿出來重問一次。從 agent、harness 與同類工具在 TypeScript、Python、Rust 等不同生態中並行發展、彼此競逐，就看得出這仍是秦失其鹿，天下共逐之的時代。¹

但如果問題還停在「哪門程式語言最好」，最後多半只會得到一份偏好清單。語言模型對某種語言、生態與框架是否熟悉，當然會影響起稿速度與初稿品質；可是在「生成結果不能直接被信任」的前提下，選型真正該看的，是哪一種程式語言 × 驗證鏈組合，比較能把生成結果穩定送進工程收斂。

判準：驗證回饋

這題看的是工程判準：系統能不能把生成結果轉成可處理的錯誤訊號、修正入口與收斂路徑。

我會把這個判準拆成三個面向：約束顯性化、錯誤可診斷性、修正迴圈成本。

第一，是約束顯性化。

系統裡真正重要的規則，有沒有被寫出來？這不只包括型別、介面、可空值與錯誤處理，也包括更高一層的架構約束：依賴方向是否受控制、重要邊界是否清楚、副作用出口是否外露、哪些規則能放在哪裡，是否已經被寫進 repo、測試與工具鏈，而不是只留在人腦與團隊默契裡。²

關鍵約束沒有顯性化，語言模型就很容易補出一段表面合理、實際上已經穿透邊界的程式碼。

第二，是錯誤可診斷性。

問題能不能提早暴露？暴露之後，位置夠不夠局部？錯誤訊息是否足夠讓人與語言模型採取下一步？有些失敗是編譯器指出型別不吻合；有些失敗是測試、靜態分析或架構規則檢查指出邊界被穿透；也有些失敗要等整段功能都跑歪之後，才以模糊症狀浮出來。前兩種通常比較容易進入修正流程；最後一種很容易把人和語言模型一起拖進猜測循環。

第三，是修正迴圈成本。

從發現問題到修掉問題，這條路有多短、多穩、多能反覆？有些語言和工具鏈把回饋收得很緊：一存檔，型別錯誤、lint、測試、靜態分析就一起往前推。有些情境則要靠團隊自己把這條鏈補起來：寫測試、補 sandbox、整理 fixture、把規格拆細。這不一定是壞事，但如果修正迴圈太長、太散、太仰賴人腦維持，生成帶來的速度最後很可能會被問題分流成本吃掉。

對 AI 協作來說，程式語言的價值，很大一部分就落在這裡。實際效果通常不是由語法表面決定，而是由它背後那整套工程鏈決定：型別系統、編譯器、靜態分析、測試、sandbox、CI、架構規則、review 習慣，以及團隊是否真的把這些機制接起來。

現有研究也大致支持這個方向。像 RUSTASSISTANT 這類研究顯示，當語言模型拿到更明確、較局部、可行動的編譯器錯誤訊號時，自動修正的表現確實可能明顯改善。³ 另一類研究則指出，自動化回饋迴圈有機會改善 LLM 產出的可修正性與整體收斂能力。⁴

這些材料還不夠推出一份跨語言總排名，但已經足夠支持一個實務判斷：AI 協作的重點，不在模型先吐出什麼，而在系統後面怎麼接。

TypeScript：應用層的顯性契約

TypeScript 很適合放在應用層，因為它擅長把原本留在人腦裡的假設寫進程式裡。

應用層系統最麻煩的地方，通常不是語法，而是資料長什麼樣子、API 回傳什麼、哪個欄位可能是 null、重構之後哪些地方會一起受影響。TypeScript 的強項，就是把這些原本靠默契維持的東西，寫成編輯器與工具鏈也看得懂的契約。

型別、介面、函式簽名、nullable 邊界，會把一部分原本隱含的假設直接前移；一旦這些假設被寫出來，回饋也比較容易來得早，而且夠局部。型別不吻合、介面沒對齊、重構後遺漏哪個使用點，往往在編輯器⁵ 或編譯階段就已經浮出來。對人和語言模型來說，這種錯誤比執行期才浮現的模糊故障更容易處理。TypeScript 官方對自己的定位也很直白：它的目標就是成為 JavaScript 的 static type checker。⁶

這不代表 TypeScript 會自動保證商業邏輯正確。它真正做的，是把許多原本靠人腦維持的假設，改成比較穩定的工程訊號。對 AI 協作來說，這很重要，因為語言模型最常出錯的地方，常常不是完全不會寫，而是把邊界寫鬆、把例外漏掉，或把幾個看似相近的型別混成一件事。

它改善得最明顯的，其實是重構診斷鏈。改動一個型別定義、調整一個介面、收斂一個資料結構，哪些地方會一起受影響，通常可以更快浮出來。這不只幫助人類開發者，也讓語言模型生成的修改比較容易被局部檢查。

所以在複雜、壽命長、多人協作、需要反覆重構的產品系統裡，TypeScript 很自然會成為 AI 協作的預設選項。

Python：探索層與後補驗證

Python 很適合探索層。

資料清洗、notebook 探索、模型實驗、工作流編排、自動化腳本、內部工具，這些工作追求的往往不是一開始就把邊界封死，而是先把想法試出來，再決定哪些約束值得前移。Python 在這一層一直很有位置，不只是因為語言模型熟，也因為它背後本來就長出了一整套成熟的探索式工作流。⁷

它的代價也很清楚。很多問題不會自己提早跳出來，而是要等到執行、測試、整合，甚至真實資料流進來之後，才逐步暴露。這在探索階段未必是問題；但當系統開始長大、模組開始互相依賴、邊界開始固定，延後暴露的成本就會愈來愈高。

所以 Python 的重點，是驗證鏈通常要靠開發者主動補齊。型別工具當然重要，但它們多半屬於後補工程，而不是預設前置約束。系統一旦開始工程化，type hints、mypy、pyright 這些工具就很有價值。它們不能把 Python 變成 TypeScript 那種強制契約環境，但確實能把一部分原本留到執行時才知道的問題，往前拉到提交之前。⁸

迭代式自我修正機制也值得注意。像 Self-Refine 的研究顯示，透過同一語言模型反覆生成批評並改寫輸出，的確可以改善部分程式相關任務的結果。⁹ 少了編譯期強護欄時，這類反覆回饋的機制就更重要。

對 Python 可以先下個簡單判斷：它適合探索層，但不適合長期停在鬆散狀態。任務一旦開始收斂，驗證鏈、型別工具、測試與自動化修正機制都得補上。

Rust：核心區的前置約束

Rust 很適合放在核心區，因為它把更多高成本錯誤推到執行之前。

所有權、借用、顯式錯誤處理、記憶體安全，加上接近 C++ 的性能，讓 Rust 很適合放在那些真正承受不起錯的地方：系統邊界、效能瓶頸、安全敏感模組、工具鏈核心。像 Hugging Face Tokenizers 與 Candle 這類專案，都把 Rust 放在很核心的位置。

從驗證回饋的角度看，Rust 最重要的地方，在於它替生成式協作加上了一個強度很高的前置驗證入口。語言模型可以先產生草稿，但草稿要放進系統前，必須先通過型別、所有權、生命週期與錯誤處理這些約束。這會帶來三個效果：約束更早顯性化、程式本體層的大量錯誤可以提早被局部定位，也有一部分問題根本進不到執行期。

不過 Rust 能前推的，主要還是那些已經被形式化、並寫進語言與程式結構裡的約束；它不會自動替你驗證產品規格、流程例外與商業判準。折扣規則算得對不對、權限邏輯是否符合產品政策、某個狀態組合在真實業務上是否合法，這些問題通常活在需求、文件、流程與領域知識裡，不會完整地活在型別系統裡。

這也是 Rust 的代價。它要求你更早面對那些在探索階段未必已經準備好定下來的結構問題：資料怎麼流、邊界怎麼切、資源由誰持有、錯誤怎麼往上拋。有些錯誤很局部，修起來很快；但有些錯誤暴露的其實不是語法細節，而是資料流、API 邊界或狀態設計本身還沒有收斂。

所以 Rust 很適合那些已經開始收斂、值得把約束前移的核心任務，卻不一定適合作為探索層的預設選項。LLM 確實降低了採用 Rust 的門檻，但 Rust 最好的位置，仍然比較像核心語言，而不是所有層次的預設答案。¹⁰

Go：平台層的穩定節奏

Go 的強項不花俏，就是穩。

它的優勢不在最強的護欄，也不在最大的探索彈性，而在一套簡潔、收斂、低負擔的預設。對 AI 協作而言，這通常代表更小的偏航空間、較一致的程式風格，以及較可控的修正成本。

Go 從一開始就不是為語法炫技設計的。Go at Google 那篇文章講得很直接：這門程式語言的目標，是減少大型軟體開發中的遲滯與笨重感，而且它是為那些要寫、讀、除錯與維護大型系統的人設計的。¹¹ 這也讓 Go 的優勢比較像一組工程取向很明確的選擇：語言表面積小、工具鏈單純、編譯快速、標準函式庫完整。Go 社群自己的年度調查，也持續把簡潔、可維護與穩定工具鏈列為很主要的使用理由。¹²

放進前面的框架來看，Go 的強項比較像是把日常工作流收得很緊。go 命令把 build、test、fmt、fix 收在同一套官方工具鏈裡¹³；語法與慣例也長期維持在相對收斂的範圍內。官方對 gofmt、idiomatic code 與 code review conventions 的長期強調¹⁴，至少讓這個判斷有了比較實在的基礎：當團隊與語言模型共同操作同一份程式碼時，比較不容易一路寫歪。

它不會像 Rust 那樣把很多高成本錯誤前推到最前面，但也比較不容易把系統帶向過度抽象、過度分散、難以追蹤的狀態。對 CLI、基礎設施、平台工程與後端服務這類工作來說，Go 往往比表面上看起來更耐用。

分層設計

把前面的判準落到實務，最可用的答案通常不是單一贏家，而是分層設計：在不同風險區，放上不同強度、不同時點的驗證機制。

如果要把這個思路濃縮成一份真的能用的選型問卷，核心其實只有三題。

第一，這一層最承受不起的是什麼：速度慢、重構痛、部署複雜，還是安全、效能與可靠性風險？

第二，這一層最需要哪種驗證：型別、編譯器、靜態分析、測試、sandbox，還是高密度的人類 review？

第三，這一層的關鍵知識主要活在哪裡：活在程式語言本身、框架慣例、repo 結構與架構規則、文件、團隊的隱形知識，還是 CI 與基礎設施流程裡？

這三個問題想清楚，程式語言選型的討論才不會停留在偏好清單。

探索層，Python 仍然很自然。它適合拿來確認方向、讓資料露出形狀、把流程跑通；但當任務開始收斂，就應補上型別註記、靜態檢查、測試與自動化驗證鏈，而不是讓探索式寫法一路帶到後期。

應用層，TypeScript 的優勢在顯性型別、重構能力、多人協作與長期維護。當系統最怕的是隱含假設太多、邊界鬆動、改一處壞三處時，它常會是 AI 輔助產品開發很自然的預設選項之一。

核心區，最值得把約束前移。當錯誤代價高到不能留在後面處理，Rust 的型別、ownership 與編譯期驗證就特別有價值。它不必成為全面預設，但很適合放在真正關鍵的地方。

平台層，很多時候追求的是一致性、簡潔性、可讀性、快編譯與低樣板。Go 不一定最華麗，但常常能提供低負擔、低偏航、易維護的工程條件。對許多團隊來說，這種穩健性比語言敘事的戲劇性更有用。

補充一點，大型企業後端往往不是從零選程式語言，而是在既有堆疊、IDE、生態、人才結構與組織流程裡持續演化。從這個角度看，Java 與 C# 的問題不只是適不適合 AI 協作，而是它們原本就已經在許多團隊中形成穩定的收斂條件。若團隊已有深厚積累，沒有必要為了語言選型的抽象論點而另起爐灶。¹⁵

程式語言選擇走到這裡，比較像架構設計，而不再只是口味問題。

尚未定論的部分

有幾件事，現在還不能講死。

第一，驗證回饋這個方向大致成立；但不同程式語言在人類問題分流成本、修正效率與整體收斂速度上的差異，到底有多大，仍然缺夠乾淨的全面性證據。現在比較多的是局部研究、特定任務或特定工具鏈的結果；它們能支持方向，還不足以直接推出一份放諸各場景皆準的程式語言排名。

第二，前置護欄的價值很真實，但護欄愈強，不代表整體開發一定愈有效率。像 Rust 這類程式語言，確實能把很多錯誤提早暴露，但提早暴露與提早解決不是同一件事。有些錯誤是局部修正，有些則會牽動資料流、API 邊界與設計本身。程式語言提供的驗證強度，不能單獨和整體生產力畫上等號；還得放回任務型態、團隊能力與系統成熟度裡一起看。

第三，程式語言本身從來不是全部。CI 有沒有真的接起來、測試與 sandbox 有沒有成形、團隊有沒有能力 review 產出、關鍵規格有沒有被整理成語言模型與工具都吃得下的形式，這些都會直接改變選型最後的實際收益。其中特別值得單獨點出的是 agentic 工作流裡的上下文管理：長上下文不是免費的。現有研究顯示，模型對長輸入中位於中段的關鍵資訊利用能力會明顯下降，而且情境變長，不代表使用品質會穩定提升。¹⁶

所以，在生成愈來愈便宜的前提下，程式語言選擇真正該優先服務的，還是驗證與收斂，而不只是起稿速度。

結語

LLM 讓生成變便宜之後，型別、編譯器、測試、靜態分析、清楚的系統邊界、可被工具檢查的架構規則、可 review 的程式碼，反而都變得更重要。

AI 時代的程式語言選型，重點還是把高成本錯誤提前到團隊還處理得起的位置。