如何使用 Cursor 和 GitHub Copilot 编码

我使用 Cursor 和 GitHub Copilot 一段时间后，最大的变化不是代码补全更快，而是查代码、改代码和验证结果的流程发生了变化。

这两类工具都能读取当前代码上下文，也都支持对话和修改文件。实际效果主要取决于提供的上下文、项目规则和任务大小。把整个需求一次性交给工具，通常会增加 review 成本。

AI 编程工具对结构清楚的项目更有效。开始使用前，我会确保仓库至少具备：

如果项目本身无法稳定构建，工具生成的代码也缺少可靠的验证基线。

Cursor 当前推荐把项目规则放在 .cursor/rules 下，使用 .mdc 文件。旧的 .cursorrules 仍可兼容，但已经不是推荐格式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

---
description: Vue 组件开发规则
globs: "src/**/*.vue"
alwaysApply: false
---

- 使用 TypeScript 和 script setup
- Props 与 Emits 必须声明类型
- 请求逻辑放在 src/api
- 完成后运行 pnpm typecheck

规则应短、具体并限定作用范围。前端、后端和测试可以分别建立规则文件，不需要把整个团队规范放进一个长文件。

Cursor 官方文档说明了 Project Rules、User Rules 和不同应用范围：Cursor Rules。

GitHub Copilot 可以通过 .github/copilot-instructions.md 保存仓库级说明，也支持 .github/instructions/*.instructions.md 形式的路径级指令。

1
2
3
4
5
6

# Repository instructions

- Use Java 21 and Spring Boot conventions used in this repository
- Do not change public API response fields without approval
- Run ./mvnw test before completing backend changes
- Follow existing exception mapping in GlobalExceptionHandler

路径级指令适合只对特定语言或目录生效的规则。GitHub 官方文档还说明了 AGENTS.md 等 Agent 指令文件的支持范围：Repository custom instructions。

接手不熟悉的模块时，我先让工具回答三个问题：

要求它引用具体文件和方法，方便我核对。分析结果确认后，再让它提出最小修改方案。

这个步骤适合 Agent 或 Chat。行内补全更适合局部实现，不适合分析跨文件调用链。

一个任务只处理一个可验证目标：

1
2
3
4
5

为 OrderService.createOrder 增加库存不足处理。
只修改订单模块和对应测试。
复用现有 BusinessException，不新增异常体系。
不要修改 Controller 返回结构。
完成后运行订单模块测试。

修改前让工具列出计划文件。执行后查看 Git diff，重点检查是否出现无关格式化、依赖升级和公共接口变化。

Cursor Tab 和 Copilot 补全适合这些工作：

不适合直接接受的内容包括权限判断、事务边界、加密实现和大范围数据迁移。这些改动需要先确认设计，再逐行 review。

Cursor 可以通过文件、目录和规则引用提供更精确的上下文。GitHub Copilot 也会结合当前文件、选中代码和对话历史。

上下文不是越多越好。我会只打开或引用与任务相关的文件，并在新任务开始时新建对话，避免旧需求影响当前修改。

GitHub 的 Prompt 指南也建议明确相关代码、拆分复杂任务并保持对话历史相关：Prompt engineering for GitHub Copilot。

我的检查顺序固定为：

工具生成了测试，不代表测试有效。要确认断言覆盖行为，而不是只验证 Mock 返回了预设值。测试失败时也要检查代码原因，不能通过删除断言或跳过测试完成任务。

使用前要确认组织的数据策略。密钥、客户数据、生产日志和未公开源码是否允许发送到模型，应以团队规定和工具当前的隐私设置为准。

Agent 模式具备文件修改和命令执行能力时，还要限制可访问目录和可执行操作。数据库删除、生产部署、密钥轮换等操作不应依赖默认授权。

我目前的分工是：

Cursor 与 Copilot 的具体功能会继续变化，但这套分工不依赖某个按钮。上下文明确、范围受控、验证可执行，才是稳定使用的基础。

现在我不会用生成了多少行代码衡量效率。改动能否快速验证、diff 是否容易 review、有没有减少重复查找，这些指标更接近日常开发的实际收益。