作者：NCL
編輯：Siqi
排版：Scout
在《AI Agent 的千億美金問題》一文中，我們提出，目前 Agent 實踐中，Code Agent 最有可能快速落地，作為開發流程中覆蓋最廣的工具，IDE（Integrated Development Environment）不僅是開發者的超級入口，也有機會完整地收集到測試、環境配置和 Debug 等環節的複雜推理過程的重要數據信息，因此，是最有機會、最早能夠出現 Coding Agent 的場景。
Excel 的出現讓資料庫使用變得「民主化」，通過更加友好的界面、內置圖表公式等工具，讓非技術用戶也能輕鬆進行數據的存儲、管理和分析。我們相信，在 LLM 的推動下，軟體行業也會迎來「Excel 時刻」：LLM 融入 IDE 後，入門級開發者甚至非技術背景用戶也能夠更好更快地實現程序編寫，用戶在代碼編寫中調用各種 LLM-based 服務、Code Agents 就像在 Excel 里用使用公式一樣簡單。
因為流量和產品先發優勢，IDE 目前幾乎是被 Visual Studio 和 Github Copolit 聯盟所壟斷，Tabnine 、Codeium、Cursor 以及 CodeWhisperer 等 LLM-first IDE 團隊則試圖基於 LLM 提供更具差異化的用戶體驗挑戰突破 Visual Studio 和 GitHub Copilot 「統治」，這些差異化功能的實踐是 Code Agents 的試驗田。
因為模型能力層面上的拉平，挑戰者們中短期內想要突破 VSCode 和 Github Copolit 市場佔領的難度極高， LLM-first IDE 賽道當下最核心的價值在於 LLM Agents 的實踐，我們相信，在賽道的充分競爭中，Code Agnets 生態一定會不斷豐富，值得保持長期關注。
以下為本文目錄，建議結合要點進行針對性閱讀。
👇
01 為什麼關注這個賽道
02 現狀：微軟帝國的裂痕
03 挑戰者：LLM 新浪潮下的暗流
04 結論
01. 為什麼關注這個賽道
我們在《AI Agent 的千億美金問題》一文中做出判斷，目前 Agent 實踐中，Coding Agent 最值得期待，不僅最有可能快速落地，且有很大潛力成為人類所有 Agent 交互中的「翻譯官」。作為開發流程中覆蓋最廣的工具，IDE（Integrated Development Environment）不僅是開發者的超級入口，也有機會完整地收集到測試、環境配置和 Debug 等環節的複雜推理過程的重要數據信息，因此，我們認為 IDE 是最有機會、最早能夠出現 Coding Agent 的場景。與此同時，我們也觀察到，一批 LLM-first IDE 公司試圖基於 LLM 提供更具差異化的用戶體驗，去挑戰過去被 Visual Studio 和 GitHub Copilot 「統治」的 IDE 。
趨勢一：IDE 是開發者的超級入口，LLM 為 IDE 的商業化帶來新機遇
IDE 是開發者的超級入口。大多數 DevOps 的使用都需要先在 IDE 中編寫、Debug 後，再提交到各類 DevOps 里進行各種自動化和集成，包括測試、部署和監控等流程。以測試為例，傳統測試中需要人力撰寫多種測試代碼和環境，這通常在 IDE 中完成；其中重複性高的部分已被 AtomicJar 等 DevOps 公司抽象化，還能自動為客戶提供測試圖表和報告。
DevOps 的市場初具規模，而作為超級入口的 IDE 卻商業化堪憂。根據 Global Market Insights 和 Markets and Markets 的研究數據， 2022 年，全球 DevOps 總收入規模在 80-100 億美元左右，並正以每年 20-30% 的增速增長，而作為超級入口的 IDE 卻商業化堪憂，主要原因是市佔率佔比最大的 Visual Studio 堅持開源和免費路線，VS 的免費策略讓大部分競對只能被動跟隨、難以開展商業化，整個賽道中幾乎只有 Jetbrains 能獲得較可觀的收入，通過 Pycharm 和 IntelliJ 兩款明星產品，Jetbrain 吃下了 IDE 市場 18% 份額, 2022 年營收規模為 4.9 億美元左右。可以看出作為超級入口的 IDE 占整個 DevOps 的份額並不大，面臨商業化能力疲軟的局面。（拾象註：份額估算部分參考了 Top IDE Index ，該網站在 Google 的搜索頻率基礎上來推理出各家份額，也有觀點認為 VS 系列產品的市佔率在 70%，但該數據引用可靠度偏低，暫不採用。)
💡
Jetbarins 創立於 2000 年，旗下擁有一系列 IDE 工具，其中最出名的 IntelliJ 和 PyCharm 分別為 Java 和 Python 開發設計的 IDE 產品，Jetbarins 的商業化主要來自 IDE 工具及商店抽成。
而 LLM 的到來也許會為 IDE 這一超級流量入口帶來新的商業化途徑、改善 IDE 商業化現狀。文本場景入口的 Notion 通過 Notion AI 僅用短短几個月的時間便成功實現了數百萬美元的 ARR ；Google Workspace 最初依賴廉價的雲盤空間作為商業化方式，而如今則有望通過 Bard 的增值服務提高這數億用戶產品的收益潛力；此外，微軟通過將 GitHub Copilot 引入 VSCode 這一龐大的開發者渠道，在產品正式上線的 18 個月內，就實現了 1 億美元 ARR。
趨勢二：IDE 是探索 LLM 複雜推理能力的最好場景，LLM 能力邊界逐步從代碼補全滲透到代碼重構、測試、Debug 和分析等高價值環節。
GitHub Copiliot X 引入 GPT-4 後，由於能為模型提供更完整的代碼、環境和反饋信息，不少用戶認為，類 Copilot 在代碼重構、測試、Debug 和分析等高價值環節有很大的潛力。Github Copilot 在 2021 年 10 月初次推出的時，其能力是基於 120 億參數量的 OpenAI Codex 模型，擅長以較低延遲推理出質量不錯的代碼，尤其適合代碼自動補齊功能，到今年 3 月，Github 推出的 Copilot X 則引入了 1.8 萬億參數的 GPT-4，在 GPT-4 的支持下，用戶將代碼、環境和反饋信息結合指令輸入後，模型能在開發過程中的各個子環節都有亮眼的表現，Copilot X 從初代的代碼自動補齊滲透到更多開發環節中。
早期 Copilot 採用的 Codex 只能覆蓋屬於只能覆蓋 Code 和 Create 部分需求，而這類需求只佔到預算份額的 3.8%，而隨著 GPT-4 等更強力模型的發布，其能力能逐步滲透到整個內容工具 18%。DevOps 可以簡單拆分成流程工具和內容工具，流程工具主要用於自動化和優化軟體開發和部署的過程，內容工具主要用於生成文檔、任務、報告或圖片等內容。Redpoint 的合伙人 Sai Senthilkumar 調研了 60 位來自有 500 位員工以上的中大型公司的 DevOps 負責人，對各個類型 DevOps 的預算份額進行總結（如下表）。隨著 GPT-4 等後繼新模型的能力增強，配合上 LLM 應用的演化，我們預計傳統內容工具背後的演算法將逐步被 GPT 模型這樣的通用模型替代、覆蓋改板塊 18% 的預算份額。
Source: Redpoint Partner Sai Senthilkumar
趨勢三：軟體開發將迎來「Excel 時刻」，而 IDE 則是巨變的關鍵入口
當 LLM 能力迅速迭代不斷降低開發門檻，我們一定會迎來開發者數量的迅速增長。知名的開發者社區 Stackoverflow 在 ChatGPT 推出後，首當其衝地受到衝擊、流量明顯下滑，除了 ChatGPT 之外，LLM-first IDE 也正替代 Stackoverflow、甚至提供比 Stackoverflow 更好的開發體驗，更是成為 LLM 正逐漸成為新手開發者學習和糾錯的首選工具。真正的學習通常需要犯下大量的錯誤並從中吸取經驗，而 LLM 以其卓越的能力，幫助新手深入理解編程概念，提供實時的建議和指導，助力他們戰勝編程學習過程中的挑戰和困惑。此外，Github 也發現代碼新手更容易接受 Copilot 的建議（如下圖），他們將顯著受益於 LLM 的普及。
Excel 是資料庫使用的「民主化」。和需要專業編程知識和複雜查詢語言的資料庫相比，Excel 首先提供了一個用戶友好的界面，使得非技術用戶也能輕鬆進行數據的存儲、管理和分析，其次，在處理小規模數據時，Excel 的內置圖表、公式等數據分析工具極大地簡化了數據處理過程。雖然資料庫在處理大規模、複雜數據時更具優勢，如更高的處理效率和數據安全性，但 Excel 在財務分析、小型項目管理等場景中仍顯示出其獨特的適用性。
我們認為，在 LLM 的推動下，軟體行業也會迎來類似於「Excel 時刻」的轉變。毫無疑問， IDE 充當的正是一個用戶友好的「界面」，在 LLM 的輔助下，各行業的非技術人群能為自己的工作編寫小程序，調用 LLM 功能、Code Agents 就像如今人們在 Excel 里用使用公式一樣簡單。
趨勢四：輕量程序的開發流程再革新，對需求描述和測試的 AI Agents 市場將湧現，而 IDE 有望成為 Agents 的分發平台
傳統的開發流程是編碼完成後再進行測試，這一流程意味著開發人員直到項目晚期才會發現漏洞，也因此漏洞帶來的影響範圍、解決漏洞的成本相應提升，近年流行的 TDD(Test-Driven Development) 則在項目早期就花大量精力設計測試，確保每個功能從一開始就經過嚴格測試，從而保證複雜的長期項目更穩定。
但在相對輕量的編程程序中，開發者們通常偏好直接編碼，在這一過程中，LLM 則可以用於輔助生成需求描述和測試，以確保再使用的上手簡易性和穩定性。比如，大部分人在使用 Excel 公式功能時，都通常不會為公式編寫詳盡的說明，這造成了再次使用時的摩擦；更不會寫詳盡的測試案例，導致報表有時會因為數據類型等問題報錯。
編程的高複雜度會帶來巨大的再使用摩擦和穩定性考量，湧入的編程新手意味著對 LLM Agents 的海量需求，IDE 則能成為 Agents 的分發平台。由於輕量軟體所涉及的編程語言和代碼庫遠複雜於 Excel 公式語法，這意味著巨大的再使用摩擦和穩定性難題，畢竟同樣的代碼在切換電腦時報錯是極為常見的問題。這就需要 LLM Agents 的協助，幫助他們將根據代碼生成需求描述和測試（如下左圖），甚至是自動幫用戶優化/Debug 代碼（如下中圖）。若不少 Agents 能充分證明自身的獨特性，如擅長 Python Numpy 庫或 JS VUE， 這時將會出現 LLM Agents 平台，而 IDE 作為開發者的超級入口則能順勢成為 Agents 的分發平台。
02. 現狀：微軟帝國的裂痕
GitHub Copilot 是現階段 IDE 場景下的絕對頭部。根據 The Information 今年 10 月的報道，GitHub Copilot 目前擁有 100 萬付費用戶、達到了 1 億美元 ARR，GitHub Copilot Business 版本在今年 3 月時只有 5000 個企業使用，但到 6 月底這一數字就飆升到了 20000 個。GitHub CEO Thomas Dohmke 也極其樂觀地表示，GitHub Copilot 在未來將會覆蓋 1500 萬開發者用戶，從而為世界帶來 1.5 萬億的 GDP 增量。
Thomas Dohmke 的底氣來自於 GitHub Copilot 在用戶側的出色表現：目前 Copilot 用戶已有 46% 的代碼由模型生成，能讓這些用戶節省 55% 的開發時間；Copilot 建議代碼接受率在 30%以上 ，並在用戶上手半年後能提高到 36% 左右。Thomas 預計，在未來， Copilot 將撰寫 80% 的代碼，而程序員能將主要精力和思考花在系統設計和剩下的 20% 關鍵代碼上。
下圖為 GitHub 對 2000 位用戶所做的客戶體驗洞察，可以看到，GitHub Copilot 不僅在效率提升上表現優越，也顯著改善了用戶的開發體驗的滿意度。
Research Source: Quantifying GitHub Copilot』s impact on developer productivity and happiness
GitHub Copilot 強勢增長的背後是「微軟聯盟」帶來的綜合優勢：IDE 里近 40% 市佔率 的 Visual Studio 系列產品、擁有最強 LLM 模型的 OpenAI ，以及還有多年代碼生成產品積累的 GitHub Copilot 三者同屬於微軟體系。VS 作為強勢渠道為 GitHub Copolit 帶來絕對的流量優勢，OpenAI 則是 Coding 服務表現的基礎保障，GitHub Copilot 不僅受益於前兩者，其多年來在產品和用戶上的積累也會推動自身的增長飛輪。
GitHub Copilot 的產品壁壘首先建立在它和 Visual Studio 的深度整合上，VS 在其前端 UX 上給 GitHub Copilot 預留了多個專屬功能，在 VS 的龐大流量滋養下 GitHub Copilot 成長迅速。
早期， GitHub Copilot 的成功離不開前端交互方式的創新。早期 Copilot 的產品負責人 Alex Graveley 在當時創新地提出了代碼自動補齊的交互，即「根據前文內容，不斷地跳出代碼建議，如果用戶認同則在摁下 Tab 後就能填入建議」。這樣的多行代碼補全是當時 VS 無法做到的，在微軟出面牽線下， VS 團隊為 GitHub 開發了 InlineCompletionProvider 這一 API，從而讓用戶在 VS 中就可以使用代碼補齊，而這個 API 為 Github 帶來的效益也相當亮眼，GitHub 前 CEO Nat Friedman 在 2 月份的 Jasper Conference 上透露，這樣全新的 UI 在內測時表現亮眼，產品的終生留存率超過了 65%。
為了鞏固 Github Copilot 的壁壘，VS 還違背開源和 Extension 友好的初衷，持續為 GitHub Copilot 優先推出多個專屬 UX API。儘管在開源精神下， VSCode 在後期將專門為 Github Copolit 開發的 InlineCompletionProvider API 公開， VSCode Extension 市場里有幾個不錯的 Copilot 挑戰者，如 Tabnine 和 Codeium，都調用了這個 API 來達到實現類 Copilot 的代碼補全效果，但為了鞏固 GitHub Copilot 的地位，微軟和 Visual Studio 的資源傾斜相當明顯：除了 Visual Studio 官網主推 Github Copilot（如下圖），VS 團隊還繼續為 Copilot X 專屬開發了 UX API，比如 in-editor Chat 和 ChatView 等，並且這些 API 短期內都不會開放給其他產品/開發者。
In-Editor Chat 能讓用戶方便地選取一段代碼後，讓 GPT 提供更針對性的幫助，如下一圖。Chat View 則讓用戶直接在 IDE 里直接向 GPT-4 詢問代碼問題，它可以自動讀取相關的代碼文件，而不用複製並切去 ChatGPT，如下二圖。
儘管 GitHub Copilot 利用 VSCode 的專屬 UX API 和渠道優勢幾乎壟斷了代碼生成市場，但我們認為，GitHub Copilot 自身的產品壁壘可能並不深，也存在一些問題，而這些都留給了挑戰者們增長窗口期：
1. Github Copilot X 的核心能力來自 LLM 的技術壁壘， Github Copolit 並不能獨佔模型能力。
Github 最新推出的 Copolit X 底層是 GPT-4，儘管背靠微軟讓 Github Copilot 能夠獲得 OpenAI 最新模型的內測資格，但這一優先權並非獨家，類似 Codium、Cursor 等優秀的初創公司也能在新一代模型正式發布前期參與內測。這意味著，在測試、Debug 等高價值環節，Github Copilot X 並不能提供性能上的明顯優勢。
Github Copilot 的代碼補齊（Code Completion ）是基於OpenAI CodeX 模型實現的，在今年 6 月更新後，最新一代模型能夠在更長的上下文里更智能地選取相關的上文進行推理，從而將用戶代碼接受率從 30% 提升到了 36% 左右，此外，模型的延遲也下降了 13%。
但我們認為，CodeX 這樣的小模型也並不能讓 GitHub Copilot 建立自己的壁壘：首先， GitHub 一直都沒能像 OpenAI GPT-4 那樣拿出碾壓全場的測評比分，反而多個競爭對手（Tabnine 和 Codeium）都拿出了各個場景的測評，證明自身產品能力和 Copilot 的差距不大；此外，隨著 Llama，Mistral 和 Falcon 等開源中小模型已能在各種測評集里挑戰 GPT-3.5 的性能，我們認為 OpenAI CodeX 已經很難幫助 Github 在代碼補全這樣的小模型上建立明顯的護城河。
此外，因為 Github 嚴重依賴 OpenAI 的模型研發能力，導致 Code Completion 的模型沒有及時更新訓練集，並對於上下文窗口的利用能力不高。首先，Github 團隊目前並沒有展現出自己訓練小模型的能力，仍需要微軟牽頭讓 OpenAI 團隊勻精力到這個模型上，導致 Copilot 的模型更新頻率不高，模型目前甚至不知道 Langchain 這樣爆火的項目，導致生成效果不佳；此外，目前 Github Copolit 團隊還沒有用向量資料庫來協助模型找到最相關的代碼塊，這樣能充分利用有限的上下文窗口（Code Completion 模型通常在 2000 tokens），以達到更好的生成效果。
2. 數據安全和合規性上存在紕漏：
儘管 Github 明確表明會保證零數據留存，並在傳輸過程中進行加密，但是這些安全承諾並沒有經過第三方機構的認證，根據 Github 的 FAQ 內容， Github Copilot 預計要到 2024 年 5 月才能完成 SOC 2 這樣行業通用的安全認證。
Github 在訓練模型時並沒有清除未經許可或特殊許可的代碼，包括 GPL，LGPL 和 AGPL 的代碼。最直接的例子是 Copilot 會直接生成 ffmpeg 的代碼片段，而這顯然是有合規風險的。在 Twitter 上，也有不少用戶抱怨 Copilot 的灰色行為，比如 Tim Davis 就怒斥 Copilot 使用了他版權保護的 CSparse 庫，也有用戶深扒了 Github Copilot 的用戶協議，發現用戶將需要自己確保生成代碼的法律合規性。
數據安全和合規上的短板會讓用戶有極大概率選擇放棄 Copolit，在 2024 年 5 月 GitHub Copilot 完成安全認證之前，新一代 LLM-first IDE 團隊則可以積極利用該時間窗口期拓展用戶，尤其是看重數據安全與隱私的企業側客戶。
3. 企業級功能並不完善：
除了數據安全上的短板，GitHub Copolit 也尚未提供分析面板、模型個性化套件和許可權管理等企業級用戶常用的功能上。
例如，企業通常都需要通過分析面板來評判工具是否有實現預期的能力，而 Github 僅給最大的幾個客戶提供使用情況分析，而不會提供像下圖一樣的實時分析面板。
Codeium 產品面板
和 LLM 類似，出於性能、成本和合規等考慮，企業客戶對 Code Completion 的 Fine-tune 需求也很旺盛。具體來說，大多數企業通常希望能利用好自己的專屬數據，比如，Google 內部會有大量優質內部工具或優化 TPU 性能的代碼，顯然 Fine-tune 後模型能力會有質變；專屬數據也允許模型能用更少的參數就能獲得類似的性能，這將帶來更低的推理成本、延遲；在嚴格的監管環境下，處理敏感數據的企業可能需要對其模型進行微調，以確保其尊重隱私要求，遵守內容準則。
既然模型是數據的一種壓縮形式，在理想情況下，模型的許可權管理要求應接近數據的要求，所以許可權管理和私有化部署是一個常見需求。比如，一種方式是通過管理不同部門的人能接觸不同版本的模型，並記錄下每個用戶使用 Log；而有更極端數據安全要求的公司，也會尋求私有化部署模型的方案。但目前 Github Copilot 並沒有推出這些功能。
總之，儘管 VSCode 和 Github 在微軟的統籌下，已初步壟斷了 LLM 在開發者超級入口 IDE 的應用，但是目前也有許多初創公司注意到了微軟帝國的裂痕，打算在這個充滿想像力的市場里能佔據一席之地。
03. 挑戰者：LLM 新浪潮下的暗流
儘管 Github Copilot 目前拿走了市場的主要聲量，但仍舊有不少挑戰者初露頭角，值得我們關注。Stackoverflow 在 2023 年 6 月份發布了其年度開發者報告，其中最流行（下圖1）和最受好評（下圖2的紅點）的 AI 工具毫無疑問都是 GitHub Copilot，但與此同時，我們也看到很多新名字上榜、並且成績不俗：Tabnine 已經擁有較為可觀的用戶基數，Codeium 則已經在較小的用戶群體（下圖2的藍點）里取得了極高的評價（下圖 2 的紅點），CodeWhisperer 依靠AWS 的背書和渠道，也有不錯的用戶基數和評價。
我們可以把 VS 和 Github Copolit 「微軟聯盟」的挑戰者們劃分為兩大類：「模型+Extension」和「模型+IDE」。前者更適合在中短期內通過類似 GitHub Copilot 的形式，通過 VSCode Extention 和現有渠道結合來捕獲客戶心智，而後者則嘗試通過交互和 UI 上的創新，在中長期里探索下一代開發體驗。
從差異化角度，我們則可以從底層能力（模型）和產品（交互、輔助工具和 Coding Agents ）來看，其中：
1）模型能力：
各家幾乎拉平，但在模型服務上，Codeium 和 Tabnine 做得要比 Github Copilot 好；
2）產品：
• 用戶交互（UI/UX） ：Github Copilot 憑藉 VSCode 所提供的專屬 UI API 在觸達用戶上有一定優勢，但目前 LLM 的功能發掘仍在早期，留給初創公司進行創新的空間還很大；
• 輔助工具上主要是 Prompt Engineering 和 RAG 系統的搭建，但目前還沒有一家公司有明顯優勢；
• Coding Agents：Agents 是我們認為長期可以拉開仍處於行業早期，Cursor 和 CodiumAI 目前有一些不錯的小嘗試，但沒有一家公司有明顯優勢。
需要強調的是，Github Copolit 背靠 Visual VSCode 躺在流量富礦之上，新玩家們目前主要通過 PLG 的方式實現增長，短期內要超越 GitHub Copilot 還需要 GTM 角度的非凡策略和卓越表現。
模型
在後端模型側，行業的主要選手都傾向於選用兩套模型：
• 一個中小模型（10-40B 參數）進行代碼補齊任務；
• 另一個針對複雜任務的模型則主要藉助 GPT-4 或 Claude-2 等大模型來實現。
由於大模型的頭部領先優勢較為明顯，並且生態開放程度高，所以主要選手都調用 GPT 或 Claude 等頭部模型的 API，但在中小模型環節，正如我們在前文中分析的，OpenAI 為 Github Copilot 開發的 Codex （以及後續更新）優勢並不明顯，並有多個開源模型證明自己模型已追上 GPT-3.5 能力，所以現階段初創團隊通常選擇自研、或基於開源模型進行繼續訓練。
雖然從模型調用上各家無法真正拉開差距，或建立獨特壁壘，但在模型服務環節，則有機會真正拉開差距。
我們整理了多家開源和自研代碼的中小模型的代碼生成測試成績，其中 Code Llama 34B 的多個變種在代碼任務上能超過 GPT-3.5，甚至在一些理想條件下能接近 GPT-4，而 Github 先前採用的 CodeX 則早已沒有什麼性能優勢。
測評參考：https://paperswithcode.com/sota/code-generation-on-humaneval)
此外，由於 OpenAI 為了最小化訓練和推理成本，可能將代碼生成任務交給 GPT-3.5，所以 Github Copilot 的競對除自研外也可以調用 GPT-3.5 API。OpenAI 在 2023 年 3 月份宣布了將推薦先前 Codex API 的用戶逐步轉向 GPT 3.5-Turbo（根據上表來看 GPT3.5-Turbo 的性能的確有顯著的提升），因為代碼數據能提高模型的推理能力，而文本數據能提高模型理解用戶意圖的能力。此外，由於推理伺服器通常能通過同時服務數十個請求來攤低推理成本，所以整合文字和代碼的推理請求後，GPT-3.5 Turbo API 等成本大概率能做到比大多開源模型更低，以帶來性價比優勢。
就像前文中說的，Github 代碼補全模型服務環節的主要問題在於數據安全和合規性上存在紕漏，並且仍無法提供各種企業級需求，而挑戰者們正積極抓住這個機會：
• Tabnine 和 Codeium 都已完成 SOC2 數據安全認證，並在訓練數據中儘力去除了未經許可/特殊版權保護的代碼庫。
• Tabnine 和 Codeium 都允許用戶將模型部署在自有伺服器，滿足用戶對數據安全的需求。
• Tabnine 和 Codeium 都允許用戶自有的代碼庫對模型進行 Fine-tune，不過 Codium 所提供的模型管理面板功能更全面，而 Tabnine 則只能聯繫團隊定製。
由於以上需求大多為企業級場景，因此我們認為在幾乎同樣的模型能力下，主打 Enterprise 的代碼補全公司有局部市場機會，而在 to C 場景下，市場將繼續由 Github Copilot 領跑。這是因為 Github Copilot 憑藉 VSCode 渠道優勢和 Github 的品牌效應就能俘獲大多數用戶的心智，而 toC 市場的挑戰者必須要在 UX 上有明顯創新才能擁有自己的一席之地。
產品
Perplexity 以其出色的 Prompt Engineering 和 LLM Agents 設計，在搜索這個被 Google、Bing 等大廠佔領的場景突圍，所以我們認為，在 Coding 領域，初創公司也有機會能通過 Prompt Engineering 和 LLM Agents 挖掘出更多 GPT-4 的潛力從而給到用戶更好的使用體驗、形成新一代產品心智。
Anshul Ramachandran 在其 How to Make AI UX Your Moat 文章中提到，LLM 產品的 UX 護城河能在三個方向逐步建立，分別是：
• Presence：將 LLM 儘可能的嵌到現有的 UI 和 工作流中；
• Praticality：當 LLM 已經嵌入工作流後，在相同任務或問題解決上，即便明明大家都用的是 GPT-4 API，用戶仍舊能明顯能感覺到一家的生成內容比其他家更優質（例如格式/內容實時性/易用性等）；
• Power：指的是用 LLM 做競爭對手或傳統技術下沒有的功能，直接在功能豐富度上與對手競爭。
Presence
Presence 指的是先將 LLM 儘可能地嵌到現有的 UI 和 工作流中，這裡主要涉及到的是 UI 創新。
IDE 入口中，VSCode 的前端界面基本成為了行業的通用標準，Cursor、Google Project IDX、AWS Cloud9 和 Codestory 都採取了類似的界面。這種前端界面通常由 Activity Bar、Primary Sidebar、Editor、Secondary Sidebar 以及 Status Bar 等幾個組件構成（如下一圖）。
Github Copilot 主要是在 Editor 部分加入了 Code Completion 和 In-Editor Chat，並在 Primary Sidebar 加入了 Copilot Chat 。值得指出的是，VSCode 目前僅允許 Github Copilot 在 Editor 界面彈出 In-Editor Chat 窗口，而其他產品則只能在 Primary Sidebar 顯示 Chat 界面。
為能和 Github 競爭，這些挑戰者們在 UI 上進行了多處創新：
• Copy to Chat：
將 Chat 融入 IDE 首要的好處是能快速向 Chat 導入代碼段。比如 Cursor 就在 Editor、Terminal 里允許用戶快速導入代碼段到 Chat 中，並小心處理回車和前置空格。
• Context Provider @：
為了繞過 VSCode 的 Restricted API，Cursor 選擇基於 VSCode 開源代碼自研一個 IDE，團隊首當其衝做的功能就是復刻了 In-editor Chat，並基於此創新地引入了 @ 符號，類似 Notion、飛書等文檔協作工作中已經普遍使用的 關聯文檔功能。在 @ 的功能下，開發者能夠更準確地表述需求，例如，如果開發者想讓生成的代碼使用另一個文件里的特定代碼段，就可以使用 @ 來選取相關文件（如下左圖）。CodeStory 也有類似的功能，如下右圖。
• Quick Command：
Codeium 在 Editor 界面中加入了快捷鍵（如下左圖），將一些常用功能用固定的 Prompt 方式交給模型，這不僅能降低用戶 Prompt Engineering 的門檻，團隊也能在模型訓練過程中強化這些 Quick Command 的性能。Codestory 則參考了 Notion 中的 Slash（/） Command，將常用的指令能通過 / 調用（如下右圖）。
Practicality
Praticality 指的是，在 LLM 已經嵌入工作流後，在相同的任務或問題的處理上，即便大家都調用的是 GPT-4 API，在底層模型能力拉齊的基礎上，用戶仍能明顯能感覺到其中某個產品的生成內容比其他家更優質，這裡的優質可以具象化為生成格式、內容實時性、易用性等細節，本質上則是不同團隊在 Prompt Engineering 和 RAG 的優化上的能力體現，Praticality 也是不同產品團隊對用戶洞察能力的體現。
1）Prompt Engineering：
一個優質 Prompt 通常包含以下三個組件：
• Command：
用戶的指令和任務，可以提示並輔助用戶填入更明確的需求。比如更追求計算高效還是內存高效，函數名是否要確保符合命名規則等，是否要盡量用調用上下文的其他函數等。
• Constraints:
收集用戶偏好設置後，在每次任務中自動導入。這類似於 ChatGPT 的 Custom Instructions，用戶能輸入自己的編程背景，更偏好 GPT 在哪些生疏的語言里配上更詳細的注釋，同樣的功能更偏好用什麼語言和包完成。
• Context:
從代碼庫和企業知識庫中，提取出和問題最相關內容；再結合系統環境和運行情況（如報錯信息和 Log），在有限的 Context Window 中放入更高質量的信息。我們將在後文的 RAG 部分展開介紹。
類似這樣的 Prompt 模版還有 RTF、Tree of Thought 等，暫時不做展開介紹。
具體來說，儘管在 Codeium 的 UI 上僅有一個「Refactor」 詞作為 Prompt，但是在後台真正輸出給 GPT-4 的可能是下面這樣的：
You are a software developer. You will be given a function as context, and are responsible for rewriting it according to a given set of instructions and constraints, and returning the rewritten function to the user. Make sure that the rewritten function is easily understandable by other software developers and add comments describing how the code works: <constraints><funciton code><context>
其中的 「Constraints」，可以學習 GPTs 設置過程中的引導對話，並從中提煉出用戶的使用習慣和編程經驗。比如問答之後，LLM 總結出了如下一段話。
<constraints>: I prefer compute efficient and robust code, so please vertorize the computation whenever possible. I am using 14700K+RTX4090+128G DDR6. The function naming should follow Google Style Guides. I am familiar with Numpy and Pytorch, so please use them whenever possible. I am currently using MinGW-W64 GCC-7.3.0 for cpp.
此時，UI 上還應該提示一些常見的代碼偏好，進一步豐滿 Constraints，讓模型的生成效果更貼合用戶需求，比如下面幾條
A. add console log statement to make debugging easier
B. add print statement to make debugging easier
C. add comments and docstring to the code
D. add codes to reallocate memory
E. ...
總之，僅一個 Refactor Code 的按鍵設計背後都需要複雜的系統工程，要先引導用戶去豐滿他們的指令，再導入用戶的偏好和限制要求，協助用戶穩定快捷地獲取高質量的輸出。還有極為重要的部分是 RAG，自動找到相關的各種背景知識，在有限的輸入窗口中放入更高質量的代碼。
2) RAG
（該部分內容主要基於拾象團隊 Cage 的內部研究)
儘管 GPT-4 在近期已成功將上下文窗口擴展到 128000 tokens，但是出於成本和延遲的考慮，並且典型的 Code Autocomplete 模型的窗口仍限制在 10000 Tokens 不到，所以行業實踐中，通常會通過 RAG 技術來作為 LLM 的輔助。
💡
RAG 技術指的是用各種搜索演算法幫助模型從資料庫中找到和用戶請求較為相關的內容，用來提升模型生成內容的質量和個性化程度。
語義搜索資料庫的建立和維護通常有以下幾個步驟（如下圖），其中， TextSplitter 和 Embedding Model 的技術護城河重要性高於 Vector DB。
TextSplitter 通常被用來將長短不一的文檔切割成合理的信息長度，以放入 Embedding Model 做索引。一個優秀的 TextSplitter 需要避免將較相關的上下文切到兩端文本中，以避免重要信息丟失。
Embedding Model 則負責將文本段轉化成向量，一個優秀的 Embedding Model 通常在分類、召回等任務中有不俗的表現。
（讀者可以參考 Hugging Face 對各個開源 Embedding Model 的全面測評 https://huggingface.co/spaces/mteb/leaderboard ）
由於 Textsplitter 的切割效果對 Embedding Model 的效果測評有明顯影響，而各家公司也能對開源 Embedding Model 進行 Fine-tune，所以我們認為會有團隊能在代碼和文字混用的場景下圍繞 Embedding Model 和 Textsplitter 建立起護城河。
此外，很多團隊正在探索從單 Embedding Model 轉向多 Embedding Model 做 Index，認為這將顯著改善召回結果的性能和個性化程度。根據 Hugging Face 的 Embedding Model 測評，目前還沒有一個 Embedding Model 能夠在所有任務中都能成為表現最好的，所以有很多團隊提出用多個 Embedding Model 進行 Index。
在搭建 RAG 的召迴流程上，行業目前的通用做法是用一個 Embedding Model 將 Query 和數據進行相似性比對，找出相似度最高的幾個 Retrieved Contexts （粗排），這時再用 Reranker 模型對這些 Contexts 進行排序（精排），最後整合到 Prompt 中作為重要信息（如圖1）。最近行業里正在將傳統搜索/推薦演算法和技巧結合到語義搜索中：用戶的 Query 先到各個 Vector DB 多路找出相關 Context 後再用 Reranker 模型進行排序（如圖2）。
現階段，市面上的 IDE 代碼助手在這方面的探索並不充分：
• Github Copilot 在自己的技術博客中表示，他們目前只通過最簡單的 Vector DB 找到相關 Context ；
• Codeium 是在所有團隊中唯一在 RAG 上進行探索的，但 Codeium 的方式也只是多加一步 Reranker。
雖然目前行業里通常認為語義搜索演算法配合上關鍵詞搜索的效果最好，並且即將成為主流選擇，但我們認為 RAG 的技術路徑還將繼續發散，這套方法還有很大的優化空間，將顯著增強相關性，減少延遲，並優化提示，我們相信，如果會團隊能在 RAG 環節積累 Textsplitter、Embedding Model 和召迴流程上的技術優化，就有機會在 IDE 代碼助手上復刻 PerplexityAI 對搜索巨頭的效果碾壓。
Power
Practicality 的目標是在現有功能實現上給予更好的體驗，而 Power 則是指如何基於 LLM 來實現競爭對手或傳統技術下沒有的功能，是從功能豐富度上與對手競爭，也正是這些功能開發實踐會帶來豐富的 Code Agents 生態，這是我們在今天關注 LLM 和 IDE 融合的最主要原因。沙盒環境的運用和 Agents 的搭建可能會成為這一環節的競爭關鍵。
OpenAI 推出的 Code Interpreter 解鎖了 LLM 在沙盒環境自主運行代碼的能力，Python 代碼包生態的繁榮將為 LLM 提供近乎全能的工具箱。Code Interpreter 的推出進一步讓用戶感受到 LLM 的驚人潛力，既能用數學代碼庫大幅提升了模型的複雜運算能力和可靠性，又能憑藉 Python 豐富的代碼庫讀寫幾乎所有常用的文件格式，還能給出精美的數據分析和可視化圖表，這讓賓大的副教授 Ethan Mollick 都感嘆，Code Interpreter 在很多複雜數據分析中出錯的概率甚至比人類還低。
但因為 Code Interpreter 的沙盒環境由 OpenAI 負責託管在雲端，出於安全和成本的考量，它不僅無法訪問互聯網、API 和資料庫，且沙盒環境的設置自由度和運行時間受限，雲端託管也讓用戶上傳的各類文件還會有泄密的風險。而 Open Interpreter 則允許 LLM 使用本地電腦或伺服器上的沙盒環境，從而轉嫁了成本和安全風險。
💡
Open Interpreter ：
實現 OpenAI Code Interpreter 效果的開源代碼，今年 9 月上線，Open Interpreter 可以讓 LLMs 在本地運行代碼（比如 Python、JavaScript、Shell 等）。安裝後，在終端上運行即可通過類似 ChatGPT 的界面與 Open Interpreter 聊天。
在 IDE 環境中，LLM 通過 Open Interpreter 自我測試代碼，不僅提高了準確性和自動化程度，還通過利用 Python 的豐富生態系統，滿足了更廣泛的需求，並降低了針對不熟悉的代碼庫的學習成本。同時，LLM能夠獲得系統級的上下文信息，大大減少了用戶在管理代碼環境方面的精力和學習成本。
Open Interpreter 所消耗的 Token 數需求比文案多兩到三個數量級，促使代碼場景的客單價可能遠超文案，從而彌補代碼人群大幅少於文案人群的質疑。Open Interpreter 通常會在多步思考里導入大量的上下文、系統和報錯信息，還要用大量的空格和符號維護詳細的代碼結構，所以 Open Interpreter 的成熟將為 GPT 帶來天量的生成需求。比如 Reddit 上的 jaimito 是一位前端工程師，他僅僅用了 1 小時就為 GPT-4 API 支付了 10 美元，而這在文案場景下通常夠用 1 個月。
在《AI Agent 的千億美金問題中》，我們提到，LLM Agent 和 LLM- Based 應用的顯著差異點主要體現在：
• 合作機制（ Orchestration）：存在多模型、多 agent 分工與交互的機制設計，能實現複雜的工作流。
• 環境交互 （Grounding）：Agent 能理解自己的不足，並適時從外部尋找合適的工具解決問題。
個性化記憶 （Memory）：能記憶用戶偏好和工作習慣，使用越久越了解用戶。
• 主動決策 （Decision）：Agent 有能力在虛擬環境中探索、試錯、迭代。
不難發現，當 LLM 熟練掌握沙盒環境的運用能力，配合上 GPTs 帶來的模型個性化普及，結合前文提到的 RAG 技術的成熟後，我們認為驚艷的 AI Agents 將逐步湧現。
CodiumAI 為代碼測試開發了 Integrity Agent，致力於挖掘出潛在的代碼漏洞。Integrity Agent 會先找出文件中現有的測試，再利用 LLM 給用戶建議數個多個潛在問題點，再生成用戶感興趣的測試並導入現有測試代碼的邊上。Integrity Agent 使用了 TestGPT（為測試場景 Fine-tune 版本的 GPT-4），生成的描述會更符合常見測試需求的規整，而生成的代碼則允許根據用戶樣例更貼合用戶習慣。
Cursor 在 Twitter 上火爆的原因之一是其 Auto-Debug 功能，致力於一鍵修復用戶運行代碼後的報錯。例如下圖就展示了一個 Auto-Debug 功能：Cursor 從報錯信息中得知你可能打錯了文件名/文件路徑，會主動用文件夾瀏覽工具掃描代碼庫，它要麼會告訴你這個文件夾里沒有此文件，或是建議另一個類似的文件名（可能是大小寫錯誤）。
由於我們仍處於 Agent 早期，儘管 CodiumAI 和 Cursor 的例子僅在 Orchestration 和 Grounding 上取得進展，我們已能初步窺探 LLM Agent 潛在的功能爆發。在這些功能配合上 UI 和小工具的輔助後，用戶將能明顯體驗到和Github Copilot 的產品區分，並擺脫 LLM Wrapper 的質疑。
04. 結論
單純從 IDE 工具角度來看，因為底層模型能力基本拉平，而用戶體驗上的努力是一個長期的過程，整個 IDE 領域可能在相當長時間仍是 VScode 和 Github Copolit 的主場，對於 LLM-first IDE 們而言，除了在用戶體驗和功能上做增量外，找到差異化的 GTM 策略也至關重要，例如我們在前文提到的抓住企業級需求，此外，考慮到 LLM 還帶來新開出了發者的湧入，參考生產力軟體中常用的教育策略，LLM-first IDE 也可以通過綁定新手開發者、培養新一代用戶的 IDE 入口也是一種方式，例如 Replit 就曾嘗試過和 CodeAcademy 等開發者學習網站合作。
雖然在 IDE 挑戰者主題下，VScode 被顛覆挑戰的可能性較低，但 LLM-first IDE 整個賽道對於行業來最大的價值在於 LLM Agents，我們相信 Code Agnets 生態會在整個競爭過程中不斷豐富，因此，值得對賽道保持長期關注。
Reference
https://pypl.github.io/IDE.html
https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
https://codeium.com/blog/code-assistant-comparison-copilot-tabnine-ghostwriter-codeium
https://github.blog/2023-06-27-the-economic-impact-of-the-ai-powered-developer-lifecycle-and-lessons-from-github-copilot/
https://www.freethink.com/robots-ai/github-copilot
https://cloudinfrastructure.substack.com/p/cloud-infrastructure-part-ii-devops?s=w
https://code.visualstudio.com/blogs/2023/03/30/vscode-copilot
https://www.reddit.com/r/OpenAI/comments/16hu7nr/open_interpreter_vs_cursor_ai_anyone_compared/
Filming Less：AI時代的視頻剪輯產品淘汰賽
專訪Pika Labs創始人：探索視頻生成的GPT時刻
Mistral AI：歐洲最強模型團隊，打造開源輕量LLM
2023獨角獸市值分析：Gen AI的崛起與地域分布
Figure：為人類部署數十億台人形機器人
