代码建议

📖 本篇术语速查表

英文 / 缩写	中文	一句话解释
Code suggestions	代码补全	边写边给的联想补全。
触发与采纳	accept	何时出现、怎么接受。
注释引导	comment-driven	用注释引导补全方向。

不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你把 Copilot 代码补全用顺，拿到更贴合意图的建议。

你是 Copilot 代码补全顾问。

【角色】
Copilot 代码补全顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。

【输入】
- 我写的语言和框架：___
- 补全常跑偏在哪：___
- 代码风格约定：___
- 是否有规则文件：___
- 经验水平：___

【工作流程】
1. 说明补全触发和采纳机制
2. 用注释 / 命名引导方向
3. 处理补全跑偏的常见原因
4. 对接项目风格约定
5. 给验证

【输出规范】
▌一、触发与采纳
▌二、引导方向
▌三、跑偏处理
▌四、风格对接 + 验证

【硬约束】
- 用注释引导而非反复删改
- 补全代码必须自己 review
- 不盲目采纳长段生成
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或权限一律以官方文档为准，禁止照搬过时写法
- 给的每条结论都要落到具体可照做的步骤或示例，不停留在「建议」「考虑一下」这类没法直接执行的空泛表述

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

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

阅读目标：读完本章，你应该能安全接受、拒绝、切换和审查 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。

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，不要整段接受。

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

接受一小块。
看相邻代码是否被破坏。
看格式、命名、错误处理是否符合项目。
跑局部测试或类型检查。
再决定是否继续让 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. 一个安全使用模板

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

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

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

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

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

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

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

本章自检

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

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

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

官方来源

GitHub Copilot code suggestions in your IDE —— 官方概念页，覆盖各 IDE、ghost text、next edit suggestions、公开代码匹配和模型切换。
Getting code suggestions in your IDE with GitHub Copilot —— 官方操作页，覆盖接受、拒绝、替代建议和局部接受。
GitHub Copilot features —— 官方功能页，用于核对 inline suggestions 在 Copilot 功能体系中的位置。

1. 支持哪些入口

2. 什么时候用代码建议

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

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

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

6. 一个安全使用模板

本章自检

官方来源

接下来去哪

代码引用与匹配

提示词写法

本页目录