Vibe Coding 在代碼生成與協作中的實踐與思考

演講嘉賓｜向邦宇

編輯｜Kitty

策劃｜QCon 全球軟件開發大會

AI 發展過程中誕生了許多優秀的 Coding 產品，但非專業開發者需要掌握一些簡單的研發知識才能完成研發任務，而這些工具和研發知識的匱乏，都在不同程度上影響非專業開發者的熱情。

本文整理自阿里巴巴高級技術專家向邦宇在 2025 QCon 全球軟件開發大會（上海站）的分享 “Vibe Coding 在代碼生成與協作中的實踐與思考”。主要探討如何構建下一代 Vibe Coding 工具，從阿里當前的挑戰出發，提出以用戶為中心、強化工具質量、深化場景適配、支持協作與包容不確定性的核心設計原則與實踐。

內容亮點

• Vibe Coding 工具在建設過程中遇到的問題，以及解決的辦法

• 構建 Vibe Coding 工具所趟過的產品方面的坑

• 構建 Vibe Coding 工具時的技術創新與落地實踐

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

多年來，我一直在阿里巴巴內部的技術研發設施平臺上從事研發者工具的工作，其中包括內部的 AI 編程工具以及 Web IDE 工具等。從 2023 年開始，我參與了相關工作的轉型，從之前的內部 Copilot 逐步轉向如今的 Agent 方向。

當我拿到這次演講選題時，我在思考 Vibe Coding 這一主題。雖然 Vibe Coding 已經出現幾個月了，但它似乎還不是一個非常確定性的概念，因為大家對它的理解以及所使用的相關工具都存在差異。而我由于接觸了大量內部用戶對這些工具的使用情況，包括他們在使用過程中遇到的問題，以及作為產品提供方，面對眾多用戶在使用工具時所遇到的問題，我需要思考如何解決這些問題。

首先，我會簡單介紹一下我們內部在哪些行業以及具體使用了哪些 Vibe Coding 工具。接著，我會講述用戶在使用 Web 編程工具過程中遇到的一些問題。然后，作為 Vibe Coding 工具的兩位核心主導者之一，我會分享我是如何思考這些問題的。最后，我在之前的許多分享中已經介紹過我們如何使用國產模型以及在適配國產模型過程中遇到的問題。

Vibe Coding 產品形態

目前，Vibe Coding 工具大致可以分為四類。首先是 Native IDE，例如近年來較為流行的 Cursor、Trae，以及我們阿里巴巴的 QCoder 等，它們都以本地集成開發環境的形式存在。第二類是 IDE 插件，比如我們內部的 Aone Copilot 等工具，這些插件大多是基于現有的開發環境，如 VSCode 或 JetBrains 的插件形式存在。目前來看，內部用戶使用這類插件仍是一種比較主流的習慣，盡管其靈活性可能不如 Native IDE 那么高。第三類是 Web Agent，它的入口在瀏覽器上，整個執行過程在一個異步容器中進行，可能是沙箱環境。它可以解決信任問題以及云端執行中的安全問題，并且對于協作更加友好，能夠在 Web Agent 中實現多人同步協作和分享。這類主要是跨平臺工具，具有廣泛的適用性。最后一類是 CLI 命令行工具，這其實是一個比較意外的類別。我們之前并沒有預料到像 Claude Code 這樣的 CLI 工具會如此受歡迎。最初，我們認為這種工具不會受到主流研發人員的歡迎，但后來發現大家其實非常接受這種模式。現在我們認為，CLI 模式在被集成的方式中，比如 CI 或一些異步容器中執行垂直任務時，具有更高的可用性。這就是我對 Vibe Coding 工具大致分類的介紹。

Vibe Coding 在阿里內部的發展現狀

接下來，我主要介紹一下我主導的兩個 Vibe Coding 工具的使用情況。首先是基于 IDE 的 Vibe Coding 工具。我們內部有一個名為 Aone Copilot 的工具，它已經存在多年，擁有眾多用戶，每周大約有數千的活躍用戶。目前，用戶在使用 IDE 的 Vibe Agent 工具時，主要場景包括新增代碼、修復漏洞以及代碼分析等。在后端場景中，這種工具的滲透率相對較高，而在前端場景中，大家可能更傾向于使用 Native IDE，如 Cursor 或 QCoder。

