大厂面试官爆料:面了5个人,4个说用AI写代码,但一问就卡住了

职场上最容易拉开差距的，不是用不用AI，而是你把AI当成了什么。

现在打开任何一份后端简历，技能栏里几乎都躺着同一行字：熟练使用AI工具提效。

写的人多了，这行字就跟当年的"精通Office"差不多，谁都有，谁也不当真。

最近看到一个面试官发的帖子，挺有意思。

他说自己帮团队面后端，连着面了5个候选人，简历上都写了熟练使用AI工具。

他随口一问：你平时用AI写代码，一般怎么给它下指令？举个例子？

4个人答得差不多：就把需求直接贴进去，让它生成，不对再改。

他接着问：生成完，你怎么判断这段代码能不能用？踩过什么坑没有？

问到这，基本就都卡住了。

有一个甚至说"它写得挺好的，基本不用改"。面试官追问最近一次改它代码是什么情况，对方想了半天，回了句"好像没有"。

也有答得实在的。一个候选人说自己主要拿AI写单元测试和正则表达式，复杂业务逻辑不敢交给它，怕有隐藏bug。他还掏出手机，给面试官看了自己收藏的prompt模板，分场景整理的那种。

表面看，面试官问的是"会不会用AI"，实际上问的是：你有没有对代码负责的能力。

"直接贴进去，生成，不对再改"，这个流程里最薄弱的一环不是AI的水平，是"不对再改"这四个字。

什么叫不对？边界条件对不对？异常分支处理了没？并发场景想过没有？

答不上来，那这段代码就不是他写的，他只是替AI按了个回车。

站在团队的角度，这个问题问得很值。

招一个后端，不是招会按回车的人，是招AI写完代码之后能兜底的人。

线上半夜出bug，AI不会爬起来修，人要。

所以"你怎么判断代码能不能用"，比"你会不会用AI"重要得多。

真正把人拉开差距的，不是AI本身，是有人把它当杠杆，有人把它当拐杖。

回头再看那位用AI写单测和正则的候选人。

他聪明的地方不在于用了AI，在于他清楚AI的边界在哪：机械的、模式固定的、容易验证的活交出去；复杂的、和业务绑死的、错了要出事的活自己写。

会提效的人很多，知道边界的人很少。团队想要的，是后者。

如果你平时也用AI写代码，不妨拿三个问题问问自己。

第一，你能不能说清楚，自己是怎么把一个需求拆解给AI的？

第二，生成完之后，你拿什么验证？单测、review、边界case，总得有一样。

第三，你最近一次改AI写的代码，改的是什么，为什么改？

答得出这三个问题，AI是你的杠杆；答不出，你就是AI的传声筒。

当然，一个面试官的帖子，样本只有5个人，说明不了整个行业。

每个人用AI的习惯不同，每个团队的判断标准也不同，一张截图给不了谁下结论。

AI可以帮你写代码，但替不了你对代码负责。

工具能放大一个人，也能暴露一个人，区别只在你把它放在什么位置。