---
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="/docs/github-copilot/official/02-code-suggestions-and-chat/code-suggestions" />
  <Card title="代码引用与匹配" description="处理公开代码匹配、引用日志、许可证信息和团队审查流程。" href="/docs/github-copilot/official/02-code-suggestions-and-chat/code-referencing" />
  <Card title="提示词写法" description="把 Copilot prompt 拆成目标、上下文、例子、约束、迭代和验收。" href="/docs/github-copilot/official/02-code-suggestions-and-chat/prompt-engineering" />
  <Card title="响应定制" description="用 personal、repository、organization 和 agent instructions 固化项目约定。" href="/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="/docs/github-copilot/official/02-code-suggestions-and-chat/code-suggestions" />
  <Card title="提示词写法" description="如果你主要用 Chat 解释、生成和重构，从这里开始。" href="/docs/github-copilot/official/02-code-suggestions-and-chat/prompt-engineering" />
</Cards>