另一個我主導的項目是 Aone Agent。這是一個以外部容器發起的異步任務工具。它強調用戶可以通過自然語言發起任務，我們在異步容器中啟動一個 Agent，這個 Agent 會自行調用各種工具，無論是搜索工具、文件讀取工具還是 Shell 工具。這種在容器內執行的異步 Agent 與前面提到的 IDE Agent 有本質區別。雖然用戶主要是后端人員，但我們發現測試人員、前端人員、算法工程師、產品經理、運營人員、設計師以及運維人員等都在使用這種工具。它的用戶群體更加多元，提交的任務類型也更加豐富多樣，包括代碼分析、代碼修改、單元測試、代碼生成以及文案方案調研等，用戶通過這種工具進行各種探索。

在 Vibe Coding，尤其是 Agent 模式發展之后，我們看到了一些顯著的變化。以 Aone Copilot 的 Agent 模式為例，從 4 月份開始，我們觀察到用戶提交代碼行數的變化。藍色的線表示高頻用戶，即那些經常使用該工具的用戶。我們發現，在 Agent 模式下，這些高頻用戶的代碼提交行數有了顯著提升。雖然整體趨勢都在上升，但高頻用戶的提升更為明顯。從定量角度來看，9 月份高頻用戶每天提交的代碼行數約為 560 行，而其他用戶只有 400 多行。這至少證明了 Agent 模式在提高效率方面是有效的。

我們還發現，不同用戶對這些工具的使用方式有所不同。前 10% 的用戶提交的代碼行數是其他用戶的兩倍。但我認為，Agent 對人的效率提升可能不止兩倍，因為大量的工作可能涉及協作或會議等。我們還發現，TOP 10 用戶的 Token 消耗占總消耗的 80%。在 Vibe Coding 工具的使用下，由 AI 生成的代碼提交占比越來越高。隨著 Vibe Coding 工具的發展，像 JDK 升級、NPM 包升級或 SDK 升級等任務已經可以由 AI 完成，尤其是 JDK 11 及以上版本的升級場景，我們內部幾乎全部交由 Vibe Coding 工具來完成。此外，數據分析和數據整理工作也部分交給了 Agent。過去，一些必須由人工完成的任務，如大促過程中的截圖或壓力測試中的重復任務，現在都可以由 Agent 完成。還有一些在研發過程中成本過高而無法進行的事情，比如一次發布是否會引發其他相關系統的故障，現在也在探索使用 Agent 來解決。過去，由于無法審查每一行代碼對其他系統的影響，這類問題很難處理，但如今 Agent 可以承擔這項任務。

用戶在 Vibe Coding 過程中遇到的挑戰

在審視當前技術發展現狀時，從用戶的角度來看，技術和產品都面臨著一些亟待解決的問題。首先，用戶常常因為 AI 的表現不盡如人意而感到沮喪。從后臺日志中，我們可以看到大量用戶抱怨“電腦太笨了”等類似的不滿情緒，這些反饋充滿了挫敗感。同時，用戶頻繁地刪除和修改代碼的現象也屢見不鮮。無論是公司內部還是在社區中，都存在許多用戶因 Agent 能力不足而陷入困境的情況。此前，甚至有用戶在 GitHub 上分享關于 AI 的“八榮八恥”提示詞，其中不乏諸如“以不修改原始代碼為榮”等觀點。

綜合來看，Vibe Coding 工具給用戶帶來的問題主要體現在以下幾個方面。首先是代碼質量問題，生成的代碼往往缺乏質量把控。其次是調試和維護困難，這給用戶帶來了額外的負擔。第三是用戶體驗不佳，目前的 AI 編程工具尚未達到讓用戶滿意的程度。最后是成本與效率問題，這些問題也在一定程度上影響了工具的使用效果。

我認為代碼質量不足主要體現在幾個方面。首先是代碼一致性不足。在不同場景下，生成代碼的質量和風格存在較大差異。例如，在存量代碼倉庫中編寫代碼時，AI 往往會按照自己的風格生成代碼，這與現有代碼風格不一致。其次，邊界條件的處理不夠完善。對于復雜業務邏輯的邊界情況，AI 生成的代碼往往處理得不夠充分。此外，生成的代碼還存在性能缺失的問題。最后，安全漏洞問題尤為突出，尤其是 SQL 注入類漏洞。斯坦福大學的一項研究指出，AI 生成的代碼中存在注入類漏洞的比例約為 45%。

