過去18個月，北美技術(shù)招聘圈流傳一個詭異現(xiàn)象：簡歷上的項目越來越漂亮，面試現(xiàn)場的表現(xiàn)卻越來越抽象。

不是那種緊張導(dǎo)致的結(jié)巴，而是根本性的認知斷層——候選人能寫出跑通的代碼，被追問"這段為什么這樣寫"時，卻像突然被拔掉了電源。

機制一：代碼能跑，但人不會了

AI編程工具的普及，把"寫出功能"的門檻砍到了腳踝。GitHub Copilot、Cursor這類工具讓新手幾小時內(nèi)就能攢出一個像模像樣的項目，放到簡歷上足夠唬人。

問題在于，這個生產(chǎn)過程里，人扮演的角色越來越像策展人而非創(chuàng)作者。選哪個方案、調(diào)哪行參數(shù)，決策權(quán)交給了算法。候選人提交的作品集確實"functional"，但技術(shù)面試要的不是這個——它要的是你面對白板時，能從第一性原理推導(dǎo)出解法。

一位Google招聘委員會成員描述這種落差：「他們帶來的項目看著很完整，但問'如果輸入是空數(shù)組會怎樣'，眼神就空了?！?/p>

機制二：功能導(dǎo)向正在制造"紙面工程師"

教育體系對AI工具的擁抱，無意中強化了一種危險的學(xué)習路徑：以輸出為唯一目標，跳過中間的掙扎與試錯。

傳統(tǒng)編程學(xué)習的價值，很大程度上來自那些卡住的夜晚——調(diào)試時被迫逐行追蹤變量，重構(gòu)時親手把面條代碼拆成模塊，這些痛苦才是理解的錨點。AI工具把痛苦外包了，理解也就成了無根之木。

招聘現(xiàn)場的反饋很殘酷：候選人能解釋"這段代碼做什么"，但解釋不了"為什么選這個數(shù)據(jù)結(jié)構(gòu)"或"時間復(fù)雜度怎么來的"。這種"表面熟練"在高壓面試中迅速崩盤，因為追問一旦超出工具生成的代碼邊界，知識體系就出現(xiàn)斷層。

機制三：技術(shù)面試成了壓力測試的照妖鏡

面試設(shè)計的初衷，本就是模擬真實開發(fā)中無法Google、無法求助AI的場景。它刻意制造認知負荷，逼候選人展示無法被工具替代的思維能力。

但AI教育培養(yǎng)出的開發(fā)者，在這種環(huán)境下暴露出一個結(jié)構(gòu)性缺陷：他們的知識是"調(diào)用型"而非"生成型"。能識別好代碼，但寫不出；能跑通測試用例，但造不出測試用例。面試中的白板環(huán)節(jié)、邊界條件追問、復(fù)雜度分析，恰好戳中這些軟肋。

更麻煩的是系統(tǒng)性風險。如果招聘標準被迫下調(diào)以填補headcount，企業(yè)最終雇用的是一群"代碼搬運工"——日常開發(fā)或許能應(yīng)付，但生產(chǎn)環(huán)境出故障時，缺乏從根因定位到修復(fù)的完整能力鏈條。

一位Meta工程總監(jiān)的觀察很直白：「我們不是在招會按Tab鍵的人，是在招系統(tǒng)出問題時能扛住的人?！?/p>

裂縫正在擴大

這個趨勢沒有自限機制。AI工具在進化，教育體系的調(diào)整卻滯后得多。當新一代開發(fā)者批量進入市場，招聘方被迫在"能干活"和"真懂行"之間做越來越艱難的權(quán)衡。

已有公司在調(diào)整策略：延長試用期、增加系統(tǒng)設(shè)計輪次、把"解釋你三個月前寫的代碼"變成固定環(huán)節(jié)。但這些是補丁，不是解法。

根本矛盾在于，AI輔助編程和基礎(chǔ)能力培養(yǎng)之間，還沒有找到穩(wěn)定的共生模式。工具越強大，新手越難抵抗"先跑起來再說"的誘惑——而那個"再說"，往往永遠不會來。

教育者和行業(yè)領(lǐng)袖現(xiàn)在面臨一個選擇：是讓AI成為腳手架，還是讓它變成拐杖？這個選擇的結(jié)果，將決定未來幾年軟件行業(yè)的平均故障率和凌晨三點的on-call頻率。

一位參與多輪校招的Netflix工程師留下一個未解的問題：「如果五年后，AI能生成并維護90%的代碼，我們面試時到底該考什么？」