【30秒生成的微服务，为什么扛不住10分钟的宕机？】一位初级开发者用ChatGPT在30秒内创建了一个微服务。我只问了一个问题：如果下游服务宕机10分钟，数据会怎样？他愣住了。AI没有告诉他什么是背压机制，没有解释幂等性设计，也没有提到死信队列。代码是生成了，但系统韧性呢？完全空白。这让我想起最近一场面试。候选人面对的场景是：一个每秒处理3000个请求的系统，每条请求都要持久化用于分析，保留期一年。简单算一下，每天就是两亿多条记录。我问他怎么处理数据清理。答案是：加个时间戳索引，跑个定时任务删旧数据。这是代码思维，不是工程思维。批量删除的策略呢？表分区的考量呢？锁竞争和复制延迟的影响呢？删除是否真的是最优解，还是应该考虑TTL或归档？这些问题，他一个都没想过。AI擅长的是"快乐路径"。它写的代码假设网络永远不会断，数据库永远秒级响应。但真实世界90%的工程量都在处理"悲伤路径"：超时、部分失败、竞态条件。"能跑起来"和"能稳定运行"之间，隔着一整个工程学科。有人说，初级开发者可以继续追问AI这些问题啊。问题是，你得先知道要问什么。真正的学习来自理解系统，而不是使用工具。ChatGPT是那些已经知道该问什么问题的人的杠杆。知识会复利增长，捷径的复利方式则完全不同。AI在有经验的工程师手里是力量倍增器。但如果缺乏工程基础，它只会加速你的盲区扩张。代码生成的成本趋近于零，但系统韧性的成本从未降低。凌晨三点，生产环境着火的时候，没有人关心你的微服务是30秒还是30分钟写出来的。他们只关心一件事：你能不能解释清楚系统为什么会这样失败，以及怎么让它不再失败。这才是工程师真正被需要的地方。x.com/SumitM_X/status/2014378635336229001
