代码建议（Copilot Suggestions）

Copilot 最稳定的能力，还是代码建议本身。别把它想得太玄，先把它当成一个很会补全、但需要你喂上下文的助手，效果反而更好。

#它通常会在哪些时候给建议

• 你开始写函数签名的时候
• 你已经写了几行注释，准备补实现的时候
• 你在重复写类似的接口请求、校验逻辑或测试结构

这类场景的共同点，是代码意图已经有雏形。Copilot 不是读心术，它需要一个起点。

#建议类型

#行内补全

最常见。适合补一行、几行，或者接住你当前正在写的链式调用和对象结构。

#多行补全

当函数名、参数和注释都比较明确时，它可能直接补出一整段实现。写 CRUD、转换函数、测试样板时特别明显。

#多候选建议

如果第一条不对，别急着接收。通常还有其他版本可切。这个动作很多人懒得用，结果就会误以为 Copilot “只会给错的”。

#怎么写，建议质量会更高

#先写注释，再写函数

ts复制
// 读取本地缓存的用户配置
// 如果不存在则返回默认值
export function loadUserSettings() {
  // Copilot 会在这里继续补
}

#先写结构，再补实现

ts复制
async function fetchUserProfile(userId: string) {
  // 1. 调用 API
  // 2. 处理错误
  // 3. 返回标准化结构
}

#类型越清楚，猜错越少

如果你的参数、返回值、接口名都很模糊，它只能乱猜。相反，类型和命名越清楚，补全越像你真正要的东西。

#一个很现实的经验

我一般不会直接接受它第一次给的整段代码，尤其是包含错误处理、权限判断、异步流程的时候。Copilot 在 happy path 上常常看起来很聪明，但边界条件还是得你自己守。

#适合让它补的内容

• 重复性很强的样板代码
• 清楚输入输出的工具函数
• 测试用例骨架
• 类型声明和数据映射

#不适合完全放手的内容

• 权限与安全逻辑
• 复杂事务处理
• 关键业务分支
• 会影响很多文件的一次性大改

这些内容不是不能让它参与，而是别一键接收。

#如果它总给错，先查什么

• 你的注释是不是太空
• 类型是不是没写清楚
• 当前文件有没有足够上下文
• 项目里是不是已经有和你想法相反的旧写法

很多“Copilot 不准”的案例，最后都是上下文质量问题。

#参考资料

• GitHub Copilot Quickstart: https://docs.github.com/en/copilot/get-started/quickstart↗
• GitHub Copilot Docs: https://docs.github.com/en/copilot↗