編輯 | 伊風(fēng)
AI 會有自己的編程偏好嗎？
如果問 Claude Code “最偉大的編程語言”是什么，它又會怎么回答呢？
今天，Hacker News 上一篇技術(shù)博客引發(fā)了熱烈討論。作者結(jié)論相當(dāng)直接：靜態(tài)類型語言更適合“Vibe Coding”。
圖片
自從 Claude Code 上線后，這位作者改變了自己十多年依賴 Python 開發(fā)的習(xí)慣。
轉(zhuǎn)而頻繁使用自己并不十分熟悉的 Rust 等強(qiáng)類型語言。
憑借 Claude Code 的功能和編譯器的安全檢查，他即使在并不熟悉的語言中，也能快速生成并驗證數(shù)千行改動，而且?guī)缀醪黄茐姆€(wěn)定性。
他甚至預(yù)測：
在企業(yè)生產(chǎn)環(huán)境中，Python 的采用率將會下降——盡管我個人依舊很喜歡它。
然而，這樣的結(jié)論在評論區(qū)卻遭到不少質(zhì)疑與反駁，尤其是在 Rust 這個熱門語言上的討論，更是針鋒相對。
接下來，我們就看看，作者是如何得出“AI IDE 更擅長靜態(tài)類型語言”這一判斷的，而他的觀點，又能否站得住腳？
1.因為 Claude Code，我轉(zhuǎn)向了 Rust——更快、更安全
作者說，在CC上線后，他超過 10 年的編程習(xí)慣發(fā)生了巨變。
Python 不再是他新項目的首選語言。
如今，他常常管理一些并不精通的語言項目——TypeScript、Rust 和 Go——而且運(yùn)行得相當(dāng)順利。
對他而言，這很反直覺：過去，他一直習(xí)慣用 Python 把項目“Vibe”出來。
而在 AI IDE 的加持下，他逐漸發(fā)現(xiàn)，靜態(tài)類型、編譯型語言在 vibecoding 中反而更適合，因為它們提供了更強(qiáng)的安全性保障。
當(dāng)項目規(guī)模達(dá)到一定程度后，Claude Code 搭配 Rust 反而比搭配 Python 更快、更安全——哪怕 Rust 的代碼更底層。這完全得益于 AI 工具的加入。
他舉了個例子：在 TextCortex 重構(gòu)大量 TypeScript 前端代碼時，Claude Code 會在完成每個任務(wù)后自動運(yùn)行 tsc，確保代碼編譯通過才提交。這樣的工作流，讓他的效率遠(yuǎn)超使用 Python——畢竟 Python 并沒有編譯期的安全網(wǎng)。更讓他驚訝的是，那些在短短幾小時內(nèi)提交的 3-5k 行改動，不僅沒有破壞系統(tǒng)，反而提升了穩(wěn)定性。
“大語言模型依然是‘有泄漏的抽象（leaky abstractions）’，”作者寫道，“但它們現(xiàn)在已經(jīng)足夠成熟，既能保留過去 Python 的快速原型開發(fā)體驗，又能避免 Python 在安全性、性能、語義清晰度上的短板。”
他甚至預(yù)測，未來生產(chǎn)環(huán)境里，Python 可能會被包括 Rust 在內(nèi)的強(qiáng)類型語言擠壓。
的確，Rust 擁有內(nèi)存安全、零成本抽象、強(qiáng)類型和編譯期檢查等特性，但作者的個人體驗，未必能代表大多數(shù)開發(fā)者的現(xiàn)實感受。
2.網(wǎng)友質(zhì)疑：大模型在生成 Rust 代碼上是出了名的差！
在評論區(qū)，不少有 Rust 經(jīng)驗的開發(fā)者對“更快、更安全”的說法表示質(zhì)疑，甚至給出了完全相反的故事。
許多網(wǎng)友認(rèn)為，AI 生成的 Rust 代碼質(zhì)量堪憂——即便能編譯通過，也常常低效、臃腫、不優(yōu)雅。
“這和我用 Claude 寫 Rust 的體驗完全不符。我有 2.5 年的 Rust 商業(yè)開發(fā)經(jīng)驗，水平不差。Claude 會在 Rust 代碼上產(chǎn)生幻覺，因為它是統(tǒng)計模型，而不是靜態(tài)分析工具。即便寫出能編譯的代碼，這些代碼通常也低效、難看。”
圖片
造成這種現(xiàn)象的原因，當(dāng)然也和 Rust 語言本身的特性密切相關(guān)：
1）語義難度高
Rust 的內(nèi)存安全和所有權(quán)系統(tǒng)對 LLM 來說理解門檻很高。
“我看到 LLM 在 Rust 上的主要困難，是理解語言語義——也就是編譯器靜態(tài)驗證的那些規(guī)則。比如，它們會‘以為’存在 use-after-free 或 use-after-move 這種問題，但在安全的 Rust 中，這根本不可能發(fā)生，因為語言本身保證了不會出現(xiàn)這種情況。
Rust 是為數(shù)不多真正做了新東西的語言，它的語義和 Go、TypeScript 的差異，比 Go 和 TypeScript 之間的差異大得多。我猜在 Haskell、OCaml、Prolog 這類語言中，LLM 的表現(xiàn)也會差不多。”
圖片
2） 邊緣情況多，寫法不統(tǒng)一
Rust 的標(biāo)準(zhǔn)庫龐大、邊緣情況豐富，甚至還有不少“看似應(yīng)該存在但實際沒有”的特性，例如沒有沒有隱式類型轉(zhuǎn)換，沒有默認(rèn)的沒有默認(rèn)的“空值”/null等等。這些都容易讓 AI 生成錯誤代碼。
大語言模型在生成 Rust 代碼上是出了名的差。…… Rust 本身坑很多、標(biāo)準(zhǔn)庫龐大且邊緣情況多，還有很多你以為應(yīng)該存在但其實不存在的東西。Rust 的寫法種類也很多，而不是像有些語言那樣只有一種慣用法。
3）訓(xùn)練數(shù)據(jù)劣勢
與 Java、Python 相比，Rust 在 LLM 訓(xùn)練語料中的高質(zhì)量代碼庫相對較少，這直接影響了模型的生成質(zhì)量。
一方面，Rust 誕生時間較短（2015 年穩(wěn)定版發(fā)布），成熟項目和大規(guī)模開源庫數(shù)量有限；另一方面，很多 Rust 代碼分布在較小的社區(qū)倉庫中，不像 Java/Python 那樣集中在大型開源項目和知名代碼平臺，爬取難度也更高。
3.不過，這并不表示AI IDE不合適寫Rust
Rust 一直以高性能和內(nèi)存安全著稱，但學(xué)習(xí)曲線陡峭。
如今，Claude Code 等一類好用的 AI 編程工具，正在顯著降低 Rust 的上手門檻。
有網(wǎng)友指出，即便是相對小眾的語言（如 OCaml、Scala），在 AI 輔助下產(chǎn)出高質(zhì)量結(jié)果的時間和精力成本都大幅下降——雖然第一次生成幾乎不會完全正確，但修正和迭代的速度快了很多。
那么，如何利用 Rust 的特性找到適合 AI 輔助的用法？
一位開發(fā)者分享了自己的經(jīng)驗：
我用 Claude 寫 Rust 的結(jié)果還不錯。我的提示語通常是這樣： “我有一個數(shù)據(jù)庫表 Foo，這是它的 DDL：<SQL>，幫我在 /v0/foo 創(chuàng)建 CRUD 接口；用和 Bar 相同的代碼風(fēng)格。” 我覺得它在模仿現(xiàn)有代碼風(fēng)格方面做得挺好。
原因在于，強(qiáng)類型語言在 AI 編碼中確實能形成更快的錯誤定位與修復(fù)循環(huán)。
另一位網(wǎng)友補(bǔ)充：
“尤其是在 agentic coding 環(huán)境里。強(qiáng)類型/靜態(tài)類型語言配合良好的編譯器提示，能通過解析和類型檢查形成非常快的反饋循環(huán)，而如果配合像 Claude.md 這樣的規(guī)則文件，還能迭代得更快。”
4.寫在最后：AI并不能直接幫你上手不會的語言
為什么評論區(qū)有人說“AI 寫 Rust 出奇地差”，而作者卻有完全相反的體驗？
一位網(wǎng)友給出了一個有趣的解釋——他借用了傳播學(xué)中的“媒介素養(yǎng)”概念：當(dāng)人們在某個領(lǐng)域是專家時，他們能分辨信息源的好壞；但當(dāng)他們對主題不熟時，往往會假設(shè)信息源至少是靠譜的。
他說，自己在用大語言模型做 Web 開發(fā)時，也有和作者類似的感受：看起來 AI 的表現(xiàn)很不錯——至少比自己手寫的“爛攤子”要好。但問題是，他其實沒有資格去判斷 AI 代碼的真正質(zhì)量。“
他說了一句很扎心的話：“我覺得，AI 的不少價值，都來自工程師以為自己有資格判斷它寫得好不好。”
這番話引起了不少共鳴。有人補(bǔ)充說：
“雖然 AI 寫不好 Rust，但如果讓它從零生成可用且優(yōu)雅的 Python 代碼，它反而挺不錯的。順便說一句，我并不精通 Python。”
那么，AI 最擅長寫的，其實正是你不精通的語言？
在諷刺之余，這也提醒了我們：在 AI 時代，開發(fā)者的持續(xù)學(xué)習(xí)依然有意義——編程能力既無法被一鍵自動化取代，也需要為所謂的“AI 編程神話”降降溫。
不過，像作者這樣，被 Claude Code 改變十年編程習(xí)慣的故事，未來只會越來越多。
你覺得 AI 更擅長寫哪種語言？
你有被哪款 AI IDE 改變過編程習(xí)慣嗎？歡迎在評論區(qū)聊聊。
