我不知道，Claude寫的！新手的PR徹底讓全網開發者抓狂！資深工程師警告：新人用AI更容易翻車!反而是老手越來越強，弱者越弱
譯文作者 | Can Elma
編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
“AI 會不會完全接管編程？”這個問題已經被問爛了，人們還在不斷嘗試回答。我不覺得還有什么特別新鮮的說法。但今天，我想分享一些自己的觀察。
這里只是想說一件事：之前市場所鼓吹的“新人+AI”打造高質量代碼的敘事模式，基本告吹了。恰恰相反，現實中，公司需要的是更多的“資深+AI”。
為什么老手更能駕馭 AI？
大模型輔助編程工具的長處很明顯：
- 快速生成樣板代碼和腳手架
- 自動化重復性工作
- 嘗試不同實現方案
- 借助快速迭代來迅速驗證
- 只要明確目標，就能快速上線功能
但前提是，你得知道自己要什么。資深工程師正好具備三樣關鍵能力：
- 清晰目標感他們知道問題的邊界，能把需求拆解成明確的 Prompt。模糊提問，只會得到模糊答案。
- 經驗兜底AI 寫的東西再快，也免不了出 Bug。老手一眼就能看出邏輯漏洞，快速修正。新人往往還在琢磨“這代碼到底對不對”。
- 架構思維AI 不會真正設計架構，它只是拼裝。老手能用經驗控制復雜度，讓 AI 產出的東西在正確的軌道上運行。
在老手手里，AI 就像一臺加速器：寫代碼更快，驗證更快，上線更快。而且最重要的是——可控。
而對于新人來說，想要將這些優勢真正轉化為價值，并不是不可能，只是難度大得多。
為什么新人更容易翻車？
在更多新人手里，AI 往往變成了“坑爹導師”。
- 不會提問新人最常見的 prompt 是：“幫我寫個 XX?！眴栴}是，不說清楚業務邏輯和邊界條件，AI 只能給出“看似合理”的代碼，結果漏洞一堆。
- 不會判斷AI 輸出的內容，不管對錯都照單全收。遇到 bug，不知道是 AI 搞錯了，還是自己用法不對。于是越改越亂，掉進“幻覺迷宮”。
- 不會自查很多新人直接把 AI 寫的代碼提交，連最基本的 review 都沒過。資深一看，全是坑：命名混亂、邏輯重復、安全漏洞。最后返工比從頭寫還累。
一位網友這么形容：新人把 AI 當“萬能外掛”，結果卻是“放大短板的顯微鏡”。
畢竟，今天的AI還需要保姆級照料
歸根結底，編程是一件系統工程。而 AI 目前也只是從海量公開的代碼中學習到了部分概率分布而已。如果想要真正支棱起來，下面這幾項都是需要開發者所注意的。
- 代碼審查：AI 不能真正推理。它的審查有點幫助，但一旦出現邊界情況（而 AI 生成的代碼里常常會出現），你還是得依賴資深開發者。
- 糟糕的 Prompt：誰能寫好 Prompt？只有真正理解自己在構建什么的人。如果缺乏知識，最多能得到“還行”的結果，但沒有合適的驗證手段，只會帶來 bug 和麻煩。
- 架構設計：沒有扎實的架構，軟件價值會快速縮水。今天的 AI 還做不到真正設計好架構。它看起來好像能，但這種推理還是需要人。弱架構起步的項目，最終都會淹沒在技術債務里。
- 代碼質量：如何選擇正確的抽象、正確運用設計模式、保持整潔和上下文匹配，這些 AI 依舊很難。
- 安全性：就像一棟沒有門，或者門鎖壞掉的房子。新人 + AI 組合下，安全漏洞出現得更頻繁。當然，安全問題到處都有，但資深至少有一定的意識和謹慎。
- 錯誤的學習：如果一個人沒能力評估代碼，他可能根本意識不到 AI 產出的代碼哪里有問題。在公司里，這可能意味著帶來損害而不是價值。
還有更多例子，但核心結論是：AI 目前對資深開發者還不是威脅，反而可能增強了他們的優勢。這不是在批評新人，而是不要讓他們在不切實際的期待下陷入高風險場景。
目前看，AI 應該被用在的地方
那么，既然大模型還不能做到接管編程工作，它真正的用武之地應該在哪里呢？
- 快速原型：非常適合快速嘗試一個想法。
- 加速日常工作：最重要的用途。把那些你熟悉且經常重復的事情自動化。
- 跨學科工作：填補知識空白，推薦有用的方法或庫，幫助在多領域交叉時建立聯系。
- 功能測試：簡單、重復、低風險且容易核查的代碼。
在我看來，目前的狀況就是這樣：我們仍然必須閱讀 AI 寫下的每一行代碼。它還遠不完美，沒有意識，推理只是模仿，結果不可預測，所以我們還得依賴測試這種確定性的東西。但問題是，你真的會放心讓 AI 寫測試，然后用來驗證它自己寫的代碼嗎？
我想起自己發過的一條推文：有人寫了一個 Prompt，讓 AI 在不知道時回答“I don’t know”。我的看法是：“如果這樣的 AI 說‘I don’t know’，你也不能確定它是真的知道自己不知道?！?/p>
AI還沒有真正普惠編程
“新人 + AI”的組合曾經很誘人，看起來更便宜，還能加深“AI 會搶我們工作”的恐懼。但當你把軟件行業和其他行業對比，就會發現它依然顯得很不成熟。
建筑行業有建筑師設計，軟件里甚至“架構師”還在親自寫磚頭一樣的代碼。我們的分工還不夠專業化，價值驅動不夠明確，成本控制卻占據主導。這讓工作被貶值，也讓人精疲力竭。
所以，現在的情況是：AI 并沒有真正普惠編程，反而更多地把力量集中到專家手里。期待和現實出現了偏差。未來會怎樣還不好說，我對 AI 長遠發展保持樂觀，但短期內我們可能需要重置一下期待，不要讓它繼續被扭曲。
網友炸鍋：我不知道，Claude寫的？一聽就抓狂
實際體感上，很多網友也是遇到了這樣的問題。
一位昵稱“kaydub”的網友，對于“AI+新人”模式作出如此的評論：
因為新人不知道什么時候自己已經被帶進了“兔子洞”。所以他們會讓大模型在幻覺里越陷越深。
我有個新人，本來只是要部署我寫好的一個 Terraform 模塊。這個任務拖了很久，我去問問進展。他跟我說遇到問題，請我幫忙看一下。
結果我一看他的倉庫，簡直一團糟，一眼就能看出是 Claude 把他帶偏了。我問：“這里為什么會有一堆 Python？模塊本身是獨立的啊?！?nbsp;
他回答：“我不知道，Claude 寫的?！?這完全印證了我的猜測。他們缺乏經驗，對大模型工具過度依賴。不僅在設計和實現階段如此，連排查問題也一樣。
如果你用一個會“幻覺”的工具來調 Bug，而你自己又沒能力判斷它是不是在幻覺，那你這趟旅程會很漫長。
對比之下，自己對于AI工具的把握還是要好很多。
與此同時，大模型工具幫我減掉了很多我討厭的活。我通常能很快看出它是不是在走偏（至少大多數時候能），并在它繼續之前及時叫停。結果就是，我反而重燃了對寫代碼和構建軟件的熱情，產出更多，質量也更好。
另一位網友victor9000則更是提出了一句“小白金句”：
我不知道，Claude 寫的。
我是那種會認真讀代碼、提出追問的 reviewer。我從新人和資深工程師口里都聽過這句話。真讓人抓狂，他們一本正經地說出這種話，還指望保住工作？如果有人在提交自己都不理解的代碼，那他們就是團隊、產品和雇主的負擔。
最逗趣地是，還有一位網友爆料道：
我老板曾經決定用 Devin 提一堆 PR。我告訴他，我花在審查 PR 上的時間，比他節省的時間還要多。
總之，關于代碼評審這塊，網友是徹底剎不住車了。大模型生成的代碼各種明線和暗線的bug，不可不查、不可布防！
好消息是，AI再一次被證明替代不了人類程序員！
