01 · GitHub Copilot 是什么

GitHub Copilot 不是一个“会补全代码的插件”。GitHub 官方把它定义为 AI 编程助手（AI coding assistant），但 2026 年的 Copilot 已经覆盖内联建议（inline suggestions）、Copilot Chat、PR 摘要（PR summaries）、IDE 里的 Agent Mode、Copilot CLI、Cloud Agent（曾用名 Copilot coding agent）、Copilot Spaces、MCP 服务器、Agent skills、custom agents 和管理员治理。

所以学习 Copilot 的第一步，不是背快捷键，而是分清它的两种形态：同步辅助（assistive features）和代理式工作流（agentic features）。

打个新手友好的比方：辅助形态像副驾驶——你开车它给提示，方向盘还在你手上；代理形态像代驾——你说"送我去机场"，它自己规划路线、踩油门、变道，但敏感动作（合并 PR、跑生产命令、删除文件）仍要你点头。两种都是 Copilot，但你"放手的程度"不一样，验收方式也不一样：副驾驶看建议，代驾看 diff、tests 和 PR review。

1. 官方定义里的关键点

GitHub 官方文档说，Copilot 让你写代码更快、心智负担更小，把节省下的精力放回到“解决问题”和“团队协作”上。

这句话的重点不是“更快写代码”，而是“协作”。Copilot 住在 GitHub 和 IDE 的工作流里，天然贴近 issue、pull request、code review、branch、terminal 和组织级策略——它读得懂这些上下文，所以才有资格被叫成“coding assistant”而不是“代码补全器”。

flowchart TD
  Copilot["GitHub Copilot"] --> Assist["Assistive features"]
  Copilot --> Agentic["Agentic features"]
  Copilot --> Custom["Customization"]
  Copilot --> Admin["Administrator features"]
  Assist --> Suggest["Inline suggestions / Chat / PR summaries"]
  Agentic --> Work["IDE Agent / CLI / Cloud Agent / Code review"]
  Custom --> Context["Spaces / Instructions / MCP / Skills"]
  Admin --> Governance["Policy / Access / Usage / Audit / Exclusions"]

这也是 Copilot 和普通 AI 聊天框的差异：它不是只回答你复制进去的问题，而是试图进入 GitHub 对象、本地 IDE、终端和团队治理系统。

2. 四类功能怎么理解

GitHub 官方把 Copilot 功能分成四类。

理解这四类后，你就不会把“按 Tab 补全一行代码”和“让 Cloud Agent 自动开 PR”当成同一风险等级——前者是辅助，后者是代理。

3. Copilot 的入口不是一个

官方文档列出的使用位置包括 IDE、GitHub Mobile、Windows Terminal Canary、GitHub CLI 和 GitHub.com 网站。VS Code 官方文档还强调，Copilot 在 IDE 里能完成“规划（plan）→ 实现（implement）→ 验证（verify）”的跨文件改动闭环。

常见入口：

• IDE（编辑器）：写代码、Chat、inline suggestions、Agent Mode、review edits。
• GitHub.com（网站）：围绕仓库、文件、issue、PR、安全告警、Dashboard 提问和协作。
• GitHub Mobile（移动端）：延续上下文和做轻量提问。
• Windows Terminal（Canary 通道）：解释命令和 shell 报错。
• GitHub CLI / Copilot CLI（终端）：委派任务、修 bug、加功能、创建 PR。
• Cloud Agent（云端代理）：研究仓库、制定计划、改分支，让你 review diff 后再合 PR。

4. 第一层用法：辅助写代码

Assistive features 适合低到中风险任务：

• 解释一段代码。
• 补全局部函数。
• 生成单元测试草稿。
• 总结 PR 变更。
• 根据本地变更生成 commit message。
• 在 terminal 里解释命令含义。

验收方式很直接：

• 看 diff。
• 跑测试。
• 检查 PR summary 是否准确。
• 命令执行前确认副作用。

不要因为 Copilot 给了建议就直接合并。辅助能力提供的是候选结果，不是最终责任。

5. 第二层用法：Agentic 工作流

Agentic features 能自主推进任务，但通常需要人批准敏感动作，比如运行 terminal command 或合并 pull request。

典型任务：

• IDE Agent mode 跨文件修 bug。
• Copilot CLI 在终端里修一个 failing test。
• Cloud Agent 研究 issue、开分支改代码、提交 PR。
• Copilot code review 给出 review suggestions。

这类任务至少保留四个证据：

1. 任务计划。
2. 文件 diff。
3. 测试或检查输出。
4. 人工 review 结论。

6. 第三层用法：上下文和治理

Copilot 的质量高度依赖上下文。官方 customization 类功能包括：Copilot Spaces（上下文空间）、custom instructions（自定义指令）、prompt files（提示词文件）、MCP 服务器、agent skills 和 custom agents——本质是让 Copilot 看见“你的项目特征”，而不是泛泛回答。

团队上线时，管理员（administrator）功能同样重要：

• access management（访问管理）：谁能用 Copilot。
• policy management（策略管理）：哪些功能在本组织可用。
• usage data（用量数据）：上线后实际采用率和成本。
• audit logs（审计日志）：每个动作的可追踪性。
• file exclusions（文件排除）：哪些代码不应暴露给 Copilot。

这五项缺一不可：少了 access 团队就用不上；少了 policy 高风险能力就关不掉；少了 usage 不知道有没有人用；少了 audit 出事不可追溯；少了 file exclusions 敏感代码可能进训练或被检索到。如果只培训“怎么按 Tab 补全”，没有培训这五项，团队上线就是不完整的。

7. 第一天怎么安全上手

推荐顺序：

1. 确认个人或组织授权来源。
2. 选择低风险仓库。
3. 在 IDE 里让 Copilot 解释项目结构。
4. 用 inline suggestion 或 Chat 做一个小改动。
5. 审查 diff 并运行现有测试。
6. 再学习 Agent mode、Cloud Agent、CLI、MCP 和管理员策略。

不要第一天就让 Cloud Agent 改生产仓库，也不要在不了解命令副作用时让 CLI 自动跑命令。

8. 自检

你应该能回答：

• Copilot 的 assistive 和 agentic features 分别是什么？
• GitHub.com、IDE、Terminal、CLI、Cloud Agent 分别能看到什么上下文？
• 为什么 Cloud Agent 的结果必须回到 diff、checks 和 PR review？
• 团队上线前为什么必须配置 access、policy、usage、audit 和 exclusions？

通过标准：你能给新人设计一条 onboarding 路线，而不是只说“装个 Copilot 插件”。

官方来源

• What is GitHub Copilot?：GitHub 官方 Copilot 定义、功能范围、入口和访问路径。
• GitHub Copilot features：官方 assistive、agentic、customization、administrator 四类功能。
• GitHub Copilot in VS Code：VS Code 官方说明 Copilot 在 IDE 内的 plan、implement、verify 工作流。

接下来去哪