---
title: "補全與 Chat"
description: "按 GitHub 官方文件梳理 Copilot 程式碼建議、程式碼引用、提示詞寫法和響應定製的使用邊界。"
verifiedAt: "2026-05-06"
---

這一組處理 Copilot 最常用、也最容易被誤用的兩類能力：編輯器裡的程式碼建議，以及 Chat 裡的對話式生成。真正的分界不是“一個自動補全，一個聊天”，而是它們拿到的上下文、修改程式碼的方式和驗收入口不同——把它們用反了，速度快但質量塌。

GitHub 官方把 code suggestions 放在 completions 能力下，把 prompt engineering 和 response customization 放在 prompting 能力下。學習時應該一起看：建議負責短反饋，Chat 負責解釋、計劃和多輪澄清，定製能力負責長期注入專案約定。

> [!TIP]
> **閱讀目標**：讀完本組索引，你應該能判斷一個任務該用 inline suggestion、Chat prompt、自定義指令還是程式碼引用審查。

## 1. 能力地圖

- **程式碼建議**：在 IDE 中邊寫邊給 ghost text 或 next edit suggestions，適合區域性補全、小函式、測試骨架和樣板程式碼。
- **程式碼引用與匹配**：當 Copilot 建議與公開程式碼匹配時，幫助你檢視來源、許可證和處理方式。
- **提示詞寫法**：把目標、上下文、例子、約束和驗收標準寫清楚，減少含混 prompt。
- **響應定製**：用個人、儲存庫、組織或 agent instructions 持續注入穩定規則，減少每次重複解釋專案約定。

```mermaid
flowchart TD
    Task["當前任務"] --> Small{"是否區域性編輯?"}
    Small -->|是| Suggest["程式碼建議"]
    Small -->|否| Chat["Copilot Chat"]
    Suggest --> Match{"出現公開程式碼匹配?"}
    Match -->|是| Ref["程式碼引用審查"]
    Match -->|否| Review["diff / test 驗收"]
    Chat --> Prompt["提示詞寫法"]
    Prompt --> Custom{"規則會反覆使用?"}
    Custom -->|是| Instructions["響應定製"]
    Custom -->|否| Review
    Ref --> Review
    Instructions --> Chat

    style Suggest fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Ref fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style Review fill:#dcfce7,stroke:#16a34a,stroke-width:2px
```

## 2. 本組頁面

<Cards>
  <Card title="程式碼建議" description="理解 ghost text、next edit suggestions、替代建議、區域性接受和模型切換邊界。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/code-suggestions" />
  <Card title="程式碼引用與匹配" description="處理公開程式碼匹配、引用日誌、許可證資訊和團隊審查流程。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/code-referencing" />
  <Card title="提示詞寫法" description="把 Copilot prompt 拆成目標、上下文、例子、約束、迭代和驗收。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/prompt-engineering" />
  <Card title="響應定製" description="用 personal、repository、organization 和 agent instructions 固化專案約定。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/response-customization" />
</Cards>

## 3. 使用順序

第一次給團隊做 Copilot onboarding，不要直接從“怎麼寫 prompt”開始。更穩的順序是：

1. 先讓成員理解程式碼建議的邊界：它適合短反饋，不適合無審查地替你改跨模組邏輯。
2. 再講程式碼引用：看到相似程式碼提示時，不要忽略來源和許可證。
3. 再講 prompt：目標、上下文、例子和驗收寫清楚。
4. 最後講定製：把穩定規則沉澱為 instructions，把一次性任務留在 prompt 裡。

## 4. 商業級檢查

上線前至少檢查這幾件事：

- IDE 是否是官方支援入口，Copilot extension 是否為最新可用版本。
- 組織是否設定了 Suggestions matching public code 策略。
- 團隊是否知道 `Tab` 接受、`Esc` 拒絕、替代建議和區域性接受的區別。
- 專案是否有儲存庫級 instructions，並且沒有把金鑰、賬號、內網地址寫進去。
- prompt 是否明確驗收方式：diff、test、typecheck、PR review 或引用審查。

<details>
<summary>深讀：為什麼補全和 Chat 必須一起治理</summary>

程式碼建議看起來是區域性補全，但它仍可能生成需要審查的程式碼；Chat 看起來只是問答，但它也可能輸出可複製進專案的實現。兩者共同風險是：使用者把“看起來合理”當成“已經正確”。

商業專案要把它們放進同一個審查框架：建議可以快，但接受前看上下文；Chat 可以解釋和生成，但落地前必須回到檔案、測試、引用和策略。
</details>

## 本組自檢

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

1. 當前任務是區域性補全、對話生成、長期規則，還是程式碼來源審查？
2. Copilot 能看到哪些上下文，哪些上下文不該給它？
3. 接受建議前是否看過相鄰程式碼、diff 和測試入口？
4. 出現公開程式碼匹配時，團隊是否知道去哪裡看來源和許可證？

透過標準：你能把 Copilot 補全與 Chat 放進可審查流程，而不是隻依賴一次生成結果。

## 官方來源

- [GitHub Copilot code suggestions in your IDE](https://docs.github.com/en/copilot/concepts/completions/code-suggestions) —— 官方概念頁，覆蓋 ghost text、next edit suggestions、公開程式碼匹配和模型切換。
- [Getting code suggestions in your IDE with GitHub Copilot](https://docs.github.com/en/copilot/how-tos/get-code-suggestions/get-ide-code-suggestions) —— 官方操作頁，覆蓋接受、拒絕、替代建議和區域性接受。
- [Prompt engineering for GitHub Copilot Chat](https://docs.github.com/en/copilot/concepts/prompting/prompt-engineering) —— 官方 prompting 策略頁。
- [About customizing GitHub Copilot responses](https://docs.github.com/en/copilot/concepts/prompting/response-customization) —— 官方響應定製頁。

## 接下來去哪

<Cards>
  <Card title="程式碼建議" description="如果你主要在編輯器裡接收補全，從這裡開始。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/code-suggestions" />
  <Card title="提示詞寫法" description="如果你主要用 Chat 解釋、生成和重構，從這裡開始。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/prompt-engineering" />
</Cards>
