GitHub Copilot 上下文工程实战指南与 7 个核心技巧
核心心智模型：Copilot 是怎么'思考'的？
在学习技巧前，你需要理解 Copilot 的大脑构造。它不是在瞎猜，它是在根据你喂给它的'上下文（Context）'计算概率。
Copilot 的上下文由三层组成：
- 顶层约束：
.github里的规则（即'项目宪法'），权重最高。 - 短期记忆：你当前打开的 Tabs（临近文件）。
- 当前指令：你光标处的注释和代码。
你的目标：控制这三层输入，从而控制输出。
秘籍一：项目宪法 (Project Constitution)
—— 全局锁死技术栈与规范
- 痛点：每次新建实体类，Copilot 都给你生成 JPA 注解，而你用的是 MyBatis。每次都要手动纠错，效率极低。
- 解法：利用系统提示词，一次性写入'最高指令'。
- 实操：
在项目根目录创建
.github/copilot-instructions.md，填入以下内容：
# 项目规范 - 技术栈：Spring Boot 3 + MyBatis-Plus + Lombok - 数据库：PostgreSQL，主键自增 - 实体类：必须使用 @Data, @TableName - 禁止：禁止使用 JPA，禁止硬编码魔法值
效果：新建文件时，AI 会自动遵守所有规则，宛如一个入职 3 年的老员工。
秘籍二：临近选项卡战术 (Neighboring Tabs Strategy)
—— 物理注入上下文
- 痛点：在写 Controller 时，Copilot 经常捏造一个 Service 里不存在的方法名（比如叫
finish()而不是complete()）。 - 解法：AI 会读取你当前打开的文件。把相关文件'喂'到它嘴边。
- 实操：
- 动作：在写
TodoController之前，先打开TodoItem.java（实体）和TodoService.java（接口），并不要关闭。 - 编码：
@PostMapping("/{id}/done")
public ApiResponse<TodoItem> done(@PathVariable Long id) {
// AI 此时拥有了上帝视角，它确切知道 Service 里有一个 completeTask 方法
// 自动补全：return ApiResponse.success(todoService.completeTask(id));
}
秘籍三：注释驱动开发 (CDD)
—— 思维链 (Chain of Thought) 注入
