过去18个月，北美技术招聘圈流传一个诡异现象：简历上的项目越来越漂亮，面试现场的表现却越来越抽象。
不是那种紧张导致的结巴，而是根本性的认知断层——候选人能写出跑通的代码，被追问"这段为什么这样写"时，却像突然被拔掉了电源。
机制一：代码能跑，但人不会了
AI编程工具的普及，把"写出功能"的门槛砍到了脚踝。GitHub Copilot、Cursor这类工具让新手几小时内就能攒出一个像模像样的项目，放到简历上足够唬人。
问题在于，这个生产过程里，人扮演的角色越来越像策展人而非创作者。选哪个方案、调哪行参数，决策权交给了算法。候选人提交的作品集确实"functional"，但技术面试要的不是这个——它要的是你面对白板时，能从第一性原理推导出解法。
一位Google招聘委员会成员描述这种落差：「他们带来的项目看着很完整，但问'如果输入是空数组会怎样'，眼神就空了。」
机制二：功能导向正在制造"纸面工程师"
教育体系对AI工具的拥抱，无意中强化了一种危险的学习路径：以输出为唯一目标，跳过中间的挣扎与试错。
传统编程学习的价值，很大程度上来自那些卡住的夜晚——调试时被迫逐行追踪变量，重构时亲手把面条代码拆成模块，这些痛苦才是理解的锚点。AI工具把痛苦外包了，理解也就成了无根之木。
招聘现场的反馈很残酷：候选人能解释"这段代码做什么"，但解释不了"为什么选这个数据结构"或"时间复杂度怎么来的"。这种"表面熟练"在高压面试中迅速崩盘，因为追问一旦超出工具生成的代码边界，知识体系就出现断层。
机制三：技术面试成了压力测试的照妖镜
面试设计的初衷，本就是模拟真实开发中无法Google、无法求助AI的场景。它刻意制造认知负荷，逼候选人展示无法被工具替代的思维能力。
但AI教育培养出的开发者，在这种环境下暴露出一个结构性缺陷：他们的知识是"调用型"而非"生成型"。能识别好代码，但写不出；能跑通测试用例，但造不出测试用例。面试中的白板环节、边界条件追问、复杂度分析，恰好戳中这些软肋。
更麻烦的是系统性风险。如果招聘标准被迫下调以填补headcount，企业最终雇用的是一群"代码搬运工"——日常开发或许能应付，但生产环境出故障时，缺乏从根因定位到修复的完整能力链条。
一位Meta工程总监的观察很直白：「我们不是在招会按Tab键的人，是在招系统出问题时能扛住的人。」
裂缝正在扩大
这个趋势没有自限机制。AI工具在进化，教育体系的调整却滞后得多。当新一代开发者批量进入市场，招聘方被迫在"能干活"和"真懂行"之间做越来越艰难的权衡。
已有公司在调整策略：延长试用期、增加系统设计轮次、把"解释你三个月前写的代码"变成固定环节。但这些是补丁，不是解法。
根本矛盾在于，AI辅助编程和基础能力培养之间，还没有找到稳定的共生模式。工具越强大，新手越难抵抗"先跑起来再说"的诱惑——而那个"再说"，往往永远不会来。
教育者和行业领袖现在面临一个选择：是让AI成为脚手架，还是让它变成拐杖？这个选择的结果，将决定未来几年软件行业的平均故障率和凌晨三点的on-call频率。
一位参与多轮校招的Netflix工程师留下一个未解的问题：「如果五年后，AI能生成并维护90%的代码，我们面试时到底该考什么？」
热门跟贴