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%，但該資料引用可靠度偏低，暫不採用。) 

而 LLM 的到來也許會為 IDE 這一超級流量入口帶來新的商業化途徑、改善 IDE 商業化現狀。文字場景入口的 Notion 透過 Notion AI 僅用短短幾個月的時間便成功實現了數百萬美元的 ARR ；Google Workspace 最初依賴廉價的雲盤空間作為商業化方式，而如今則有望透過 Bard 的增值服務提高這數億使用者產品的收益潛力；此外，微軟透過將 GitHub Copilot 引入 VSCode 這一龐大的開發者渠道，在產品正式上線的 18 個月內，就實現了 1 億美元 ARR。

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% 的預算份額。

當 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 裡用使用公式一樣簡單。

傳統的開發流程是編碼完成後再進行測試，這一流程意味著開發人員直到專案晚期才會發現漏洞，也因此漏洞帶來的影響範圍、解決漏洞的成本相應提升，近年流行的 TDD(Test-Driven Development) 則在專案早期就花大量精力設計測試，確保每個功能從一開始就經過嚴格測試，從而保證複雜的長期專案更穩定。

但在相對輕量的程式設計程式中，開發者們通常偏好直接編碼，在這一過程中，LLM 則可以用於輔助生成需求描述和測試，以確保再使用的上手簡易性和穩定性。比如，大部分人在使用 Excel 公式功能時，都通常不會為公式編寫詳盡的說明，這造成了再次使用時的摩擦；更不會寫詳盡的測試案例，導致報表有時會因為資料型別等問題報錯。

程式設計的高複雜度會帶來巨大的再使用摩擦和穩定性考量，湧入的程式設計新手意味著對 LLM Agents 的海量需求，IDE 則能成為 Agents 的分發平臺。由於輕量軟體所涉及的程式語言和程式碼庫遠複雜於 Excel 公式語法，這意味著巨大的再使用摩擦和穩定性難題，畢竟同樣的程式碼在切換電腦時報錯是極為常見的問題。這就需要 LLM Agents 的協助，幫助他們將根據程式碼生成需求描述和測試（如下左圖），甚至是自動幫使用者最佳化/Debug 程式碼（如下中圖）。若不少 Agents 能充分證明自身的獨特性，如擅長 Python Numpy 庫或 JS VUE， 這時將會出現 LLM Agents 平臺，而 IDE 作為開發者的超級入口則能順勢成為 Agents 的分發平臺。

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 不僅在效率提升上表現優越，也顯著改善了使用者的開發體驗的滿意度。

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 短期內都不會開放給其他產品/開發者。

儘管 GitHub Copilot 利用 VSCode 的專屬 UX API 和渠道優勢幾乎壟斷了程式碼生成市場，但我們認為，GitHub Copilot 自身的產品壁壘可能並不深，也存在一些問題，而這些都留給了挑戰者們增長視窗期：

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），以達到更好的生成效果。

Github 在訓練模型時並沒有清除未經許可或特殊許可的程式碼，包括 GPL，LGPL 和 AGPL 的程式碼。最直接的例子是 Copilot 會直接生成 ffmpeg 的程式碼片段，而這顯然是有合規風險的。在 Twitter 上，也有不少使用者抱怨 Copilot 的灰色行為，比如 Tim Davis 就怒斥 Copilot 使用了他版權保護的 CSparse 庫，也有使用者深扒了 Github Copilot 的使用者協議，發現使用者將需要自己確保生成程式碼的法律合規性。

資料安全和合規上的短板會讓使用者有極大機率選擇放棄 Copolit，在 2024 年 5 月 GitHub Copilot 完成安全認證之前，新一代 LLM-first IDE 團隊則可以積極利用該時間視窗期拓展使用者，尤其是看重資料安全與隱私的企業側客戶。

例如，企業通常都需要透過分析面板來評判工具是否有實現預期的能力，而 Github 僅給最大的幾個客戶提供使用情況分析，而不會提供像下圖一樣的即時分析面板。

具體來說，大多數企業通常希望能利用好自己的專屬資料

