TypeScript 的創造者談 AI：無聊的事丟給它，有趣的留給你
Anders Hejlsberg 在 GitHub 訪談裡給出對 AI 輔助開發最直接的建議：把重複、無聊、但耗時的事丟給 AI 去跑。TypeScript 已成為 GitHub 上使用人數最多的語言，而這位設計了 Turbo Pascal、Delphi、C# 和 TypeScript 的工程師，對 AI 的看法比外界想像的更接地氣、也更保守。
目錄+
GitHub 在 2026-04-19 發布了一支 Anders Hejlsberg 的長訪談影片，附上摘錄文章「7 learnings from Anders Hejlsberg」。其中被 @github 官方帳號單獨截出來引用的一句話是：
"Find the stuff that's boring and uninteresting, but you know still costs you, and try to get AI to do that for you."
這不是那種 hype 滿滿的 AI 宣言。說這話的人，是四十年來設計了 Turbo Pascal、Delphi、C#、TypeScript 的 Anders Hejlsberg，現任 Microsoft Technical Fellow。他對 AI 的看法比大多數人接地氣，而且他有夠多的踩坑經驗可以舉例。
他是誰，為什麼值得聽
1960 年生於丹麥哥本哈根，Hejlsberg 在 Borland 時代設計了 Turbo Pascal 和 Delphi，替那個年代的開發者定義了「快速回饋」是什麼感覺——在 64KB 的機器上寫程式，整個程式都得裝在你腦袋裡，每一層 abstraction 都要付出代價。
1996 年加入 Microsoft 後，他主導了 C# 和 .NET framework 的設計。2012 年開始另一個計畫：TypeScript。
TypeScript 的起點不是「我們要做一個新語言」，而是 Outlook Web 團隊在用一個叫 Script# 的工具——把 C# 編成 JavaScript 跑。Hejlsberg 把這個想法轉了個彎：不是要生一門新語言出來，而是讓 JavaScript 可以加型別，做成 typed superset。「我們的意思是：我們不打算在這裡生一門全新語言……我們只是想把壞掉的地方修好。」（根據 devclass 報導）
結果呢，他當初的心理預期是「能拿到 25% JavaScript 社群的認同就賺到了」——根據 GitHub Blog 的訪談，這是當時的基準線。現實是，根據 GitHub Octoverse 2025，TypeScript 在 2025 年 8 月第一次成為 GitHub 上使用人數最多的語言，超越 Python 和 JavaScript，單年貢獻者成長 66%，多了超過 100 萬人。
AI 是「大型回收再利用機器」
Hejlsberg 對 AI 有一個直白的描述，刊登在 GitHub Blog：
"AI's ability to write code in a language is proportional to how much of that language it's seen. It's a big regurgitator, with some extrapolation."
這不是在貶 AI。他的意思是：AI 對一個語言的掌握程度，跟它訓練時看過多少那個語言的程式碼直接掛鉤。JavaScript、Python、TypeScript 被看過最多次，所以 AI 在這幾個語言上最順手。新語言反而吃虧。
這個說法有一個具體的踩坑案例可以對照。TypeScript 的核心 compiler 目前正在做 port to Go 的計畫。他們一開始試著直接叫 AI 幫忙翻譯程式碼：
"That went not so great … we want a very deterministic outcome here. We want to port half a million lines of code and know that they do exactly what the old lines of code did. If you ask AI to translate them, it might hallucinate a little bit here and there, and now you've got to go carefully examine every line of code."
50 萬行程式碼，每一行都要重新檢查有沒有被 AI 幻覺出錯誤。這不是在用 AI，是在被 AI 坑。
他給出的正確姿勢是：不要叫 AI 幫你翻，叫 AI 寫一支幫你翻的程式。 這樣跑起來得到的是確定性的輸出，不是那種「應該對、但說不準」的逐行翻譯。這個方法後來他們真的套用在另一個場景上——把舊 TypeScript codebase 的新 PR 自動同步到 Go 那邊——「我們用 AI 做這個，結果還蠻不錯的。」
無聊的事，就是 AI 的使用場景
訪談裡另一個讓人印象深刻的觀點：AI 最適合的不是「有趣的問題」，而是「你知道它重要、但就是提不起勁去碰」的那種工作。
GitHub Blog 文章 7 learnings 的另一條是快速回饋的重要性。Hejlsberg 在 64KB 機器時代磨出的直覺是：feedback loop 越短，你學到的東西越多，做的決策越準。TypeScript 的 language service（即時型別檢查、紅色底線、自動補全）本質上就是把 feedback loop 壓縮到打字當下。他認為 AI 最終也會在這個 language service 層帶來很大的變化——「AI 在這塊能做得比現在好太多了。」
TypeScript 的另一個優勢是 12 年的公開 GitHub 歷史。設計討論、被否決的方案、架構上的取捨——全都留在 issue 和 PR 裡，不會埋進 email 或內部系統消失不見。這是 AI 訓練的原料，也是未來維護者最重要的脈絡資源。
但這個建議本身有個前提
「把無聊的事丟給 AI」聽起來很直覺，但背後有個前提沒說出來：你得先能判斷什麼叫無聊、什麼叫關鍵。
Hejlsberg 對語言設計夠熟，所以他很清楚 TypeScript port to Go 的每一行翻譯需要「確定性的輸出」——這才是他判斷 AI 不適合直接翻譯的原因，不是什麼對 AI 的恐懼，是對問題本質的清醒判斷。
同一時間 Microsoft 做了另一個決策：把 .NET 的 deterministic upgrade assistant（Visual Studio 裡那個工具）砍掉，換成 Copilot 版本。開發者社群的反應是直接炸鍋——理由和 Hejlsberg 的案例如出一轍：確定性的工具被機率性的工具取代，出了問題很難追根究柢。
所以 Hejlsberg 這句話背後的邏輯是：先搞清楚你的問題需要確定性的答案、還是「大概對就好」，再決定怎麼用 AI。 需要確定性的，叫 AI 幫你寫一支 deterministic 的程式去跑；只是想快點做完、結果不用完美的，直接叫 AI 做就行。
TypeScript 在 AI 時代為什麼反而更重要
有件事值得留意：AI 工具讓寫程式碼這件事變得更容易了，但 TypeScript 的嚴格型別反而變得更重要，不是更沒必要。
原因在於 AI 生成的程式碼很難追蹤它的意圖——你看不到它怎麼想，你只看得到它吐出來的結果。型別系統在這裡扮演的角色是「把 AI 的意圖鎖進程式碼裡」，讓後來接手的人（和 AI 自己）更容易確認這段程式碼是不是按照預期在跑。GitHub Octoverse 2025 的報告也直接點出：「TypeScript 的 static type system，讓它特別適合 AI-first 的開發流程。」
這是一個語言設計走了 40 年、和 AI 時代意外撞上的故事：TypeScript 當初不是為了 AI 設計的，但它的設計決策——typed superset、漸進式採用、補足而不是取代——讓它在 AI 輔助開發的浪潮裡，反而比任何競爭者站得都穩。
「我們只是想把 JavaScript 壞掉的地方修好。」——這句話是 2012 年說的，卻在 2025 年成為 GitHub 上最多開發者每天依賴的語言背後的邏輯。