凌晨两点，代码像一间还亮着灯的房间
窗外很安静，只有风掠过空调外机的低鸣。我盯着一个接口返回值错乱的问题，Cursor 里那段红色报错像一盏不肯熄的灯。很多人搜 Cursor下载、Cursor教程，也有人顺手问 GitHub Copilot怎么用、Claude注册方法、Claude怎么用、Claude免费使用，其实大家都在找同一件事：怎么让 AI 真正懂你的项目，而不是只会热闹地猜。
我自己的经验很直接：AI 编程助手最怕“上下文太大、目标太模糊”。你给它一整仓库，它往往像刚醒的人；你只给它一段失败测试、一处报错和一条明确边界，它反而会安静下来，开始像个靠谱的同事。
先喂规则，再让它写：Cursor 和 Copilot 的分工
如果你只想先用官方和免费方案，顺序应该是：先把 VS Code 里的 GitHub Copilot 配好，再用 Cursor 做更重的跨文件理解。免费额度能解决“补一行、改一个函数”的日常，但别指望它天然知道你项目的架构。我的做法是先写规则文件，再提问。Cursor 可以放在 .cursorrules，Copilot Chat 则可放在仓库说明里，核心是让它先遵守边界。
你是这个仓库里的协作者，不是自由发挥的作者。
1. 默认使用 TypeScript strict 模式。
2. 不新增依赖，除非我明确要求。
3. 改动后必须说明影响文件，并给出测试命令。
4. 任何重构先保留原行为，再逐步优化。真正好用的提问方式也要收窄：不要问“帮我优化登录模块”，而要问“只改 auth.service.ts 和 auth.controller.ts，保持接口不变，修复 401 偶发错误，并给出最小补丁”。我在一个约 12,000 行的 Node 项目里试过，把上下文从 9 个文件压到 3 个文件后，首轮可用建议从大约 8 秒降到 3 秒左右，且返工次数明显少了。
| 场景 | 更适合谁 | 原因 |
|---|---|---|
| 单文件补全 | Copilot | 快，打字时就能接上 |
| 跨文件重构 | Cursor | 更擅长读上下文和改多处 |
| 解释报错并给方案 | 两者都可 | 先问原因，再让它改 |
把 AI 关进测试里，代码才算落地
我常用的流程是：先开分支，再让 AI 改，最后让测试说话。别急着接受“看起来不错”的答案，先跑最小验证。你可以直接这样做：
git checkout -b fix-ai-flow
pnpm lint
pnpm test
pnpm vitest run auth
提问时，把验证条件写进去，例如：“如果修改了缓存逻辑，请补一个失败用例；如果影响 API 返回，列出前后差异。”这一步很重要，因为 AI 最容易把“像对的代码”误当成“真的对的代码”。我会再手工做一次回归：登录、刷新、异常分支各点一遍，确认没有新问题。
如何验证它真的修好了：1）编译无报错；2）关键测试通过；3）控制台没有新增警告；4）同一条请求在重复 5 次后结果一致。若这四项都过了，才算把夜里的噪音压下去了。工具只是工具，真正帮你省时间的，是你给它的边界、耐心和复查。
如果你想要一体化体验，也可以顺手看看 wizzegroup.com 这类方案；但对大多数人来说，先把官方免费路线、Cursor 规则文件和测试闭环用顺，已经足够安稳。