奔赴日韩从事程序员难以实现职业增值

奔赴日韩从事程序员难以实现职业增值

凌晨一点，首尔的朋友发来消息。他在韩国做后端第三年，工资条比国内同期多一截，但每天干的事是给遗留系统贴补丁、改本地化文案、写 Excel 批处理。想跳回国内大厂，面试时讲不出高并发，也没碰过核心链路。他说：“我好像只是换了个国家继续拧螺丝。”

这不是个例。你把赴日韩当成职业增值跳板，现实可能是薪资小涨、能力原地。日韩市场有大量维护、外包、本地化项目，语言和文化天花板真实存在。能赚钱，没错。但职业增值不靠换邮编。

更扎心的是，很多人一边焦虑增值，一边用 AI 编程工具把自己带进另一个坑：让 Cursor 写 demo 很爽，改老工程时幻觉、乱改、编译不过。地域迁移和 AI 工具，都只是杠杆。杠杆用错方向，放大的是混乱。

一、高效实战技巧：把 Cursor 从“补全神器”变成“可控工程师”

1. 先画边界，再让 AI 动代码

Cursor 最大的问题不是不会写，而是不知道你的工程边界。你问“帮我重构订单服务”，它会自信地补出不存在的字段、编造内部 SDK、把同步逻辑改成异步。

操作步骤：

• 在项目根目录建 .cursorrules 或团队规则文件，写清技术栈、目录职责、禁止修改的文件。
• 对话时只 @ 相关文件，别把整个仓库丢进去。
• 要求它先输出影响面：会改哪些文件、哪些接口、哪些表。
• 确认后再让它给 diff，不要直接 Apply。

我处理过一个 Node.js + Postgres 的结算服务。价格计算散在三个文件里，AI 第一版把税费逻辑抽到新模块，却顺手改了数据库字段名。后来我加了一条规则：“禁止改 schema，除非先给 migration。”第二版才落地。

【金句：AI 编码的第一原则：让它在围栏里干活，而不是在草原上放羊。】

2. 测试先行，小步提交

AI 改代码最怕“一口气改完”。你看着 diff 几百行，根本不知道哪行埋雷。正确姿势是：先补测试，再小步改，每步提交。

操作步骤：

• 让 Cursor 读现有测试，别急着写新测试。
• 补一个覆盖当前行为的测试，跑通，提交。
• 再让它做一个小改动，只改一个函数或一个分支。
• 跑测试、类型检查、lint，过了再提交。
• 失败就回滚，别在脏 diff 上继续让 AI 修。

一个分页接口有 N+1 查询。我让 AI 先写测试：请求 20 条订单，断言 SQL 查询次数不超过 3。它第一次改完，测试过了，但缓存键少拼了租户 ID。测试没覆盖多租户，我补上后才发现。小步提交救了这次改动。

【金句：AI 可以帮你写代码，但只有测试能告诉你它有没有撒谎。】

3. 三段式提示词：目标、约束、验收

“帮我优化一下”是无效提示。你要把 AI 当外包工程师，给清楚目标、约束、验收标准。

模板：

目标：把导出 CSV 接口从全量加载改成流式输出。
约束：不改路由，不改鉴权，不新增依赖，保持返回字段顺序。
验收：10 万行导出内存不超过 200MB，现有测试全过。
上下文：@export.controller.ts @export.service.ts @csv.util.ts

一个后台导出接口，原来一次性 find() 十万行，内存直接打满。用这个模板后，Cursor 给出了 stream + Transform 方案。中间它想引入 fast-csv，我按约束拒绝，最后用 Node 原生流实现。代码不花哨，但能落地。

【金句：提示词不是许愿，是把验收标准提前写进合同。】

二、高频避坑要点：5 个最容易把工程改坏的坑

坑 1：让 AI 猜上下文，幻觉 API 和字段。
现象：它写出 userService.getUserProfile()，你项目里根本没这个方法。
危害：编译不过，或者运行时才炸。
规避：贴类型定义、接口签名、数据库 schema。要求它先复述上下文，再动代码。

坑 2：一次性大改，diff 失控。
现象：你让它“重构支付模块”，它改了 18 个文件。
危害：代码审查形同虚设，回滚成本极高。
规避：限制文件数，按“读—改—测—提交”循环。每次只解决一个明确