使用 GitHub Copilot 处理任务的最佳做法

注意

有关 Copilot编程助理的简介，请参阅“关于 GitHub Copilot 编码代理”。

确保问题范围明确

当分配清晰、范围明确的任务时，GitHub Copilot 提供更好的结果。理想的任务包括：

清晰描述要解决的问题或所需的工作。
关于什么样的解决方案才算好的完整验收标准（例如，是否应该有单元测试？）。
关于需要更改哪些文件的指示。

当您通过分配问题将任务传递给 Copilot 时，请将分配给 Copilot 的问题视为一个提示，这非常有用。考虑问题描述是否有可能作为 AI 提示，并使 Copilot 能够进行所需的代码更改。

选择要给予 Copilot 的正确任务类型

在使用 Copilot 的过程中，你将了解到其最适合处理的任务类型。起初，你可能想给予 Copilot 一些简单的任务，以了解其作为编码代理是如何工作的。例如，你可以首先要求 Copilot 修复错误、修改用户界面功能、增加测试覆盖率、更新文档、提升可访问性或偿还技术债务。

你可能选择自行处理而不分配给 Copilot 的问题包括：

```
        **复杂、范围广泛的任务**
```
- 需要跨仓库知识和测试的范围广泛、上下文丰富的重构问题
- 需要了解依赖项和旧代码的复杂问题
- 需要深入域知识的任务
- 涉及大量业务逻辑的任务
- 对代码库的大规模更改需要保持设计一致性
```
        **敏感和关键任务**
```
- 生产关键问题
- 涉及安全性、个人身份信息、身份验证反响的任务
- 事件响应
```
        **不明确的任务**
```
- 缺少清晰定义的任务：要求不明确的任务、开放式任务、需要从不确定性中寻找解决方案的任务
```
        **学习任务**
```
- 开发人员希望通过学习实现更深入理解的任务

使用评论来迭代拉取请求

使用 Copilot 处理拉取请求与使用人工开发人员一样：在合并拉取请求之前，通常还需要进一步的工作。当拉取请求由 Copilot 创建时，使其进入可合并状态的过程与由人类创建时的过程完全相同。

还可以在拉取请求评论中提及 @copilot，解释你认为不正确或可以改进的内容，然后让 Copilot 进行所需的更改。或者，可以自己处理功能分支，然后将更改推送到拉取请求。

在评论中提及具有写入权限的用户@copilot之后，Copilot 将开始进行任何所需的更改，并在更改完成后更新拉取请求。由于 Copilot 会在评论提交后立即开始查看评论，因此如果你可能对一个拉取请求进行多条评论，最好通过单击“Start a review”来批量处理，而不是单击“Add single comment”********。然后，可以一次性提交所有评论，触发 Copilot 来处理整个审查，而不是分别处理单个评论。

注意

Copilot 仅回复对存储库具有写权限的人员的评论。

当 Copilot 对拉取请求进行更改时，它将更新标题和正文，以反映当前的更改。

将自定义说明添加到代码库

通过向存储库添加自定义说明，可以指导 Copilot 理解项目，并了解如何构建、测试和验证项目的更改。

如果 Copilot 能够在其自己的开发环境中生成、测试和验证其更改，则更有可能生成可快速合并的好的拉取请求。

Copilot编程助理支持许多不同类型的自定义说明文件：

/.github/copilot-instructions.md
/.github/instructions/**/*.instructions.md
**/AGENTS.md
/CLAUDE.md
/GEMINI.md

有关详细信息，请参阅为GitHub Copilot添加存储库自定义说明。

仓库范围的说明

若要在存储库中添加应用于分配给 Copilot 的所有任务的说明，请在存储库的根目录中创建一个 .github/copilot-instructions.md 文件。此文件应包含有关项目的信息，例如如何构建和测试项目，以及希望 Copilot 遵循的任何编码标准或约定。请注意，这些说明也将适用于 Copilot对话和 Copilot代码审查。

首次请求 Copilot 在给定存储库中创建拉取请求时，Copilot 将留下一条注释，其中包含一个链接以自动生成自定义指令。你还可以根据我们的推荐提示随时请求 Copilot 为你生成自定义指令。请参阅“为GitHub Copilot添加存储库自定义说明”。

还可以选择随时编写自己的自定义指令。下面是有效 copilot-instructions.md 文件的示例：

This is a Go based repository with a Ruby client for certain API endpoints. It is primarily responsible for ingesting metered usage for GitHub and recording that usage. Please follow these guidelines when contributing:

## Code Standards

### Required Before Each Commit
- Run `make fmt` before committing any changes to ensure proper code formatting
- This will run gofmt on all Go files to maintain consistent style

