TypeScript 之父 Anders Hejlsberg：別折騰“AI新語言”了，真正變天是 IDE 讓位給 Agent

編譯｜宇琪、Tina

過去十年，TypeScript 被很多團(tuán)隊當(dāng)作“工程化 JavaScript”的答案；到了 AI 編程時代，它又意外變成了 AI 最順手的語言之一——原因很簡單：AI 寫代碼的能力基本取決于它見過多少這種語言的代碼，而 TypeScript/JavaScript 恰好是訓(xùn)練語料最豐富的那一檔；更關(guān)鍵的是，TypeScript 還把類型與接口這些“語義線索”明明白白寫在代碼里，正好讓 AI 更容易理解、重構(gòu)和補(bǔ)全。

也正是在這種背景下，微軟在 2025 年 12 月 16 日完成了 TypeScript 史上最激進(jìn)的一次重構(gòu)：用 Go 語言遷移（重寫）編譯器與部分工具鏈，宣稱帶來 10 倍性能飛躍。但消息一出，社區(qū)立刻炸鍋——明明 Rust 才是當(dāng)下重寫系統(tǒng)級工具的“默認(rèn)答案”，為什么偏偏選 Go？

TypeScript 之父、同時也是 Turbo Pascal、Delphi、C# 等語言的核心設(shè)計者 Anders Hejlsberg，在與 GitHub 研究顧問 Eirini Kalliamvakou 的對談中正面回應(yīng)了這些質(zhì)疑：很多人認(rèn)為他們“應(yīng)該選另一門語言”，但他堅持“我們選了最合適的工具，而且過去一年已經(jīng)證明了這一點”。

更有意思的是，Hejlsberg 也談到 AI 在這次遷移中的真實位置：團(tuán)隊曾嘗試讓 AI 直接把 TypeScript 代碼遷移到 Go，“結(jié)果不太理想”，因為他們需要的是五十萬行代碼級別、行為完全一致的確定性遷移；AI 只要偶爾“偏一點”，就會把成本轉(zhuǎn)移到逐行審查上，得不償失。相比之下，讓 AI 去生成遷移工具、以及在遷移之后自動同步舊代碼庫新增的 PR 變更，反而更有效——這部分他們“已經(jīng)相當(dāng)成功”。

同時，Hejlsberg 也明確指出：在“AI 無處不在”的新環(huán)境里，TypeScript 的語言服務(wù)（補(bǔ)全、跳轉(zhuǎn)、重構(gòu)、快速修復(fù)）不會只是原樣搬家，而是在被大幅重塑——因為很多過去必須靠 IDE 才能做的事，AI 將會做得更好。未來真正不確定的也不是 TypeScript 語言本身（它仍沿著 JavaScript 標(biāo)準(zhǔn)化路徑演進(jìn)），而是工具形態(tài)：AI 正從 IDE 的助手變成主要工作者，人類轉(zhuǎn)向監(jiān)督與審閱；這也是為什么把語言服務(wù)接入 MCP 這類機(jī)制會突然變得誘人——讓 AI 能提出語義級問題、發(fā)起重構(gòu)請求，用“智能體方式”完成過去只能在 IDE 里完成的工作流，開發(fā)工具將因此被徹底改寫。

基于該播客視頻，InfoQ 進(jìn)行了部分刪改。

核心觀點如下：

• 通過擴(kuò)展 JavaScript 的能力，我們并非要創(chuàng)造一門全新的語言，而只是想修復(fù)它本身存在的問題。

• 對 AI 來說，“最好的語言”就是它已經(jīng)大量見過的語言，在這個新世界里，全新的編程語言反而處于劣勢。

• 找到那些無聊卻昂貴的事情，把它們交給 AI。

• 工程師的金字塔正在變窄，入門層級的人變少了，而我們需要認(rèn)真思考，如何在這樣的環(huán)境下培養(yǎng)下一代資深工程師。

