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

确保问题范围明确

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

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

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

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

在使用 Copilot 的过程中，你将了解到其最适合处理的任务类型。 起初，你可能想给予 Copilot 一些简单的任务，以了解其作为编码代理是如何工作的。 例如，你可以首先要求 Copilot 修复 bug、更改用户界面功能、提高测试覆盖范围、更新文档、改进辅助功能或解决技术债务。

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

• 复杂、范围广泛的任务

  • 需要跨仓库知识和测试的范围广泛、上下文丰富的重构问题
  • 需要了解依赖项和旧代码的复杂问题
  • 需要深入域知识的任务
  • 涉及大量业务逻辑的任务
  • 要求设计一致性的大规模代码库更改

• 敏感和关键任务

  • 生产关键型问题
  • 涉及安全性、个人身份信息、身份验证反响的任务
  • 事件响应

• 不明确的任务

  • 缺少清晰定义的任务：要求不明确的任务、开放式任务、需要从不确定性中寻找解决方案的任务

• 学习任务

  • 开发人员希望通过学习实现更深入理解的任务

使用评论来迭代拉取请求

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

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

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

路径特定说明

若要添加适用于 Copilot 将处理的特定类型的文件（例如单元测试或 React 组件）的说明，请在仓库中创建一个或多个 .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

使用模型上下文协议 (MCP)

可以使用 MCP 扩展 Copilot 编码智能体 的功能。 这使 Copilot 编码智能体 能够使用本地和远程 MCP 服务器提供的工具。 GitHub MCP 服务器和 Playwright MCP 服务器默认启用。 有关详细信息，请参阅“使用模型上下文协议 (MCP) 扩展 GitHub Copilot 编码助手”。

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

处理任务时，Copilot 可以访问其自己的临时开发环境（由 GitHub Actions 提供支持），可在其中浏览代码、进行更改、执行自动测试和 Linter 等。

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

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

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