日韩严苛职场等级让程序员丧失工作自由
日韩严苛职场等级让程序员丧失工作自由
晚上十点半，首尔江南一栋写字楼的十七层还亮着灯。一个写了八年 Go 的工程师把刚改到一半的接口关掉，起身去参加部门例行的"报告—联络—商量"会。会上他不负责提技术方案，只负责报进度：方案由科长定，科长上面还有次长。东京那边也差不多，年功序列摆在那儿，三十五岁的资深工程师给三十岁的组长交周报，架构选型从来轮不到键盘前那个人拍板。
这种环境里，程序员丢掉的自由很具体：不能选技术栈，不能拒绝无效会议，不能决定某个模块该不该重构。你唯一还能自己说了算的，是"单位时间产出多少"。
于是很多人开始用 Cursor 这类工具，想把自己从琐事里捞出来。用了两周发现，代码是变多了，坑也变多了。我见过两种典型误区：
误区一：把它当成"自动写完整项目"的按钮。 打开 Agent 模式，丢一句"帮我做个订单系统"，然后等着收代码。它给你的东西能编译，但和现有工程格格不入——目录结构、错误码、日志格式全对不上。
误区二：它写得越流畅，你越容易跳过 review。 等到线上报 500，翻回去才发现它调的那 个库函数，在你锁定的版本里根本不存在。
下面是我反复用、能直接照搬的东西。
一、三个能直接照搬的实战技巧
1.1 用 rules 文件给 AI 划边界，别每次口头交代
操作步骤：
- 在项目根目录建
.cursor/rules/project.mdc（老版本是.cursorrules），写清楚：语言与版本、框架、目录约定、命名风格、日志库、错误包装方式。 - 最关键的一条：把项目里已有的一个典型文件整段贴进去当范例，让它照着模仿，而不是照着想象。
- 写"禁止事项"清单，比如"禁止引入新的第三方依赖""禁止改动
internal/legacy下的任何文件"。
真实案例： 一个支付网关项目，日志统一用 zap 的 SugaredLogger。AI 默认爱用 fmt.Println 和 log.Printf，每生成一个新文件我都得手动改一遍。把 rules 写清楚并贴了一个 handler 当范例之后，新生成的文件直接用 logger.Infow，字段名也对齐了。
注意：rules 不是写一次管一辈子。你改了错误码规范、换了下游 SDK，就要回去更新，否则 AI 会照着过期规范生成。
【金句：AI 不是不懂你的项目，是你从来没告诉过它。】
1.2 精确 @ 引用文件，别让它自己"猜"上下文
操作步骤：
- 用
@文件名指定要改的文件和要参考的文件，单次不超过 5 个。少用大范围的全库检索，那玩意儿一慢二散。 - 提示词里先让它输出改动计划，你点头再让它动手。
- 明确写"只在以下文件内改动：xxx"，把范围钉死。
真实案例： 改一个订单状态机，本来只需要动 state_machine.go 和它的测试。第一次我没限定范围，它顺手把 repository 层也重写了，SQL 拼接方式都给我换了，diff 出来 200 多行。后来改成 @state_machine.go @state_machine_test.go，并写明"只在这两个文件内改动"，diff 降到 40 行，review 十分钟搞定。
【金句：让 AI 自由发挥，等价于让实习生直接 push 到 main。】
1.3 先写一个失败的测试，再让它去把测试变绿
操作步骤：
- 自己写测试，断言你真正要的行为，把边界和错误分支都写进去。
- 把测试和被测文件一起 @ 进去，提示词写："让这个测试通过，不许修改测试文件本身。"
- 跑通之后再让它补错误处理和日志。
真实案例： 一个库存预扣接口，最怕并发超卖。我先写了一组测试：200 个协程并发扣 100 件库存。AI 第一版给的是 Redis DECRBY 加判断，单线程测试能过，并发一跑就挂，库存变负数。我把失败日志原样贴回去，它改成 Lua 脚本做原子操作，测试才变绿。
为什么这招好使：测试是你写的，验收标准就掌握在你手里。AI 骗不了
go test。
【金句：把验收标准写在测试里，比写在提示词里有用一百倍。】
二、五个最容易踩的坑
2.1 幻觉 API 与版本错配
现象： 它给你一个 client.WithRetryPolicy(...)，你去文档里一查，你这个版本根本没这个方法。
危害： 编译不过还好，最怕它自己又编了个兼容层把编译糊过去，上线才炸。
规避： 让它先读 go.mod / package.json；@ 引用本地已有的调用示例；新引入的 API 一律自己去官方文档核一遍。
2.2 大范围重写，改坏原有工程
现象： 你只想加个字段，它把整个文件重排了，顺手"优化"了命名和错误处理。
危害： diff 上千行，真 bug 藏在噪声里，review 直接失效。
规避： 开工前建分支；提示词写死改动范围；合并前逐块看 diff，不是一路 approve。
2.3 长对话里早期约束被"忘掉"
现象： 聊到第二十轮，它开始用 snake_case，而你项目是 camelCase。
危害： 一个模块两种风格，后面接手的人骂你。
规避： 约束写进 rules 文件，不靠对话记忆；任务切换就新开会话，别一条线程干到底。
2.4 看起来对，边界没处理
现象： 主流程写得漂亮，事务边界、空值、超时、并发全没管。
危害： 测试环境全绿，线上一到高峰期就脏数据。
规避： 每次收到代码补一句提问："这段代码没有处理的边界情况有哪些？逐条列出来。" 它的自我检查往往比第一版代码有价值。
2.5 把密钥和生产数据贴进对话
现象：