• 開源本身是一場巨大的實驗，盡管至今沒人真正解決“如何為開源持續(xù)提供資金”這個問題，但它不僅沒有衰退，反而比以往任何時候都更龐大、更活躍。

1 不如直接修 JS：TypeScript 的頓悟時刻

Eirini：從 Turbo Pascal、Delphi、C# 到如今的 TypeScript，你的工作塑造了數(shù)以百萬計開發(fā)者每天寫代碼的方式。

Anders：我第一次接觸計算機(jī)大概是在高中時期，那是 70 年代末，我很快對編程產(chǎn)生了濃厚興趣。后來，隨著 8 位微型計算機(jī)開始出現(xiàn)，我決定自己動手組裝一臺套件機(jī)，并為它編寫大量軟件。我發(fā)現(xiàn)自己在這方面做得相當(dāng)不錯，而且也真的很享受這個過程。那時無論是結(jié)構(gòu)化編程還是匯編語言，對我來說都不成問題。當(dāng)然，還要考慮一個現(xiàn)實條件：只有 64K 內(nèi)存，能塞進(jìn)去的東西非常有限，還得給用戶留出空間，所以當(dāng)時一切都還能裝在腦子里。

Eirini：Turbo Pascal 在很大程度上革新了開發(fā)者體驗，核心在于縮短開發(fā)者的反饋回路。這在多大程度上是你一開始就有意識的設(shè)計理念？

Anders：首先，人們之所以喜歡早期機(jī)器上的 BASIC，很大原因正是它的短反饋周期。BASIC 是解釋型語言，輸入代碼就能立刻運行，但代價是運行速度慢，而且編輯器是基于行的，體驗很糟。相比之下，當(dāng)時的文字處理軟件已經(jīng)是所見即所得的屏幕編輯器，可以自由移動光標(biāo)，這顯然更適合寫代碼。與此同時，“輸入—運行—立刻看到結(jié)果”的模式又非常吸引人。

要在編譯型語言中實現(xiàn)這一點并獲得性能，就必須有極快的編譯器。Turbo Pascal 的做法是：你一按下運行，它立即在內(nèi)存中完成編譯，甚至不需要訪問磁盤，然后直接運行。如果出現(xiàn)錯誤，就立刻回到編輯器。編譯器本身非常原始，你甚至需要通過出錯地址反推源碼位置。但正因如此，突然之間就獲得了一種高度交互的體驗，在當(dāng)時堪稱革命性。

Eirini：那種“編譯要等一個下午”的體驗，會不會讓你感到沮喪？

Anders：當(dāng)然會，沒有人喜歡等待。代碼已經(jīng)寫完了，你只想立刻運行，而不是坐在那里干等。

Eirini：Turbo Pascal 還有一個重要影響，就是以低價讓更多人接觸到編程。回頭看，這一點你有什么感受？

Anders：這里有個有意思的故事。Turbo Pascal 的前身叫 Poly Pascal，是我在丹麥一家小型軟件公司里開發(fā)的 Pascal 編譯器。后來我們聯(lián)系上了 Borland 的創(chuàng)始團(tuán)隊，他們看過之后覺得非常驚艷，提議一起把它作為產(chǎn)品推向美國市場。然后他們決定定價 49.95 美元。我當(dāng)時的反應(yīng)是：“你們瘋了嗎？這樣根本賺不到錢。”事后看來，這個決定非常聰明。雖然價格只有原來的十分之一，但銷量卻高出了三到四個數(shù)量級。最終結(jié)果非常成功，這個功勞主要要歸于 Borland 的創(chuàng)始人 Philippe。

Eirini：Delphi 標(biāo)志著你從獨立創(chuàng)作者向團(tuán)隊領(lǐng)導(dǎo)者的轉(zhuǎn)變。

