编码时间降了65%，但我反而更焦虑了

你有没有过这种感觉——效率明明涨了交付的东西明明多了但下班的时候心里虚得慌。我以前一直以为是矫情。直到上个月我给自己做了个实验然后失眠了一个晚上。事情是这样的。我一个十年 Java 程序员从去年开始陆陆续续在用 AI 写代码。Claude Code 为主偶尔 Codex 打杂。用着用着觉得挺顺手就想看看它到底省了我多少时间。5 月底我开了个严格对照手头三个 Spring Boot 微服务——设备数据接入、告警上报、音视频流转发——再加一个管理后台。我把 AI 当成刚入职的 P6我当 Tech Lead。我负责描述需求、审查代码、拍板架构它负责写。对照基线是 4 月份纯手写、规模接近的同类项目。跑满 30 天拉数据。结果是日均编码时间从 5.2 小时掉到了 1.8 小时。注意这不是说 AI 帮我把一天变成了不到两小时——是我真正坐在电脑前敲键盘的时间不到以前的一半。交付的有效代码行从 180 行涨到了 420 行。这里我剔除了 AI 直接吐出来的东西只统计我自己手敲和大幅修改的部分。说白了活干得更多了手敲得更少了。Commit 次数从日均 3.2 跳到了 11.5。不是变勤奋了是节奏被 AI 改了。以前一个接口吭哧写一天中间懒得提交。现在 20 分钟干完一个 CRUD顺手就 git commit 了。单元测试覆盖率从 61% 飙到 73%这没啥好说的AI 写测试确实是碾压级的。说实话数字好看到有点不真实——第一次把这几张表拼出来的时候我心里咯噔了一下隐约觉得哪里不对劲但没细想毕竟谁会跟自己的效率数据过不去。到这里一切都很美好。朋友问我用 AI 什么体验我说像带了个干活贼快的 P6。但 30 天实验结束时一统计同样类型和规模的交付线上 bug 从 3 个涨到了 11 个。就是那 11 个 bug 让我失眠的。我一个个复盘。7 个是同一个根因——并发安全。2 个空指针。1 个缓存一致性。1 个异常被吞。全都是那种理论上测不出来上线就炸的类型。最典型的是积分扣减。代码长这样Transactional public void deductPoints(Long userId, Integer amount) { User user userMapper.selectById(userId); if (user.getPoints() amount) { throw new BusinessException(积分不足); } user.setPoints(user.getPoints() - amount); userMapper.updateById(user); PointsLog log new PointsLog(); log.setUserId(userId); log.setAmount(-amount); pointsLogMapper.insert(log); }本地跑三天测试全绿。上线以后两个并发请求同时读到 points 100各扣 10 分都写回了 points 90。MySQL 默认 RR 隔离级别普通的 SELECT UPDATE就这个窗口。说出来不怕你笑话这段代码我在 Code Review 的时候看了两遍没看出问题。不是因为逻辑复杂——逻辑一眼就通。是因为 AI 写得太快了快到我把 Code Review 变成了看一眼通不通而不是推演一遍并发路径下会怎样。缓存一致性那个更离谱。我让 AI 写了个设备状态变更后刷新在线状态缓存的逻辑。它生成的代码很标准——先更新数据库再删 Redis。所有教科书都这么教的。但线上跑了两天偶尔有设备明明在线缓存里却显示离线。排了半天发现问题出在时序上坑就出在删 Redis这一步写在了 Transactional 方法体里——事务要等方法返回才真正提交但删缓存的动作已经先执行了。这个窗口期只要有别的请求插进来读一次库缓存就脏了而且脏了之后不会自己修复除非再有人写一次。AI 不知道这个接口的 QPS不知道你的事务隔离级别不知道你的缓存过期策略。它只知道先更新数据库再删缓存是一条标准答案。标准答案在低并发下是对的在你这里不是。说白了它就像个 P6。基础扎实干活快。你告诉它写什么它 30 秒给你一个完整的 Service 层格式统一注释齐全。写测试、优化 SQL、拼配置类这些活它干得比谁都利索。但它也跟 P6 一样有些东西你教不会。它不知道你们系统里哪些接口是高并发的。不知道上游某个字段可能传 null。不知道你删了 Redis key 之后另一个请求会插进来读到旧数据。这些不是语法错误是你干了十年攒下来的东西——扫一眼就知道这里会崩、那里没判空、这段的缓存对不齐。AI 不会自动长出这些经验。你不说它就不知道。而且这一次你教了它下一次换个同样的问题它还是按默认套路来。你带一个 P6 两年他会成长。AI 你用两年它还是按你最近一次 prompt 里的上下文办事。这个月之后我给自己钉死了几条自查清单1. 涉及余额、库存、计数类字段的更新默认走乐观锁或行锁不写先查后改这种裸奔的 SELECT UPDATE2. 缓存删除动作必须放在事务提交之后执行绝不能塞在 Transactional 方法体内部至少先守住这一条底线延时双删、binlog 订阅那些看场景再上3. 只要是读一次、算一次、再写回去这种组合操作先问自己一句并发下这两步中间会不会被别人插队不求多就求 AI 写完之后我扫一眼代码能对上这几条。30 天实验结束的时候我给自己画了一条线。不是给别人看的是给自己——什么活直接甩给 AI什么活老老实实自己啃。CRUD、单元测试、SQL 优化、配置类、工具方法、枚举转换、日志框架、API 文档——全都丢。这些活的规则是明确的不需要你做业务判断。你纠结的时间AI 已经写完三遍了。架构设计、复杂业务逻辑、跨模块重构、线上排查、安全相关代码——留给自己。这些东西需要你把整个系统的上下文装在脑子里AI 现阶段就是在浪费你的时间。这条线也不是一刀切的。比如给设备心跳接口加一层在线状态缓存这种活看着像 CRUD能丢给 AI但我现在都会自己啃——因为一牵扯到缓存和实时状态就绕不开一致性问题一旦交出去风险就藏在你看不到的地方。判断标准很简单这活出了问题你能不能一眼看出锅在哪。能就丢给 AI看不出来就自己写。还有个用法很多人没试过让你手写的代码给 AI 做 Review。不是让它审自己写的是审你写的。你把手写代码丢进去问一句找出所有并发问题、空指针风险和性能瓶颈它十秒能扫出一堆你漏掉的。人工 review 容易漏AI 刚好补上。所以你发现没有分工其实很自然——AI 写的你审你写的 AI 审。不是谁替代谁的关系是交叉检查。顺便说一句如果你嫌 Claude Code 贵现在大部分模型都能接了。我中间试了个 CC-Switch 把后端切到 DeepSeek V4大概两折半日常写 CRUD 和跑单元测试基本感受不到差距。复杂重构再切回 Claude。一个月 API 费不到两百块。失眠那个晚上我翻来覆去想一个问题。不是AI 为什么会写出 bug——它当然会写不写才奇怪。也不是我为什么没审出来——审不出来是因为它写太快我跟不上。这些都不是真正让我睡不着的东西。真正让我睡不着的是这个当 AI 把写代码的门槛降到零之后我干了十年的经验到底还值不值钱。我问了自己一夜。天亮的时候有了一个答案。比以前更值钱。但前提是你得意识到你现在干的不叫写代码叫审代码。审的不是格式规范不是命名约定是并发、安全、一致性——是所有 AI 不会自动学会的东西。审的也不是代码本身是这个方案在你的业务里什么条件下会失效。写代码变简单了所以写代码的人会变多。但编程变难了——因为当所有人都能写的时候你能不能在三秒内扫出一段代码在高并发下会崩能不能一眼判断出这里缺了缓存一致性能不能预判到上游可能为 null——这些以前是加分项现在正在变成及格线。AI 没有抬高天花板。它把地板抬高了。把以前还不错的那批人跟真的懂的那批人拉开了。我以前觉得写技术文章这事挺没意思的。网上教程那么多不缺我一个。但这次 AI 实验做下来我发现真正缺的东西不是教程——是那种我也踩过这个坑的共鸣。如果你也在用 AI 写代码也有过那种效率涨了但心里不踏实的感觉这篇文章评论区聊聊。我把这次实验里复盘的 11 个 bug 整理成了一份踩坑笔记包括每一条的触发场景和修复后的代码。不是什么正式文档就是一个工程师的踩坑记录。不发教程只发踩坑记录。十年 Java 老兵用代码说话。