新手的PR徹底讓全網(wǎng)開發(fā)者抓狂！資深工程師警告：新人用AI更容易翻車!反而是老手越來越強(qiáng)，弱者越弱

51CTO技術(shù)棧

發(fā)布于 2025-9-22 19:37

瀏覽

0收藏

作者 | Can Elma

編輯 | 云昭

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

“AI 會(huì)不會(huì)完全接管編程？”這個(gè)問題已經(jīng)被問爛了，人們還在不斷嘗試回答。我不覺得還有什么特別新鮮的說法。但今天，我想分享一些自己的觀察。

這里只是想說一件事：之前市場所鼓吹的“新人+AI”打造高質(zhì)量代碼的敘事模式，基本告吹了。恰恰相反，現(xiàn)實(shí)中，公司需要的是更多的“資深+AI”。

為什么老手更能駕馭 AI？

大模型輔助編程工具的長處很明顯：

快速生成樣板代碼和腳手架
自動(dòng)化重復(fù)性工作
嘗試不同實(shí)現(xiàn)方案
借助快速迭代來迅速驗(yàn)證
只要明確目標(biāo)，就能快速上線功能

但前提是，你得知道自己要什么。資深工程師正好具備三樣關(guān)鍵能力：

清晰目標(biāo)感他們知道問題的邊界，能把需求拆解成明確的 Prompt。模糊提問，只會(huì)得到模糊答案。
經(jīng)驗(yàn)兜底AI 寫的東西再快，也免不了出 Bug。老手一眼就能看出邏輯漏洞，快速修正。新人往往還在琢磨“這代碼到底對不對”。
架構(gòu)思維AI 不會(huì)真正設(shè)計(jì)架構(gòu)，它只是拼裝。老手能用經(jīng)驗(yàn)控制復(fù)雜度，讓 AI 產(chǎn)出的東西在正確的軌道上運(yùn)行。

在老手手里，AI 就像一臺(tái)加速器：寫代碼更快，驗(yàn)證更快，上線更快。而且最重要的是——可控。

而對于新人來說，想要將這些優(yōu)勢真正轉(zhuǎn)化為價(jià)值，并不是不可能，只是難度大得多。

為什么新人更容易翻車？

在更多新人手里，AI 往往變成了“坑爹導(dǎo)師”。

不會(huì)提問新人最常見的 prompt 是：“幫我寫個(gè) XX。”問題是，不說清楚業(yè)務(wù)邏輯和邊界條件，AI 只能給出“看似合理”的代碼，結(jié)果漏洞一堆。
不會(huì)判斷AI 輸出的內(nèi)容，不管對錯(cuò)都照單全收。遇到 bug，不知道是 AI 搞錯(cuò)了，還是自己用法不對。于是越改越亂，掉進(jìn)“幻覺迷宮”。
不會(huì)自查很多新人直接把 AI 寫的代碼提交，連最基本的 review 都沒過。資深一看，全是坑：命名混亂、邏輯重復(fù)、安全漏洞。最后返工比從頭寫還累。

一位網(wǎng)友這么形容：新人把 AI 當(dāng)“萬能外掛”，結(jié)果卻是“放大短板的顯微鏡”。

畢竟，今天的AI還需要保姆級照料

歸根結(jié)底，編程是一件系統(tǒng)工程。而 AI 目前也只是從海量公開的代碼中學(xué)習(xí)到了部分概率分布而已。如果想要真正支棱起來，下面這幾項(xiàng)都是需要開發(fā)者所注意的。

代碼審查：AI 不能真正推理。它的審查有點(diǎn)幫助，但一旦出現(xiàn)邊界情況（而 AI 生成的代碼里常常會(huì)出現(xiàn)），你還是得依賴資深開發(fā)者。
糟糕的 Prompt：誰能寫好 Prompt？只有真正理解自己在構(gòu)建什么的人。如果缺乏知識，最多能得到“還行”的結(jié)果，但沒有合適的驗(yàn)證手段，只會(huì)帶來 bug 和麻煩。
架構(gòu)設(shè)計(jì)：沒有扎實(shí)的架構(gòu)，軟件價(jià)值會(huì)快速縮水。今天的 AI 還做不到真正設(shè)計(jì)好架構(gòu)。它看起來好像能，但這種推理還是需要人。弱架構(gòu)起步的項(xiàng)目，最終都會(huì)淹沒在技術(shù)債務(wù)里。
代碼質(zhì)量：如何選擇正確的抽象、正確運(yùn)用設(shè)計(jì)模式、保持整潔和上下文匹配，這些 AI 依舊很難。
安全性：就像一棟沒有門，或者門鎖壞掉的房子。新人 + AI 組合下，安全漏洞出現(xiàn)得更頻繁。當(dāng)然，安全問題到處都有，但資深至少有一定的意識和謹(jǐn)慎。
錯(cuò)誤的學(xué)習(xí)：如果一個(gè)人沒能力評估代碼，他可能根本意識不到 AI 產(chǎn)出的代碼哪里有問題。在公司里，這可能意味著帶來損害而不是價(jià)值。

