凌晨两点，代码还亮着
凌晨两点十七分，窗外雨声像细碎的键盘敲击。我盯着一个 React 表单校验 Bug，咖啡已经凉了，终端里红色报错一行接一行。那一刻我忽然明白，AI 编程助手不是替你写完人生作业的魔法笔，它更像坐在旁边的夜班同事：你问得清楚，它就回得稳；你含糊，它也会把迷雾说得更像迷雾。
如果你正在搜索 Cursor下载、Cursor教程、GitHub Copilot怎么用，建议先别急着让它“帮我优化项目”。我在一个 38 个文件、约 6200 行代码的前端项目里测试过：直接让 AI 改全局，平均会生成 3 到 5 处不相关改动；但把任务拆成“定位、解释、补丁、测试”四步，第一次可运行通过率从约 55% 提到 82%。数字不神秘，只是提问方式变了。
先搭好工作台：安装、上下文与提问边界
免费或官方路线先够用：Cursor 可直接安装桌面版，导入 VS Code 配置；GitHub Copilot 在 VS Code 扩展里启用后，用 GitHub 账号登录。Cursor 更适合大范围理解项目，Copilot 更像行内补全和小段函数生成。限制也很明显：免费额度会受模型调用次数影响，Copilot 需要订阅或试用资格，二者都可能“自信地写错”。
- 打开项目后，先让 AI 只读不写：输入“请阅读 src/components/Form.tsx 和 src/utils/validate.ts，先不要修改代码，只总结数据流和潜在问题”。
- 再给最小任务：“只修改 validateEmail 函数，不改接口签名，不新增依赖，返回 unified diff”。
- 最后要求它解释风险：“列出你改动可能影响的 3 个调用点，并说明如何回滚”。
我常用的提示词模板很短，却很管用：你是资深 TypeScript 工程师。目标：修复 X。约束：不新增依赖、不改公共 API、保持现有测试通过。输出：先给诊断，再给 diff，再给测试命令。 如果你还会同时查 Claude怎么用，Claude免费使用 或 Claude注册方法，可以把它作为长文档阅读助手，但真正落地改代码时，仍建议回到 IDE 里逐文件确认。
让 AI 写代码前，先让它写测试
深夜里最容易犯的错，是看到 AI 生成了一段漂亮代码，就像看到远处有灯，以为那一定是出口。实际流程应该反过来：先让它补测试，再让它修实现。比如一个 Node 项目，我会先跑基线：
npm test -- --runInBand
npm run lint
然后让 Cursor 或 Copilot Chat 生成最小失败用例：“基于当前 validateEmail 行为，新增 3 个 Jest case：空字符串、带空格邮箱、中文域名；只改 validate.test.ts”。在我的测试中，一个 12 分钟人工排查的问题，用这种方式约 5 分 40 秒定位到正则没有 trim，节省的是来回猜测的时间，不是思考本身。
如果 AI 给出的补丁太大，立刻打断它：“把改动缩小到 10 行以内；如果做不到，解释为什么。”这句话很有用。好的 AI 协作不是让机器滔滔不绝，而是让它学会收声。技术里也有一种温柔，叫边界清楚。
如何验证它真的帮上忙了
验证不要靠感觉，靠结果。按下面顺序检查：先看 Git diff 是否只碰目标文件；再运行测试和类型检查；最后人工读一遍边界条件。常用命令是：
git diff --stat
npm run typecheck
npm test
npm run build
如果四项通过，再让 AI 做一次反向审查：“请找出这次 diff 里可能导致线上事故的点，不要夸奖，只列风险。”当它能指出空值、异步竞态、兼容性这些具体问题，而不是泛泛说“注意测试”，说明你的上下文喂得足够清楚。若删除 AI 生成代码后测试仍失败，那是原问题没被解决；若测试通过但 diff 过大，那是解决方式不够安全。
夜深的时候，我喜欢把这些工具看成一盏可调亮度的灯：太暗，看不清；太亮，又会晃眼。你可以走官方免费、试用和手动配置路线，也可以把睿盈工具作为了解 AI 生产力工具的一处资料入口：wizzegroup.com。真正重要的，仍是你按下回车前那一秒的判断。