2025 年 8 月,TypeScript 在 GitHub 上超越 Python 和 JavaScript,成為平台上最多人使用的程式語言。一年內新增超過一百萬名貢獻者,成長幅度 66%。
這不是自然演化。這是 AI 在背後推了一把。
GitHub 的開發者倡導者 Andrea Griffiths 替這個現象取了一個名字:便利迴圈(Convenience Loop)。當 AI 讓某個技術用起來特別順手,開發者就會湧向它。湧入的開發者產出更多程式碼,這些程式碼成為 AI 的訓練資料,AI 對這個技術變得更強,吸引更多開發者。
迴圈就這樣轉起來了。而且停不下來。
TypeScript 為什麼是最大贏家
一個數字就能說明問題:2025 年一項學術研究發現,LLM 產出的編譯錯誤中,94% 是型別檢查失敗。
想想這代表什麼。AI 寫的程式碼,十次編譯錯誤有九次以上是型別搞錯了。TypeScript 的型別系統就像一張安全網——你宣告了 x: string,AI 立刻知道該排除所有不適用於字串的操作。Python 的動態型別沒有這道防線,錯誤要到 runtime 才會爆開。
對 AI 來說,靜態型別不是束縛,是導航系統。
1 | // TypeScript 給 AI 明確的邊界 |
1 | # Python 的動態型別讓 AI 猜測 |
這不是說 Python 不好。在 AI 研究領域,Python 仍然是王者——2025 年 GitHub 上近半數新 AI 專案用 Python 寫的。但在應用層,TypeScript 正在吃掉市場。GitHub 把這個趨勢稱為「AI 驅動的混合堆疊」:Python 負責資料管線,TypeScript 負責應用和 API。
80% 的新手第一週就用 Copilot
這個數字讓我停下來想了很久。
GitHub 上 80% 的新開發者,在加入的第一週就開始使用 Copilot。他們從學寫程式的第一天起,「容易」的定義就被 AI 重新設定了。
如果 Copilot 在 TypeScript 上表現很好,新手就會覺得 TypeScript 很簡單。如果 Copilot 對某個小眾語言支援很差,新手就會覺得那個語言很難用。問題是——那個語言本身可能不難,只是 AI 不會寫而已。
我認為這改變了一個根本性的東西:開發者選擇語言的方式。
十年前,你選語言看的是社群大小、套件生態、效能特性。現在多了一個隱性指標:AI 寫這個語言寫得好不好。沒有人會在決策文件裡寫這一條,但它實際上影響著每個「用起來順不順手」的直覺判斷。
新語言的死亡螺旋
便利迴圈最殘酷的面向,是它對新語言做的事。
一個新程式語言剛出來,GitHub 上的程式碼量很少。Copilot 的訓練資料不夠,所以它在這個語言上的表現很差。開發者試用後覺得「AI 不支援,太麻煩了」,轉頭去用 TypeScript 或 Python。語言的使用者沒有成長,程式碼量沒有增加,AI 永遠學不會。
這是一個死亡螺旋。贏家通吃,新進者幾乎不可能突圍。
Steve Klabnik(Rust 核心貢獻者之一)在 2026 年初寫了一篇文章談他的新語言專案 Rue。他明確提到:AI 工具的缺乏支援是新語言推廣最大的障礙之一。不是語言設計不好,不是缺少特性,是 Copilot 不會寫你的語言,所以沒人想用。
Rust 本身算是少數突圍成功的案例——靠著 Mozilla 的推動和系統程式設計的不可替代性,累積了足夠多的程式碼讓 AI 學會。但下一個 Rust 呢?在便利迴圈的世界裡,門檻高了十倍。
你的技術決策正在被 AI 左右
Microsoft CEO 說 AI 產出公司 30% 的程式碼。Google CEO 說超過 25%。這不是實驗階段的玩具,這是生產環境裡真實在跑的東西。
當 AI 參與這麼大比例的程式碼產出,它對技術棧的「偏好」就不再是可以忽略的噪音。它變成一股重力場——把整個產業往特定方向拉。
我觀察到幾個正在發生的事:
前端框架全面預設 TypeScript。 Next.js、Nuxt、SvelteKit,新專案的腳手架工具現在預設就是 TypeScript。不是因為開發者投票選的,而是因為 AI 在 TypeScript 上的表現明顯更好,框架維護者自然會往這個方向靠。
MCP(Model Context Protocol)一年內從 10 萬下載量衝到 9,700 萬。 970 倍。Anthropic、OpenAI、Google、Microsoft、Amazon 全部原生支援。這個協議把 AI 和工具的連接標準化了,而它的 SDK 只有 Python 和 TypeScript 版本。如果你用其他語言,你就在 AI 工具生態的邊緣。
AI 編輯器三國鼎立。 Cursor(36 萬付費用戶)、Windsurf、Claude Code,三個工具的設計哲學完全不同,但都往同一個方向走:更深的 AI 整合、更自動化的程式碼產出。你的 IDE 選擇決定了你跟 AI 協作的方式,而 AI 的能力反過來決定了你用什麼語言最順手。
這代表什麼
我不覺得便利迴圈是壞事。TypeScript 的型別系統確實讓程式碼更可靠,AI 放大了這個優勢,這本身沒有問題。
但我在意的是另一件事:我們是否意識到自己的選擇正在被 AI 的訓練資料分佈所左右。
當你說「TypeScript 比較好用」,有多少是語言本身的優勢,有多少是 Copilot 在 TypeScript 上表現更好帶來的錯覺?這條界線正在變得模糊。
幾個值得思考的方向:
- 選語言時,把「AI 支援度」當成一個明確的評估指標,而不是讓它躲在「開發體驗」的模糊感受裡。
- 如果你在用小眾語言,提前評估 AI 工具的支援狀況。不是要你放棄,而是要你知道自己放棄了什麼。
- 關注語言社群的 AI 策略。Rust 社群在積極推動 AI 工具支援,這是明智的。如果你喜歡的語言社群對這件事毫無動作,那是一個警訊。
- 對「容易」保持警覺。AI 讓一個技術變得「容易」,不代表那個技術在你的場景下是最佳選擇。
便利迴圈已經轉起來了。它不會停。我們能做的不是對抗它,而是看清楚它在哪裡影響我們的判斷,然後帶著這個認知做出決策。
參考來源:
