今年是AI Agent内卷元年。后端开发人才评估从传统的八股文变成AI工具熟练度。但就近期个人的面试PHP/GO后端开发的经历来分析发现当前的人才评估在AI冲击下较为混乱，甚至出现“AI万能论”，注重AI工具的熟练度忽视工程能力、决策能力等深层次的能力，简单粗暴地将会用AI等同于胜任工作。
我经历的技术面试大致分为4个部分，占比如下：
- 自我介绍：10%
- 系统设计题 x 1：40%
- Vibe Coding、Claude Code等工具的使用：40%
- AI Agent架构：10%
这种面试方法几乎无法评判候选人的真实水平，似乎拥有Claude就能拥有一切，所有的难题都能迎刃而解。这里我结合自己的事件驱动微服务项目和面试的过程来分析。
争议一：AI编码 vs 手动调试/手工编码
个人项目由于历史问题使用较为小众的开发框架，面临文档资料不全甚至无资料等难题，和其他主流技术组件的组合几乎没有被公开讨论，只能通过手动调试和手动编码解决，甚至修改框架源码。但面试官走极端，否认项目的技术深度认为AI完全可以胜任进而判断候选人不合适，这是非常大的错误！
我起初选择用AI完成，但AI单独编写组件导致代码复杂度上升一个数量级，所以只用在业务逻辑和其他重复性工作。
面试官是想了解怎么用AI自主解决技术难题，但这类问题AI顶多是充当辅助的角色，所以应该重点考查候选人的思维、决策和权衡能力而不是机械地考查AI工具的熟练度。
争议二：编码速度 vs 工程哲学
结合第一点提到的问题。我当时要用kafka带上key传信息，但开源插件不支持。面试官认为AI可以完成，我有试过但得到的结果是“单独编写插件”，代价过大，你需要为此建立新的代码仓库自行维护，CI/CD流水线要配置golang的私有仓库，还要编写大量测试用例来测试；手工编码仅需在插件的源码增加3行代码即可，调试简单，无需变更依赖。
从这个案例可以知道，AI能快速生成代码复刻一个组件却造成巨大的维护成本，把原本简单的事情复杂化，修改源码需要对组件有深刻的理解。
综上所述，当前后端开发人才评估出现一些偏离本质的做法，关注AI编码工具的使用忽视工程能力和技术深度。熟练使用Claude Code等编码工具能快速构建想要的产品，但这些面试官没有意识到，如果有一天，其使用的框架的源码有个未公开的Bug导致生产事故怎么办？AI能容纳整个框架代码作为上下文来排查吗？所以高估AI低估技术深度带来的风险不容小觑。
