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

了解如何从 Copilot 编码智能体 获得最佳结果。

谁可以使用此功能？

Copilot 编码智能体 可在启用了该功能的存储库中，通过 GitHub Copilot Pro+ 和 GitHub Copilot Enterprise 计划使用。 Copilot 编码智能体 在 托管用户帐户 拥有的仓库中不可用。
Sign up for Copilot

本文内容

注意

Copilot 编码智能体 is in 公共预览版 and subject to change. During the preview, use of the feature is subject to GitHub 预发行许可条款.

确保问题范围明确

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

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

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

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

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

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

  • 复杂、范围广泛的任务

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

  • 敏感和关键任务

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

  • 不明确的任务

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

  • 学习任务

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

使用评论来迭代拉取请求

使用 Copilot 处理拉取请求与使用人工开发人员一样：在合并拉取请求之前，通常还需要进一步的工作。 当拉取请求由 Copilot 创建时，使拉取请求进入可合并状态的过程与由人工创建时的过程完成相同。 如果愿意，你可以自己在功能分支上工作，并将更改推送到拉取请求。 不过，也可以直接在拉取请求中添加评论，解释你认为不正确或可以改进的地方，然后让 Copilot 进行所需的更改。

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

注意

Copilot only responds to comments from people who have write access to the repository.

将自定义说明添加到仓库

通过将自定义说明添加到仓库，可以指导 Copilot 如何理解项目，以及如何生成、测试和验证其更改。

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

将说明添加到仓库中的 .github/copilot-instructions.md 文件。 有关详细信息，请参阅“为 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

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

可以使用 MCP 扩展 Copilot 编码智能体 的功能。 这样一来，Copilot 编码智能体 便可使用本地 MCP 服务器提供的工具。 有关详细信息，请参阅“使用模型上下文协议 (MCP) 扩展 Copilot 编码助手”。

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

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

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

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

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