选择日韩海外程序员赛道需警惕猝死风险
凌晨两点的“明日午前”，和一组被 AI 改红的测试
东京客户在 Slack 里发来一句“明日午前までに”，你这边是凌晨两点。项目是日韩外包，验收细、沟通绕、交付窗口短。你本来只想用 Cursor 把订单服务的批量取消逻辑补上，结果它顺手改了鉴权、换了 DTO、还把 MyBatis 的 resultMap 删了半截。你一边回滚，一边重跑测试，天亮了。
很多人对 AI 编程有两个误区。
误区一：把 Cursor 当编译器。 以为提示词越短越强，打一句“帮我重构订单模块”就等奇迹。AI 不是编译器，它更像一个手速极快、但没看过你完整工程的外包新人。
误区二：把 AI 当加班燃料。 日韩赛道项目节奏紧，时差让人白天沟通、晚上写码。AI 确实能省时间，但如果你跳过边界、上下文和验证，它会把返工切得更碎，让你连续熬夜。猝死风险从来不只来自工时，也来自工程失控后的持续高压。
下面这些 Cursor 实战技巧，都是在一线项目里被凌晨测试逼出来的。
一、高效实战技巧：3 个能直接照搬的方法
技巧 1：先画工程边界，再让 Cursor 动手
Cursor 最容易犯的错，是“热心过头”。你让它修一个接口，它可能把 Controller、Service、DTO、配置全改一遍。你要做的第一件事，是给它画边界。
操作步骤：
- 在项目根目录建
.cursorrules或AI_RULES.md，写清技术栈、测试命令、禁止改动目录。 - 在 Chat 里先让它读目录和关键文件，别急着让写代码。
- 明确只允许改哪几个文件，要求输出 diff，不要直接 Apply。
- 每改一步，先跑测试，再 commit。
真实项目案例：一个 Spring Boot 订单服务要加“重复提交幂等”。我给 Cursor 的约束是：只改 OrderService、OrderMapper 和对应测试，不许动鉴权、不许升级依赖。它第一次仍然想改 Controller，我把规则文件贴进对话后，它收敛到 Service 层，用 Redis 做 token 校验。测试跑通，diff 只有 4 个文件。
【金句：AI 写得快不快，取决于你给的边界清不清。】
技巧 2：用“三步提示法”，让 AI 先想再写
直接说“帮我修 N+1 查询”，Cursor 可能给你一个看似合理、但索引全错的方案。我常用三步提示法：
第一步，让 AI 复述需求和约束。
第二步，让它列出风险和不确定点。
第三步，再让它给补丁或 diff。
提示词可以这样写：
你是资深 Java 后端。项目 Spring Boot 2.7 + MyBatis，JDK11。
目标：修复订单列表 N+1 查询。
约束：只改 Repository 和 XML，不升级依赖，不改接口返回结构。
先复述需求，列出 3 个风险点，再给 diff。测试命令：mvn test -Dtest=OrderRepositoryTest。
真实案例：一个订单列表接口，循环里查用户信息，200 条订单打 201 次数据库。AI 先指出可以批量查用户，再提醒要注意 IN 参数过大。它给出 selectBatchIds 方案，测试通过。那次没有熬夜。
【金句：让 AI 先想再写，比让它写完再骂更省命。】
技巧 3：把验证写成命令，不要靠眼睛
AI 代码最危险的地方，是“看起来对”。变量名对、注释对、格式对，跑到线上就错。你要把验证变成命令。
操作步骤：
- 让 Cursor 生成单元测试、集成测试或脚本。
- 要求它必须运行测试命令，失败就把日志贴回来。
- 让它在 diff 里标注未覆盖的边界。
- 核心链路加 feature flag，能回滚。
真实案例：支付回调签名校验，AI 初始版本漏了时间戳窗口，本地手工点能过，测试一跑就暴露。补上时间戳校验后，又发现时钟漂移问题，最后加了 5 分钟容差。
【金句：没有测试的 AI 代码，都是给凌晨准备的。】
二、高频避坑要点：5 个最容易踩的坑
坑 1：直接 Apply 大范围重构
现象：AI 一次改十几个文件，你点 Apply 很爽。
危害：原有工程被改坏，回滚都找不到边界。
规避：要求输出 diff，分步 Apply，每步跑测试并 commit。大重构拆成小任务。
坑 2：上下文缺失，AI 开始幻觉
现象：它调用不存在的 API，编造配置项，猜错数据库字段。
危害：编译失败算轻，线上事故算重。
规避：贴接口定义、表结构、日志、依赖版本。别只说“有个订单服务”。
坑 3：忽略版本和依赖
现象：AI 按最新 Spring Boot 3 写法改你的 2.7 项目，或者引入新库。
危害：依赖冲突，打包失败。
规避：把 pom.xml 或 package.json 放进上下文，明确“不许升级依赖”。
坑 4：让 AI 改核心链路却没有回滚
现象：鉴权、支付、库存、结算，直接让 AI 生成补丁。
危害：一旦出错，影响面大。
规避：分支开发、feature flag、回滚脚本、灰度发布。核心链路必须人工 review。
坑 5：把 AI 当加班放大器
现象：日韩客户催得急，你通宵让 AI 生成代码，越改越乱。
危害：身体扛不住，项目也扛不住。
规避：设硬性截止，需求不清就停下确认。自动化优先，拒绝无边界追加。AI 可以加速，不能替你睡觉。
【金句：AI 不会替你猝死，但会放大你熬的夜。】
三、真实完整案例复盘：批量取消未支付订单
项目背景：一个面向日韩市场的 Spring Boot 订单系统，客户要求新增“批量取消超时未支付订单”。业务方原话是“每天上午十点前清理掉，不要影响报表”。项目是 Spring Boot 2.7 + MyBatis + MySQL，JDK11。
我输入的提示词：
你是资深 Java 后端。项目 Spring Boot 2.7 + MyBatis，JDK11。