在實際應用中，我們發現了一些典型案例。首先是安全漏洞，包括 SQL 注入和 XSS 攻擊。其次是在邊界邏輯處理方面，邏輯錯誤和邊界條件處理不當的情況較為常見，例如空指針異常和數組越界等問題，這些都是我們在用戶使用過程中觀察到的現象。

我們發現 AI 在代碼生成過程中存在自洽問題。過去，我們曾考慮讓 AI 生成代碼的同時，也生成對應的單元測試，以此來解決代碼質量問題。然而，我們很快發現，如果讓 AI 同時負責代碼邏輯和單元測試的生成，它無法保證質量，因為 AI 會在邏輯上進行自洽。例如，下圖展示的一段數組去重函數及其對應的測試代碼，雖然測試通過率達到了 100%，但其邏輯實際上是存在問題的。這說明，如果完全依賴 AI 來完成代碼和測試，很容易出現自我擬合的情況。因此，我們建議用戶在使用 AI 生成代碼時，至少有一項由人工進行 Review 或主導，以確保質量

在用戶使用 Vibe Coding 工具的過程中，我們還發現調試時間增加了 30% 到 50%。這是因為 Vibe Coding 更傾向于生成黑盒代碼邏輯，盡管最終會讓人確認代碼的差異（DIFF）后才能提交，但生成過程和代碼本身通常不會被逐條仔細檢查。因此，我們將其視為一種黑盒操作，AI 生成代碼就像一種“黑魔法”，一旦出現問題，用戶可能不知道從何處入手，技術債務也會不斷累積。

另一個問題是上下文理解的局限性。對于存量任務，其業務邏輯往往是經過多年積累形成的，一些代碼為何如此編寫，是否可以刪除等問題，對于 Agent 來說都是難題。我們認為，Vibe Coding 工具缺乏全局思維，生成的代碼模塊化程度不足，代碼耦合度較高。為了解決這一問題，目前有一些方案，例如 Repo Wiki 或 Deep Wiki 等。

此外，Vibe Coding 缺乏可追溯性，這限制了工具的使用。由于 Vibe Coding 一次性生成大量代碼，我們很難確定是新的需求導致代碼出錯，還是最初生成時就存在錯誤。因此，如何引入版本管理的概念，以便在代碼出錯后能夠回滾到正確狀態，是一個亟待解決的問題。目前有一些方法，例如在每次修改并通過測試后提交一個 Commit，以便后續能夠從該 Commit 回滾。也有一些工具，如 Cursor 或其他回滾工具，但總體而言，Vibe Coding 在可追溯性方面仍有不足。用戶在生成大量代碼或經過多次迭代后，往往無法進行有效的版本管理，只能選擇回滾或重新開始。

目前 Vibe Coding 工具還無法像人類開發者那樣熟練運用常見的調試工具。在過去傳統的編程模式中，開發者們常常會大量使用調試工具，例如在代碼中設置斷點，或者在瀏覽器中進行調試。然而，對于 Vibe Coding 工具來說，要利用這些調試工具來定位問題的堆棧信息，幾乎是不可能完成的任務。那么，Vibe Coding 工具是如何應對這種情況的呢？它們通常會通過大量打印日志（如 console log）來解決問題。它們要求用戶在執行代碼后，將控制臺中的報錯信息或打印內容復制并粘貼給工具，以便進一步分析。這種模式不僅需要人工介入，而且效率低下。因此，我認為大型模型的調試手段相對單一，傳統的調試方法很難被這些模型有效利用。

從用戶使用 Vibe Coding 工具的角度來看，除了編碼層面的問題外，工具本身也存在諸多不足。首先，穩定性和成功率是最大的問題之一。Vibe Coding 工具的執行時間往往較長，用戶可能需要等待 30 秒到 5 分鐘才能得到結果，而且并非每次都能成功。失敗的原因可能是模型返回錯誤、工具調用出錯，或者 IDE 本身不穩定等。一些用戶在初次使用后，發現結果不穩定，尤其是在時間緊迫、任務繁重的情況下，他們就不再愿意使用這類工具。

其次，交互界面設計也存在一些問題。這并非缺陷，而是因為許多 Vibe Coding 工具頻繁改版，導致用戶難以找到以前的功能，或者工具中不斷增加新功能，使得用戶感到困惑。以 Devin 為例，它在改版過程中，曾經引入了劇本、MCP 市場和知識庫等功能，但后來又取消了。這種頻繁的改版讓用戶難以適應。

