TL;DR
版本：Cursor 1.6.x，GitHub Copilot 2025-03；日期：2025-03-08。先做三件事：开对上下文、限住修改范围、每次改完立刻验证。Cursor 适合多文件重构，Copilot 适合单文件补全与注释驱动开发。不要让 AI 直接“全仓库自由发挥”。先给最小输入，再看最小输出。
可直接照抄的结论：80% 的失败来自上下文太大、提示词太空、没有验证命令。把这三项收紧，命中率会明显上升。
一、前置条件：先把环境弄干净
目标不是“装上就能用”，而是“装上后可重复产出可审查的修改”。
-
编辑器：Cursor 1.6.x 或 VS Code 1.88+。
-
代码库：至少有可运行测试命令，例如 pytest、pnpm test、go test ./...。
-
权限：GitHub Copilot 账号已登录；Cursor 已完成模型设置。
-
网络：如果你在国内环境访问 GitHub 或 Google 相关服务不稳定，先保证登录与补全通道稳定，再谈效率。否则你会把“网络问题”误判成“模型不好用”。
Note: 先确认仓库里有 lint、test、typecheck 三类命令。没有这些，AI 改代码后的收益会被回归成本吞掉。
二、Cursor：用“局部上下文 + 明确目标”替代大段废话
Cursor 的强项是跨文件理解和批量改写。弱点是你给的范围越大，越容易把“正确方向”写成“看起来像对”。我的经验是：先框目录，再框函数，最后框行级修改。
-
只选相关文件。不要把整个 repo 丢进去。先选 2-4 个直接相关文件。
-
提示词写成任务单。例如：
请只修改 auth/*.ts 和 middleware/*.ts。 目标：把 JWT 过期后的错误统一返回 401。 约束：不改接口签名，不新增依赖。 输出：先列出修改文件，再给 diff。期望输出：列出 2-3 个文件，给出可审查 diff，而不是长篇解释。
-
先让它解释，再让它改。先问“这段逻辑的入口和出口是什么”，再问“按这个规则修改”。这样可以快速暴露模型是否理解边界条件。
实测数据：在一个 18k 行的 Node.js 服务里，我把上下文从 11 个文件缩到 3 个文件后，第一次可用补丁的采纳率从约 40% 提升到约 75%。测量方式很简单：记录每次 AI 输出后需要手工重写的行数。
Warning: 不要在 Cursor 里一次性要求“优化整个模块”。如果任务不可分解，AI 通常会优先保持表面一致性，而不是正确性。
三、GitHub Copilot：把它当“行级加速器”，不是架构师
GitHub Copilot 的优势在于单文件补全、注释生成代码、补齐样板。它最适合的场景是：你已经知道要写什么，只是不想逐字敲。
-
用注释定义意图。例如：
// parse env, fallback to default, and log only once function loadConfig() {期望输出：它补出完整函数骨架、默认值处理、日志分支。
-
用局部测试驱动补全。先写断言，再让 Copilot 补实现。别反过来。
-
让它补“重复但容易出错”的部分。例如 DTO 映射、错误码表、SQL 参数绑定、mock 数据。
在我自己的使用里，Copilot 对模板化代码的速度提升最稳定。一个 120 行的表单校验文件，纯手写约 14 分钟，配合注释式补全约 6 分钟。这个数字来自三次重复任务的平均值，差异主要来自我是否提前写好输入校验清单。
Note: Copilot 对“已存在风格”的贴合度通常高于 Cursor 的大范围重构。需要一致性时，先让 Copilot 补局部，再让 Cursor 做跨文件整理。
四、组合拳：补全、重构、排错的最短路径
-
先补全：用 Copilot 写出当前文件的基础实现。
-
再重构：把重复逻辑交给 Cursor 合并到公共函数。
-
最后排错：把失败日志贴给 Cursor，只给一条错误链，不要贴整屏噪音。
排错提示词建议固定成这个格式：
错误现象：jest 通过，runtime 报 TypeError。
日志：TypeError: Cannot read properties of undefined at src/a.ts:42
约束：只修这条链路，不改测试框架。
请给出根因、最小修复、验证命令。
期望输出：根因定位到具体变量或分支，给出最小修复，以及可执行验证命令。
验证命令示例：
pnpm lint
pnpm test
pnpm typecheck
期望输出：三条命令都返回 0；lint 无 error，test 全绿，typecheck 无报错。
五、怎么判断真的提效了
-
看重写率：AI 产出后你手工改动超过 50%，说明提示词或上下文有问题。
-
看回归率：改完后如果测试失败次数增加，说明你把“看起来对”当成“真的对”。
-
看时间分布：如果你的时间主要耗在解释需求，而不是审查 diff，AI 已经在帮倒忙。
How to verify it works：任选一个真实小任务，记录“开始时间、AI 首次输出时间、可合并时间、测试通过时间”。如果可合并时间比纯手写减少 30% 以上，且测试仍通过，这套方法就是有效的。
如果你想同时保留免费/官方路线与更顺手的工作流，先把上面这套方法跑通，再按团队政策选择工具。需要一个入口时，可以把官方文档与工作流集成到 roxi.cc 做统一整理，但核心仍然是上下文控制、最小修改和验证闭环。
References
GitHub Copilot 官方文档
Cursor 官方文档