Anders：一開始我基本上是單打獨斗，雖然在丹麥的 Borland 辦公室也會和兩三個人合作，但隨著機(jī)器性能飛速提升、用戶期望不斷提高，這種模式顯然無法持續(xù)。我必須學(xué)會團(tuán)隊協(xié)作，這在 Turbo Pascal 期間就已經(jīng)開始，而在 Delphi 項目中尤為明顯。

你必須接受事情不會完全按照你個人偏好的方式完成，代碼也不一定長成你心目中的樣子。而且你往往沒有時間親自去“修正”這些細(xì)節(jié)，何況那樣做也未必真的改變產(chǎn)品行為，更重要的是學(xué)會放權(quán)。只有當(dāng)團(tuán)隊成員在各自負(fù)責(zé)的功能和模塊中感到被信任、被賦權(quán)，團(tuán)隊才能真正運轉(zhuǎn)起來。

Eirini：你在 Microsoft 參與 Visual J++ 的經(jīng)歷，對 C# 和 .NET 平臺的目標(biāo)產(chǎn)生了怎樣的影響？

Anders：我是在 1996 年底加入 Microsoft 的，擔(dān)任 Java 開發(fā)工具集的首席架構(gòu)師。我們剛發(fā)布了 Visual J++ 1，本質(zhì)上只是把 C++ 的 IDE 換成 Java 編譯器，談不上真正的集成，更沒有快速的應(yīng)用開發(fā)體驗。于是我們著手改進(jìn)，這最終成為 Visual J++ 6.0，并開始與 Visual Basic、Visual Studio 的版本體系對齊。

如果要為 Microsoft 的 DOS 和 Windows 平臺做 Java，就必須與這些環(huán)境高度互操作。但 Java 當(dāng)時強(qiáng)調(diào)“一次編寫，到處運行”，強(qiáng)制使用最小公分母的 UI 接口，最終只能做出體驗很差的小程序。我們不得不引入一些擴(kuò)展，簡化與原生平臺的互操作，并構(gòu)建封裝 Windows UI 的類庫。很快就發(fā)現(xiàn)，這條路走不通。

如果真正為用戶著想，就必須允許構(gòu)建針對特定環(huán)境的最佳方案。人們既想要 Visual Basic 的易用性，又想要 C++ 的表達(dá)能力。于是我們嘗試把這兩者結(jié)合起來，并構(gòu)建在 .NET 這樣一個可持續(xù)演進(jìn)的平臺之上，最大限度地利用用戶所運行的系統(tǒng)能力，這正是整個構(gòu)想的核心。

Eirini：你既在談不同類型的用戶，又在描述為整個生態(tài)系統(tǒng)服務(wù)的思路，這種整體視角是如何形成的？

Anders：用戶并不在乎這是語言特性、框架特性、平臺能力，還是編輯器或調(diào)試器的問題，對他們來說，一切加在一起才是“體驗”。因此，這些部分必須協(xié)同設(shè)計。

我們構(gòu)建了運行時、JIT 編譯器、垃圾回收器，設(shè)計了平臺的字節(jié)碼，開發(fā)了類庫。我既參與語言設(shè)計，也參與類庫和運行時的設(shè)計，與負(fù)責(zé)這些組件的工程師密切合作，最終效果因此更好。否則，各自為政會形成孤島，最后只能靠復(fù)雜的互操作層勉強(qiáng)拼接，結(jié)果自然談不上“最佳實踐”。

此外，我們也不懼怕與底層平臺深度互操作。過于教條地堅持最小公分母，拒絕利用具體平臺的優(yōu)勢，這樣永遠(yuǎn)不可能做到真正意義上的“最佳體驗”。

Eirini：當(dāng)時是否有某個“頓悟時刻”，讓你意識到 JavaScript 在規(guī)模化發(fā)展中的陣痛已經(jīng)成為必須解決的問題，而且這是一個需要由你、由 Microsoft 來解決的問題？