第三，溝通和交互存在障礙，主要表現為 AI 的理解能力不足。用戶需要反復確認意圖，尤其是在不同場景下，這種確認雖然有意義，但也增加了溝通成本。例如，在最近流行的 Spark Coding 中，用戶先提出需求，生成設計稿，再讓 Agent 執行。對于復雜的任務，這種模式可能是必要的，但對于其他任務，可能需要 Agent 自由探索。此外，長鏈路任務的執行能力也存在不足，無法維持長期的上下文對話。由于 Agent 大模型的 Token 有上限，當上下文過長時，其記憶和召回能力就會下降。

最后，工程工作流程的中斷也是一個問題。目前有大量 Vibe Coding 工具，包括 IDE、CLI 和 Web Agent 等，每種工具都有其擅長的領域，但它們無法讓用戶在一個統一的流程或上下文中解決問題。例如，用戶在 IDE 中完成一項任務后，如果切換到 CLI，就需要重新向新的 Agent 介紹需求。這種頻繁切換不僅增加了用戶的負擔，也降低了工作效率。

Vibe Coding 產品自身遇到的挑戰

隨著 Agent 和模型能力的不斷提升，產品功能也在不斷演進。從最初的單代碼補全場景，單個任務 4000 個 Token，到后來的 Chat 模式，單個任務 1000 個 Token，輸出約為 4000 個 Token。再到 IDE 或 CLI 模式，Token 消耗量達到十萬級別。如今，Web Agent 模式具備獨立容器，能夠廣泛使用各種工具，實現多種任務類型的 Agent 模式，Token 消耗量更是達到百萬級別。像 Cursor、Trae 等 Native IDE 工具正在探索 Sub-Agent 或 Multi-Agent 架構，單個任務的 Token 消耗量甚至可能達到上億級別。這種演進模式雖然為用戶提供了更強大的功能，但也給產品設計帶來了挑戰。一方面，我們需要讓用戶滿意，另一方面，成本控制必須與用戶規模相匹配。

在產品設計方面，Vibe Coding 工具，無論是 IDE Agent 還是 Web Agent，都處于摸索階段。盡管模型能力的提升推動了產品功能的不斷變化，但產品界面的區分度卻不夠。例如，Chat、Deep Research、Agent 等產品都采用對話框形式，用戶難以區分不同產品的功能差異。此外，用戶缺乏引導，面對 Vibe Coding 的對話框，用戶往往不知道該輸入什么內容。不同工具適用于不同場景，但用戶常常一刀切地認為某個產品應該滿足他們的需求，然而在實際使用中，他們發現產品無法達到預期目標。這不僅增加了用戶的學習成本，也降低了產品的使用頻次。我們觀察到，像 Devin 這樣的 Web Agent 工具，留存率非常低，這反映出用戶在使用過程中遇到的諸多問題。另一個問題是缺乏一站式的功能閉環。用戶面臨的不僅僅是代碼編寫問題，還包括發布、部署、調試等多方面的問題。目前的 Vibe Coding 工具無法在一個產品中同時解決不同難度問題。比如，初學者可能需要更多指導和簡化功能，而復雜問題則需要更強大的工具支持。這種功能上的割裂導致用戶在使用過程中需要頻繁切換工具，增加了使用成本和學習難度。

Vibe Coding 工具的安全性問題值得我們高度關注。可能大家有所耳聞，例如 Cursor 曾出現過刪除用戶本地代碼的情況，雖然這類事件相對較少，但今年已經發生了好幾次。另一個案例是 Anthropic 的 Claude Code 被劫持，攻擊者利用 Vibe Coding 工具在用戶網絡中探測漏洞，并編寫代碼將敏感信息暴露出來。

在內網環境中，我們可能還無法完全信任 Vibe Coding 工具。當前，供應鏈攻擊和開源代碼的發展帶來了新的挑戰。許多人會在開源社區中潛入木馬，一旦我們稍不留意，拉取的 SDK 或代碼可能本身就存在漏洞。Vibe Coding 工具由于對代碼或當前電腦具有一定的控制能力，能夠進行自由探索，可能會發現系統中的漏洞并加以利用。因此，我們在使用 Vibe Coding 工具時，必須謹慎對待其安全性問題，確保在安全的環境中使用，并對工具的權限進行嚴格管理。

Agent 建設過程中的一些經驗

在參與 Agent 建設的過程中，我積累了一些經驗，這些經驗對我們后續的工作有著重要的啟示。