還有更多例子，但核心結(jié)論是：AI 目前對資深開發(fā)者還不是威脅，反而可能增強(qiáng)了他們的優(yōu)勢。這不是在批評新人，而是不要讓他們在不切實(shí)際的期待下陷入高風(fēng)險(xiǎn)場景。

目前看，AI 應(yīng)該被用在的地方

那么，既然大模型還不能做到接管編程工作，它真正的用武之地應(yīng)該在哪里呢？

快速原型：非常適合快速嘗試一個(gè)想法。
加速日常工作：最重要的用途。把那些你熟悉且經(jīng)常重復(fù)的事情自動(dòng)化。
跨學(xué)科工作：填補(bǔ)知識空白，推薦有用的方法或庫，幫助在多領(lǐng)域交叉時(shí)建立聯(lián)系。
功能測試：簡單、重復(fù)、低風(fēng)險(xiǎn)且容易核查的代碼。

在我看來，目前的狀況就是這樣：我們?nèi)匀槐仨氶喿x AI 寫下的每一行代碼。它還遠(yuǎn)不完美，沒有意識，推理只是模仿，結(jié)果不可預(yù)測，所以我們還得依賴測試這種確定性的東西。但問題是，你真的會(huì)放心讓 AI 寫測試，然后用來驗(yàn)證它自己寫的代碼嗎？

我想起自己發(fā)過的一條推文：有人寫了一個(gè) Prompt，讓 AI 在不知道時(shí)回答“I don’t know”。我的看法是：“如果這樣的 AI 說‘I don’t know’，你也不能確定它是真的知道自己不知道。”

AI還沒有真正普惠編程

“新人 + AI”的組合曾經(jīng)很誘人，看起來更便宜，還能加深“AI 會(huì)搶我們工作”的恐懼。但當(dāng)你把軟件行業(yè)和其他行業(yè)對比，就會(huì)發(fā)現(xiàn)它依然顯得很不成熟。

建筑行業(yè)有建筑師設(shè)計(jì)，軟件里甚至“架構(gòu)師”還在親自寫磚頭一樣的代碼。我們的分工還不夠?qū)I(yè)化，價(jià)值驅(qū)動(dòng)不夠明確，成本控制卻占據(jù)主導(dǎo)。這讓工作被貶值，也讓人精疲力竭。

所以，現(xiàn)在的情況是：AI 并沒有真正普惠編程，反而更多地把力量集中到專家手里。期待和現(xiàn)實(shí)出現(xiàn)了偏差。未來會(huì)怎樣還不好說，我對 AI 長遠(yuǎn)發(fā)展保持樂觀，但短期內(nèi)我們可能需要重置一下期待，不要讓它繼續(xù)被扭曲。

網(wǎng)友炸鍋：我不知道，Claude寫的？一聽就抓狂

實(shí)際體感上，很多網(wǎng)友也是遇到了這樣的問題。

一位昵稱“kaydub”的網(wǎng)友，對于“AI+新人”模式作出如此的評論：

因?yàn)樾氯瞬恢朗裁磿r(shí)候自己已經(jīng)被帶進(jìn)了“兔子洞”。所以他們會(huì)讓大模型在幻覺里越陷越深。

我有個(gè)新人，本來只是要部署我寫好的一個(gè) Terraform 模塊。這個(gè)任務(wù)拖了很久，我去問問進(jìn)展。他跟我說遇到問題，請我?guī)兔匆幌隆?/p>
結(jié)果我一看他的倉庫，簡直一團(tuán)糟，一眼就能看出是 Claude 把他帶偏了。我問：“這里為什么會(huì)有一堆 Python？模塊本身是獨(dú)立的啊。”
他回答：“我不知道，Claude 寫的。” 這完全印證了我的猜測。他們?nèi)狈?jīng)驗(yàn)，對大模型工具過度依賴。不僅在設(shè)計(jì)和實(shí)現(xiàn)階段如此，連排查問題也一樣。
如果你用一個(gè)會(huì)“幻覺”的工具來調(diào) Bug，而你自己又沒能力判斷它是不是在幻覺，那你這趟旅程會(huì)很漫長。

對比之下，自己對于AI工具的把握還是要好很多。