Jiwon Min Developer

团队引入 GitHub Copilot 前，领导者需要先明确什么

本文由 AI 撰写并编辑，经运营者审核后发布。缩略图也可能由 AI 生成。

在冲刺中期，一位团队成员将 Copilot 生成的代码原封不动地提交到了 PR 中。评审者花费了比平时多一倍的时间来验证逻辑，最终以“这代码是你自己写的，还是 Copilot 写的？”这个问题开始了审查。当时，该团队引入 Copilot 已有三周，但没有任何标准。

这种情况并非工具本身的问题。Copilot 被设计为个人生产力工具，但在团队中使用时，会同时带来审查标准、上下文共享和许可证管理等问题。如果没有任何准备就“先用起来”，那么在生产力提升之前，摩擦会先出现。

本文将讨论领导者在团队引入 Copilot 之前，应根据团队规模（1人 → 3人 → 10人）决定的事项及其原因。重点在于团队共识点，而非安装方法。

团队引入 GitHub Copilot 前，领导者需要先明确什么

© AI 生成图片

为什么个人工具会成为团队问题

Copilot 是一个编辑器插件。它在各自的 IDE 中运行，并且建议只显示在个人屏幕上。然而，其产出的代码是通过 Git 共享的。这种差异造成了问题。

如果提交到 PR 的代码几乎没有修改地包含了 Copilot 的建议，评审者需要同时做两件事：首先，审查代码本身的正确性；其次，判断作者是否充分理解这段代码。后者原本并非审查项。

此外，Copilot Business 许可证按席位计费。截至 2025 年，每用户每月 $19（GitHub Copilot Business 套餐）。团队规模越大，如果不追踪“谁实际在使用”，费用就会不断累积。

1人使用阶段应建立的标准

单独使用时，似乎不需要规则，但如果以后没有标准来指导团队成员入职，就需要从头重新制定。在独自使用阶段养成以下两个习惯会很有帮助。

明确建议采纳标准

在采纳 Copilot 建议之前，简单整理一份自问清单，这样将来可以更容易地发展成团队规则。

# copilot-accept-checklist.md (个人用)

## 采纳建议前确认
- [ ] 能用一句话解释这段代码的作用吗？
- [ ] 边缘情况（空值、网络错误等）是否已处理？
- [ ] 是否添加了新的外部包？该包是否已被审查？
- [ ] 是否包含敏感信息或硬编码值？

这份清单并非用于在 Copilot 出错时纠正错误。它是一种确认我是否理解了建议的工具。

开始编写 .github/copilot-instructions.md

GitHub Copilot 会读取仓库根目录下的 .github/copilot-instructions.md 文件，并将其反映到建议风格中（Copilot for Business，自2024年下半年起支持）。在1人使用阶段创建此文件，可以确保团队成员加入时，Copilot 共享相同的上下文。

# .github/copilot-instructions.md

## 项目上下文
- 后端：Node.js 20 + TypeScript 5，基于 Express
- 数据库：PostgreSQL 15，使用 Prisma ORM
- 测试：Vitest，覆盖率保持在 70% 以上

## 代码风格规则
- 禁止使用 `any` 类型。未知类型声明为 `unknown` 后再收窄
- 错误处理：使用 Result 模式代替 try/catch（参见 src/utils/result.ts）
- 单个函数只做一件事。超过30行时考虑拆分

## 安全规则
- 绝不能在代码中包含 API 密钥、密码
- 用户输入必须通过 zod 验证后使用

如果没有此文件，每个团队成员的 Copilot 会以不同的风格提供建议，导致代码库失去一致性。

转向3人团队时增加的决策

当团队成员达到2-3人时，许可证管理和审查标准会同时变得必要。

许可证分配标准

在 GitHub Organization 中启用 Copilot Business 后，管理员会为每个用户分配席位。默认设置为“为所有成员激活”，如果保持此状态，外部贡献者或只读成员也可能产生费用。

# GitHub Organization > Settings > Copilot
# 推荐设置：更改为“选定的团队和用户”

# 分配标准示例
启用:
  - 全职开发者
  - 计划贡献6个月以上的合同工

考虑禁用:
  - 设计师（如果只进行代码审查）
  - DevOps（如果只处理基础设施代码 → 单独判断）
  - 实习生（入职期结束后重新评估）

建议每月检查一次实际使用量。在 GitHub Organization > Insights > Copilot 中，可以查看每个用户的采纳率和活跃天数。对于30天内活跃天数为0的席位，可以考虑禁用。

PR 审查标准共识

当团队开始使用 Copilot 后，评审者不能每次都问“你提交的这段代码，真的理解了吗？”。将这个问题结构化的方法是在 PR 模板中添加检查项。

# .github/pull_request_template.md

## 变更摘要
<!-- 用一段话说明更改了什么、为什么更改 -->

## 测试方法
<!-- 如何在本地验证的 -->

## Copilot 使用情况
- [ ] 此 PR 中使用了 Copilot 建议
  - 如果使用了：请简要说明在哪些部分使用了
  - 例：“服务层单元测试样板代码，已亲自审查并修改”