最初，我們采用了一種 All In One 架構，這種架構在建設 Vibe Agent 時帶來了諸多問題。當時，Vibe Agent 的核心是一個輸入框，圍繞這個輸入框的是 MCP 工具、知識庫（Knowledge）以及各種劇本（Playbook）。這些外圍工具構成了一個完整的場景圖，涵蓋了數據處理、后端開發、前端開發、代碼審查、風險管理等多個方面。在這種架構下，所有工具和知識都需要放入上下文中，導致上下文內容異常龐大，成本難以壓縮。例如，當時我們使用 Claude 模型執行一個任務，成本高達幾百元，這顯然是不可持續的。

此外，這種 All In One 架構還導致任務成功率較低。當所有工具和知識集中在一起時，上下文過長，消耗大量 Token，不僅增加了成本，還降低了任務執行的效率。更重要的是，這種架構難以針對不同場景進行優化。例如，當我們對比其他類似產品時，我們的 Vibe Agent 在前端場景上的表現卻不盡如人意。這說明，我們的架構缺乏靈活性，無法根據不同場景進行針對性的調整和優化。

在后續的 Agent 建設過程中，我們采取了一系列措施來優化工具的性能和用戶體驗。首先，我們對知識和數據進行了調整，特別是在代碼數據建設方面，通過構建 Repo Wiki 和 Embedding 數據庫，提升了對整體代碼庫的搜索理解和搜索能力。此外，我們還將研發行為數據納入考量，包括構建 CI、CR、發布監控等行為。由于我們依托的是集團內部的發布平臺和代碼平臺，因此能夠將代碼數據與需求數據相結合，形成一個綜合的數據體系。

我們意識到，傳統的文檔知識庫難以直接被 Agent 使用，原因在于這些知識庫可能存在信息過時、前后矛盾、圖文混雜以及錯誤信息等問題。這些問題如果直接傳遞給 Agent，可能會導致誤導。因此，我們沒有采用傳統的 RAG 技術，而是通過建立一個中間層來處理面向 Agent 的數據協議，從而解決文檔知識庫的引入問題。

在 Agent 的建設過程中，我們還發現很多知識并不在文檔或代碼中，而是存在于開發者的頭腦中。因此，我們思考如何設計一個產品，幫助用戶將這些知識沉淀下來。這并非通過自動生成實現，而是需要用戶主動參與編寫。

在上下文記憶方面，我們進行了大量處理工作，包括寫入、提取、壓縮和隔離等操作。我們的 Agent 工具旨在滿足大多數用戶的需求。為此，我們在容器中集成了大量工具，涵蓋任務管理、基本交互、文件操作（讀寫、編輯、管理）、命令行執行監控等功能。由于 Agent 可以執行命令行，對于一些耗時較長的命令，我們需要監聽其執行結果，并在超時后進行中斷處理。

我們還加入了瀏覽器自動化工具，例如使用 Playwright 等工具進行網頁操作，幫助用戶完成登錄等交互任務。同時，我們還集成了多媒體開發工具，支持用戶將代碼部署到特定環境進行調試。在協作方面，我們設計了團隊協作功能，用戶可以將任務分享給他人，基于任務繼續協作。我們還加入了高級功能，如并行執行優化和網絡搜索等

在面對模板和成本過高的問題時，我們采取了一系列措施來優化和解決。最初，我們發現單個任務的 Token 消耗量接近 400 萬到 1000 萬，這是一個極為嚴重的問題。為了降低 Token 成本，我們進行了一些操作和設計調整。

積極適配和擁抱國產開源模型

在探討為何要解決成本問題時，我相信從事相關工作的人都能理解其重要性。實際上，解決成本問題的另一個重要方向是積極擁抱國產開源模型。然而，國產開源模型并非針對我們的具體場景進行訓練，因此仍存在諸多問題。

使用國外的 SOTA 閉源模型也存在諸多風險。首先，這類模型非常昂貴，尤其是處理復雜問題時，需要在長鏈路任務中運行，成本極高。其次，隱私問題不容忽視，閉源模型可能存在合規風險。第三，我們還發現了被限流和性能下降的問題，即使是同一模型、同一供應商，在不同時間的表現也可能不同，有時會出現格式錯誤或陷入死循環等問題。最后，國外模型在面向 C 端用戶時，可能還存在備案等額外問題。

