在 VS Code 中追求極致智慧
2023 年 11 月 13 日，作者：Chris Dias, @chrisdias
如果您上週關注了 GitHub Universe，您會看到人工智慧在整個開發者工作流程中取得了巨大的進步、創新和願景。在這篇博文中，我們想重點介紹過去幾個月 Visual Studio Code 在實現這一更宏偉願景方面取得的進展。
“聰明絕頂”
在馬特·達蒙和本·阿弗萊克開創性的電影《心靈捕手》中，我最喜歡的一句臺詞是“my boy's wicked smaaahtt”（用波士頓口音讀，效果更佳）。
這句臺詞由 Morgan（凱西·阿弗萊克，本的兄弟）說出，當時 Will（馬特·達蒙）透過逐頁、逐字地回憶美國曆史事實，化解了 Chuckie（本·阿弗萊克）與一位過於自信的“一年級研究生”之間的衝突。可以說，Will 是透過他讀過的所有書籍訓練出來的，並能根據對話內容回憶起它們。
AI 與 Will 類似——它瞭解大量文字。但 AI 缺少的是——人類擁有而 AI 沒有的——特定互動的上下文，以便給出最佳答案。在 Will 的案例中，因為他還能“察言觀色”，所以他能利用書本知識給出一個精心設計的有力回擊。
大語言模型 (LLM) 是在某個時間點上使用公共程式碼倉庫資料訓練的。這意味著它們對您當前的程式碼一無所知。它們瞭解一般的程式碼，但沒有必要的上下文來準確回答關於您程式碼的問題，或者建議符合您工作區形式和功能的新程式碼。
為了解決這個問題，GitHub Copilot Chat 會發送程式碼片段來幫助模型更好地回答問題（這被稱為“檢索增強生成”，即 "RAG"）。透過看到最相關的程式碼，答案會變得更好。但是，可以傳送給 LLM 的程式碼量（以及透過提示進行的指導）是有限的。對於一個小專案來說，這通常不是問題。但考慮到任何大型原始碼倉庫，您會很快意識到不可能將每個檔案的內容都發送給模型。獲得更好答案的解決方案是在合理的時間內，使用適量的資源，傳送相關的上下文。為了幫助解決這個問題並解鎖許多其他場景，我們在 Copilot Chat 中加入了**參與者 (participants)** 的概念。
參與者
聊天參與者是領域專家，他們可以以任何他們想要的方式回答使用者的查詢——透過在查詢處理中充分利用 AI，或者透過傳統方式將其轉發到後端服務。參與者還可以為大語言模型提供訪問領域特定工具的許可權。在 LLM 的幫助下，參與者可以選擇一個工具並定義如何呼叫它。@workspace 就是這樣一個聊天參與者的例子。@workspace 參與者瞭解您的工作區，並能回答關於它的問題。在內部，該參與者由不同的工具提供支援：GitHub 的知識圖譜結合語義搜尋、原生代碼索引和 VS Code 的語言服務。
聊天參與者可以由客戶端或服務端提供。在 GitHub Universe 上，演示了一個服務端參與者，即 github.com 聊天體驗中的“文件代理 (Docs Agent)”，它知道如何搜尋程式碼倉庫中的文件（即將登陸 VS Code）。
客戶端參與者可以透過傳統的 VS Code 擴充套件來提供。關於這一點，我們將在可擴充套件性部分詳細介紹，但讓我們先看看今天在 VS Code 中可用的兩個聊天參與者：@workspace 和 @vscode。
@workspace
@workspace 參與者知道如何收集關於您工作區中程式碼的上下文，可以幫助您導航、查詢相關的類、檔案等。想象一下，您在 VS Code 程式碼倉庫中，想了解更多關於負責當前 ICodeEditor 的服務；您可以使用該參與者，像這樣：
使用自然語言向 @workspace 參與者提問：“我用哪個服務類來獲取當前的 ICodeEditor”。然後，參與者會執行以下操作，以獲取恰到好處的上下文傳送給 LLM：
-
vscode 倉庫已被 GitHub Search Blackbird 服務索引。
@workspace參與者使用此索引作為工具來利用倉庫的知識圖譜。@workspace參與者執行語義搜尋，返回相關的程式碼片段和元資料。GitHub 搜尋服務已經索引了排名前 1 萬的 GitHub 倉庫，並計劃增加更多。 -
@workspace參與者使用的下一個工具是在本地索引上進行詞法文字搜尋，以查詢額外的程式碼，例如本地未提交的更改和 Copilot 的對話歷史記錄。 -
然後，
@workspace使用最後一個工具——VS Code 的語言智慧，來新增關鍵細節，如函式簽名、引數，甚至內聯文件。
所有這些上下文資訊都由 @workspace 參與者進行排序、切片和總結，然後傳送給 LLM 來回答問題。
因為它擁有所有必要的上下文，@workspace 參與者可以回答開發者更可能提出的那種問題。例如，關於程式碼不同部分如何互動的問題：
- “
@workspace通知是如何排程的？”
或者需要了解相關程式碼、依賴項和設計模式的問題：
- “
@workspace新增表單驗證，類似於時事通訊頁面”
@vscode
VS Code 的定製方式多種多樣，以至於即使是 VS Code 團隊的成員在發現一些隱藏功能時也會感到驚喜。為了幫助我們的使用者和團隊成員充分發揮 VS Code 的潛力，我們建立了 @vscode 參與者。
該參與者對 VS Code 瞭如指掌，可以幫助您彌合自然語言與 VS Code 命令和定製之間的差距。@vscode 參與者內部使用的工具使其能夠訪問所有設定和命令的索引，我們正在新增一個工具，以便該參與者也可以使用 VS Code 的文件。現在您可以問一些模糊的問題，比如“@vscode vscode 假開啟檔案時那個東西叫什麼？怎麼停用它？”。
請注意，響應中有一個**在設定編輯器中顯示 (Show in Settings Editor)** 按鈕。這是因為 @vscode 參與者不僅知道 VS Code 的工作原理，還有一個工具可以呼叫設定編輯器或命令面板。
此外，命令面板現在支援相似性搜尋，所以您在搜尋命令時不再需要知道確切的名稱。您不再需要說 VS Code 獨特的行話，就能解鎖團隊每個月釋出的所有好功能。
這僅僅是 @vscode 參與者的開始。我們計劃支援越來越多的場景，讓使用者更好地理解和完全控制 VS Code。
斜槓命令
聊天參與者還可以貢獻我們稱之為**斜槓命令**的功能，它們是參與者提供的特定功能的快捷方式。回答問題時的任務之一是確定意圖，理解您想做什麼。
我們可以推斷出“建立一個新的 Node.js Express Pug TypeScript 工作區”意味著您想要一個新專案，但“@workspace /new Node.js Express Pug TypeScript”則明確、簡潔，並節省您的打字時間。
一旦意圖明確，儘管自然語言存在固有的模糊性，@workspace 參與者有更好的機會滿足使用者的需求。@workspace 可以提議一個目錄結構，使用者可以點選提議的檔案進行預覽。還有一個**建立工作區 (Create Workspace)** 按鈕，可以在新資料夾中生成這些檔案。
可擴充套件性
“VS Code 只是一個空殼，你需要擴展才能讓它大放異彩！”——這是從事 VS Code 擴充套件開發的微軟團隊在會議上常說的一句話，自豪地炫耀他們在 VS Code 成功中的作用。我們作為 VS Code 核心團隊，完全同意他們的看法——沒有豐富的擴充套件生態系統，VS Code 不會是今天這個樣子！AI 也不例外，雖然核心 AI 體驗由 Copilot 點亮，但我們的願景是，我們生態系統中的所有擴充套件都可以參與進來，讓 LLM 模型擁有最佳的上下文和基礎。今天，我們透過在提案狀態下新增 聊天參與者 API，為這一願景奠定了基礎。
聊天參與者 API 允許擴充套件貢獻可以回答使用者特定問題的參與者。@workspace 和 @vscode 參與者都是使用這個 API 實現的。透過聊天參與者，使用者可以在編輯器流程中將來自其內部和外部迴圈工具的豐富且最新的資訊帶入 AI 對話。參與者就像某個領域的專家，當用戶在提示中明確提及一個 @participant 時，該提示會被轉發給貢獻該特定參與者的擴充套件。
參與者可以使用 Markdown 來響應簡單的文字和圖片，也可以用檔案樹或按鈕來提供更具互動性的體驗。例如，當參與者提議為使用者建立一個新工作區時，可以使用檔案樹作為預覽。參與者可以為每個響應提供後續操作，可以把它們想象成推動對話進一步發展的建議。為了提供流暢的使用者體驗，整個 API 都是基於流的。如前所述，參與者可以引入斜槓命令——特定功能的快捷方式。例如，@docker 參與者可能會貢獻一個 /generate 斜槓命令，從而產生以下示例使用者提示：“@docker /generate a DOCKERFILE for workspace”。當前明確而簡潔的語法可以方便地節省時間。儘管如此，我們仍在研究意圖檢測，以允許 VS Code 核心根據使用者的自然語言提示自動選擇正確的參與者和斜槓命令。
想象一下，在 VS Code 中直接安裝一個瞭解 Azure 或 Docker 的聊天參與者。或者您可能只需要一個 DALL-E 參與者，它使用影像生成作為工具，展示一個可愛的動物來肯定您做得很好。
參與者可以帶來任何領域特定的內容，同時訪問該領域的工具。例如，1ES 代表 One Engineering System，是微軟內部的工程系統。1ES VS Code 擴充套件貢獻了一個 @1es 參與者，可以為微軟內部工程師回答特定問題。@1es 參與者會動態地規劃並展示它正在做什麼。它使用了一些 LLM 模型中可用的公開資料，但也識別了微軟內部的特性，並將兩者結合起來提供最佳答案。
因為參與者擁有當前上下文，所以它可以繼續討論。
我們還增加了一個 API，允許擴充套件訪問 LLM，並可以選擇使用 LLM 來處理和回答使用者的查詢。目前，這個 API 僅限於那些實現參與者的擴充套件。聊天參與者 API 會將確切的使用者提示傳遞給貢獻的參與者，透過 LLM 訪問，參與者可以方便地將這些語言提示轉換為特定的後端 API 呼叫。我們將謹慎且透明地處理此 API 的使用，以便使用者瞭解參與者使用了多少請求和令牌。
聊天參與者 API 仍處於提案階段，我們正在徵求關於如何改進它的反饋，目標是在不久的將來最終確定該 API。您今天就可以嘗試一些東西，最好的起點是我們的聊天參與者可擴充套件性示例。我們迫不及待地想看到您為開發者創造的由 AI 驅動的創新。
便利性
我們對參與者及其帶來的無限可能性感到非常興奮，但我們也想談談我們在 VS Code 中直接在您的常規工作流程中新增的那些由 Copilot 驅動的便利小互動。您不應該為了利用 AI 而重新學習您的編輯器。
智慧操作
智慧操作無縫整合在您的 VS Code 流程中（例如，在快速修復和上下文選單中），它們完全不需要您編寫任何提示。最強大的智慧操作是 /fix。這裡有一個相對簡單的 TypeScript 快速排序演算法，帶有一個錯誤提示“型別 'number' 的引數不能賦給型別 'never' 的引數”。點選燈泡圖示並選擇**使用 Copilot 修復 (Fix using Copilot)**。
這個選項會開啟內聯聊天，並填充 /fix 和錯誤資訊。在幕後，我們引入了額外的 VS Code 診斷上下文，然後讓 Copilot 提供一個修復方案——更新 left 和 right 陣列以使用正確的型別宣告。
我們注意到 /fix 對於像 shell 指令碼這樣的語言特別有用，因為這些語言的傳統工具支援有時會有所欠缺。
為了使其建議更清晰，Copilot 會嘗試解釋為什麼它提出了特定的修復方案。我們很高興地瞭解到，使用者接受 Copilot 建議的修復方案的比例約為 60%。有時，修復可能與燈泡附近的原始碼無關，而是需要安裝一個缺失的依賴項——在這種情況下，/fix 會提議一個可以在整合終端中執行的命令。
與 /fix 類似，/doc 智慧操作也很受使用者歡迎。要使用 /doc，選擇一段程式碼，右鍵單擊，然後選擇 **Copilot** > **生成文件 (Generate Docs)**。Copilot 會為您的程式碼生成文件註釋，我們相信您會對文件質量感到驚訝。
生成提交和拉取請求訊息
有時意圖非常明確。當這種情況發生時，AI 的體驗會感覺近乎神奇。我現在最喜歡的功能是讓 Copilot 自動生成提交訊息。在安裝了 Copilot 的原始碼管理檢視中，您會在提交訊息欄位旁邊看到一個新的閃光圖示。選擇這個閃光圖示，Copilot 就會為您填寫好訊息！
我對這個體驗非常興奮，前幾天在用 vscode.dev/github 編輯 Markdown 時，我甚至做了這樣一個提交，因為 Copilot 擴充套件還沒有適配 Web。
回到我們的流程，讓我們繼續建立一個拉取請求。我安裝了 GitHub Pull Requests and Issues 擴充套件，它能感知到 Copilot Chat 擴充套件的存在。當我建立一個 PR 時，標題和描述旁邊會出現另一個閃光圖示。選擇它，Copilot 就會自動寫好一段不錯的描述！
這是 AI 可以幫助您提高生產力的另一個領域，它能自動處理您每週要做幾十次甚至上百次的簡單而繁瑣的任務。
說什麼？！
最後，打造一個真正智慧的 AI 意味著讓互動儘可能地輕鬆。
在過去的幾年裡，我們整個行業在語音識別技術方面取得了長足的進步。我們知道很多人一直渴望將語音助手與先進的 LLM 結合起來。現在，您可以在 VS Code 中同時使用這兩者了。
新的 VS Code Speech 擴充套件為 VS Code 帶來了語音轉文字的支援。安裝後，您會在所有自然語言輸入對話方塊中看到一個麥克風圖示。選擇它，向 Copilot 提出您的問題，然後享受魔法吧。
覺得怎麼樣？！我告訴過你，我的夥計聰明絕頂！
該擴充套件仍處於預覽階段，目前只支援英語，但我們會在未來幾個月內繼續更新，增加新的語言和功能。
工作更聰明，而不是更辛苦
以上所有以及更多功能今天都可以在 VS Code 中使用！您只需安裝 GitHub Copilot 擴充套件即可。您可以在我們的文件中瞭解更多關於 Copilot Chat 的功能。
謝謝！
Chris 和 VS Code 團隊
祝您**智慧**程式設計愉快！