編譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

近日，TypeScript 與 C# 的發(fā)明者、微軟技術(shù)研究員 Anders Hejlsberg 表示，現(xiàn)有編程語言之所以更適合 AI 編程，并不是因為它們更“先進”，而是因為它們擁有最大的訓練數(shù)據(jù)集。

而對于 AI，他給出了一個直接的評價：

當前的大模型，本質(zhì)上更像是一個“把別人做過的事情重新吐出來，在此基礎(chǔ)上做一些簡單推演”的高級復讀機。

這番表態(tài)來自他與 GitHub 研究顧問 Eirini Kalliamvakou 的一次對談。此次訪談中，Hejlsberg 不僅分享了 TypeScript 團隊內(nèi)部使用 AI 的實際經(jīng)驗，也回顧了 TypeScript 的發(fā)展歷程，并展望了它未來可能的演進方向。

TypeScript 7.0 核心升級：原生編譯器登場，性能提升 10 倍

即將到來的 TypeScript 7.0，最重要的變化之一，是引入原生編譯器。目前該版本已經(jīng)進入預覽階段。

Hejlsberg 表示，原先的 TypeScript 編譯器是用 TypeScript 自己寫的，并運行在 V8 JavaScript 引擎之上。但隨著項目規(guī)模和使用場景不斷擴大，這種實現(xiàn)方式在性能上已經(jīng)明顯吃緊：“我們很快就發(fā)現(xiàn)，原生編譯器能讓性能提升 10 倍——其中一半收益來自原生代碼本身，另一半則源于對共享內(nèi)存并發(fā)特性的充分利用。”

看似“從頭重寫”更干凈，但在 TypeScript 的場景下，這幾乎是不可行的。

Hejlsberg 解釋說，TypeScript 的類型檢查器規(guī)模巨大、邏輯極其復雜，而且存在大量只體現(xiàn)在代碼語義行為中、并沒有文檔化的隱式規(guī)則：

“TypeScript 擁有一個體量龐大、邏輯復雜的類型檢查器，其諸多行為邏輯僅體現(xiàn)在現(xiàn)有代碼的精準語義中，并無其他文檔或形式可完整復刻?！?/blockquote>

如果不是逐函數(shù)、逐邏輯地移植，而是采用“等價實現(xiàn)”的方式，那么哪怕結(jié)果只出現(xiàn)極小差異，都會在用戶遷移時引發(fā)大量長尾問題。所以，這款全新原生編譯器的設計目標非常明確：輸出必須和舊編譯器完全一致，甚至要包括那些歷史遺留的“怪癖”。

語言選型引爭議：棄 Rust、舍 C#，最終選 Go

在為原生編譯器選擇實現(xiàn)語言時，TypeScript 團隊的決定一度引發(fā)了不小的爭議。

Hejlsberg 透露，遷移的技術(shù)需求直接就排除了 Rust：Rust 不支持團隊移植所需要的循環(huán)數(shù)據(jù)結(jié)構(gòu)，同時也沒有自動垃圾回收（GC），而這些在移植過程中是剛需。

團隊最初也對 C# 做了相關(guān)試驗，但最終還是選擇了 Go 語言，因為“Go 與 JavaScript 的語法和設計思路高度相似”。

這一決定讓 C# 社區(qū)倍感不解，不少開發(fā)者質(zhì)疑：

“作為 C# 的發(fā)明者，Hejlsberg 為何不選用你自己設計的語言，順便提升一下 C# 的影響力？”

Hejlsberg 并沒有正面回應這個問題，只是表示：“確實有很多人覺得，我們應該選另一種語言。但我堅信我們選對了工具，過去一年的實踐已經(jīng)證明了這一點?！?/p>

用 AI 做編譯器移植？現(xiàn)實并不理想

在 AI 話題上，Hejlsberg 的態(tài)度同樣相當冷靜。他透露，最初團隊也曾試圖用 AI 完成從 TypeScript 到 Go 的代碼遷移工作，但“效果很不理想”。