相比之下，國產模型在短鏈任務中表現良好，但在長鏈任務中仍存在一些問題。例如，死循環問題較為常見，因為 Agent 有多種選擇和入口，可能在執行過程中陷入某種循環，無法跳出。另一個問題是格式遵循能力不足，例如 XML 標簽格式不準確，前后無法匹配，導致無法正確解析，容易失敗。此外，還存在指令遵循問題，在處理大量 Token 的上下文時，模型可能忘記某些指令，尤其是在未被充分訓練的情況下。最后，我們還發現全局智能方面存在缺陷，模型容易陷入“走一步看一步”的情況，導致 Token 消耗大，步驟時間長。

為了應對這些問題，我們采取了一系列措施。首先，針對穩定性問題，我們設計了主備模型切換和重試機制。其次，為了解決速度慢或 Infra 穩定性問題，當模型輸出被截斷時，我們引入了流式輸出和續寫設計。此外，我們還進行了健康檢查和死循環檢測，在 Agent 中針對重復執行指令或相同錯誤點的無限循環問題進行了優化。當檢測到明顯錯誤邏輯時，我們能夠及時干預。同時，我們還進行了格式檢查和修復，針對模型生成的 XML 標簽格式錯誤，通過堆棧或自動補齊方式解決格式缺失問題。

目前，我們已經將所有國外模型替換為國產模型。在運行過程中，我們會實時檢測任務是否進入死循環，一旦發現，會采取干預措施，例如截斷后續任務執行，或對任務進行總結和壓縮，使其能夠繼續執行。這些措施都是我們在上下文管理方面的探索和實踐。

在思考如何提升產品用戶體驗和降低使用成本時，我發現了一個核心問題：普通用戶甚至小白用戶在使用我們的產品時，往往不清楚產品能做什么。即便他們知道自己需要什么，也難以準確地提出需求，不知道如何在產品中選擇合適的工具或知識。這導致產品的任務成功率很低，同時 Token 消耗量卻很大。

為了解決這些問題，我考慮是否可以將一些已經成功完成的垂直任務進行抽象和模板化。例如，如果某個任務經過多次探索后成功完成且用戶非常滿意，我們能否將其經驗抽象出來，形成一套標準化的模板？通過這種方式，我們可以針對不同的垂直場景不斷積累模板，從而提高任務的成功率，降低 Token 消耗。當用戶面對對話框時，模板也能提供一定的引導性，幫助他們更好地使用產品。

在模板設計方面，這些模板可以被理解為工具組合和知識組合的集合。有了模板后，用戶在使用對話框時可以先選擇一個模板，這大大提高了任務的完成率。目前，大約有 50% 的用戶任務都使用了模板，任務完成率提高到了 95% 以上。通過固化 Prompt、工具和知識，形成模板后，用戶在下次生成或執行任務時可以先選擇模板，再進行具體操作。

Manus 1.5 提出了一個新概念：Agent 也是一種工具。這意味著我們可以將 Agent 視為一個工具，例如一個專門用于深度調研的工具，它可以獨立完成網頁搜索和內容總結。這樣，主 Agent 只需要調用這個工具即可，從而將部分任務抽象化，形成一個工具。從最初的“函數即工具”，到“LLM 即工具”，再到現在的“Agent 即工具”，我們將所有任務都視為子任務，通過工具化的方式進行處理。

以上內容是我關于產品和用戶體驗方面的分享。實際上，我們的工作不僅局限于內部，也已經向外部用戶開放使用。未來，我們還將進一步把內部的技術成果開放給社區，以促進更廣泛的交流與合作。

演講嘉賓介紹

向邦宇，阿里巴巴代碼平臺負責人，在代碼管理、代碼結構化數據處理、代碼搜索、代碼評審以及編輯器技術等領域擁有豐富的專業知識和實踐經驗。在阿里，負責了包括 CloudIDE、代碼搜索、CodeReview 等多個關鍵產品的開發與管理，成功引領了代碼智能平臺的建設與發展。他主導實現的阿里內部多個 AI Coding 工具，包括 Aone Copilot 和 Aone Agent 等，在阿里內部被廣泛使用。他還主導開發了 AI Development 產品“搭叩”。

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續的「Value From AI」。從前沿技術雷達、架構設計與數據底座、效能與成本、產品與交互、可信落地、研發組織進化六大維度，系統性展開深度探索。QCon 北京 2026，邀你一起，站在拐點之上。