当 AI 能写 80% 的代码时，后端工程师的核心价值还剩什么？

开头Review 现场代码能跑、测试全绿、注释齐全——这还不够。前两天我 Review 了一个新人的 MR。代码写得规整测试覆盖率 100%看着很漂亮。我扫了三行就皱眉头——不是挑刺是闻到了线上事故的味道。事务边界不对。 在数据库事务里同步调用支付和库存接口任意一个超时都会让事务长时间占着连接和行锁。缓存 Key 设计有坑。 把整个活动首页塞进一个固定 Key既是大 Key又会被所有请求集中访问大促流量一上来很容易压垮单个 Redis 节点。异常处理吞掉了关键信息。 catch 里只写了 log.error(“处理失败”)却没把异常对象传进去真出问题连堆栈都查不到。我把小伙子叫过来「这代码 AI 帮你写的吧」「嗯…目前有什么问题吗」空气中弥漫着尴尬的沉默。「AI 通常不会犯低级语法错误但上下文给不全它很容易埋下工程问题。这几类坑我在线上都踩过。」于是我把上述三个问题和他同步了一下。这事儿让我想了很久。不是想「AI 多危险」而是想——如果 AI 能写 80% 的代码了那我这个干了十多年的后端剩下的价值到底是什么二、AI 能搞定的 80%01我先承认AI 在我日常工作中确实帮了大忙。它最擅长的是把「已经定义清楚的问题」快速变成「能跑的实现」。CRUD 接口从 Entity 到 Mapper 到 Service 到 Controller一把梭我只需要加个权限注解SQL 优化把慢查询丢给它能分析出索引缺失、回表次数、Using filesort单元测试快速补齐常规分支和 Mock省掉大量重复工作接口文档Swagger 注解、Javadoc 自动补全有时比手写的还详细Bug 定位NullPointer 这类常见异常把堆栈丢进去很快就能缩小排查范围这些活已经没必要全靠人手工完成了。对于边界明确、模式固定的任务AI 往往更快也更少犯低级错误。但这也容易带来一种错觉产出变高了却更容易忽略一个问题——写出来的代码到底是在解决正确的问题还是在把错误的问题写得更漂亮三、剩下那 20%AI 写不出来因为答案不在代码里02但有些东西单靠 AI 很难给出可靠答案。不是因为它不够聪明而是因为关键上下文没有进入提示词。它不知道公司的运营群、不知道团队的 DBA 只会 MySQL、不知道上次上线为什么回滚。它只能基于「通用最佳实践」给出一份看起来合理的答案但是线上环境往往都不是按照教科书出牌。李开复在 2017 年台湾大学的演讲中把 AI 比作一根「魔法棒」。其中有句话我很认同有了 AI 这支魔法棒你有责任去解决困难的问题。不要浪费时间做那些机器很快就能胜过人类的事。——李开复落到后端日常里真正困难的问题——满减规则到底怎么算、故障先查哪条线、架构方案能不能兜住——往往就是剩下那 20% 的核心。下面三个踩坑经历说的都是同一件事。3.1 业务毒点——只有踩过坑的人才知道有回搞满减活动PRD 上只有一句话满 100 减 15满 200 减 30满 500 减 100。AI 按这句话生成的优惠逻辑单看代码完全没问题。上线当天下午 4 点客服电话被打爆「我购物车原价 210为什么只减了 15不是应该减 30 吗」把订单摊开一算关键问题是 PRD 没写清楚用哪个金额判断门槛以及优惠按什么顺序计算用户是会员商品先打了 9 折原价 210 元 → 折后 189 元满减门槛系统按「折后价」判断189 200够不上「满 200 减 30」但够上了低档「满 100 减 15」→ 所以用户只看到减了 15而运营的真实规则是写在需求文档之外只在运营群 所有人 说过会员日当天先按折前原价判断并计算满减再叠加会员折扣。按这条规则正确算法应该是先用原价 210 判断210 ≥ 200 → 应减 30再叠会员 9 折应付 (210 − 30) × 0.9 162 元用户期望减 30系统只减 15——不是 AI 算错了加减法是没人把「折前还是折后」「先打折还是先满减」写进 PRD。AI 可以写出满减算法但这类问题往往还得靠人追问一句「会员折扣和满减同时存在时门槛按哪个金额顺序怎么定」如果没人把运营群里的消息补进上下文AI 不会主动知道但后端系统会为这条遗漏买单。3.2 流量毒点——在日志和监控里不在代码逻辑里大促前夜凌晨 2:47钉钉连响三条订单服务 P99 延迟超 3 秒CPU 85%Redis 连接数逼近上限。我把超时调用栈和 getOrderList 的代码丢给 AI。它看到列表查询没有强制时间范围很快给出建议给 create_time 加联合索引再把深分页改成游标分页。建议本身没错但它解释不了这次告警。我先没动代码打开了 Grafana。2:45 起订单接口的请求量仍在平时的 300 QPS 左右但 Redis 命令量从每秒 4000 多次冲到 6.8 万次与此同时MySQL QPS 只涨了不到 20%。CPU 烧在 Java 进程里数据库反而不忙。这就很反常如果问题主要在慢 SQL数据库连接数、活跃线程和磁盘 IO 应该先抬头现在却是应用和 Redis 先扛不住。接着查发布记录——今晚零发版。再查 Nginx access log发现 2:44 到 2:47 之间/admin/order/export 被连续调用了 17 次同一个 admin_token同一个 User-Agent。2:50 我给值班运营打了个电话。对方还在赶第二天的报表「页面一直转圈我以为没点上就又点了几次……」又点了几次——实际上她一共点了 17 次。每次导出都会不加时间范围默认拉近半年的订单——接近 48 万行在内存里用 POI 拼 Excel单个任务峰值占用约 500MB 堆内存每行订单顺带查一次用户昵称——最多触发 48 万次 Redis GET既没批量也没做本地去重17 个导出任务叠在一起堆内存开始频繁 Full GCCPU 被打满Redis 连接池也被占满连带把正常用户的 getOrderList 拖慢了。AI 看到的现象是「getOrderList 慢」——因为 Redis 连接池耗尽后订单列表查用户缓存也开始排队超时。症状落在列表接口病根却在导出接口。 它更不知道的是这 17 次调用背后是运营看到页面没反应后反复点击的本能操作。最后怎么处理不是加索引而是三件事立刻在网关临时关闭导出入口滚动重启被拖住的实例再把接口限制为单用户单任务随后导出改成异步任务——写任务表、后台 worker 生成文件页面只返回「任务已提交」补上边界导出强制带时间范围单次最多 31 天超过 10 万行拆分文件并走离线任务这类问题很难单从代码里读出来。 堆栈告诉你「哪里在等待」监控告诉你「哪类资源先异常」访问日志里的 URI 和 admin_token才把问题指向那 17 次导出。只有挨过罚、赔过钱、凌晨被叫起来查曲线的人才会养成习惯告警响了先看变更、先看流量、先看上下游——而不是一头扎进 IDE 改 SQL。3.3 架构毒点——靠权衡不靠标准答案有回我们接了个新项目社区团购的后台PM 的口径是「日活 10 万、峰值 QPS 2000、8 周 MVP 上线」。我只把业务目标和峰值指标丢给 AI它给出一份很标准的架构方案拆 5 个微服务用户、商品、订单、库存、支付MySQL 读写分离 Redis Cluster 做缓存和分布式锁Kafka 做订单异步解耦Seata 管跨服务分布式事务每一种都是成熟方案但一次性全上我们团队根本兜不住。当时真实的约束是这样的维度 AI 方案隐含的条件 团队现状后端人力 多个服务需要独立开发和维护 2 人其中一个 6 周后离职中间件运维 Kafka 3 Broker 起、Redis Cluster 6 节点 0 专职运维DBA 只熟 MySQL 主从业务确定性 系统会长期运行并持续扩容 PM 私下说「3 个月验证不了就砍」上线窗口 — 8 周含联调提测如果照 AI 方案硬上光 Kafka 消费积压排查、Seata 超时回滚、跨服务链路追踪就够 2 个人全职填坑——业务代码反而没时间写。我们最后定的方案看起来「不够高级」Spring Boot 单体按领域分包user / product / order模块边界写清楚但部署只有一个 jarMySQL 一主一从从库先用于故障切换和只读校验备份单独做不急着把读写分离引进业务代码——压测显示订单写入峰值单主库能扛住托管版 Redis 主从 2G缓存 分布式锁先不自建 Cluster本地消息表 代替 Kafka——订单创建后写一条 outbox 记录定时任务扫表发通知最终一致性够用不做 Seata——扣库存和创建订单在同一数据库事务里完成跨库场景一律设计成可补偿会上有同事质疑「这方案能撑到 100 万 DAU 吗」我的回答是眼下的问题不是 100 万是 8 周后能不能上线、上线后 2 个人能不能睡整觉。 架构不是选「理论上最优」是选「当前约束下最不容易死、出了问题 10 分钟能回滚」的方案。后来项目没砍日活慢慢涨到了 35 万。大促高峰时Redis 延迟开始抬头部分缓存请求超时后降级查询数据库。但这时候团队已经扩到 5 人缓存 Key 规范和序列化协议也早已统一迁移到 Cluster 的改造范围比较可控订单模块随后也从单体里独立出来早期划清的代码边界让这次拆分少走了很多弯路。反过来看隔壁组当时走了 AI 同款方案3 个微服务 Kafka3 个人维护。上线没多久Kafka 就积压了 40 万条消息没人发现——不是没人写消费逻辑是没人 7×24 会看 Kafka 的 lag 面板。等用户投诉「下了单没短信」排查才发现消费者早就被一次错误发布搞挂了只是没人盯着。AI 给的是标准答案但工程决策从来不是标准题。 真正要回答的往往是这个方案今晚出了问题谁能在 30 分钟内 rollback这个中间件团队里有没有第二个人会修这个拆分是为了解决眼前的瓶颈还是为了简历好看更现实的选择往往是「团队现在能稳住、出了问题能回滚、半年内不会成为债」——而不是「架构图上看起来最漂亮」的那一个。四、重新定义后端工程师的价值