现在的开发者面试如果还盯着 LeetCode 看，可能根本测不出一个人在 AI 时代到底能不能干活

现在面试开发者有个很诡异的现象，差不多 80% 的候选人都会坦白说自己现在基本不怎么亲手写代码了，大部分时间在给 AI Agent 下指令。这种「指令驱动」的开发模式让很多习惯传统编码的人感到不安，因为很难判断对方在脱离 AI 之后，是否还具备基础的编码能力和系统设计思维。

传统的 LeetCode 刷题面试在 AI 时代还管用吗

很多面试官在纠结是否该坚持传统的算法题和系统设计面试。其实在这种环境下，如果候选人完全依赖 Agent，他们可能会在面对白板编程或禁止使用 AI 的环境时彻底哑火。但问题在于，如果一个开发者能高效地指挥 Claude Code 产出高质量、无 Bug 的代码，他是否还需要在面试中证明自己能徒手写出快排？

我认为不能完全放弃传统面试，但得改变考察重心。如果一个候选人说自己是「Agent-pilled」（完全依赖 AI 代理），那么面试官应该重点考察他对 AI 生成结果的审查能力。你可以给一段由 AI 生成但带有隐蔽逻辑漏洞的代码，看他能否在不使用 AI 的情况下通过 Code Review 找出来。如果他连 AI 写的 Bug 都看不出来，那这种「高效」其实是巨大的技术债。

面对全靠 AI 编程的候选人该怎么考

当候选人明确表示自己不再手动写代码时，考察维度应该从「实现能力」转向「评审与架构能力」。

一、 验证代码审查能力
不要让他们从零写代码，而是给他们一个复杂的 PR（Pull Request），里面包含 AI 常犯的错误（比如边界条件处理不当、异步竞态问题或内存泄漏），要求他们在 15 分钟内指出所有潜在问题并给出修改方案。

二、 深度挖掘系统设计
AI 可以快速生成简单的架构图，但很难处理复杂的权衡（Trade-off）。面试时应增加具体场景的压力测试问题，例如：

• 当 QPS 达到 10k 时，这个 AI 建议的缓存方案会怎么崩？
• 数据库索引在这种情况下的执行计划会如何变化？
• 如果去掉这个第三方库，用原声实现会有什么性能损耗？

三、 实操 Agent 指令能力
既然他们主打 Agent 驱动，那就让他们现场演示如何通过 Prompt 让 AI 完成一个具体功能。观察重点不在于结果，而在于：

• 他如何定义上下文（Context）。
• 当 AI 出现幻觉或陷入死循环时，他如何通过修正指令引导 AI 回到正确路径。
• 他是否能快速判断 AI 给出的是「能跑的垃圾代码」还是「生产环境可用代码」。

这种趋势带来的潜在风险

完全依赖 Agent 的开发模式虽然提升了速度，但潜伏着一个巨大的风险：开发者的「感知力」在退化。一个不写代码的开发者，在面对极其复杂的底层 Bug 或需要深度性能调优的场景时，往往缺乏直觉。

如果一个团队里全是这种「指令工程师」，一旦遇到 AI 无法解决的冷门领域问题，或者需要对编译器、内核进行微调时，团队可能会陷入集体瘫痪。因此，在面试时，无论对方怎么吹 Agent 的效率，依然要通过具体的工程细节（比如具体的版本特性、内存模型、网络协议细节）来确认他是否还拥有底层的技术掌控力。