AI 时代工程师招聘面试，到底该考什么？ AI 能写代码之后，软件工程面试正在经历一场真正的身份危机。面试官现在最头疼的问题不是候选人水平不够，而是根本不知道该考什么——因为评判标准本身就变了。

这几条标准正在慢慢成为大家的共识：
1. 能不能判断 AI 输出的质量
不是会不会用工具，而是能不能识别 AI 生成的代码里哪里是对的、哪里是危险的。
实际面试场景：给候选人一段 AI 生成的代码，让他 review。能找出隐藏 bug、性能陷阱、安全漏洞的，才算真懂。

2. 能不能在 AI 失控时接管
Vibe Coder常出现的能力问题：面试官给候选人看一段代码，要求做小改动，结果Vibe coder"一脸茫然——因为他的工作方式是 prompt 进去等输出，从没真正读过代码。

测试方法：给一段中等复杂度的 AI 生成代码，要求候选人口头解释它的逻辑，然后手动加一个功能。能做到的，说明理解是真实的；做不到的，说明只是个 AI 的传话筒。

3. 能不能设计好 agent 的边界和失败模式
2026 年的工程师越来越多在做 agent 系统，而不是写单个函数。这类工作最容易出问题的地方不是代码对不对，而是 agent 在边界情况下会不会失控。

考察点：让候选人设计一个 agent workflow，然后问"它在什么情况下会失败？怎么检测？怎么恢复？"。这类问题没有标准答案，但能区分真正有经验的人。

4. 能不能控制推理成本
AI 调用不是免费的。生产环境里用一个 Opus 做本来 Haiku 就能搞定的事，成本直接爆炸。
实际考察：给候选人一个 agent 系统的需求，问他如何选模型、怎么分层调用、哪些步骤可以缓存结果。这类问题能直接暴露"只在玩具项目里用过 AI"的候选人。

5. 系统设计能力有没有随 AI 一起升级
旧的系统设计面试考"设计一个 微博"。现在更有价值的问题是：设计一个有 AI 组件的系统，它的一致性、可观测性、容错性应该怎么做？
这是因为 AI 组件引入了一类全新的不确定性——同样的 prompt 不一定给出同样的输出。传统系统设计里的"幂等性"假设在 AI 系统里开始动摇。

现在衡量工程师的标准已经从"会不会写代码"变成了"会不会管理 AI 写出来的代码"。这两件事表面上很像，但需要的能力完全不同。前者需要记忆和执行，后者需要判断和系统思维。

#HOW I AI# #程序员#