入口與使用場景

GitHub Copilot 不是一個單入口產品。它同時出現在 GitHub.com、VS Code、Visual Studio、JetBrains、Xcode、Eclipse、Windows Terminal、Copilot CLI、Cloud Agent 和移動端。學 Copilot 的第一步，是把“任務發生在哪裡”與“應該使用哪個入口”對上——入口選錯，再強的模型也只能在錯誤的上下文裡猜。

這組頁面只處理入口分工。你不需要一次學完所有環境；先把任務放到正確 surface，再進入對應教程。

1. 入口地圖

• GitHub.com：最適合儲存庫、檔案、PR、issue、discussion、commit、安全 alert 的就地提問；不適合處理本地未提交 diff、終端環境和執行測試。
• VS Code：最適合本地編輯、Agent session、inline suggestions、inline chat、customization 和 MCP；不適合只圍繞遠端 PR/issue 協作而不改原生代碼的任務。
• IDE Chat：最適合在 Visual Studio、JetBrains、Xcode、Eclipse 等 IDE 中解釋程式碼、生成測試、修復錯誤；不適合需要 GitHub.com 頁面上下文的 PR/issue 問題。
• Windows Terminal：最適合命令解釋、shell 語法建議和錯誤解釋；不適合自動執行危險命令、部署、刪除和生產操作。
• Copilot CLI：最適合本地 agentic command-line workflow、遠端 steering 和自動化；不適合無命令邊界的生產儲存庫。
• Cloud Agent：最適合非同步任務、分支、PR 和團隊 review；不適合需要你即時操作本地 IDE 的小改動。

flowchart TD
    Task["開發任務"] --> Where{"任務發生在哪裡?"}
    Where -->|儲存庫/PR/issue/alert| GitHub["GitHub.com"]
    Where -->|原生代碼編輯| VSCode["VS Code / IDE Chat"]
    Where -->|命令列問題| Terminal["Windows Terminal / CLI"]
    Where -->|非同步交付 PR| Cloud["Cloud Agent"]
    GitHub --> Review["回到 GitHub 物件驗收"]
    VSCode --> Diff["回到 diff / tests 驗收"]
    Terminal --> Command["人工檢查命令副作用"]
    Cloud --> PR["透過 PR review 驗收"]

    style VSCode fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Terminal fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style PR fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. 本組頁面

3. 選擇原則

不要把所有問題都丟給同一個 Chat 面板。入口選錯，Copilot 不是不會回答，而是會用錯誤上下文回答。

• “這個 PR 改了什麼？”：推薦在 GitHub.com PR 頁面問；回到 PR diff、checks 和 review comments 驗收。
• “當前檔案職責是什麼？”：推薦用 IDE Chat；看 references、當前檔案和呼叫方是否覆蓋完整。
• “幫我補一個小函式”：推薦用 VS Code inline suggestion 或 inline chat；回到本地 diff 和測試驗收。
• “這個命令是什麼意思？”：推薦用 Windows Terminal 或 CLI；執行前人工確認命令沒有危險副作用。
• “修復 failing test 並開 PR”：推薦用 VS Code Agent 或 Cloud Agent；用 test output 和 PR review 驗收。
• “讓 Copilot 使用內部 API”：推薦用 IDE Chat / Agent + MCP；檢查 MCP 許可權、tool 呼叫和審計記錄。

4. 許可權和計費要跟入口一起看

GitHub 官方文件和 VS Code 官方文件都提示：組織或企業管理員可能關閉某些能力，例如 Chat、agents、CLI、模型切換或 MCP。模型選擇也可能影響 premium request usage。

所以團隊 onboarding 不能只寫“開啟 Copilot”。應該寫清楚：

1. 哪些入口允許使用。
2. 哪些入口只讀使用。
3. 哪些入口可以改程式碼。
4. 哪些入口可以執行命令或呼叫 MCP。
5. 使用哪些模型、哪些任務需要人工 review gate。

深讀：為什麼入口分工會影響結果質量

GitHub.com 有 GitHub 物件上下文，適合協作和審查；VS Code 有本地檔案、選區、diff、terminal 和 agent session 上下文，適合編輯和驗證；Terminal 有當前 shell 上下文，適合命令解釋；Cloud Agent 有非同步 PR 上下文，適合交付可 review 的變更。

如果你在瀏覽器裡問本地未提交 diff，它看不到；如果你在終端裡問 PR 需求，它缺少協作上下文；如果你在 IDE 裡讓它解釋 GitHub security alert，卻沒給 alert 頁面，它只能猜。入口不是 UI 偏好，而是上下文邊界。

本組自檢

讀完整組後，用這 4 個問題檢查：

1. 任務發生在 GitHub 物件、原生代碼、終端命令還是非同步 PR？
2. 當前入口能不能看到必要上下文？
3. 當前入口是否可能觸達命令、MCP、生產資源或私有資料？
4. 完成後結果回到哪裡驗收：diff、test、PR、issue、alert、terminal output 還是管理員後臺？

透過標準：你能先選入口，再寫 prompt，而不是先寫一段大 prompt 讓 Copilot 猜上下文。

官方來源

• GitHub Copilot documentation —— Copilot 官方文件總入口，覆蓋 GitHub.com、IDE、CLI、Cloud Agent、MCP、billing 和治理。
• GitHub Copilot in VS Code —— VS Code 官方 Copilot 總覽，覆蓋 agents、inline suggestions、inline chat、smart actions 和 customization。
• GitHub Copilot Chat —— 官方 Chat 入口總覽，覆蓋 IDE、Windows Terminal、GitHub 和 Mobile。

接下來去哪