來自 GitHub 的數據表明，AI 工具正在創造“便利循環”，重塑開發者的語言選擇

作者 | Steef-Jan Wiggers

譯者 | 平川

近日，GitHub 2025 年的 Octoverse 報告揭示了開發者可能沒有意識到的一些事情。AI 編程助手不僅改變了開發者編寫代碼的速度，還影響了開發者最初選擇的語言。

TypeScript 以 66% 的驚人年增長率成為 GitHub 上使用最多的語言，其原因不僅僅是框架的默認設置。GitHub 開發大使 Andrea Griffiths 稱之為“便利循環（convenience loop）”，其工作原理是：當 AI 使某項技術變得方便使用時，開發者就會蜂擁而至，而這反過來產生了更多的訓練數據，使 AI 在該技術上變得更加出色。

根據 GitHub 2025 年的 Octoverse 報告，到 2025 年 8 月，TypeScript 超越了 Python 和 JavaScript，成為 GitHub 上月活躍貢獻者最多的語言，擁有 263.6 萬開發者。這是十多年來最大的語言排名變動。當然，像 Next.js 和 Astro 這樣默認使用 TypeScript 的框架提供了一些幫助。但對于為什么 TypeScript 與 AI 如此契合，有一個更深層次的技術原因。

（圖片來源：GitHub 博客）

在最近的一篇博文中，Griffiths 進行了分析說明：

當一個任務或流程進行得順利時，你的大腦就會記住。便利性吸引注意力。減少阻礙變成了偏好，而大規模的偏好可以改變生態系統。在 GitHub 上 ，80% 的新開發者在第一周內使用了 Copilot 。這些早期接觸重新定義了“簡單”的基線。

其技術優勢顯而易見。強類型語言為 AI 提供了明確的護欄。當你在 TypeScript 中聲明 x: string 時，AI 立即就知道要忽略所有不適用于字符串的操作。JavaScript 采用的那種無拘無束的方法，對 AI 來說像是迷宮般的挑戰。實際上，有研究支持這一點。 Visual Studio Magazine 曾引用 2025 年的一項學術研究，由 LLM 造成的編譯錯誤 94% 是類型檢查失敗。靜態類型語言能在 AI 所犯的錯誤成為生產問題之前捕捉到它們。

TypeScript 并不是這個趨勢中的孤例。GitHub 對類型化語言的分析顯示，Luau（Roblox 的逐步類型化語言）年增長率為 194%，Typst（一個強類型的 LaTeX 替代品）增長了 108%。與此同時，當前有超過 110 萬個公共存儲庫使用 LLM SDK。這已經成為主流，不再是實驗性的了，并且集中在與 AI 協作良好的技術棧上。

Idan Gazit 領導著 GitHub Next 團隊（ Copilot 背后的團隊）。在另一次訪談中，他解釋了 AI 如何從根本上改變了開發者在選擇技術時的考量：

在 AI 技術出現之前，選擇一種語言是在運行時、庫生態系統和個人熟練度之間進行權衡。有了 AI 之后，出現了一個新的約束條件：如果我選擇這種語言，模型會給我帶來多少提升？

Python 仍然主導著 AI 項目開發；2025 年， GitHub 上新增的 AI 存儲庫有近一半開始時使用了 Python ，這是因為它適用于模型訓練和原型設計，而不是因為它是 AI 輔助應用開發的最佳選擇。然而，若從整體發展態勢來看，JavaScript/TypeScript 生態系統的發展規模遠超其他任何領域。

Medium 博客作者 Cenk ?etin 分析 了這對整個行業來說意味著什么：

隨著 AI 輔助編碼的普及，提供靜態類型檢查的語言其地位不斷上升。TypeScript 提供的嚴格類型系統有助于在 AI 生成的代碼進入生產環境之前捕捉錯誤，增加代碼可靠性。

Griffiths 希望團隊能更有意識地考慮這個問題。她在 博文 中提出了一個簡單的練習：

看看你最近做的三個技術決策：為新項目選擇的語言，為新功能選擇的框架，為工作流選擇的工具。AI 工具支持在這些選擇中占了多少比重？如果答案是“不多”，我敢打賭它比你意識到的更重要。

對于語言設計者來說，便利循環開創了一個具有挑戰性的現實。在 GitHub 采訪中，TypeScript 首席架構師 Anders Hejlsberg 直截了當地解釋了這一點：

AI 使用一種語言編寫代碼的能力與其見過的該語言的代碼量成正比。它是一個大型復讀機，輔以一定的推理能力。AI 已經看過大量的 JavaScript、Python 和 TypeScript 代碼，所以它在編寫這些語言的代碼方面非常出色。從這個角度來說，新語言無疑處于劣勢。

新語言陷入了惡性循環。Hejlsberg 指出，AI 模型基本上是復述它們之前見過的內容，并加入了一些推理結果。因此，如果你的語言沒有數百萬的代碼示例，Copilot 就無法提供太大的幫助。而當無法獲得 Copilot 的幫助時，開發者就會選擇其他的東西。這也意味著你的語言永遠不會有數百萬行的代碼示例。這是一個殘酷的反饋循環，贏家已經鎖定。

GitHub 的增長規模極為驚人：2025 年的 Octoverse 數據顯示，平臺擁有 1.8 億開發者、6.3 億個代碼存儲庫，當年提交次數接近 10 億次，同比增長率達 25%，相當于全年每秒新增一位用戶。

對于試圖理清這一切的領導者，Griffiths 給出了實用的建議：不要只統計使用 AI 工具的人數，要關注這些工具實際產出了什么。GitHub 新推出的 Copilot 使用指標儀表盤（企業版仍處于公開預覽階段）詳細展示了誰在使用什么、使用的語言以及編碼助手的采用方式。這有什么實際的意義嗎？這有助于發現特定的語言或模型何時開始與存在缺陷的代碼產生關聯，從中可以看出團隊需要優化提示詞或加強代碼審查的環節。

根據 Griffiths 的分析，可以得出的主要結論是：AI 兼容性正在悄然重塑你做出的每一個技術決策。在選擇框架或語言時，你可能沒有有意識地將其納入考慮因素，但它就在那里。與 AI 助手不兼容的工具已經在失去市場。便利循環不在乎你的偏好，它只會使那些讓編程感覺更輕松的東西加速發展。

https://www.infoq.com/news/2026/03/ai-reshapes-language-choice/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。