一、开头：Review 现场
代码能跑、测试全绿、注释齐全------这还不够。
前两天我 Review 了一个新人的 MR。代码写得规整，测试覆盖率 100%，看着很漂亮。我扫了三行就皱眉头------不是挑刺，是闻到了线上事故的味道。
事务边界不对。 在数据库事务里同步调用支付和库存接口，任意一个超时，都会让事务长时间占着连接和行锁。
缓存 Key 设计有坑。 把整个活动首页塞进一个固定 Key，既是大 Key，又会被所有请求集中访问；大促流量一上来，很容易压垮单个 Redis 节点。
异常处理吞掉了关键信息。 catch 里只写了 log.error("处理失败")，却没把异常对象传进去；真出问题，连堆栈都查不到。
我把小伙子叫过来：「这代码 AI 帮你写的吧？」
「嗯...目前有什么问题吗？」空气中弥漫着尴尬的沉默。
「AI 通常不会犯低级语法错误，但上下文给不全，它很容易埋下工程问题。这几类坑我在线上都踩过。」于是我把上述三个问题和他同步了一下。
这事儿让我想了很久。不是想「AI 多危险」，而是想------如果 AI 能写 80% 的代码了，那我这个干了十多年的后端，剩下的价值到底是什么？
二、AI 能搞定的 80%
我先承认，AI 在我日常工作中确实帮了大忙。它最擅长的，是把「已经定义清楚的问题」快速变成「能跑的实现」。
- CRUD 接口：从 Entity 到 Mapper 到 Service 到 Controller，一把梭，我只需要加个权限注解
- SQL 优化：把慢查询丢给它，能分析出索引缺失、回表次数、Using filesort
- 单元测试：快速补齐常规分支和 Mock，省掉大量重复工作
- 接口文档：Swagger 注解、Javadoc 自动补全，有时比手写的还详细
- Bug 定位：NullPointer 这类常见异常，把堆栈丢进去，很快就能缩小排查范围
这些活，已经没必要全靠人手工完成了。对于边界明确、模式固定的任务，AI 往往更快，也更少犯低级错误。
但这也容易带来一种错觉：产出变高了，却更容易忽略一个问题------写出来的代码，到底是在解决正确的问题，还是在把错误的问题写得更漂亮？
三、剩下那 20%：AI 写不出来，因为答案不在代码里
但有些东西，单靠 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 GC，CPU 被打满；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），模块边界写清楚，但部署只有一个 jar
- MySQL 一主一从，从库先用于故障切换和只读校验，备份单独做；不急着把读写分离引进业务代码------压测显示订单写入峰值单主库能扛住
- 托管版 Redis 主从 2G，缓存 + 分布式锁；先不自建 Cluster
- 本地消息表 代替 Kafka------订单创建后写一条
outbox记录，定时任务扫表发通知，最终一致性够用 - 不做 Seata------扣库存和创建订单在同一数据库事务里完成，跨库场景一律设计成可补偿
会上有同事质疑：「这方案能撑到 100 万 DAU 吗？」
我的回答是：眼下的问题不是 100 万，是 8 周后能不能上线、上线后 2 个人能不能睡整觉。 架构不是选「理论上最优」，是选「当前约束下最不容易死、出了问题 10 分钟能回滚」的方案。
后来项目没砍，日活慢慢涨到了 35 万。大促高峰时，Redis 延迟开始抬头，部分缓存请求超时后降级查询数据库。但这时候团队已经扩到 5 人，缓存 Key 规范和序列化协议也早已统一，迁移到 Cluster 的改造范围比较可控；订单模块随后也从单体里独立出来，早期划清的代码边界，让这次拆分少走了很多弯路。
反过来看，隔壁组当时走了 AI 同款方案：3 个微服务 + Kafka，3 个人维护。上线没多久，Kafka 就积压了 40 万条消息没人发现------不是没人写消费逻辑，是没人 7×24 会看 Kafka 的 lag 面板。等用户投诉「下了单没短信」，排查才发现消费者早就被一次错误发布搞挂了，只是没人盯着。
AI 给的是标准答案，但工程决策从来不是标准题。 真正要回答的往往是：
- 这个方案，今晚出了问题，谁能在 30 分钟内 rollback？
- 这个中间件，团队里有没有第二个人会修？
- 这个拆分，是为了解决眼前的瓶颈，还是为了简历好看？
更现实的选择，往往是「团队现在能稳住、出了问题能回滚、半年内不会成为债」------而不是「架构图上看起来最漂亮」的那一个。
四、重新定义后端工程师的价值
所以我后来想通了。后端工程师真正的核心能力，不是「写出能跑的代码」，而是四样东西：
- 业务毒感：PM 说要做个导出功能，第一反应往往不是「好我加个接口」，而是「这个查询条件加上去会扫全表」「运营一天会用几次？要不要走异步？」
- 系统嗅觉：代码看起来没问题，但扫一眼就能嗅到「这个索引在生产环境的数据量下会失效」「这个 Key 在双十一会被打穿」
- 故障直觉：报警响了，往往不是先翻代码，而是先看「哪个改动最近上线的」「哪个第三方服务刚从 HTTP 换了 HTTPS」
- 权衡能力：没有最优方案，只有最合适的方案。技术选型拼的不是谁懂得多，是谁更清楚「我们团队兜得住什么技术栈」
这四样东西，AI 可以辅助，却很难替你承担。
不是因为 AI 不够聪明，而是因为它们不只在代码里。它们还在：
- 凌晨 3 点的告警铃声里
- 被 PM 改了 4 版需求之后的那句「这逻辑改过好几次了，得把老逻辑也兼容上」
- 上线前最后的 Code Review 里那句「等会儿，这里再加个幂等校验」
五、更值得投入的三件事
如果 AI 已经能写 80%，或许该把更多力气从「写」挪到「定、审、兜」：
- 接到需求先写清边界：输入输出、异常路径、幂等规则、数据量级------再交给 AI 写实现，而不是把原始 PRD 整段丢进去。
- Review 时盯四类雷区：事务边界、缓存 Key、重试与超时、日志是否可追踪------这些是 AI 高频埋雷的地方。
- 主动接「要对结果负责」的活：上线评审、事故复盘、容量评估------这些才是人与 AI 之间更深的护城河。
六、结尾
AI 确实能写 80% 的代码了。剩下那 20%，不在语法里，不在框架里，而在赔过一次钱、熬过一次夜、改过一次线上事故之后，慢慢长出来的直觉里。
值钱的地方，从「写得出」挪到了「兜得住」。
更容易被 AI 替代的，不是「后端工程师」这个职业，而是其中那些只把需求翻译成 CRUD、却不对线上结果负责的工作。
把 AI 当成那根「魔法棒」之后，我越来越深的体会是：工程师的价值，从来不在写了多少行代码，而在敢不敢为那几行代码签字。
创作不易，求个点赞关注在看三连～
我是老猫，我们下期见！🐱