谷歌工程师被AI困住72小时：一个字母大小写引发的魔幻现实

20%到30%的效率提升数字正在硅谷流传。一些公司开始裁员，产品经理拿着AI工具直接生成代码，工程师从创造者变成了审核员。

这场景让我想起《堂吉诃德》里的一个偏方：菲耶拉布拉斯香膏。传说它能治愈任何伤口。堂吉诃德深信不疑，调配喝下后却剧烈呕吐，差点丧命。但他坚持认为这药有效——信念的力量压倒了证据本身。

AI现在正被当成那瓶香膏。不是作为工具，而是作为解药：更快、更便宜、零代价。

01 一个大小写字母，困住AI 72小时

最近有个案例让我印象深刻。一位工程师的AI陷入了死循环——同一个问题，不同变体，反复尝试修复。代码改了一版又一版，token烧了一堆又一堆。

问题根本不在代码。

开发环境用的是不区分大小写的文件系统，部署环境区分大小写。一个字母的大小写差异，让AI在错误的方向上狂奔了三天。

这不是技术故障。这是判断力的缺席。AI无法识别"这不是代码问题"，因为它被训练成输出代码。而工程师如果也被训练成只审核输出，谁来问"问题出在哪一层"？

我见过太多类似的场景：团队用AI重构系统，三个月后债务爆炸；生成式工具快速搭建原型，生产环境却漏洞百出。速度是快了，但快不等于对。

02 工程正在被重新定义

真正让我担心的不是工程师失业。是工程本身正在缩小。

软件开发的本质是判断：这个功能该不该做？这个 trade-off 值不值？为什么存在比怎么做更重要。当工程被简化为"输出代码"，加速输出的工具自然看起来像完整方案。

一位从业十五年的技术负责人告诉我：「现在面试新人，能写代码的不少，能讲清楚'为什么这样设计'的越来越少。」

AI擅长的是"怎么做"。它不会问你：用户真的需要这个吗？这个架构三年后会不会成为枷锁？当团队里只剩审核员，谁来提出这些问题？

更隐蔽的风险是能力断层。初级工程师通过修复bug、踩坑、被代码虐，才能建立系统直觉。如果这层磨砺被AI跳过，五年后我们从哪找架构师？

03 效率数字背后的幻觉

那些20%、30%的效率提升，统计的是代码产出速度，还是问题解决速度？是原型搭建，还是系统交付？

我见过一份内部报告：某团队AI辅助后，功能上线时间缩短40%，但生产事故增长170%。净效率是正是负，取决于你把时间框定在哪一段。

堂吉诃德的香膏也有"效果"——他确实感觉好多了，在呕吐之后。

企业财报喜欢展示"用更少人做更多事"，但很少追踪三年后技术债务的利息、系统迭代的摩擦成本、以及核心工程师流失后的知识断层。

一位CTO私下承认：「我们现在像用信用卡买效率，账单还没来。」

04 工具与解药的区别

我日常用AI。它帮我写正则表达式，生成测试数据，快速理解陌生代码库。在这些场景里，它是杠杆——放大已有判断力，而非替代。

危险的是把它当成替身。让产品经理直接生成代码，就像让会用CAD的人设计建筑结构。工具能执行，但无法承担。

工程团队正在分化：一派把AI当副驾驶，决策权在人；另一派把AI当自动驾驶，人只负责踩刹车。后者的刹车频率，正在指数级上升。

那位困住AI 72小时的工程师最后怎么解决的？他关掉工具，花了十分钟检查环境配置。

十分钟。三天。这个比例会不会成为某种隐喻？

当行业热议"AI替代工程师"时，真正该问的是：我们想要的工程，是输出代码的流水线，还是解决问题的判断力？如果选后者，现在的"效率革命"是在加速，还是在透支？