入口与使用场景

GitHub Copilot 不是一个单入口产品。它同时出现在 GitHub.com、VS Code、Visual Studio、JetBrains、Xcode、Eclipse、Windows Terminal、Copilot CLI、Cloud Agent 和移动端。学 Copilot 的第一步，是把“任务发生在哪里”与“应该使用哪个入口”对上——入口选错，再强的模型也只能在错误的上下文里猜。

这组页面只处理入口分工。你不需要一次学完所有环境；先把任务放到正确 surface，再进入对应教程。

1. 入口地图

• GitHub.com：最适合仓库、文件、PR、issue、discussion、commit、安全 alert 的就地提问；不适合处理本地未提交 diff、终端环境和运行测试。
• VS Code：最适合本地编辑、Agent session、inline suggestions、inline chat、customization 和 MCP；不适合只围绕远端 PR/issue 协作而不改本地代码的任务。
• IDE Chat：最适合在 Visual Studio、JetBrains、Xcode、Eclipse 等 IDE 中解释代码、生成测试、修复错误；不适合需要 GitHub.com 页面上下文的 PR/issue 问题。
• Windows Terminal：最适合命令解释、shell 语法建议和错误解释；不适合自动执行危险命令、部署、删除和生产操作。
• Copilot CLI：最适合本地 agentic command-line workflow、远程 steering 和自动化；不适合无命令边界的生产仓库。
• Cloud Agent：最适合异步任务、分支、PR 和团队 review；不适合需要你实时操作本地 IDE 的小改动。

flowchart TD
    Task["开发任务"] --> Where{"任务发生在哪里?"}
    Where -->|仓库/PR/issue/alert| GitHub["GitHub.com"]
    Where -->|本地代码编辑| VSCode["VS Code / IDE Chat"]
    Where -->|命令行问题| Terminal["Windows Terminal / CLI"]
    Where -->|异步交付 PR| Cloud["Cloud Agent"]
    GitHub --> Review["回到 GitHub 对象验收"]
    VSCode --> Diff["回到 diff / tests 验收"]
    Terminal --> Command["人工检查命令副作用"]
    Cloud --> PR["通过 PR review 验收"]

    style VSCode fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Terminal fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style PR fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. 本组页面

3. 选择原则

不要把所有问题都丢给同一个 Chat 面板。入口选错，Copilot 不是不会回答，而是会用错误上下文回答。

• “这个 PR 改了什么？”：推荐在 GitHub.com PR 页面问；回到 PR diff、checks 和 review comments 验收。
• “当前文件职责是什么？”：推荐用 IDE Chat；看 references、当前文件和调用方是否覆盖完整。
• “帮我补一个小函数”：推荐用 VS Code inline suggestion 或 inline chat；回到本地 diff 和测试验收。
• “这个命令是什么意思？”：推荐用 Windows Terminal 或 CLI；执行前人工确认命令没有危险副作用。
• “修复 failing test 并开 PR”：推荐用 VS Code Agent 或 Cloud Agent；用 test output 和 PR review 验收。
• “让 Copilot 使用内部 API”：推荐用 IDE Chat / Agent + MCP；检查 MCP 权限、tool 调用和审计记录。

4. 权限和计费要跟入口一起看

GitHub 官方文档和 VS Code 官方文档都提示：组织或企业管理员可能关闭某些能力，例如 Chat、agents、CLI、模型切换或 MCP。模型选择也可能影响 premium request usage。

所以团队 onboarding 不能只写“打开 Copilot”。应该写清楚：

1. 哪些入口允许使用。
2. 哪些入口只读使用。
3. 哪些入口可以改代码。
4. 哪些入口可以运行命令或调用 MCP。
5. 使用哪些模型、哪些任务需要人工 review gate。

深读：为什么入口分工会影响结果质量

GitHub.com 有 GitHub 对象上下文，适合协作和审查；VS Code 有本地文件、选区、diff、terminal 和 agent session 上下文，适合编辑和验证；Terminal 有当前 shell 上下文，适合命令解释；Cloud Agent 有异步 PR 上下文，适合交付可 review 的变更。

如果你在浏览器里问本地未提交 diff，它看不到；如果你在终端里问 PR 需求，它缺少协作上下文；如果你在 IDE 里让它解释 GitHub security alert，却没给 alert 页面，它只能猜。入口不是 UI 偏好，而是上下文边界。

本组自检

读完整组后，用这 4 个问题检查：

1. 任务发生在 GitHub 对象、本地代码、终端命令还是异步 PR？
2. 当前入口能不能看到必要上下文？
3. 当前入口是否可能触达命令、MCP、生产资源或私有数据？
4. 完成后结果回到哪里验收：diff、test、PR、issue、alert、terminal output 还是管理员后台？

通过标准：你能先选入口，再写 prompt，而不是先写一段大 prompt 让 Copilot 猜上下文。

官方来源

• GitHub Copilot documentation —— Copilot 官方文档总入口，覆盖 GitHub.com、IDE、CLI、Cloud Agent、MCP、billing 和治理。
• GitHub Copilot in VS Code —— VS Code 官方 Copilot 总览，覆盖 agents、inline suggestions、inline chat、smart actions 和 customization。
• GitHub Copilot Chat —— 官方 Chat 入口总览，覆盖 IDE、Windows Terminal、GitHub 和 Mobile。

接下来去哪