补全与 Chat
按 GitHub 官方文档梳理 Copilot 代码建议、代码引用、提示词写法和响应定制的使用边界。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| 补全与对话 | suggestions & chat | Copilot 最基础的两类能力。 |
| 何时用哪个 | which | 联想补全 vs 主动提问。 |
| 上下文质量 | context | 决定建议好坏的关键。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你分清 Copilot 补全和 Chat 各管什么、怎么配合。
你是 Copilot 补全与对话导航顾问。
【角色】
Copilot 补全与对话导航顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 我现在的任务：___
- 倾向被动补全还是主动问：___
- 项目上下文是否充分：___
- 想提升的点：___
- 经验水平：___
【工作流程】
1. 区分补全和 Chat 的适用场景
2. 对照任务给选择
3. 说明怎么提升上下文质量
4. 给两者配合用法
5. 给第一步
【输出规范】
▌一、补全 vs Chat
▌二、按任务选
▌三、提升上下文
▌四、配合用法 + 第一步
【硬约束】
- 按任务选能力，不混用
- 上下文质量优先
- 建议结果自己核验
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或权限一律以官方文档为准，禁止照搬过时写法这一组处理 Copilot 最常用、也最容易被误用的两类能力：编辑器里的代码建议，以及 Chat 里的对话式生成。真正的分界不是“一个自动补全，一个聊天”，而是它们拿到的上下文、修改代码的方式和验收入口不同——把它们用反了，速度快但质量塌。
GitHub 官方把 code suggestions 放在 completions 能力下，把 prompt engineering 和 response customization 放在 prompting 能力下。学习时应该一起看：建议负责短反馈，Chat 负责解释、计划和多轮澄清，定制能力负责长期注入项目约定。
阅读目标：读完本组索引，你应该能判断一个任务该用 inline suggestion、Chat prompt、自定义指令还是代码引用审查。
1. 能力地图
- 代码建议：在 IDE 中边写边给 ghost text 或 next edit suggestions，适合局部补全、小函数、测试骨架和样板代码。
- 代码引用与匹配：当 Copilot 建议与公开代码匹配时，帮助你查看来源、许可证和处理方式。
- 提示词写法：把目标、上下文、例子、约束和验收标准写清楚，减少含混 prompt。
- 响应定制：用个人、仓库、组织或 agent instructions 持续注入稳定规则，减少每次重复解释项目约定。
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:2px2. 本组页面
代码建议
理解 ghost text、next edit suggestions、替代建议、局部接受和模型切换边界。
代码引用与匹配
处理公开代码匹配、引用日志、许可证信息和团队审查流程。
提示词写法
把 Copilot prompt 拆成目标、上下文、例子、约束、迭代和验收。
响应定制
用 personal、repository、organization 和 agent instructions 固化项目约定。
3. 使用顺序
第一次给团队做 Copilot onboarding，不要直接从“怎么写 prompt”开始。更稳的顺序是：
- 先让成员理解代码建议的边界：它适合短反馈，不适合无审查地替你改跨模块逻辑。
- 再讲代码引用：看到相似代码提示时，不要忽略来源和许可证。
- 再讲 prompt：目标、上下文、例子和验收写清楚。
- 最后讲定制：把稳定规则沉淀为 instructions，把一次性任务留在 prompt 里。
4. 商业级检查
上线前至少检查这几件事：
- IDE 是否是官方支持入口，Copilot extension 是否为最新可用版本。
- 组织是否设置了 Suggestions matching public code 策略。
- 团队是否知道
Tab接受、Esc拒绝、替代建议和局部接受的区别。 - 项目是否有仓库级 instructions，并且没有把密钥、账号、内网地址写进去。
- prompt 是否明确验收方式：diff、test、typecheck、PR review 或引用审查。
深读：为什么补全和 Chat 必须一起治理
代码建议看起来是局部补全，但它仍可能生成需要审查的代码；Chat 看起来只是问答，但它也可能输出可复制进项目的实现。两者共同风险是：用户把“看起来合理”当成“已经正确”。
商业项目要把它们放进同一个审查框架：建议可以快，但接受前看上下文；Chat 可以解释和生成，但落地前必须回到文件、测试、引用和策略。
本组自检
读完整组后，用这 4 个问题检查：
- 当前任务是局部补全、对话生成、长期规则，还是代码来源审查？
- Copilot 能看到哪些上下文，哪些上下文不该给它？
- 接受建议前是否看过相邻代码、diff 和测试入口？
- 出现公开代码匹配时，团队是否知道去哪里看来源和许可证？
通过标准：你能把 Copilot 补全与 Chat 放进可审查流程，而不是只依赖一次生成结果。
官方来源
- GitHub Copilot code suggestions in your IDE —— 官方概念页，覆盖 ghost text、next edit suggestions、公开代码匹配和模型切换。
- Getting code suggestions in your IDE with GitHub Copilot —— 官方操作页，覆盖接受、拒绝、替代建议和局部接受。
- Prompt engineering for GitHub Copilot Chat —— 官方 prompting 策略页。
- About customizing GitHub Copilot responses —— 官方响应定制页。