这两年，很多团队都在问同一个问题：AI 越来越会写代码了，我们到底还该招什么样的工程师？

如果招聘流程还停留在“背 API、记框架、拼手速”那一套，很可能已经有点偏了。AI 正在吃掉越来越多机械性的实现工作，但这并不意味着工程师不重要。恰恰相反，工程师真正值钱的地方反而更清楚了：他能不能先把问题看明白，能不能拆开复杂系统，能不能在方案之间做判断，出了结果之后又能不能认真验证，而不是把第一版答案直接当结论。

软件工程一直在变，变化的从来不只是工具

把时间线拉长一点看，软件工程这份工作本来就在不断“上移”。

• 主机时代，工程师离硬件很近，内存、指令和机器限制决定了一切
• 高级语言普及后，大家不必再和底层细节死磕，重心开始转向业务逻辑
• Web 爆发以后，网络、分布式系统、无状态架构成了新基本功
• 云平台成熟后，很多基础设施操作被进一步抽象成服务能力

今天，AI 正在继续推动这个过程。它不是第一次改变工程师工作的工具，也不会是最后一次。每往前走一步，重复性的机械劳动都会减少一点，而真正需要思考的部分会更突出一点。

所以，能长期跑赢行业变化的人，往往不是最会背上一代工具细节的人，而是能迅速适应下一层抽象的人。

为什么“会不会某个技术栈”越来越不够看

很多 JD 现在仍然喜欢写：

• 必须熟悉 React
• 必须掌握 Kubernetes
• 必须精通 Terraform
• 必须有某云平台实战经验

这些要求当然不是完全没意义，但如果把它们当成最核心的判断标准，就容易把招聘做偏。

原因很简单：具体实现层的知识贬值速度太快了。一个框架、一个生态、甚至一整套工程实践，可能几年就换一轮。你今天把面试题全压在某个技术栈上，筛选出的很可能只是“刚好熟悉当前工具”的人，而不是“未来还能持续适应变化”的人。

更耐用的能力，往往不是“会不会这个栈”，而是“能不能看懂这套系统到底怎么运转”。一个靠谱的工程师，听到方案时会下意识去想代价和风险，讨论需求时会先确认真正要解决的问题，遇到复杂系统时也会本能地留意边界条件和可能出错的地方。这样的人通常学新工具并不慢，因为他抓住的不是表层用法，而是底下那套逻辑。相反，只会熟练操作某一套固定栈的人，一旦地面一晃，往往就会明显吃力。

AI 把工程师的价值，进一步推向“问题层”

很多人谈 AI 对软件开发的影响，第一反应是“写代码更快了”。这当然没错，但更重要的变化其实不是速度，而是工程师把精力放在哪一层。

如果代码生成继续进步，未来最稀缺的可能就不是“把代码敲出来”，而是把模糊需求讲清楚、把系统结构定对、把复杂度压住、把结果验扎实。再往后走一步，甚至连“怎么和 AI 分工、怎么交叉校验”都会变成基本功。说白了，真正难的部分从来都不是键盘输入本身，而是判断。AI 只是把这个事实提前暴露出来了。

这也意味着，未来优秀工程师的核心竞争力不会是“我比别人更会写样板代码”，而是“我能把一个混乱问题整理成可以执行、可以验证、可以交付的方案”。

AI 时代，面试到底该看什么

如果还把面试重心放在具体工具上，最后往往只是在挑“眼下最容易出题”的东西，而不是“真正决定成败”的东西。

我更认同的一套招聘思路是，把重点放在候选人的思考过程上。一个人是不是先澄清问题再动手，是不是会自然想到不同方案之间的取舍，他追问的角度到底停留在表面，还是已经碰到系统真正的骨架，这些都比“请背出某个框架生命周期”更能看出他未来能走多远。尤其是在陌生问题面前，有些人会有条理地建立假设、逐步收窄范围；有些人则会立刻开始乱猜，这种差别在 AI 时代只会越来越明显。

如果想把这件事落得更实一点，面试题也可以跟着调整：

1. 少考记忆题，多考问题拆解