Anders：行業(yè)里的運行時環(huán)境開始變得足夠成熟，比如 Google 在 V8 上做了非常出色的工作，JavaScript 的運行性能突然變得相當(dāng)可觀。HTML5 也正式定稿，UI 能力大幅提升。同時，手機(jī)、iPad 等各種形態(tài)的設(shè)備出現(xiàn)了，而它們并不運行 Windows。整個行業(yè)突然意識到，真正的平臺競爭不在 Java，而在 JavaScript、瀏覽器和 HTML 上。

于是，人們開始編寫越來越龐大的應(yīng)用，因為新的運行時和 UI 技術(shù)已經(jīng)允許這樣做。但很快大家就發(fā)現(xiàn)，在一種動態(tài)語言里、缺乏成熟工具支持的情況下，這件事難得令人發(fā)指，于是我們看到了各種奇怪的扭曲做法。

其中一個典型案例是 Outlook.com 團(tuán)隊找到我們，主要是 .NET 和 C# 團(tuán)隊，詢問是否可以把他們內(nèi)部的一個叫 Script# 的東西產(chǎn)品化。我當(dāng)時一頭霧水：“Script# 是什么？”他們說，這是一個允許你用 C# 編寫代碼，然后編譯成 JavaScript 來運行的工具。我第一反應(yīng)是：這聽起來像是兩邊的缺點都占全了。

但事實是，這么做的真正原因在于可以獲得“成熟的工具鏈”：類型檢查、團(tuán)隊協(xié)作能力、接口定義，以及對模塊之間交互方式的清晰描述。因為他們有成百上千名程序員參與開發(fā)，不可能只靠裸寫 JavaScript，在沒有檢查、沒有自動補(bǔ)全、沒有重構(gòu)支持的情況下完成工作。

這讓我開始反思：JavaScript 真的已經(jīng)糟糕到這種程度了嗎？而“先寫另一門語言，再把 JavaScript 當(dāng)成中間表示或字節(jié)碼來編譯”，真的是解決問題的最佳方式嗎？如果能直接修復(fù) JavaScript 本身，會發(fā)生什么？于是我們開始探索這條路，事實證明，這個方向效果相當(dāng)不錯。

2 JavaScript 單線程的天花板：我們在浪費 90% 的算力

Eirini：TypeScript 被設(shè)計成 JavaScript 的嚴(yán)格超集，這背后顯然有深思熟慮的戰(zhàn)略考量。你是如何堅持這一決策的？這又能給其他語言設(shè)計者哪些啟示？

Anders：每當(dāng)有人跑來跟我說：“我在考慮做一門全新的編程語言，能解決這個、解決那個”，我給出的第一條建議通常是：這個世界對新編程語言的需求，就像對頭上再多一個洞的需求一樣。

第二條建議是：如果你真的要做一門語言，要意識到其中 90% 的工作，和其他所有語言是完全一樣的，而且這個比例還在不斷上升。如今，程序員的期望早已不只是一個編譯器，你還需要完善的語言服務(wù)，能夠集成到幾乎所有主流 IDE 中，需要能與 AI 交互的 MCP 服務(wù)器，需要調(diào)試器、性能分析工具……

此外，你還得有至少十年的時間，因為一門語言真正站穩(wěn)腳跟、獲得有意義的用戶規(guī)模，往往就是這么長的周期。沒有人會在一開始就擁抱一門全新的語言，頭五年你很可能用戶寥寥，還得不斷回答“我們真的要繼續(xù)投入嗎？”這是一門非常艱難的生意。

通過擴(kuò)展 JavaScript 的能力，我們并非要創(chuàng)造一門全新的語言，而只是想修復(fù)它本身存在的問題。在 Visual Studio Code 里，我們的語言服務(wù)對 TypeScript 和 JavaScript 是同一套。對我們而言，JavaScript 只是沒有類型注解的 TypeScript，或者使用 JSDoc 注解的另一種形式。這意味著我們不是在做兩套東西，而是在同一項投入之上，精確地構(gòu)建真正必要的能力，只為讓整個生態(tài)系統(tǒng)變得更好。

