使用語言服務器為 GitHub Copilot CLI 提供真正的代碼智能

您是否曾見過 GitHub Copilot CLI 將 JAR 文件解壓到臨時目錄，通過 grep 搜索 .class 文件，然後從原始字節碼中拼湊出 API 簽名？代理雖然足智多謀，但沒有語言服務器，這是它最好的表現。

語言服務器協議（LSP）是驅動 VS Code 等編輯器中“轉到定義”、“查找引用”和類型解析的標準。它在終端中同樣適用。LSP 設置技能可自動安裝和配置 Copilot CLI 的 LSP 服務器，使代理能夠獲得關於代碼的精確、結構化答案，而不是依賴文本搜索啓發式方法。

在本文中，您將瞭解該技能的內部工作原理、它生成的配置格式，併為其目前支持的 14 種語言中的任何一種進行設置。

問題：啓發式代碼理解

在沒有 LSP 服務器的情況下，GitHub Copilot CLI 中的代理通過文本搜索和二進制提取逆向工程 API 信息。對於 Java 項目，這可能看起來像：

查找依賴 JAR

find ~/.m2/repository -name "*httpclient*.jar"

解壓到臨時目錄

mkdir /tmp/httpclient && cd /tmp/httpclient jar xf ~/.m2/repository/org/apache/httpcomponents/httpclient/4.5.14/httpclient-4.5.14.jar

搜索提取的類文件中的方法

grep -r "execute" --include="*.class" .

對於 Python，代理可能會 cat site-packages 內的文件。對於 TypeScript，它會遍歷 node_modules。這些基於文本的方法適用於簡單情況，但它們在原始文本上進行模式匹配，而不是真正的語義分析，因此會遺漏泛型、重載和傳遞類型，並且根本無法查看編譯後的字節碼。這正是語言服務器彌補的差距。

LSP 服務器從結構上解決了這個問題。當代理髮送某個符號的 textDocument/definition 請求時，語言服務器返回精確的源位置、完全解析的類型和簽名。

LSP 設置技能的工作原理

觸發後，該技能執行一個七步工作流：

1. 語言選擇

代理使用 ask_user 提供一組選擇，以確定用户需要 LSP 支持的語言。這一步驅動所有後續步驟。

1. 操作系統檢測

代理運行 uname -s（或在 Windows 上檢查 $env:OS / %OS%）來確定目標平台。安裝命令因操作系統而異。例如，在 macOS 上使用 brew install jdtls，在 Linux 上則從 eclipse.org 下載。

1. LSP 服務器查找

該技能包含一個參考文件（references/lsp-servers.md），其中包含 14 種語言的精選數據：每個操作系統的安裝命令、二進制名稱和現成的配置片段。代理讀取該文件並選擇匹配的條目。

1. 配置範圍

代理詢問配置應應用於：

用户級別：~/.copilot/lsp-config.json — 應用於所有倉庫

倉庫級別：倉庫根目錄下的 lsp.json 或 .github/lsp.json — 限定於單個項目

如果兩者都存在，倉庫級別的配置優先。

1. 安裝

代理運行相應的安裝命令。例如：

任何操作系統上的 TypeScript

npm install -g typescript typescript-language-server

macOS 上的 Java

brew install jdtls

任何操作系統上的 Rust

rustup component add rust-analyzer

1. 配置

代理將條目寫入或合併到所選配置文件。格式使用 lspServers 對象，其中每個鍵是服務器標識符：

{ "lspServers": { "java": { "command": "jdtls", "args": [], "fileExtensions": { ".java": "java" } } } }

該技能強制執行的關鍵規則：

command 必須在 $PATH 上或是絕對路徑

args 通常包含 "--stdio" 用於標準 I/O 傳輸（某些服務器如 jdtls 內部處理此操作）

fileExtensions 將每個擴展名（帶前導點）映射到語言標識符

配置文件中的現有條目將被保留 — 代理進行合併，從不覆蓋

1. 驗證

代理運行 which（或在 Windows 上運行 where.exe）以確認服務器可訪問，然後驗證配置文件是否為格式正確的 JSON。

支持的語言

該技能為多種編程語言預定義了一組語言服務器。如果編碼代理遇到尚未映射的語言，它將搜索合適的服務器並引導您進行手動配置。

設置後的變化

一旦配置了 LSP 服務器，CLI 代理可以：

跨依賴項解析類型 — 不再需要 grep 搜索 JAR 文件或 node_modules

跳轉到第三方庫中的定義，即使源代碼未檢入倉庫

在整個項目中查找對某個符號的所有引用

讀取任何函數、類或類型的懸停文檔

這意味着代理在工具調用上花費的時間更少，並在第一次通過時產生更準確的代碼。對您來説，這意味着更少的時間等待代理解壓縮 JAR 文件或 grep 搜索 node_modules 來回答您的 IDE 已經知道的問題，更少基於錯誤簽名的錯誤轉向。代理以與您的編輯器中“轉到定義”相同的結構化理解來推理您的代碼，因此您可以交給它更大、更棘手的任務並信任結果。

開始使用

下載技能：訪問 Awesome Copilot LSP 設置技能頁面，點擊下載按鈕獲取 ZIP 文件。

將 ZIP 解壓到 ~/.copilot/skills/：運行

unzip lsp-setup.zip -d ~/.copilot/skills/

重啓 GitHub Copilot CLI：如果 Copilot CLI 已在運行，先輸入 /exit。然後重新啓動 copilot，以便它拾取新技能。

要求代理設置語言服務器：例如，“為 Java 設置 LSP”或“啓用 Python 的代碼智能”。

驗證：技能安裝並配置 LSP 服務器後，再重啓一次 Copilot CLI（/exit，然後重新啓動），運行 /lsp 檢查服務器狀態，然後嘗試在其中一個依賴項中的符號上使用轉到定義。

該技能是 Awesome Copilot 項目的一部分。它是開源的，因此歡迎貢獻和反饋！