与其问“某个 API 怎么用”，不如给一个模糊但真实的场景，看候选人怎么拆。

比如：

• 一个服务延迟突然抖高了，你会先从哪里下手
• 一个需求听起来合理，但实现成本极高，你怎么和产品重新定义问题
• 一个系统要扩展到更高并发，你会优先检查哪些瓶颈

这类题没有标准答案，但特别容易看出一个人是不是在真正思考。

2. 追问“为什么”，而不只是“做过什么”

很多候选人都能讲项目经历，但真正有价值的是他对当时决策的理解。

可以继续往下挖：

• 为什么当时选这个方案
• 有没有想过替代路径
• 最担心的风险是什么
• 如果重来一次，哪些地方会改

讲得越具体，越能分出“只是参与过”还是“真的吃透了”。

3. 看他如何处理陌生问题

AI 时代特别重要的一点，是工程师面对未知时的反应。

因为很多实现细节都能查、都能问模型，真正拉开差距的反而是：当没有现成套路时，他会不会先建立假设、再验证、再修正，而不是停在原地等提示。

4. 允许候选人展示与 AI 协作的方式

这不是说面试里要变成“谁 Prompt 写得花”。而是要观察：他会不会把 AI 当成加速器，同时又保留基本的判断力。

好的候选人会把 AI 当成加速器，而不是判断力的替代品。他会用它起草、搜索、扩展思路，但真正关键的假设、上下文补充和结果验证，还是自己盯住。什么时候可以借力，什么时候必须停下来重查，这种分寸感很难装出来，面试里聊几轮基本就能感觉到。把 AI 当拐杖的人，和把 AI 当协作工具的人，区别其实非常明显。

5. 看候选人是不是真的想解决这类问题

还有一个很容易被忽视的点：候选人对你所在领域的兴趣。

会写代码的人不少，但愿不愿意长期啃你团队正在面对的那类问题，是另一回事。真正合适的人，通常不只是“能做”，而是“愿意持续往里钻”。这种动机会直接影响他后续的学习速度、沟通质量和责任心。

那初级工程师怎么办？

这可能是 AI 时代最难也最现实的问题。

过去，很多初级工程师就是在一些偏实现层的工作里长出来的。写样板代码、修小 Bug、搭小组件、补一些边角功能，这些任务不一定高级，但它们能帮助新人慢慢建立直觉。

现在问题来了：这些活，AI 越来越能做了。那新人怎么成长？

我不认同“既然 AI 能做，就少招初级工程师”这种思路。对行业来说，这会是个很坏的方向。但这确实意味着，团队要更有意识地调整对初级工程师的判断标准。

相比过去，初级工程师身上那些更底层的特质会更重要，比如好奇心够不够强，学东西是不是快，碰到问题时能不能先自己拆一层，面对陌生系统时会不会主动建立一个基本的结构化理解。换句话说，初级工程师要看的，和高级工程师其实是同一类能力，只是要求没那么成熟。

还有一点我很认同：AI 降低了技术学习门槛之后，候选人的背景未必需要那么单一。只要思考能力、判断力和学习意愿足够强，来自非传统计算机背景的人，也可能非常有潜力。

当然，这也给团队提了个醒：以后带新人，不能只靠“先让他干点重复活练手”了。你需要更明确地设计训练方式，让他们在使用 AI 的同时，仍然真正理解自己在构建什么系统。

真正不过时的，始终是复杂问题求解

技术会变，语言会变，框架会变，AI 也会继续吞掉更多曾经被视为“核心能力”的工作。

但有一件事一直没怎么变：能不能把复杂问题想清楚。

这个能力在主机时代有价值，在 Web 兴起时有价值，在云计算普及后有价值，到了今天同样有价值。甚至可以说，AI 越强，这种能力反而越值钱。

所以，如果今天还在招工程师，我会更愿意把招聘问题改成下面这句：

不是“你最擅长哪个框架”，而是“遇到复杂、陌生、边界模糊的问题时，你会怎么把它一步步变成可执行的解法？”

这比任何一张技术清单都更接近未来。