## 检查清单
- [ ] 无敏感信息、无硬编码值
- [ ] 添加新依赖项时已与团队共享
- [ ] 包含边缘情况测试

强制标记“Copilot 使用情况”并非监视。这是为了让评审者知道需要重点关注哪些部分的信息。对于 Copilot 生成的代码中涉及业务逻辑的部分，评审者自然会更加仔细地审查。

10人团队的不同之处

当团队超过10人时，需要组织层面的政策，而非个人配置文件。主要变化点有三点。

1. 将 copilot-instructions.md 作为正式文档管理

文件存在与团队信任其内容是两码事。在10人团队中，应将此文件提升到与 ADR (Architecture Decision Record) 相同的管理级别。更改时需经过 PR 审查，并注释说明添加特定规则的原因。

# .github/copilot-instructions.md

## [2024-11 添加] 强制使用 Result 模式
# 原因：try/catch 嵌套导致错误上下文丢失问题反复出现
# 参考：ADR-012
- 错误处理只使用 Result<T, E> 模式
- 使用 src/utils/result.ts 中的 ok(), err() 辅助函数

## [2025-03 添加] 禁止外部 API 调用
# 原因：当 Copilot 建议使用外部 SDK 的代码时
#       曾发生包含未经公司批准的包的情况
- 新的 HTTP 客户端、SDK 必须经过依赖项审查后才能添加

2. 单独编写 Copilot 政策文档

10人团队会不断有新人入职。为了避免重复回答“如何使用 Copilot？”这样的问题，内部 Wiki 上应有一份简短的政策文档。

# Copilot 使用政策 (内部 Wiki)

## 允许
- 生成样板代码、重复代码
- 编写单元测试草稿
- 编写文档注释草稿

## 注意
- 生成业务逻辑 → 必须亲自审查后采纳
- 数据访问层 → 未理解数据库 Schema 禁止采纳

## 禁止
- 将 Copilot 建议直接应用于敏感信息、认证令牌相关代码
- 在聊天（Copilot Chat）中输入未对外公开的内部 API 规范

最后一点很重要。将内部 API 规范粘贴到 Copilot Chat 中，可能带来与内容被用作 GitHub 学习数据相关的政策问题。尽管 GitHub Copilot Business 明确指出默认不使用用户输入进行学习(GitHub Copilot 信任中心)，但所有团队成员都应了解此政策。

3. 设置使用量审查周期

# Copilot 使用量月度审查项

1. 确认未使用席位
   - GitHub Org > Insights > Copilot
   - 活跃天数少于5天 → 考虑下月解除席位

2. 确认团队平均采纳率
   - 如果采纳率过高(>80%)：检查是否充分审查了建议
   - 如果采纳率过低(<10%)：需要更新 instructions.md

3. 审查摩擦反馈
   - 在冲刺回顾中收集1-2个“因 Copilot 导致审查困难的案例”
   - 反映到 instructions.md 或 PR 模板中

采纳率高并非总是好事。如果几乎未经修改就接受了建议，则需要确认审查是否充分。

两个常被忽视的成本

认知负荷

当 Copilot 建议出现在屏幕上时，开发者每次都必须决定“是否采纳”。如果是熟悉的代码模式，可以快速判断；但如果建议的是陌生的库或复杂的逻辑，仅判断本身就会消耗精力。如果整个团队一整天都在重复这种决策，那么用于实际设计和判断的专注力就会减少。

解决方案很简单。通过在 copilot-instructions.md 中明确缩小范围，可以提高建议的质量，减少判断时间。越具体地描述“此项目使用的模式”，效果越好。

安全审计范围扩大

开始使用 Copilot 后，代码来源变得多样。相同的漏洞也可能在多个文件中被复制。例如，如果 Copilot 反复建议易受 SQL 注入攻击的模式，并且团队采纳，那么相同的漏洞可能会在多处扩散。

为缓解此问题，建议在 CI 中保留现有的 SAST 工具（如 CodeQL、Semgrep 等），并监控 Copilot 引入后的前1-2个月，看安全相关指摘事项是否增加。

按规模划分的结论

情况 推荐设置 原因
1人个人项目 copilot-instructions.md + 个人清单 为将来发展成团队规则奠定基础
3-5人初创团队 在 PR 模板中添加 Copilot 使用情况项 通过结构化减少审查摩擦。并非监视，而是信息共享
10人以上团队 政策文档 + 月度使用量审查 + instructions.md 版本管理 降低入职成本，防止不必要的席位费用
遗留代码较多的团队 在 instructions.md 中明确遗留模式，限制重构范围 防止 Copilot 学习遗留风格并反向操作
安全敏感服务 明确聊天输入政策，强制保持 SAST CI 防御 Copilot 引入后漏洞模式复制的风险

与其关闭或开启工具，不如先确保团队以相同标准使用它。Copilot 在未经协商就开启的那一刻，审查成本就会悄然上升。

参考资料