既然模型是資料的一種壓縮形式，在理想情況下，模型的許可權管理要求應接近資料的要求，所以許可權管理和私有化部署是一個常見需求。比如，一種方式是透過管理不同部門的人能接觸不同版本的模型，並記錄下每個使用者使用 Log；而有更極端資料安全要求的公司，也會尋求私有化部署模型的方案。但目前 Github Copilot 並沒有推出這些功能。

總之，儘管 VSCode 和 Github 在微軟的統籌下，已初步壟斷了 LLM 在開發者超級入口 IDE 的應用，但是目前也有許多初創公司注意到了微軟帝國的裂痕，打算在這個充滿想象力的市場裡能佔據一席之地。

儘管 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 ）來看，其中：

各家幾乎拉平，但在模型服務上，Codeium 和 Tabnine 做得要比 Github Copilot 好；

• 使用者互動（UI/UX） ：Github Copilot 憑藉 VSCode 所提供的專屬 UI API 在觸達使用者上有一定優勢，但目前 LLM 的功能發掘仍在早期，留給初創公司進行創新的空間還很大；

• 輔助工具上主要是 Prompt Engineering 和 RAG 系統的搭建，但目前還沒有一家公司有明顯優勢；

• Coding Agents：Agents 是我們認為長期可以拉開仍處於行業早期，Cursor 和 CodiumAI 目前有一些不錯的小嚐試，但沒有一家公司有明顯優勢。

在後端模型側，行業的主要選手都傾向於選用兩套模型：

• 一箇中小模型（10-40B 引數）進行程式碼補齊任務；

• 另一個針對複雜任務的模型則主要藉助 GPT-4 或 Claude-2 等大模型來實現。

所以現階段初創團隊通常選擇自研、或基於開源模型進行繼續訓練。

我們整理了多家開源和自研程式碼的中小模型的程式碼生成測試成績，其中 Code Llama 34B 的多個變種在程式碼任務上能超過 GPT-3.5，甚至在一些理想條件下能接近 GPT-4，而 Github 先前採用的 CodeX 則早已沒有什麼效能優勢。

此外，由於 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 上有明顯創新才能擁有自己的一席之地。

Github Copilot 主要是在 Editor 部分加入了 Code Completion 和 In-Editor Chat，並在 Primary Sidebar 加入了 Copilot Chat 。值得指出的是，VSCode 目前僅允許 Github Copilot 在 Editor 介面彈出 In-Editor Chat 視窗，而其他產品則只能在 Primary Sidebar 顯示 Chat 介面。

將 Chat 融入 IDE 首要的好處是能快速向 Chat 匯入程式碼段。比如 Cursor 就在 Editor、Terminal 裡允許使用者快速匯入程式碼段到 Chat 中，並小心處理回車和前置空格。

為了繞過 VSCode 的 Restricted API，Cursor 選擇基於 VSCode 開原始碼自研一個 IDE，團隊首當其衝做的功能就是復刻了 In-editor Chat，並基於此創新地引入了 @ 符號，類似 Notion、飛書等文件協作工作中已經普遍使用的 關聯文件功能。在 @ 的功能下，開發者能夠更準確地表述需求，例如，如果開發者想讓生成的程式碼使用另一個檔案裡的特定程式碼段，就可以使用 @ 來選取相關檔案（如下左圖）。CodeStory 也有類似的功能，如下右圖。

 Codeium 在 Editor 介面中加入了快捷鍵（如下左圖），將一些常用功能用固定的 Prompt 方式交給模型，這不僅能降低使用者 Prompt Engineering 的門檻，團隊也能在模型訓練過程中強化這些 Quick Command 的效能。Codestory 則參考了 Notion 中的 Slash（/） Command，將常用的指令能透過 / 呼叫（如下右圖）。

Praticality 指的是，在 LLM 已經嵌入工作流後，在相同的任務或問題的處理上，即便大家都呼叫的是 GPT-4 API，在底層模型能力拉齊的基礎上，使用者仍能明顯能感覺到其中某個產品的生成內容比其他家更優質，這裡的優質可以具象化為生成格式、內容即時性、易用性等細節，本質上則是不同團隊在 Prompt Engineering 和 RAG 的最佳化上的能力體現，Praticality 也是不同產品團隊對使用者洞察能力的體現。