Eirini：2012 年在 GitHub 上啟動 TypeScript 的開源項目，在當(dāng)時的 Microsoft 可以說是一次相當(dāng)激進(jìn)的舉動。

Anders：我們當(dāng)時對 JavaScript 生態(tài)的運作方式、價值觀以及參與社區(qū)所需的前提，其實有著非常清晰的認(rèn)識。大家都明白，如果不開源，這個社區(qū)根本不會理你，一個封閉的商業(yè)產(chǎn)品對他們毫無吸引力。因此，從一開始我們就主張開源。同時，Microsoft 內(nèi)部也逐漸意識到，開源并不是“洪水猛獸”，而是如果想真正與開發(fā)者對話，就必須擁抱的現(xiàn)實。

你剛才提到 2012 年發(fā)布在 GitHub，其實并不準(zhǔn)確。2012 年我們發(fā)布在 CodePlex——Microsoft 自家的、并不太受歡迎的開源平臺上。結(jié)果就是，反響寥寥。那時所謂的“開源”，更多只是把代碼丟到倉庫里，讓大家提 issue，然后我們再把這些 issue 抓回內(nèi)部系統(tǒng)，按內(nèi)部流程處理。某種程度上，這也解釋了為什么幾乎沒人關(guān)注。

再加上當(dāng)時 Microsoft 在開源社區(qū)中的信譽(yù)并不高。真正的“主戰(zhàn)場”在 GitHub。于是 2014 年我們遷移到了 GitHub，全面采用開放式開發(fā)流程。內(nèi)部成員和外部貢獻(xiàn)者遵循完全相同的規(guī)則，所有功能都通過 Pull Request 提交，所有討論都公開進(jìn)行。直到那時，項目才真正開始起飛，社區(qū)的興趣也隨之而來。

Eirini：從“把代碼扔給社區(qū)”到真正的開放式開發(fā)，你們學(xué)到了哪些經(jīng)驗？

Anders：這是一個徹頭徹尾的雙贏。對用戶來說，他們能看到“香腸是怎么做出來的”，所有討論都在公開的 issue 里完成，而不是私下做決定后再給出一個結(jié)果。

對項目開發(fā)者而言，這種方式同樣令人滿足。你每天都能感受到社區(qū)的參與和認(rèn)可，看到點贊、看到討論，遠(yuǎn)比關(guān)起門來做六個月或一年，然后祈禱產(chǎn)品方向正確要有趣得多。在這里，用戶每天都在用投票告訴你他們最想要什么功能，我們只需按票數(shù)排序，就能清楚地知道優(yōu)先級。你解決這些問題，社區(qū)的熱情就會進(jìn)一步增強(qiáng)，形成正向循環(huán)。

Eirini：把 TypeScript 編譯器遷移到 Go 背后的動機(jī)、權(quán)衡以及所面臨的挑戰(zhàn)是什么？

Anders：TypeScript 從一開始就是自托管的，用它自身編寫，這意味著編譯器和整個工具鏈本質(zhì)上都是一個 JavaScript 應(yīng)用。這帶來了很多好處，比如你甚至可以在瀏覽器里運行編譯器，在瀏覽器中構(gòu)建一個完整的 IDE，一切都能正常工作。但隨著 TypeScript 的廣泛采用，以及用戶項目規(guī)模不斷擴(kuò)大，可擴(kuò)展性逐漸成為頭號問題。

這里有 JavaScript 本身的一些內(nèi)在限制。它在設(shè)計上是單線程的，不支持共享內(nèi)存并發(fā)，這意味著你實際上浪費了 90% 的計算能力。此外，JavaScript 的執(zhí)行成本也很高，它的對象模型極為寬松，可以隨意給對象加屬性，這使得優(yōu)化非常困難，底層往往演變成復(fù)雜的哈希查找和緩存機(jī)制，遠(yuǎn)不如原生代碼高效。