他直言，代碼遷移需要絕對確定的輸出結(jié)果——團隊要遷移 50 萬行代碼，且要求新代碼與原代碼的執(zhí)行邏輯完全一致。但如果讓 AI 直接翻譯代碼，輸出內(nèi)容很容易出現(xiàn) “幻覺”，哪怕只是一點點，也意味著你必須逐行人工檢查，反而得不償失。

這個觀點，也與眾多開發(fā)者對微軟 Visual Studio 的吐槽形成了呼應：微軟此前棄用了確定性強的 .NET 升級助手，轉(zhuǎn)而推出基于 Copilot 的升級工具，而后者的非確定性輸出也讓開發(fā)者叫苦不迭。

在 Hejlsberg 看來，AI 在代碼遷移中的正確打開方式，并非直接翻譯代碼，而是“讓 AI 生成輔助遷移的工具程序”：通過 AI 開發(fā)的工具程序，執(zhí)行后能輸出確定的結(jié)果，真正為開發(fā)提效。此外，他也認可 AI 的技術(shù)價值，并表示TypeScript 的語言服務（負責代碼語法檢查、修復建議的核心功能）正在大幅適配 AI 技術(shù)，“在這個場景下，AI 能發(fā)揮出遠超人工的效果”。

與此同時，團隊也找到了 AI 的合適應用場景：在完成原生編譯器的初始遷移后，需要將舊代碼庫中新增的 PR 遷移至 Go 代碼庫——而在這個工作中，“AI 的使用效果相當不錯”。

TypeScript 的未來：語言不會激進更新，但工具鏈會徹底改變

談到 TypeScript 的未來，Hejlsberg 表示，它仍將遵循一貫路線：先跟隨 JavaScript 的標準化進程，再在其之上補充必要的類型系統(tǒng)特性。

作為 JavaScript 的超集，TypeScript 的發(fā)展本身也在反向影響 JavaScript 的標準化進程，因此，不要期待 TypeScript 語言本身出現(xiàn)激進變化——在Hejlsberg看來，TypeScript 未來最大的變革，將發(fā)生在工具鏈層面。

“我曾經(jīng)覺得 IDE 已經(jīng)是終極形態(tài)了，但 AI 的出現(xiàn)，徹底改變了這一切?！痹谒磥?，如今 AI 不再只是 IDE 中的一個輔助插件，反而變成了開發(fā)者需要監(jiān)督的核心工具，甚至“不再需要傳統(tǒng)意義上的 IDE 作為載體”。

但 Hejlsberg 也補充道，AI 工具仍需要語言服務的底層支持，這也是 MCP等機制愈發(fā)重要的原因——將語言服務與 MCP 打通，讓 AI 能夠直接提出語義級、結(jié)構(gòu)級的問題和修改建議。

“AI 需要具備等同于 IDE 能做的那些能力，但要以 LLM 或 Agent 的方式來完成。這將會徹底改變開發(fā)工具的形態(tài)?！?/blockquote>

TypeScript 的誕生：并不是想“發(fā)明一門新語言”，為修復 JavaScript 的痛點而生

最后，在此次完整訪談中，Hejlsberg 還講到了 TypeScript 的起源故事。

這門語言的最初構(gòu)想，來自微軟的 Outlook Web 團隊。彼時該團隊正使用一款名為 Script# 的工具，通過 C# 編寫代碼并編譯為 JavaScript，以實現(xiàn)在瀏覽器中的運行。

Hejlsberg 看到了這一思路的價值，但并未選擇基于 C# 開發(fā)，而是決定打造一款 JavaScript 的類型化超集——他的核心初衷是：“通過擴展 JavaScript 的能力，我們并非要創(chuàng)造一門全新的語言，而只是想修復它本身存在的問題?！?/p>

如今，TypeScript 已躋身主流編程語言之列，但另一方面，微軟將其編譯器從自身語言遷移至 Go 的舉動，也在無形中承認了它在性能層面的物理上限。正如 RedMonk 分析師 Stephen O’Grady 去年的疑問：

“如果一門語言連自己的編譯器都跑不動了，這會不會反過來影響人們對它的看法？”

而這個問題，或許還需要時間來回答。

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

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯(lián)合主辦「2026 奇點智能技術(shù)大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術(shù)大會上海站，我們不見不散！