---
title: "代码建议"
description: "解释 GitHub Copilot 在 IDE 中的 ghost text、next edit suggestions、替代建议、局部接受和模型边界。"
verifiedAt: "2026-05-06"
---

代码建议是 Copilot 最轻量的入口：你写代码时，它在编辑器里给出自动补全式（autocomplete-style）的建议。它适合短反馈，不适合替你完成没有边界的跨模块任务。

GitHub 官方文档把 VS Code 里的建议分成两类：ghost text suggestions（灰字内联建议，跟着光标自动浮现）和 next edit suggestions（下一编辑预测，根据你正在做的编辑预测下一处要改的位置和内容）。

> [!TIP]
> **阅读目标**：读完本章，你应该能安全接受、拒绝、切换和审查 Copilot 代码建议，而不是看到灰色代码就按 `Tab`。

## 1. 支持哪些入口

官方概念页覆盖 Visual Studio Code、JetBrains IDEs、Visual Studio、Eclipse、Vim/Neovim、Azure Data Studio 和 Xcode。不同 IDE 的能力不完全一致：

- **VS Code**：支持 ghost text suggestions 和 next edit suggestions。
- **JetBrains IDEs**：提供 inline suggestions as you type。
- **Visual Studio**：支持 ghost text；next edit suggestions 在官方页中标注为 public preview。
- **Xcode / Eclipse**：支持 ghost text，并有 next edit suggestions 相关说明。
- **Vim/Neovim / Azure Data Studio**：主要是 inline suggestions。

```mermaid
flowchart TD
    Edit["你正在编辑代码"] --> Context["当前文件 / 光标 / 已打开文件"]
    Context --> Ghost["Ghost text suggestion"]
    Context --> Next["Next edit suggestion"]
    Ghost --> Accept{"接受?"}
    Next --> Accept
    Accept -->|Tab / partial accept| Diff["查看相邻代码和 diff"]
    Accept -->|Esc| Continue["继续手写或重试"]
    Diff --> Test["运行测试或类型检查"]

    style Ghost fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Next fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style Test fill:#dcfce7,stroke:#16a34a,stroke-width:2px
```

## 2. 什么时候用代码建议

适合：

- 你已经知道要写什么，只需要补局部实现。
- 你要快速写测试样板、SQL、API 调用、framework boilerplate。
- 你在同一个文件里延续已有模式。
- 你想用自然语言注释描述小目标，让 Copilot 给出实现草案。

不适合：

- 需求需要先设计方案。
- 改动跨多个目录或需要查上下游调用。
- 需要调用工具、运行命令或处理 PR 协作。
- 涉及鉴权、支付、数据删除、生产脚本等高风险逻辑。

## 3. 接受、拒绝和替代建议

官方操作页说明，Copilot 可能对同一输入给出多个建议。你可以接受当前建议，也可以查看替代建议，或者全部拒绝。

基础规则：

- `Tab` 接受建议。
- `Esc` 拒绝建议。
- macOS 上常见替代建议快捷键是 `Option` + `]` / `Option` + `[`.
- Windows 或 Linux 上常见替代建议快捷键是 `Alt` + `]` / `Alt` + `[`.
- 有些 IDE 支持打开多个建议的新 tab。
- 只想接受下一词或下一行时，用 partial accept，不要整段接受。

商业项目里，不要把“接受建议”当成结束。正确闭环是：

1. 接受一小块。
2. 看相邻代码是否被破坏。
3. 看格式、命名、错误处理是否符合项目。
4. 跑局部测试或类型检查。
5. 再决定是否继续让 Copilot 补下一块。

## 4. 模型切换不是万能开关

官方概念页说明，某些入口可以切换 inline suggestion 使用的 AI model，但前提是有可用替代模型，并且 IDE 和 Copilot extension 满足版本条件。

关键边界：

- 模型切换只影响 ghost text suggestions。
- 它不影响 next edit suggestions。
- 它不影响 Copilot Chat 的模型。
- 可选模型列表会随时间变化。
- Free plan 的 completions 会计入 quota，不因换模型而绕过。
- Suggestions matching public code 策略不因换模型而失效。

所以模型切换适合微调补全体验，不适合解决上下文错误、需求不清或测试缺失。

## 5. 公开代码匹配要单独看

GitHub 官方说明，Copilot 会检查建议是否匹配公开可用代码。匹配结果会根据个人或组织的 Suggestions matching public code 策略，被丢弃或以 code reference 形式展示。

处理方式：

- 如果组织选择 block，匹配建议可能不会展示。
- 如果允许展示匹配，开发者需要查看来源和许可证。
- 如果建议来自常见算法或样板，也要按团队策略处理 attribution。
- 如果你改写了建议，仍然要对最终代码负责。

## 6. 一个安全使用模板

```text
目标：
补当前函数的边界处理

限制：
只改这个函数
不要引入新依赖

验收：
先看 diff
再跑当前测试文件
```

这段不是给 Copilot 的固定模板，而是给使用者的思考顺序。代码建议越短，越要把验收放在自己手里。

<details>
<summary>深读：为什么代码建议看似低风险，实际需要流程</summary>

代码建议进入项目的成本极低，一次 `Tab` 就能把代码写进文件。风险也在这里：它不一定理解业务边界、异常处理、许可证、性能约束和安全要求。

真正可上线的用法，是把 Copilot 当成快速草拟器。它帮你少打字，但你负责判断它是否符合项目、测试和审查要求。
</details>

## 本章自检

完成本章后，用这 4 个问题检查：

1. 当前建议是 ghost text 还是 next edit suggestion？
2. 接受前是否看清它会改哪一段？
3. 接受后是否跑了最小测试、类型检查或人工 review？
4. 如果出现公开代码匹配，你知道该去哪里看来源和许可证吗？

通过标准：你能把代码建议控制在小步、可回滚、可测试的范围内。

## 官方来源

- [GitHub Copilot code suggestions in your IDE](https://docs.github.com/en/copilot/concepts/completions/code-suggestions) —— 官方概念页，覆盖各 IDE、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) —— 官方操作页，覆盖接受、拒绝、替代建议和局部接受。
- [GitHub Copilot features](https://docs.github.com/en/copilot/get-started/features) —— 官方功能页，用于核对 inline suggestions 在 Copilot 功能体系中的位置。

## 接下来去哪

<Cards>
  <Card title="代码引用与匹配" description="继续学习公开代码匹配、引用日志和许可证审查。" href="/docs/github-copilot/official/02-code-suggestions-and-chat/code-referencing" />
  <Card title="提示词写法" description="当任务超过局部补全时，继续学习 Chat prompt 怎么写。" href="/docs/github-copilot/official/02-code-suggestions-and-chat/prompt-engineering" />
</Cards>
