使用 GitHub Copilot 减少技术债务

在 IDE 中工作时，选中需要改进的代码。
在 IDE 中打开 Copilot 聊天。
请求 Copilot 重构代码。例如
- 将其提取为可复用的帮助函数并添加错误处理
- 标准化此日志格式以匹配我们的规范
- 为所有可选参数添加空值检查
- 将此已弃用的 API 调用替换为当前版本
审查建议的更改。
接受更改或请求 Copilot 调整其方式。
运行测试以验证更改是否正确。

示例：标准化错误处理

如果您发现错误处理不一致——例如

// Highlight this code
try {
  await fetchData();
} catch (e) {
  console.log(e);
}

请求 Copilot 改进代码——例如

Copilot 提示

Refactor this to use structured logging and proper error handling

// Highlight this code
try {
  await fetchData();
} catch (e) {
  console.log(e);
}

Refactor this to use structured logging and proper error handling

Refactor this to use structured logging and proper error handling

Copilot 可能会建议

try {
  await fetchData();
} catch (error) {
  logger.error('Failed to fetch data', {
    error: error.message,
    stack: error.stack,
    timestamp: new Date().toISOString()
  });
  throw error;
}

注意

此响应仅为示例。Copilot Chat 的响应具有不确定性，针对相同代码运行相同提示时可能得到不同的回答。

采用即时修复方式可确保不合格的代码不会被添加到代码库中，避免产生可能永远得不到解决的积压问题。

想了解在 IDE 中使用 Copilot 的更多细节，请参阅在 IDE 中向 GitHub Copilot 提问。

使用 Copilot 云代理进行大规模重构

有些重构任务实在太大，团队在忙于开发新功能时难以完成。这时可以使用 Copilot 云代理自主处理这些任务。仍然需要人工参与——至少要审查 Copilot 云代理提出的更改——但让 Copilot 完成大部分工作可以在几乎不影响团队生产力的情况下完成大规模重构。

何时使用 Copilot 云代理

使用 Copilot 云代理处理以下任务：

涉及代码库中多个文件
需要系统性更改（如移除旧的功能标志）
需要细致测试但实现相对简单
若手动执行会中断功能开发

示例包括

影响 50+ 文件的框架升级
移除已弃用的功能标志
迁移到严格的 TypeScript
更新依赖版本
统一导入模式

Copilot 云代理工作流

创建一个 GitHub Issue 来描述重构任务。

具体说明需要更改的内容。例如

Remove all feature flags marked for cleanup in Q2.

These flags are:
- `enable_new_dashboard`
- `beta_export_feature`
- `experimental_search`

All three flags are enabled by default in production.

Remove the flag checks and keep the "enabled" code path.

将 Issue 分配给 Copilot 用户。
Copilot 云代理将会
- 搭建开发环境
- 打开草稿拉取请求
- 对代码进行必要的更改
- 运行测试
- 完成拉取请求以供审查
- 请求您审查该拉取请求
像审查人工提交的拉取请求一样审查此请求。
如需更改请留下评论——Copilot 云代理会根据您的反馈更新拉取请求。
以此方式迭代，直至工作正确完成。
批准并合并拉取请求。

想了解更多信息，请参阅请求 GitHub Copilot 创建拉取请求和审查 GitHub Copilot 创建的拉取请求。

安全防护措施

Copilot 云代理具备内置的安全措施

它只能推送到自己的 copilot/* 分支
它无法合并拉取请求——需要您批准
所有提交均有日志记录且可审计
您现有的分支保护仍然有效
在任何代码合并前都会运行 CI/CD 检查

为团队创建自定义指令

自定义指令帮助 Copilot 了解团队的代码规范和模式，确保建议从一开始就符合预期。

设置自定义指令

在您的仓库中，创建一个名为 .github/copilot-instructions.md 的文件。
以清晰、直白的方式添加团队的代码规范，例如使用项目符号列表。
将文件提交到仓库。

自定义指令示例

以下是有效自定义指令的示例

## Our Standards

- Use structured logging, not console.log
- Sanitize user input before database queries
- Check for null/undefined on all optional parameters
- Keep functions under 50 lines (extract helpers if needed)
- Every public function needs a test
- Flag any loops that might trigger N+1 queries

## Error Handling

- Always use try-catch blocks for async operations
- Log errors with context (user ID, request ID, timestamp)
- Never swallow errors silently
- Return appropriate HTTP status codes

## Testing Requirements

- Unit tests for all business logic
- Integration tests for API endpoints
- Mock external services in tests
- Test both success and failure paths

想获取编写自定义指令的详细指南，请参阅为 GitHub Copilot 添加仓库自定义指令。

自定义指令的好处

有了自定义指令后

Copilot 会提供符合您模式的代码建议
代码审查更快，关于风格更改的讨论更少
新成员通过 Copilot 的建议学习您的标准
代码库的一致性得到提升

开展试点项目

先小范围试点，以验证 Copilot 对技术债务的影响，再大规模推广。

第1周：设置并建立基线

确保所有试点参与者拥有 Copilot 访问权限并启用了 Copilot 云代理。
统计待处理的技术债务项
- 标记为 “tech debt”、 “chore” 或类似标签的问题数量
- 过时依赖的数量
- 未通过 Linter 检查的文件数量
追踪当前指标
- 重构 PR 从创建到合并的平均时间
- 每个重构 PR 的平均审查轮次
创建首个 .github/copilot-instructions.md 文件，包含 3–5 条最重要的规范。