所以我們當(dāng)時就清楚，自己正接二連三地白白損失收益。盡管放棄自托管讓人非常不舍，但即便用盡所有優(yōu)化技巧，性能瓶頸依然無法突破。

于是，在 2024 年夏天，我們開始做原型驗證，先從掃描器、解析器這些容易量化的模塊入手。很快就發(fā)現(xiàn)，性能提升可以達(dá)到 10 倍：一半來自原生代碼，一半來自共享內(nèi)存并發(fā)。這樣的提升能把原本需要幾分鐘的事情縮短到十幾秒，完全改變了游戲規(guī)則。

同時，我們也很清楚不想從零重寫一個全新的編譯器。社區(qū)里有不少聲音主張“用 Rust 全部重寫”，但我們認(rèn)為這并不可行。TypeScript 的類型檢查器極其龐大復(fù)雜，許多行為只體現(xiàn)在現(xiàn)有代碼的精確語義中。如果重寫，就會陷入永無止境的差異追趕，最終無法與舊編譯器對齊。

因此我們的目標(biāo)是“遷移”，逐函數(shù)地把同樣的邏輯搬到原生語言中。當(dāng)然，這意味著必須重構(gòu)數(shù)據(jù)結(jié)構(gòu)，因為原生語言不允許像 JavaScript 那樣隨意給對象加屬性。我們嘗試過多種語言，很快排除了 Rust，因為我們的編譯器充滿了循環(huán)數(shù)據(jù)結(jié)構(gòu)，并且高度依賴自動垃圾回收，使用 Rust 等同于重寫。

最終我們選擇了 Go。它在很多方面與 JavaScript 相似，這個選擇對我們來說非常奏效。現(xiàn)在我們擁有了一個原生編譯器，在功能上幾乎是舊編譯器的拷貝，連那些小怪癖都一模一樣，只是快了 10 倍，這意味著社區(qū)不需要推倒重來。當(dāng)我們正式切換時，我相信大家會非常滿意。

3 “最適合 AI 的語言”

Eirini：在 AI 輔助編程的背景下，你認(rèn)為 TypeScript 為什么特別適合 AI 工作流？

Anders：很多人問我，為什么不干脆設(shè)計一門“最適合 AI 的完美編程語言”。我的回答通常是：那樣的語言反而會成為最不適合 AI 的語言，因為它不會出現(xiàn)在 AI 的訓(xùn)練數(shù)據(jù)中。

AI 在某種語言中寫代碼的能力，與它見過這種語言代碼的數(shù)量幾乎成正比，它本質(zhì)上是在大量樣本的基礎(chǔ)上進(jìn)行再組合和外推。AI 已經(jīng)見過海量的 JavaScript、Python 和 TypeScript，因此在這些語言上表現(xiàn)得非常好。對 AI 來說，“最好的語言”就是它已經(jīng)大量見過的語言，在這個新世界里，全新的編程語言反而處于劣勢。

AI 的確正在改變我們構(gòu)建產(chǎn)品的方式。以這次 TypeScript 遷移為例，我們也嘗試過用 AI 自動完成代碼遷移，但效果并不好。一方面那是一年前的 AI，能力還有限；另一方面，遷移五十萬行代碼并保證行為與原代碼完全一致，我們需要的是極其確定性的結(jié)果。AI 在翻譯過程中可能會產(chǎn)生細(xì)微的“幻覺”，而你又不得不逐行檢查，這并不劃算。在這種情況下，更好的方式或許是讓 AI 幫你生成“遷移工具”，而不是直接遷移代碼。

TypeScript 項目中有很大一部分是語言服務(wù)，為 IDE 提供補(bǔ)全、跳轉(zhuǎn)、重構(gòu)和快速修復(fù)。現(xiàn)在我們也在思考：既然 AI 已經(jīng)能在很多場景下做得更好，是否還有必要原樣遷移這些功能？類型檢查器我們完整遷移了，但語言服務(wù)正在被大幅度重塑，以適應(yīng)一個“AI 已經(jīng)無處不在”的新環(huán)境。