一個優質 Prompt 通常包含以下三個元件：

使用者的指令和任務，可以提示並輔助使用者填入更明確的需求。比如更追求計算高效還是記憶體高效，函式名是否要確保符合命名規則等，是否要儘量用呼叫上下文的其他函式等。

收集使用者偏好設定後，在每次任務中自動匯入。這類似於 ChatGPT 的 Custom Instructions，使用者能輸入自己的程式設計背景，更偏好 GPT 在哪些生疏的語言裡配上更詳細的註釋，同樣的功能更偏好用什麼語言和包完成。

從程式碼庫和企業知識庫中，提取出和問題最相關內容；再結合系統環境和執行情況（如報錯資訊和 Log），在有限的 Context Window 中放入更高質量的資訊。我們將在後文的 RAG 部分展開介紹。

具體來說，儘管在 Codeium 的 UI 上僅有一個“Refactor” 詞作為 Prompt，但是在後臺真正輸出給 GPT-4 的可能是下面這樣的：

其中的 “Constraints”，可以學習 GPTs 設定過程中的引導對話，並從中提煉出使用者的使用習慣和程式設計經驗。比如問答之後，LLM 總結出瞭如下一段話。

此時，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 的按鍵設計背後都需要複雜的系統工程，要先引導使用者去豐滿他們的指令，再匯入使用者的偏好和限制要求，協助使用者穩定快捷地獲取高質量的輸出。

儘管 GPT-4 在近期已成功將上下文視窗擴充套件到 128000 tokens，但是出於成本和延遲的考慮，並且典型的 Code Autocomplete 模型的視窗仍限制在 10000 Tokens 不到，所以行業實踐中，通常會透過 RAG 技術來作為 LLM 的輔助。

TextSplitter 通常被用來將長短不一的文件切割成合理的資訊長度，以放入 Embedding Model 做索引。一個優秀的 TextSplitter 需要避免將較相關的上下文切到兩端文字中，以避免重要資訊丟失。

Embedding Model 則負責將文字段轉化成向量，一個優秀的 Embedding Model 通常在分類、召回等任務中有不俗的表現。

（讀者可以參考 Hugging Face 對各個開源 Embedding Model 的全面測評 https://huggingface.co/spaces/mteb/leaderboard ）

我們認為會有團隊能在程式碼和文字混用的場景下圍繞 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）。

• Github Copilot 在自己的技術部落格中表示，他們目前只通過最簡單的 Vector DB 找到相關 Context ；

• Codeium 是在所有團隊中唯一在 RAG 上進行探索的，但 Codeium 的方式也只是多加一步 Reranker。

OpenAI 推出的 Code Interpreter 解鎖了 LLM 在沙盒環境自主執行程式碼的能力，Python 程式碼包生態的繁榮將為 LLM 提供近乎全能的工具箱。Code Interpreter 的推出進一步讓使用者感受到 LLM 的驚人潛力，既能用數學程式碼庫大幅提升了模型的複雜運算能力和可靠性，又能憑藉 Python 豐富的程式碼庫讀寫幾乎所有常用的檔案格式，還能給出精美的資料分析和視覺化圖表，這讓賓大的副教授 Ethan Mollick 都感嘆，Code Interpreter 在很多複雜資料分析中出錯的機率甚至比人類還低。

但因為 Code Interpreter 的沙盒環境由 OpenAI 負責託管在雲端，出於安全和成本的考量，它不僅無法訪問網際網路、API 和資料庫，且沙盒環境的設定自由度和執行時間受限，雲端託管也讓使用者上傳的各類檔案還會有洩密的風險。而 Open Interpreter 則允許 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 有能力在虛擬環境中探索、試錯、迭代。

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 的質疑。

單純從 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 生態會在整個競爭過程中不斷豐富，因此，值得對賽道保持長期關注。