在全球，智能編程的市場規模預估為百億美元量級。
而在這其中，Julia Liuson 是最為關鍵的人物之一。GitHub、Visual Studio、TypeScript 、Azure 開發者平台……在微軟，你能叫出名字的一切開發者服務項目，幾乎都處於 Julia 的直接管理之下。Anders Hejlsberg、Erich Gamma 等一眾頂尖技術大牛，都在 Julia 的團隊中向其彙報。
加入微軟超過三十年，Julia 不僅深度塑造了微軟的開發者文化，也帶領微軟的相關產品成功跨越週期——GitHub Copilot 成為有史以來第一款由 GenAI 驅動的大型智能編程應用，到了 2025 年 5 月，用户規模已經超過 1500 萬。
編程界最有權勢的“代碼女王”？這是一個數年前誕生自中文互聯網的“古老稱呼”，但到今天為止，依然是對 Julia Liuson 最形象的描述。
在對話開始前，InfoQ 試圖用一個小時的時間，來尋找多個關鍵問題的答案，包括：微軟和 Cursor 關於 C/C++ 插件的授權爭議、微軟內部對於智能編程的思考、微軟大牛如何使用 AI 工作、微軟如何圍繞 AI 面試程序員等。問題很多，時間緊張。
但在對話結束後，我們驚訝的發現，那些令常人難以企及的成績，往往誕生於簡單甚至古樸的思考邏輯。一方面，Julia 及其團隊，多年來堅持着源自微軟早期的技術價值觀毫無動搖，另一方面，又對 GenAI 極為樂觀，提倡“prompt every day”，並期待着全球出現 10 億新興開發者。
Julia 披露，在產品設計問題上，因 AI 發展速度過快，微軟與許多企業一樣，總是“計劃趕不上變化”。更進一步，在 Julia 看來，架構師應該適當放棄對穩定性、可擴展性的設計執念，圍繞 GenAI 的能力提升，不斷地否定和重寫過去的代碼。
對於工程師而言，Julia 認為，面試“刷題”變得越來越不重要，使用 AI 工具的熟練度成為了“必考題”。
點擊鏈接觀看對話視頻
更多與 Julia 的對話內容整理如下，InfoQ 在不改變原意的情況下稍加整理。
InfoQ： 為何限制 Cursor 使用微軟官方插件？
Julia： 有幾件很重要的事情，我覺得要區分一下。開源指的是什麼？開源指的是代碼的開源。大家都知道 Visual Studio 是一個付費產品，發行了很多不同的二進制軟件包，有些是完全通過開源軟件編譯生成的，比方説 TypeScript、 C# 的編譯器，但有些可能包含了閉源內容，是付費產品的一部分。
Visual Studio Code 還有很多插件也是閉源的，要從 Visual Studio Marketplace 來獲取，要遵守相關的服務協議。Visual Studio Marketplace 的服務協議寫得很清楚，相關插件只提供給 Visual Studio 和 Visual Studio Code 使用，不包含任何其他產品。從十幾年前，Visual Studio Marketplace 上線開始，該條協議就沒有改變過。
類似的案例比比皆是，比如 C ++ 的插件不開源； c# 插件有一部分是開源的，有一部分是 閉源的，Python 也是一樣。
所以 cursor 或者 Windsurf，基於開源軟件， fork 一個源代碼分支是沒有問題的。
但它直接在 Visual Studio Marketplace 下載插件，可能還做了二進制補丁，是違反服務協議的。Windsurf 就沒有這麼做，很守規矩。我們歡迎競爭，但希望是良性競爭。
開源和開源軟件的最終實現，是兩回事，源代碼永遠是二進制軟件包的一部分，二者並非 100% 保持一致， 不要把二者混淆在一起。
InfoQ：曾經在微軟 Build 大會上，您預言：未來的開發者，都應該是 AI 開發者。到了今天，預言好像已經變成了現實，開心嗎？
Julia： 哈哈哈，很開心。
InfoQ：和當初的想象，有什麼差異嗎？
Julia： 我覺得，現在的 AI，比我當初想象的 AI ，能力要強太多了。當時的 AI 還像一個小朋友，今天的 AI 完全是顛覆性的。從 GPT 3.5 發佈之後，AI 發生了質的改變，超出了我的想象。我經常跟我的團隊説，以前好像還是馬車時代，現在已經是汽車引擎時代。
InfoQ：智能編程引人矚目，微軟應該也很關注這一領域？
Julia： 應該説，微軟是發起者，GitHub Copilot 是行業內第一個大型 GenAI 智能編程應用。
InfoQ：那麼能否分享一下，過去三年，微軟在設計智能編程產品的過程中，思路上有什麼變化？
Julia： 過去三年，微軟對 AI 的理解變得越來越深。另外，微軟和業界一樣，都覺得計劃趕不上變化。GitHub Copilot 的第一個預覽版，實際上在 2021 年的夏天就推出了。只有一個功能，就是在你做自動補全的時候， AI 跳進來，給你推薦一段代碼。實現這個功能，需要開發者給出提示詞，説明目的，來提升代碼補全的效果。
等到 ChatGPT 出來之後，我們發現，咦，實際上開發者可以和 AI 對話，通過大模型來理解代碼，使得智能編程工具的能力得到很大的提升。所以 GitHub Copilot 是逐步變成今天的樣子。
但當時我做了一個判斷，我覺得，放在今天仍然適用。
很多技術人員寫完代碼之後，覺得非常喜歡自己的代碼，越看越喜歡。讓他把這段代碼幹掉，對他而言，是一個比較困難的事。相當於你在否定他。所以我做了一個預言：就是在 AI 時代，你要不斷否定自己以前寫的代碼。
另外，我們通常比較習慣做大的系統工程。比如 Azure，或者某個操作系統，需要有很強的穩定性。圍繞架構的可擴展性，做很好得設計。但在 AI 時代，當你開始想這些設計性、擴展性的時候，就已經晚了、慢了。
因為 AI 的能力進化得非常快，可能以前需要用某段代碼來解決的問題，過了一週、一個月、兩個月，用大模型就可以自動解決。所以你得不斷去否定、不斷去重寫，不斷去創新，這對很多工程師來説，都是一個新的挑戰，也是一種全新的軟件開發思路。
所以關於 GitHub Copilot， 我們從戰略規劃開始，就想走在 AI 的最前沿，根據大模型的能力，不斷推出新的功能。從最簡單的編程助手，到“agent mode（代理模式）”，未來再到 vibe coding（氛圍編程），給 AI 一個創意，AI 就會幫你實現這段代碼。
當然，表達能力越強，智能編程的效果也會更好。AI 就像一個校招的大學生，對業務完全不瞭解，需要你將需求和背景描述清楚。如果你都説不清楚，那 AI 就更不清楚。很多開發者在自我介紹時，會提到自己比較內向，表達能力不行，但代碼能力還不錯。到了 AI 時代可能就要突破這個短板。
InfoQ：如您所説，該如何看待“AI 越來越強，開發者的重要性在下降”這一觀點？能否給開發者三個建議？
Julia： 可以看看 SWE-bench Verified 榜單，問題解決率最高也只達到 65% 左右。你想想，如果你有一堆系統問題需要解決，但 AI 解決簡單問題的成功率也只有 65% ，説明 AI 還有一些路要走。再比如説 vibe coding，做個小 APP 還好，解決生產級的工程問題，可能就很難。
其中難點在於，AI 不清楚某段代碼的上下文，即使是一個初來乍到的人類工程師，也很難説清楚某段代碼在整個生產線中裏的具體作用。只有對業務全流程有了解，才能理解具體模塊的劃分邏輯。而這也是 AI 接下來會面臨的挑戰。
以前如果要進大廠，開發者就會去刷題。其實在我看來，刷題沒有意義。AI 做題比人類快多了。
但是作為人類，你可以去了解整個業務和生產線，業務的價值與核心矛盾究竟是什麼，用户的訴求是什麼，要解決的問題是什麼。我不覺得當前的 AI 能理解好這些內容。
另外人才是決策者，人和 AI 的協作有點像一個開發經理帶着一羣工程師，對業務的理解才是核心。
所以我給工程師的三個建議是：
- 工程師要去理解“What”，而不是隻是“How”，理解項目的本質和用户的價值，否則就和 AI 區別不大。
- AI 會提出很多種解決方案，工程師要有判斷能力，要有能力做 trade-off。
- 智能編程是個全新的工具，需要學習才能上手，我要求我的團隊要 “prompt every day”，如果一個工程師現在還沒有開始學習 AI 的話，那他是絕對會被淘汰的。
InfoQ：如何理解“AI 原生 IDE” 的概念？
Julia： 我覺得今天我們就是在做 AI 原生 IDE 。所謂 AI 原生 IDE 就是以 agent mode 為主，一些比較激進的公司，會説作為開發者不用寫代碼，先寫個 PRD，寫個業務需求，然後讓 AI 去生成代碼，工程師做 Codereview。項目構建是以單元測試開始的，而不是以寫代碼開始的。
所以現在一些 PM 也不去求工程師寫代碼了，把 PRD 寫出來，然後生成代碼，再讓工程師 Check 一下。
但是相應的代碼審查工作也比較難做，很多公司的測試能力相對較弱，AI 的 agent mode 一下修改了幾百個文檔，如何確保 AI 沒有把業務邏輯改壞了，是需要不斷去研究的。
這反而更考驗架構師、工程師的業務理解能力。
InfoQ：以 GitHub 為例，如何確定產品的核心設計邏輯與更新節奏？
Julia： 我們的邏輯主要是用户需求驅動和企業需求驅動。我們有非常好的用户反饋機制，全球幾千萬用户會源源不斷給我們提供反饋。所以我們很容易理解用户的使用痛點。我們希望能夠幫助開發人員去寫只有你能寫的代碼。把所有浪費時間的問題都解決掉，讓你專注於創新，這是我們做產品的主軸線。
InfoQ：對於高級開發者而言，是這樣的，但如果面向初中級開發者，一些教育公司連基本的招生都比較困難，初中級開發者該如何應對被 AI 替代的焦慮？
Julia： 開發者都是從初級、中級升到高級的，這條路是不可避免，沒有人生下來就是高級開發者，對吧？實際上在 AI 出現之前，在全球至少存在百萬級的開發人才缺口，很多公司想招合格的開發者，但是招不到。而且不管是歐美還是東亞，每年出生的新生兒數量也是在下降的。
所以從另一個角度來看，我們確實需要更多的自動化。
另外剛才我們聊到，一個 PM 可以成為一個開發者，一個分析師也可以成為一個開發者，所以開發者的定義，實際上是在被拓展的。現在的開發者，我們稱其為 professional developer。但各行各業都可以通過 AI 來解決重複性工作，我們希望看到全球有 10 億新興的開發者。
InfoQ：微軟有很多專業開發者，AI 如何影響微軟自己的研發流程嗎？大家的開發狀態出現了哪些變化？
Julia： 變化非常大，每一個公司、每一個行業、每一個角色、每一個流程，都可以想想怎麼用 AI 來增強。
有很多工程師的工作任務是在全球範圍完成大型軟件的部署，經常會碰見各式各樣的問題，需要工程師半夜爬起來，定位在某一個數據中心遇見了什麼樣的問題。實際上類似的問題存在很多共性，我們可以把它做成一個 agent，自動解決。這樣也許我只需要去重啓一下機器，就可以了。不需要把工程師半夜叫醒，這是蠻痛苦的一件事情。
以前類似的問題需要外包、全職工程師配合解決，AI 只能解決其中很小的一部分。後面可能都不需要外包，AI Agent 來解決大部分問題，實在解決不掉的問題由全職工程師來解決。
此外，一些歐美公司的客户支持工作做得很有問題，有時候客服電話甚至是打到印度去的。那麼一些比較激進的公司，就會在客户支持工作上深度集成 AI——他們會將客户知識庫全部買過來，然後 AI 化，收取的服務費逐年下降，接管客户支持工作，保證客户滿意度不下降，可能還會出現上升。
InfoQ：受 AI 影響，招聘規則是否也發生了變化？
Julia： 我們的招聘規則發生了非常大的變化。以前我們做招聘，會先遠程面試。但現在就會擔心，如果面試者用 AI 來回答問題怎麼辦？哈哈哈。
現在我要考你的 AI 工具用得熟不熟練？到了現在這個階段，AI 工具用得還不熟練，我就不找你了。
我們的面試問題也完全不同。我們會更好地考察他的判斷力，看他的解題思路。至於寫代碼測試，相比之下就不是特別重要了。
InfoQ：微軟內部有很多世界級的編程大師，他們的工作狀態發生變化了嗎？他們平時怎樣用 AI ？
Julia： 我現在發現的一個非常有趣的事情是，越是頂尖大牛，越對技術有一種天然的好奇心，他就非常願意去學。一般來説，這種頂尖大牛，AI 用得是最多的。當然了，他們一般也不會把每天的時間都用來寫代碼，他們一般會去做很多探索性質的工作。
比如 Erich Gamma 一開始就在用 GitHub Copilot ，很早就開始關注 Cursor。Typescript 和 Java 是他最熟的編程語言，有一次要寫 Go 語言，他想了想，先去寫了 Typescript ，然後用 AI 重寫成了 Go，這可能是兩年多前的一個案例。
另外一個大牛，因為要解答很多社區問題，就做了一個小程序，每個問題先讓 AI 解答一遍，然後他看一下。如果這個答案好，他就直接採用；如果答的不好，他再重新編一下。
你會發現，頂尖大牛總會想各種各樣的方法來對 AI 進行探索，一直在玩新的技術，不斷思考怎樣用新技術讓生活變得更好。
InfoQ：GitHub 以及相關產品，廣受全球開發者歡迎。在這些產品的研發過程中，微軟如何避免“創新者的窘境”？
Julia： 我們有一些先天優勢。我們應該是全球對開發者領域耕耘最深的企業。“吃自己的狗糧”是我們的信仰，微軟面向開發者的產品，所有的微軟團隊每天都在用，而且會給我們非常“粗暴且直接”的反饋，告訴我們什麼東西好用，什麼東西不好用，這保證我們能把所有的產品做好。如果你是個初創團隊，就不太可能有這麼多用户給你反饋。
InfoQ：採訪開始時，我們提到，Julia 曾圍繞 AI 開發者做出了正確的預言。現在請 Julia 對我們未來的三、五年再做一個預言吧。
Julia： 我現在不敢預言了，AI 時代真的是發展得太快了。如果一定要做個預言的話，我覺得是，如果你不現在開始學習 AI 技術，那麼三、五年後，你是會被淘汰的開發者。
白皮書推薦
開發者們，別掉隊！大語言模型正以前所未有的速度重塑技術格局。微軟最新發布《大語言模型（LLM）上手指南》白皮書，涵蓋 Microsoft Copilot 副駕駛® 在代碼編寫、Debug、創意發想等方面的強大功能詳細解説。
點擊下方鏈接，在角色一欄中填寫“開發者”即可領取專屬開發者的技術文檔。
https://info.microsoft.com/GC-DevOps-WHTPP-FY25-04Apr-02-Getting-Started-with-Large-Language-Models-LLMs-SRGCM14076_LP01-Registration---Form-in-Body.html