Eirini：你如何看待 AI 工具正在改變編程本身，以及語言設(shè)計的方式？

Anders：在理想狀態(tài)下，AI 應(yīng)該幫助我們消除編程中那些繁瑣、重復(fù)的勞動。以 TypeScript 的遷移為例，在我們開發(fā)新代碼庫的同時，舊代碼庫里仍然不斷有新的 Pull Request 出現(xiàn)，我們已經(jīng)相當(dāng)成功地用 AI 把這些變更遷移過來。

再比如，項目里有成千上萬條 issue，其中很多非常古老。它們是否仍然可復(fù)現(xiàn)？是否還相關(guān)？能否根據(jù)社區(qū)反饋排序？這些清理和維護(hù)工作過去總是被一拖再拖，最終卻成為拖慢項目前進(jìn)的“錨”。現(xiàn)在，我們可以構(gòu)建 AI 機(jī)器人來完成這些工作。這是我認(rèn)為非常重要的一點：找到那些無聊卻昂貴的事情，把它們交給 AI。

當(dāng)然，這也帶來新的困惑。如果 AI 取代了初級工程師，我們又該如何培養(yǎng)資深工程師？難道指望 AI 自己成長為“高級程序員”，而人類程序員逐漸消失嗎？我并不這么認(rèn)為。我們似乎正在逼近某種上限：AI 能做很多事，但仍然需要人類以某種監(jiān)督者的角色參與其中。

可以預(yù)見的是，工程師的金字塔正在變窄，入門層級的人變少了，而我們需要認(rèn)真思考，如何在這樣的環(huán)境下培養(yǎng)下一代資深工程師。

Eirini：如果把時間拉長到未來五到十年，在一個更加 AI 原生的世界里，你認(rèn)為 TypeScript 作為一門編程語言會如何演進(jìn)？

Anders：我認(rèn)為它的演進(jìn)方向其實相當(dāng)清晰。JavaScript 已經(jīng)不再是一門年輕的語言，它有一套成熟的標(biāo)準(zhǔn)化流程，而我們也深度參與其中。TypeScript 會沿著 JavaScript 的標(biāo)準(zhǔn)化路徑繼續(xù)發(fā)展，同時在其之上補(bǔ)充必要的類型系統(tǒng)能力。

真正充滿不確定性的，是工具層面的變化。誰能想到，隨著“對話式編程”這類形態(tài)的出現(xiàn)，命令行工具又重新變得如此重要？過去，AI 更多是作為助手存在：開發(fā)者在 IDE 里，AI 幫你更快地輸入和補(bǔ)全代碼。但現(xiàn)在，這種關(guān)系正在反轉(zhuǎn)。AI 開始承擔(dān)主要工作，而人類轉(zhuǎn)向監(jiān)督和審閱。此時，AI 并不一定需要我們傳統(tǒng)意義上的 IDE，盡管它仍然需要語言服務(wù)。

這也是為什么 MCP 這類技術(shù)開始變得有吸引力：通過把語言服務(wù)接入 MCP，讓 AI 能夠提出語義級的問題、重構(gòu)請求等，并在一定的確定性邊界內(nèi)完成工作流。這本質(zhì)上是在用 LLM 或 Agent 的方式，完成過去只能在 IDE 中完成的事情，這將深刻改變開發(fā)工具的形態(tài)。

Eirini：圍繞 TypeScript 或你們的工作，有沒有哪些你希望公開澄清的誤解？或者哪些你覺得被社區(qū)忽視、但其實很重要的事情？

Anders：在開源領(lǐng)域，我們與社區(qū)的距離非常近。如果哪里不對勁、存在摩擦，幾乎會第一時間被反饋出來。比如這次轉(zhuǎn)向原生代碼的決定，確實引發(fā)了不少爭議，有人認(rèn)為我們應(yīng)該選擇另一種編程語言。但我始終堅信，我們?yōu)檫@個目標(biāo)選對了工具。過去一年里，這個決定的成果已經(jīng)逐步顯現(xiàn)。

