GitHub.com 上的 Copilot
說明 GitHub 網站中的 Copilot Chat 如何圍繞儲存庫、檔案、PR、issue、security alert、dashboard 和搜尋框工作。
GitHub.com 上的 Copilot 不是本地編輯器替代品。它最適合圍繞 GitHub 已經存在的協作物件提問：repository、file、pull request、issue、discussion、commit、安全 alert、dashboard。
官方文件反覆強調一個核心事實：Copilot Chat 在 GitHub 上會根據你所在的位置給出不同響應。也就是說，GitHub.com 入口的價值在於“就地理解 GitHub 上下文”，而不是讓你把原生代碼、終端日誌和 PR 內容來回複製。
閱讀目標：讀完本章，你應該能判斷一個問題是否適合在 GitHub.com 上問 Copilot，以及問完以後應該回到哪裡驗收。
1. GitHub.com 入口適合什麼
官方 “Getting started with prompts for Copilot Chat on GitHub” 把提示分成幾類：
| 場景 | 先進入哪裡 | 適合問什麼 |
|---|---|---|
| 通用軟體問題 | github.com/copilot 或任意頁面 Chat | 語言、框架、命令、一般開發概念 |
| 儲存庫問題 | repository 頁面 | 儲存庫目的、結構、歷史、某功能在哪裡實現 |
| 檔案和程式碼 | 檔案頁面或選中程式碼行 | 解釋檔案、改進程式碼、生成測試 |
| Pull request | PR 頁面 | 總結變更、解釋檔案、失敗 workflow 原因 |
| Security alert | code scanning / secret scanning / Dependabot alert | alert 指向哪裡、如何修復 |
| Issue / Discussion / Commit | 對應頁面 | 目的、預期輸出、討論上下文 |
flowchart TD
Question["要問 Copilot 的問題"] --> Context{"上下文在 GitHub 哪個物件裡?"}
Context --> Repo["Repository"]
Context --> File["File / selected lines"]
Context --> PR["Pull request"]
Context --> Alert["Security alert"]
Context --> Issue["Issue / Discussion / Commit"]
Repo --> Verify["回到儲存庫結構或歷史驗證"]
File --> Verify
PR --> Verify["回到 PR diff / checks / review 驗證"]
Alert --> Verify["回到 alert 和修復 PR 驗證"]
Issue --> Verify["回到 issue / discussion / commit 驗證"]
style PR fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Alert fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 進入方式
官方 “Asking GitHub Copilot questions in GitHub” 頁面說明，Copilot Chat 可以從 GitHub 任意頁面使用。常見入口包括：
- 直接訪問
https://github.com/copilot。 - 在 GitHub 頁面頂部開啟 Copilot Chat。
- 在儲存庫搜尋框裡輸入問題並選擇 Ask Copilot。
- 從 dashboard 的 prompt box 提問。
- 在儲存庫、檔案、PR、issue、discussion、commit 或 alert 頁面提問。
儲存庫搜尋框適合問整個 repository：
这个仓库的核心做了什么？
鉴权是在代码库的哪个部分实现的？
license 文件检测在这个仓库里是怎么工作的？提問前先確認你所在頁面。問“這個 job 為什麼失敗”應該在 PR 或 Actions 相關上下文裡問；問“這個 issue 要解決什麼”應該在 issue 頁面問。
3. 問法要貼近物件
GitHub.com Chat 的提示詞不需要很長，但要把物件說清。
| 頁面 | 更好的問題 | 不好的問題 |
|---|---|---|
| Repository | “這個儲存庫的主要入口和測試目錄在哪裡？” | “幫我理解一下這個專案” |
| File | “解釋這個檔案負責什麼，並指出我修改前要看哪些呼叫方。” | “最佳化一下” |
| Pull request | “總結這個 PR 改了哪些行為，並列出需要重點 review 的檔案。” | “這個 PR 可以合併嗎？” |
| Failed check | “這個 job failed 的直接錯誤是什麼？下一步應該在哪個檔案驗證？” | “為什麼失敗” |
| Security alert | “這個 alert 指向哪行程式碼？修復方案會影響哪些呼叫方？” | “修好安全問題” |
GitHub.com Chat 的回答仍然需要審查。PR 要回到 diff 和 checks；issue 要回到需求上下文；security alert 要回到 alert、修復程式碼和安全掃描結果。
4. 模型、subthreads 和圖片
官方頁面還說明了幾個互動能力：
- 可以從 model dropdown 選擇不同 AI model。
- 不同模型可能有不同 premium request multiplier，會影響 monthly usage allowance。
- Business 組織使用者是否能切換模型，取決於組織策略。
- 可以用 subthreads 在同一 conversation 裡探索問題分支。
- 圖片輸入處於 public preview，需要選擇支援圖片的模型。
這類能力不要寫死成團隊固定規則。模型、倍率和 preview 狀態變化快；教程只保留用法和風險邊界。
5. 分享對話前先判斷許可權
官方文件說明，分享 Copilot Chat conversation 處於 public preview，並且共享內容可能是 public 或 permission-based，取決於引用內容。例如關於 private repository 的 conversation，接收者需要有許可權才能檢視。
還要注意一個關鍵點：一旦分享 conversation，後續訊息也會被連結可見。
分享前檢查：
- 是否引用 private repository。
- 是否包含客戶名、內部路徑、token、日誌、未公開 PR。
- 是否會在後續 follow-up 裡繼續暴露上下文。
- 接收者是否有必要許可權。
深讀：為什麼 GitHub.com Chat 不能替代本地 IDE
GitHub.com Chat 能很好地理解 GitHub 物件：儲存庫、檔案、PR、issue、alert、discussion、commit。它不負責你的本地環境狀態，例如當前未提交 diff、未儲存檔案、環境變數、終端輸出和本地測試結果。
因此，GitHub.com Chat 適合分析和協作；真正修改程式碼、跑測試、檢查本地 diff，仍然要回到 IDE、CLI 或 PR 工作流。把兩者混用時，必須明確“哪一步在 GitHub 上問，哪一步回本地驗證”。
6. 推薦工作流
一個適合團隊的 GitHub.com Chat 流程：
- 在 issue 頁面讓 Copilot 總結需求和未決問題。
- 在 repository 頁面問相關程式碼入口。
- 在 PR 頁面讓 Copilot 總結變更和失敗 checks。
- 人工 review diff 和測試結果。
- 如果需要改程式碼，回到 IDE 或 Cloud Agent。
- 把最終判斷寫回 PR review 或 issue comment。
這條鏈路能避免上下文散落：需求在 issue，程式碼在 repo，變更在 PR，驗證在 checks。
本章自檢
完成本章後，用這 4 個問題檢查：
- 你的問題應該在 repo、file、PR、issue、alert 還是 dashboard 上問？
- Copilot 回答後，你會回到哪個 GitHub 物件驗收？
- 你是否知道模型切換可能受組織策略和 premium request multiplier 影響？
- 分享 conversation 前，是否檢查了許可權、私有內容和後續訊息可見性？
透過標準：你能把 GitHub.com Copilot 用在協作物件上，而不是把它當成沒有上下文的網頁聊天。
官方來源
- Getting started with prompts for Copilot Chat on GitHub —— 官方 GitHub.com Chat 提示示例，覆蓋 repository、file、PR、security alert、issue/discussion/commit。
- Asking GitHub Copilot questions in GitHub —— 官方 GitHub 網站 Chat 使用說明，覆蓋
github.com/copilot、搜尋框、dashboard、模型切換、subthreads、圖片和分享。