GitHub.com 上的 Copilot
说明 GitHub 网站中的 Copilot Chat 如何围绕仓库、文件、PR、issue、security alert、dashboard 和搜索框工作。
GitHub.com 上的 Copilot 不是本地编辑器替代品。它最适合围绕 GitHub 已经存在的协作对象提问：repository、file、pull request、issue、discussion、commit、安全 alert、dashboard。
官方文档反复强调一个核心事实：Copilot Chat 在 GitHub 上会根据你所在的位置给出不同响应。也就是说，GitHub.com 入口的价值在于“就地理解 GitHub 上下文”，而不是让你把本地代码、终端日志和 PR 内容来回复制。
阅读目标：读完本章，你应该能判断一个问题是否适合在 GitHub.com 上问 Copilot，以及问完以后应该回到哪里验收。
1. GitHub.com 入口适合什么
官方 “Getting started with prompts for Copilot Chat on GitHub” 把提示分成几类：
| 场景 | 先进入哪里 | 适合问什么 |
|---|---|---|
| 通用软件问题 | github.com/copilot 或任意页面 Chat | 语言、框架、命令、一般开发概念 |
| 仓库问题 | repository 页面 | 仓库目的、结构、历史、某功能在哪里实现 |
| 文件和代码 | 文件页面或选中代码行 | 解释文件、改进代码、生成测试 |
| Pull request | PR 页面 | 总结变更、解释文件、失败 workflow 原因 |
| Security alert | code scanning / secret scanning / Dependabot alert | alert 指向哪里、如何修复 |
| Issue / Discussion / Commit | 对应页面 | 目的、预期输出、讨论上下文 |
flowchart TD
Question["要问 Copilot 的问题"] --> Context{"上下文在 GitHub 哪个对象里?"}
Context --> Repo["Repository"]
Context --> File["File / selected lines"]
Context --> PR["Pull request"]
Context --> Alert["Security alert"]
Context --> Issue["Issue / Discussion / Commit"]
Repo --> Verify["回到仓库结构或历史验证"]
File --> Verify
PR --> Verify["回到 PR diff / checks / review 验证"]
Alert --> Verify["回到 alert 和修复 PR 验证"]
Issue --> Verify["回到 issue / discussion / commit 验证"]
style PR fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Alert fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 进入方式
官方 “Asking GitHub Copilot questions in GitHub” 页面说明，Copilot Chat 可以从 GitHub 任意页面使用。常见入口包括：
- 直接访问
https://github.com/copilot。 - 在 GitHub 页面顶部打开 Copilot Chat。
- 在仓库搜索框里输入问题并选择 Ask Copilot。
- 从 dashboard 的 prompt box 提问。
- 在仓库、文件、PR、issue、discussion、commit 或 alert 页面提问。
仓库搜索框适合问整个 repository：
这个仓库的核心做了什么？
鉴权是在代码库的哪个部分实现的？
license 文件检测在这个仓库里是怎么工作的？提问前先确认你所在页面。问“这个 job 为什么失败”应该在 PR 或 Actions 相关上下文里问；问“这个 issue 要解决什么”应该在 issue 页面问。
3. 问法要贴近对象
GitHub.com Chat 的提示词不需要很长，但要把对象说清。
| 页面 | 更好的问题 | 不好的问题 |
|---|---|---|
| Repository | “这个仓库的主要入口和测试目录在哪里？” | “帮我理解一下这个项目” |
| File | “解释这个文件负责什么，并指出我修改前要看哪些调用方。” | “优化一下” |
| Pull request | “总结这个 PR 改了哪些行为，并列出需要重点 review 的文件。” | “这个 PR 可以合并吗？” |
| Failed check | “这个 job failed 的直接错误是什么？下一步应该在哪个文件验证？” | “为什么失败” |
| Security alert | “这个 alert 指向哪行代码？修复方案会影响哪些调用方？” | “修好安全问题” |
GitHub.com Chat 的回答仍然需要审查。PR 要回到 diff 和 checks；issue 要回到需求上下文；security alert 要回到 alert、修复代码和安全扫描结果。
4. 模型、subthreads 和图片
官方页面还说明了几个交互能力：
- 可以从 model dropdown 选择不同 AI model。
- 不同模型可能有不同 premium request multiplier，会影响 monthly usage allowance。
- Business 组织用户是否能切换模型，取决于组织策略。
- 可以用 subthreads 在同一 conversation 里探索问题分支。
- 图片输入处于 public preview，需要选择支持图片的模型。
这类能力不要写死成团队固定规则。模型、倍率和 preview 状态变化快；教程只保留用法和风险边界。
5. 分享对话前先判断权限
官方文档说明，分享 Copilot Chat conversation 处于 public preview，并且共享内容可能是 public 或 permission-based，取决于引用内容。例如关于 private repository 的 conversation，接收者需要有权限才能查看。
还要注意一个关键点：一旦分享 conversation，后续消息也会被链接可见。
分享前检查：
- 是否引用 private repository。
- 是否包含客户名、内部路径、token、日志、未公开 PR。
- 是否会在后续 follow-up 里继续暴露上下文。
- 接收者是否有必要权限。
深读：为什么 GitHub.com Chat 不能替代本地 IDE
GitHub.com Chat 能很好地理解 GitHub 对象：仓库、文件、PR、issue、alert、discussion、commit。它不负责你的本地环境状态，例如当前未提交 diff、未保存文件、环境变量、终端输出和本地测试结果。
因此，GitHub.com Chat 适合分析和协作；真正修改代码、跑测试、检查本地 diff，仍然要回到 IDE、CLI 或 PR 工作流。把两者混用时，必须明确“哪一步在 GitHub 上问，哪一步回本地验证”。
6. 推荐工作流
一个适合团队的 GitHub.com Chat 流程：
- 在 issue 页面让 Copilot 总结需求和未决问题。
- 在 repository 页面问相关代码入口。
- 在 PR 页面让 Copilot 总结变更和失败 checks。
- 人工 review diff 和测试结果。
- 如果需要改代码，回到 IDE 或 Cloud Agent。
- 把最终判断写回 PR review 或 issue comment。
这条链路能避免上下文散落：需求在 issue，代码在 repo，变更在 PR，验证在 checks。
本章自检
完成本章后，用这 4 个问题检查：
- 你的问题应该在 repo、file、PR、issue、alert 还是 dashboard 上问？
- Copilot 回答后，你会回到哪个 GitHub 对象验收？
- 你是否知道模型切换可能受组织策略和 premium request multiplier 影响？
- 分享 conversation 前，是否检查了权限、私有内容和后续消息可见性？
通过标准：你能把 GitHub.com Copilot 用在协作对象上，而不是把它当成没有上下文的网页聊天。
官方来源
- Getting started with prompts for Copilot Chat on GitHub —— 官方 GitHub.com Chat 提示示例，覆盖 repository、file、PR、security alert、issue/discussion/commit。
- Asking GitHub Copilot questions in GitHub —— 官方 GitHub 网站 Chat 使用说明，覆盖
github.com/copilot、搜索框、dashboard、模型切换、subthreads、图片和分享。