不過，開源本身就是一種微妙的平衡。一方面，你在無償?shù)匕殉晒唤o世界；另一方面，這個項目往往由一家商業(yè)公司資助，而公司必須以某種方式生存下去。總得有人支付賬單。因此，我們團(tuán)隊始終處在一種張力之中：如何讓開源項目既符合社區(qū)期待，又與公司使命保持一致。這并不是 TypeScript 獨有的問題，而是當(dāng)今幾乎所有開源項目都面臨的現(xiàn)實。至于是否存在一種更好的激勵機(jī)制來回饋長期投入的人，目前還沒有答案。

Eirini：開源的可持續(xù)性，確實是一個反復(fù)被提起的問題。

Anders：大量企業(yè)的正常運轉(zhuǎn)，事實上依賴于那些支撐其后端的開源項目得到持續(xù)維護(hù)。但現(xiàn)實中，很多人對開源的態(tài)度仍然是“索取多于付出”。在微軟，我們至少在努力以一種更真誠的方式參與其中。僅 TypeScript 項目，就已經(jīng)累計投入了數(shù)百人數(shù)年的工作量；而 Visual Studio Code，投入甚至可能達(dá)到上千人。

Eirini：如果不算你自己參與創(chuàng)造的語言，你最敬佩、最尊重哪一門編程語言？

Anders：任何一門能被程序員廣泛使用、甚至能進(jìn)入討論范圍的編程語言，都一定有其可取之處，因此都值得尊重，我深知一門語言要走到這一步有多難。

以 Rust 為例，我非常敬佩它通過借用檢查器來探索一種不同的內(nèi)存管理方式，試圖在不依賴昂貴自動垃圾回收的情況下保證安全性。我也很尊重 Go，盡管它在設(shè)計上有些“怪”，常被認(rèn)為不太正統(tǒng)，但它實際上提供了一種簡單、內(nèi)存安全、類型安全的“現(xiàn)代 C”的思路。至于 Python，它的成功不需要多說，它驅(qū)動著 AI 和機(jī)器學(xué)習(xí)的發(fā)展，令人難以不心生敬意。

從語言設(shè)計者的角度看，我們都站在前人的肩膀之上。如果設(shè)計一門語言卻不向其他語言學(xué)習(xí)，那是愚蠢的。經(jīng)驗與智慧就在那里，理應(yīng)被尊重和繼承。

Eirini：當(dāng)你放眼整個以 GitHub 等協(xié)作平臺為中心的軟件開發(fā)生態(tài)時，是什么讓你對未來保持樂觀？

Anders：僅僅是它依然存在這一事實，就足以讓我感到樂觀。開源本身是一場巨大的實驗，盡管至今沒人真正解決“如何為開源持續(xù)提供資金”這個問題，但它不僅沒有衰退，反而比以往任何時候都更龐大、更活躍。

當(dāng)然，其中也有大量噪音，有不少項目缺乏維護(hù)，但不可否認(rèn)的是，這些代碼記錄了軟件演化的全過程。以我們?yōu)槔D(zhuǎn)向這種協(xié)作工作流后，十二年的歷史都被完整地保存在那里，可搜索、可追溯。如果我記得某個問題曾被討論過，只需要去查找，而不必面對一封再也找不到的舊郵件，這種價值是巨大的。正因如此，我由衷地高興看到它仍在持續(xù)增長，并頑強(qiáng)地存活下來。

https://www.youtube.com/watch?v=uMqx8NNT4xY

https://devclass.com/2026/01/28/typescript-inventor-anders-hejlsberg-ai-is-a-big-regurgitator-of-stuff-someone-has-done/

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實現(xiàn)技術(shù)價值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點，搶占 2026 智能升級發(fā)展先機(jī)！