### Development Flow
- Build: `make build`
- Test: `make test`
- Full CI check: `make ci` (includes build, fmt, lint, test)

## Repository Structure
- `cmd/`: Main service entry points and executables
- `internal/`: Logic related to interactions with other GitHub services
- `lib/`: Core Go packages for billing logic
- `admin/`: Admin interface components
- `config/`: Configuration files and templates
- `docs/`: Documentation
- `proto/`: Protocol buffer definitions. Run `make proto` after making updates here.
- `ruby/`: Ruby implementation components. Updates to this folder should include incrementing this version file using semantic versioning: `ruby/lib/billing-platform/version.rb`
- `testing/`: Test helpers and fixtures

## Key Guidelines
1. Follow Go best practices and idiomatic patterns
2. Maintain existing code structure and organization
3. Use dependency injection patterns where appropriate
4. Write unit tests for new functionality. Use table-driven unit tests when possible.
5. Document public APIs and complex logic. Suggest changes to the `docs/` folder when appropriate

路径特定说明

为了为特定类型的文件添加说明，如单元测试或 React 组件，而 Copilot 将处理这些文件，请在你的存储库中创建一个或多个.github/instructions/**/*.instructions.md文件。在这些文件中包含关于文件类型的信息，例如如何生成和测试文件，以及你希望 Copilot 遵守的任何编码标准或约定。

可以使用说明文件前言中的 glob 模式，指定这些说明应适用于哪些文件类型。例如，若要为 Playwright 测试创建说明，可以创建一个名为 .github/instructions/playwright-tests.instructions.md 的说明文件，其中包含以下内容：

---
applyTo: "**/tests/*.spec.ts"
---

## Playwright test requirements

When writing Playwright tests, please follow these guidelines to ensure consistency and maintainability:

1. **Use stable locators** - Prefer `getByRole()`, `getByText()`, and `getByTestId()` over CSS selectors or XPath
1. **Write isolated tests** - Each test should be independent and not rely on other tests' state
1. **Follow naming conventions** - Use descriptive test names and `*.spec.ts` file naming
1. **Implement proper assertions** - Use Playwright's `expect()` with specific matchers like `toHaveText()`, `toBeVisible()`
1. **Leverage auto-wait** - Avoid manual `setTimeout()` and rely on Playwright's built-in waiting mechanisms
1. **Configure cross-browser testing** - Test across Chromium, Firefox, and WebKit browsers
1. **Use Page Object Model** - Organize selectors and actions into reusable page classes for maintainability
1. **Handle dynamic content** - Properly wait for elements to load and handle loading states
1. **Set up proper test data** - Use beforeEach/afterEach hooks for test setup and cleanup
1. **Configure CI/CD integration** - Set up headless mode, screenshots on failure, and parallel execution

        **测试专家**：使用特定测试框架配置的代理，侧重于测试覆盖率、测试质量和测试最佳做法。 它可能仅限于读取、搜索和编辑工具，以防止对生产代码进行意外更改，同时确保全面的测试覆盖率。

        **文档专家**：专门创建和维护项目文档的代理，深入了解文档标准、样式指南以及分析代码以生成准确的 API 文档和用户指南的能力。

        **Python 专家**：了解 Python 约定、常用框架（如 Django 或 Flask）并遵循 PEP 标准的特定于语言的代理。 它将对 Python 工具、虚拟环境和测试框架（如 pytest）具有专业知识。

默认情况下，自定义代理继承存储库中已配置的所有 MCP 服务器工具，但还可以将自定义代理配置为仅对特定工具访问。

在任何使用 Copilot编程助理的位置，都可以使用自定义代理，包括在分配问题或提示任务时。

请参阅为 Copilot编程助理创建自定义代理，了解有关创建和配置自定义代理的更多信息。

在 GitHub Copilot 的环境中预安装依赖项

在处理任务时，Copilot 能访问由 GitHub Actions 提供支持的临时开发环境，在该环境中可以浏览代码、进行更改、执行自动化测试以及代码检查工具等操作。

如果 Copilot 能够在其自己的开发环境中生成、测试和验证其更改，则更有可能生成可快速合并的好的拉取请求。

要做到这一点，它将需要您项目的依赖项。 Copilot 可以通过试错过程自行发现并安装这些依赖项，但鉴于大型语言模型 (LLM) 的非确定性，这一过程可能既缓慢又不可靠。

可以配置一个 copilot-setup-steps.yml 文件，以在代理开始工作前预装这些依赖项，确保其能正常运行。有关详细信息，请参阅“自定义 GitHub Copilot 编码代理的开发环境”。

使用 GitHub Copilot 处理任务的最佳做法

谁可以使用此功能？

在本文中