第二章：GitHub Copilot 的完整能力图谱
第二章：GitHub Copilot 的完整能力图谱
大多数开发者只用到了 Copilot 能力的 20%——本章带你解锁剩下的 80%。
GitHub Copilot 在很多开发者的工作台上是一个沉默的存在：Tab 键接受建议，偶尔打开 Chat 问一个问题，然后关掉。这种使用方式就像只用搜索引擎看首页结果，从不点击第二页。
这不是工具的问题，是使用方式的问题。真正改变工作流的 Copilot 能力——Agent 模式、配置文件体系——大多数人没有触达过。本章的目标是系统性地铺开 Copilot 的完整能力地图，让你知道有哪些工具可以用，以及在什么场景下用哪个。
2.1 被忽视的 80%
根据实际观察，大多数开发者使用 GitHub Copilot 只触及了其能力的 20%——主要停留在内联代码补全（Tab 键接受建议）和偶尔的 Chat 对话。
完整的 Copilot 能力层次：
| 入口 | 功能 | 典型使用场景 |
|---|---|---|
| 内联建议（Tab） | 实时代码补全 | 重复性代码、模式续写 |
| 内联 Chat（Ctrl+I） | 选中代码后对话式修改 | 快速重构、解释单段代码、修小 bug |
| 侧边栏 Chat | 多轮对话，可引用多个上下文 | 实现新功能、设计讨论、复杂分析 |
| Agent 模式 | 跨文件自主执行，使用工具 | 完整功能开发、跨文件重构 |
| 配置驱动（.github/） | 自定义行为和知识 | 长期质量提升、标准化工作流 |
真正改变工作流的是后两层，但大多数教程都集中在前三层。本书重点讨论 Agent 模式和配置驱动这两个维度。
为什么大多数人停留在前三层？因为内联建议的反馈是即时的——按 Tab 就有结果，学习曲线几乎为零。而 Agent 模式需要你先建立测试、先写配置文件，前期有投入，收益是延迟兑现的。这是典型的"短期努力 vs 长期价值"问题。
2.2 上下文变量：精准引用的艺术
Copilot Chat 支持通过 # 符号精准引入上下文。这是减少"AI 猜测成本"的关键机制：
| 变量 | 功能 | 使用示例 |
|---|---|---|
#file |
引入指定文件全部内容 | #file:app/services/user_service.py 分析性能瓶颈 |
#sym |
引入特定符号的定义 | #sym:create_task 这个函数的错误处理是否完整 |
#selection |
当前编辑器选中的代码 | 选中代码后 Ctrl+I，自动引用 |
#codebase |
扫描整个 codebase | #codebase 哪里实现了用户配额检查 |
#terminalLastCommand |
最近一次终端输出 | #terminalLastCommand 解释这个报错 |
为什么精准引用很重要：告诉 AI “看 #file:xxx.py” 比让它自己搜索效率高 3-5 倍。AI 不需要猜测文件位置，也不会引入不相关文件的干扰，上下文更干净，输出更准确。
一个常见的错误是用 #codebase 解决一切。#codebase 触发全局扫描，耗时更长，而且会引入大量与当前任务无关的上下文，稀释 AI 对关键信息的注意力。只有在真的需要全局搜索时才用它。
精准引用的另一个好处是可重复性：#file:xxx.py 分析性能瓶颈 这样的 Prompt 可以标准化，可以共享给团队成员，可以放进 Prompt 模板。模糊的 帮我看看代码 则不能。
2.3 Slash Commands：标准化操作
Copilot 内置的 Slash Commands 覆盖了开发者最频繁的需求：
| 命令 | 功能 | 最佳时机 |
|---|---|---|
/explain |
解释选中代码的逻辑 | 读 AI 生成的代码时 |
/fix |
修复选中代码的 bug | 有报错但不确定原因 |
/tests |
为选中代码生成单元测试 | 刚完成一个函数 |
/doc |
生成文档和注释 | 代码写完后补文档 |
/new |
创建新文件（项目脚手架） | 新功能开始时 |
你自己创建的 .github/prompts/*.prompt.md 文件，是对这个列表的扩展——添加项目特定的自定义命令，如 /new-endpoint、/new-migration、/debug-prod。
使用技巧：/explain 是被低估的命令。AI 生成了 50 行代码，你不一定需要逐行读懂，但你应该知道它做了什么。选中这 50 行，/explain 得到一个清晰的摘要，然后决定是否需要深入审查。这比从头读代码效率高 3-4 倍，同时保持了你对代码的基本理解。
/tests 的正确使用时机：刚写完一个函数时立即触发 /tests，趁着你对这个函数的设计意图最清晰的时候。等到明天再补测试，你会发现需要重新想一遍"这个函数应该测什么边界情况"。
2.4 @-Agents：路由到专用知识域
Copilot Chat 中的 @ 命令将请求路由到不同的专用 Agent：
| 命令 | 路由目标 | 适用场景 |
|---|---|---|
@workspace |
理解整个代码库 | “这个项目哪里实现了 X？” |
@vscode |
VS Code 本身的功能 | “如何配置 launch.json？” |
@terminal |
终端命令与错误 | “这个 docker 报错是什么意思？” |
@workspace 是最重要的一个，它让 Copilot 能回答需要全局视角的问题，而不只是看当前打开的文件。
.github/skills/<name>/SKILL.md 实际上是在扩展这个路由机制——为项目特定场景（如"后端高级工程师"）创建专用知识域。
什么时候用 @workspace：当你问的问题需要理解代码库的整体结构时：
- “这个项目的认证逻辑在哪里？”
- “有没有地方已经实现了类似的功能？”
- “这个接口被哪些地方调用？”
@workspace 在回答这类问题上，比你自己在文件树里找效率高很多。但对于"帮我实现 X 功能"这类执行性任务，直接用 Agent 模式更合适。
2.5 Agent 模式：跨越"生成代码"的质的飞跃
Copilot 的 Agent 模式和普通 Chat 的区别不只是功能多了——而是工作方式的本质不同。
普通 Chat：你提问 → AI 回答 → 你复制代码 → 你粘贴到文件 → 你手动修改细节。
Agent 模式：你描述目标 → AI 自主搜索相关文件 → AI 理解现有代码 → AI 执行修改 → AI 验证结果 → 报告完成。
这个差异在实际使用中体现为工作量的数量级差距：
实现一个新的 API endpoint
- 普通 Chat：写 4 条提示（Model/Schema/Service/Route），等 4 次回复，复制粘贴 4 次，手动处理导入和注册
- Agent 模式：一条描述 + 触发 Prompt 模板，AI 自动完成所有文件的创建和修改
Agent 模式的前提是有可靠的测试作为安全网——因为 AI 会主动修改多个文件，你需要能快速验证整体是否正确。
Agent 模式的工作原理：当你给 Agent 一个任务，它会依次执行以下步骤（对你透明可见）：
- 分析任务，决定需要读取哪些文件
- 读取相关文件，理解现有代码结构
- 制定修改计划，通常会列出计划步骤
- 逐步执行修改，每步可以暂停等待你确认
- 运行测试（如果你配置了）
- 报告完成或遇到的问题
这个透明性很重要——你可以在任何步骤暂停、修正方向，而不是等到全部完成后才发现方向错了。
关键实践：在 Agent 开始大范围修改之前，先让它列出计划（“先告诉我你打算修改哪些文件，等我确认后再执行”）。这是一个低成本的方向校验，能防止 Agent 走偏后的大规模返工。
2.6 配置文件体系：将 Copilot 变成领域专家
这是本章最核心的主题，也是整本书反复强调的关键基础设施：
.github/
├── copilot-instructions.md ← 全局 System Prompt（所有对话自动注入）
├── prompts/
│ ├── new-endpoint.prompt.md ← /new-endpoint 命令
│ ├── new-migration.prompt.md ← /new-migration 命令
│ └── debug-prod.prompt.md ← /debug-prod 命令
└── skills/
└── backend-senior-dev/
└── SKILL.md ← @agent 时的专家角色
没有这套配置，Copilot 是一个不了解你项目的通用工具。有了这套配置，Copilot 成为一个了解你项目架构、规范和历史踩坑的专家助理。
差距不是功能性的，而是质量性的：同样的任务描述，有配置和没有配置，AI 输出的准确度可以相差 3-5 倍（体现在需要修改的代码量上）。
三个文件的分工：
copilot-instructions.md：全局基准，轻量、持久，每次对话都注入。写最关键的 3-5 条约束，让 AI 知道它在什么类型的项目里工作。SKILL.md：专家模式，详细、专业，按需激活。写完整的规范、代码模式、踩坑记录。当你做复杂的功能开发时激活它。prompts/*.prompt.md：工作流模板，操作化、可复用，通过命令触发。把你每天重复做的任务标准化成可一键触发的流程。
这套体系的维护需要工程师主动投入，但这是一次性投入、长期收益的工作。一个良好维护的 .github/ 目录，是团队所有 AI 交互质量的基准保障。
团队使用的额外价值：当这套配置提交到代码库，所有团队成员的 Copilot 都会使用相同的项目规范。新成员的 AI 辅助代码从第一天就符合团队规范，不需要漫长的"了解项目惯例"过程。
本章小结
本章系统梳理了 GitHub Copilot 从入门到深度使用的完整能力图：
- 能力层次：内联建议 → Chat → Agent 模式 → 配置驱动，越往后越有杠杆效应
- 精准引用：用
#file、#sym等变量代替模糊引用，显著提升输出质量 - Slash Commands：内置命令覆盖日常操作，自定义 Prompt 模板扩展到项目特定场景
- Agent 模式：质的飞跃，从"帮你写代码"变成"帮你做工作"，需要测试作为安全网
- 配置文件体系：
.github/目录是将 Copilot 从通用工具变成项目专家的关键
核心行动建议
- 今天就创建
.github/copilot-instructions.md，写 3 条最重要的项目约束，立刻开始改善输出质量 - 下次遇到需要修改 3 个以上文件的任务，尝试用 Agent 模式而不是普通 Chat
- 在你最频繁使用的操作上尝试
/tests和/explain，培养立即补测试的习惯 - 观察一周，找出最重复的 AI 任务，把它做成第一个
prompts/模板