當(dāng)“AI 10 倍工程師”的論斷在社交平臺上泛濫，當(dāng)“不用 AI 就會被淘汰”的焦慮如潮水般襲來，也許我們更該停下腳步，冷靜地追問一句：AI 真能帶來編程效率的指數(shù)級提升嗎？

一起來看看國外工程師 Colton Voege 的現(xiàn)身說法。

幾個月前，我陷入了一段心理低谷。過去，我一直對自己的工程能力充滿信心，但當(dāng)我在 LinkedIn 和 Twitter （現(xiàn)“X”） 上不斷刷到各種討論時，卻忍不住感到焦慮—— 我的技能，似乎正以一種令人絕望的速度落后。

如果這些信息可信的話，工程領(lǐng)域應(yīng)該已經(jīng)告別了“手寫代碼”的原始階段。真正的工程師，如今的生產(chǎn)力可能已經(jīng)是我的 10～100 倍了。我寫下這些，希望能幫助那些正在經(jīng)歷類似焦慮的人。

我向來是一個懷疑論者，每次聽到諸如“某種草藥可包治百病”的類似說法，總會不以為然。但當(dāng)這些“10 倍工程師”的論調(diào)無處不在時，我開始感到不安：

如果我錯了呢？如果不立即學(xué)會使用 AI，會不會錯過機(jī)會，再也找不到工作？畢竟，現(xiàn)在很多流傳的花哨詞匯，讓他們口中的“AI”與我所熟悉的“AI”不同。

他們所說的是 Agentic AI，一種能夠?yàn)g覽網(wǎng)頁、運(yùn)行測試、糾正自身錯誤的思考 （thinking） 模型。當(dāng)然，我也會在聊天窗口中讓它寫一些代碼，但通常會在獲取想法后，把大部分丟掉。然而，這些工程師卻把工作完全交給 Claude，在他們喝早咖啡時，讓 Agent 替他們提交 5 個PR。難道，我真成了那個跟不上時代的“恐龍”？

讓我感到焦慮的部分原因是，也許 AI 已經(jīng)在我不經(jīng)意間發(fā)生了巨變，因?yàn)槲液苌偈褂?AI，也并不喜歡使用 AI，審查代碼的過程，遠(yuǎn)不如編寫代碼有趣。難道正是這種固執(zhí)地想要享受編碼的想法，讓我落在了后面？

AI編程工具，表現(xiàn)不盡人意

最終，我決定投身?AI 編程。我嘗試了 Claude Code、Cursor、Roo Code 和 Zed，它們被認(rèn)為可以實(shí)現(xiàn) agentic 編碼。我在各種項(xiàng)目中使用它們編寫代碼，比較它們的表現(xiàn)，甚至嘗試完全不手動修改 AI 生成的代碼。

然而，結(jié)果不盡人意。盡管有人聲稱 AI 正以驚人的速度進(jìn)步，但它與以往相比并沒有本質(zhì)區(qū)別。它擅長編寫模板代碼，尤其在 JavaScript 中，特別是與 React 相關(guān)的。但它在代碼庫的標(biāo)準(zhǔn)和工具方面表現(xiàn)不佳，在處理 Terraform 這類語言時也會遇到困難，還會因?yàn)榛糜X生成存在嚴(yán)重安全漏洞的庫。

即便我輸入了很詳盡的 prompt 和 CLAUDE.md 文件，這些 AI 也仍難以理解更大代碼庫的上下文。如果使用的不是 StackOverflow 上的熱門庫，它就會搞砸，即便查閱文檔也是如此。Agent 偶爾會表現(xiàn)得很棒，比如修復(fù)自己破壞的測試，但更多情況下只是在浪費(fèi)時間和 token，在各種嘗試之間來回切換，似乎也沒有獲得更深層次的知識。因此，對我而言，AI 的最佳應(yīng)用場景仍是編寫一次性腳本，尤其是當(dāng)我對單個腳本的底層原理毫無興趣時。

因此，那些聲稱“不立即使用 AI 就會被淘汰”的警告顯然是錯誤的。使用 AI 編程并不難學(xué)。不過，AI 編程社區(qū)在一個問題上意見不一：AI 是讓編程變得簡單到連“原始人”都能做到，還是需要高級、專業(yè)的 prompt 工程師技能？我的體驗(yàn)是：確實(shí)需要學(xué)習(xí)一些東西，但掌握起來很快。例如，你需要學(xué)會將任務(wù)分解成更小的步驟，避免 AI 在上下文窗口中失去方向；像 Claude Code 這樣的工具甚至能自行完成部分工作，但并不總是可靠；還要學(xué)會在識別到 AI 偏離過遠(yuǎn)時及時接管。

通常，一個合格工程師只需不到一周，就能熟悉如何與 AI 進(jìn)行協(xié)作。而且，如果 AI 真可以隨時變得比現(xiàn)在強(qiáng) 2 倍、10 倍甚至 100 倍，那么現(xiàn)在關(guān)于如何使用它的任何經(jīng)驗(yàn)，都無關(guān)緊要。

每當(dāng)我發(fā)現(xiàn) AI 的表現(xiàn)“只是還行”，我反而更加焦慮，因?yàn)檫@意味著我找不到讓其他人“高效 10 倍”的秘訣。我好像缺乏那種天賦，就像恐龍遇上了代表 AI 的小行星。

幸運(yùn)的是，幾件事讓我走出了低谷，其中之一是閱讀了 Ludicity 的一篇文章——它直接反駁了 AI 吹捧者的論調(diào)。

我寫下這篇文章，就是想分享更多幫助我 擺脫“AI 10倍工程師冒名頂替綜合征”的經(jīng)驗(yàn) 。

“10倍工程師”有多荒謬？

讓我們先看看“10 到 100 倍生產(chǎn)力”的簡單數(shù)學(xué)邏輯。

所謂 10 倍生產(chǎn)力，意味著成果增加十倍，而不是代碼行數(shù)增加十倍。這意味著過去需要一個季度完成的工作，現(xiàn)在只需不到兩周的時間。

即便是最堅(jiān)定的 AI 信徒，也該停下腳步思考：傳統(tǒng)上需要 3 個月才能完成的工作，真能在 7 個工作日內(nèi)完成？這幾乎要求整個開發(fā)流程的每一個環(huán)節(jié)都實(shí)現(xiàn)十倍效率的提升。

任何參與過實(shí)際代碼開發(fā)的軟件工程師都知道，這根本不可能。單是代碼審查流程，就無法從 3 個月縮短到 1.5 周內(nèi)。代碼審查流程包括：

• 標(biāo)記審查者；

• 希望他們盡快完成審查 （這非常困難，因?yàn)樗麄冿@然需要審查的代碼量是之前的?10?倍） ；

• 等待期間切換到其他任務(wù)；

• 收到通知 （可能立即收到，也可能在審核人員下班后 2 小時才收到） ；

• 切換回代碼審查；

• 閱讀他們的評論；

• 做出相應(yīng)的回復(fù)；

• 重復(fù)上述步驟。

  
  

在管理規(guī)范、溝通良好的公司，這個流程可以很高效。但要說將這個流程的效率提升 10 倍來處理 10 倍的工作量？絕無可能。

實(shí)際上，企業(yè)軟件工程中涉及的人為流程并未發(fā)生顯著變化。產(chǎn)品經(jīng)理或許會用 ChatGPT 進(jìn)行“調(diào)研”，但不可能突然產(chǎn)出比之前多 10 倍的經(jīng)過嚴(yán)格審核、合理論證、準(zhǔn)確估算的需求文檔，他們無法一次性完成 10 次用戶訪談。設(shè)計(jì)師和質(zhì)保測試人員的情況也一樣。至于雇傭 10 倍數(shù)量的產(chǎn)品經(jīng)理來跟上進(jìn)度，不僅不現(xiàn)實(shí)，而且在溝通成本和組織官僚化的限制下，邊際回報會迅速遞減。

即便假設(shè)人們所說的只是編寫代碼的過程快了 10 到 100 倍，我們?nèi)詰?yīng)對這種說法持懷疑態(tài)度。編寫代碼時，你真正花在敲鍵盤上的時間有多少？可能比想象的少得多。大部分編碼時間其實(shí)用在閱讀、思考以及等待編譯、頁面刷新或測試運(yùn)行上。LLM 并不能讓 rustc 運(yùn)行得更快。

更重要的是，LLM 生成的代碼往往存在缺陷、幻覺或不符合代碼庫標(biāo)準(zhǔn)，且代碼庫規(guī)模越大，這類錯誤發(fā)生得越頻繁。這時，你需要重新 prompt，可能可以立即解決問題，也可能浪費(fèi)大量時間；或者你親自修改代碼，但這樣就回到了普通工程師的水平，甚至可能更糟——你習(xí)慣了氛圍編程 （vibe coding） ，忘記了如何編寫代碼。如果你根本不查看生成的代碼，一旦代碼庫足夠大，就會遇到生產(chǎn)力瓶頸，不得不面對完全缺乏標(biāo)準(zhǔn)和適當(dāng)抽象的問題。

我認(rèn)為人們有時會忽視 10 倍提升的規(guī)模。10 倍的差距就像小型貨車與創(chuàng)紀(jì)錄的超音速陸地噴氣機(jī)之間的差異。

想象一下，你試圖用一輛時速 600 英里的汽車在城市街道上完成 10 分鐘的通勤，能以十分之一的時間到達(dá)城市另一端嗎？顯然不能，因?yàn)榧词挂粋€ 60 秒的紅綠燈也會耗盡全部時間預(yù)算。F1 賽車在基本轉(zhuǎn)彎時也要減速到小型貨車的速度。事實(shí)證明，任何活動的大部分時間都不是以最高速度進(jìn)行的。

100 倍生產(chǎn)力，則意味著現(xiàn)在能在兩天內(nèi)完成過去需要一年的工作。這樣的數(shù)字有多荒謬，無需多言。

“10倍工程師”真的存在嗎？

我本不想?yún)⑴c這場辯論，但或許不得不說幾句。我的答案是：有時，可能會有一點(diǎn)點(diǎn)。當(dāng)我遇到生產(chǎn)力比別人高出十倍的工程師時，通常不是因?yàn)樗麄儗懘a更快，而是因?yàn)樗麄兡茏柚勾罅坎槐匾墓ぷ鳎赫f服產(chǎn)品經(jīng)理放棄根本不可行的功能，讓另一位工程師別再去構(gòu)建多余的微服務(wù)，推動開發(fā)者體驗(yàn)改進(jìn)，使所有人都能在日常任務(wù)中節(jié)省時間，并認(rèn)真記錄工作，方便未來的工程師更快上手。這些積累下來的成果，往往能讓公司節(jié)省的時間遠(yuǎn)超他們個人投入的時間，甚至達(dá)到十倍之多。

但這并非時時存在，因此優(yōu)秀的工程師只會在某些情況下達(dá)到 10 倍生產(chǎn)力。到了某個階段，每位工程師都必須專注于開發(fā)功能，而優(yōu)秀工程師可能比初級工程師快兩倍，但仍會遇到與之前相同的瓶頸。盡管“故事點(diǎn)”這一衡量方式存在缺陷，但我從未見過工程師能持續(xù)完成比平均工程師多 10 倍的工作量。

值得注意的是，AI 編碼助手對減少不必要工作幾乎毫無幫助，反而常常鼓勵草率決策和過度開發(fā)。當(dāng)我拋出架構(gòu)性問題時，它給出的答案，往往在我冷靜思考一晚或與優(yōu)秀同事交流后，就會發(fā)現(xiàn)根本沒必要去實(shí)現(xiàn)。若其他條件完全一致，編碼更快確實(shí)意味著更高的產(chǎn)出，但這并不是決定性的十倍差異，更難在實(shí)踐中保持“其他條件不變”。而且，越是執(zhí)著于以最快速度完成任務(wù)，就越容易忽略那些真正能節(jié)省總體工作量的關(guān)鍵環(huán)節(jié)。

這些AI-posters在說謊？

我認(rèn)為這些 AI-posters 可以按惡意程度從低到高分為以下幾類：

• 心地善良的人，但他們對自己和他人都有誤判；

• 在 AI 成功上投入了大量個人或財(cái)務(wù)資源的人 （如 AI 初創(chuàng)公司創(chuàng)始人、投資者等） ；

• 明目張膽地試圖讓工程師感到不安，以免他們辭職、尋找其他工作或要求加薪的老板們。

  
  

1. 數(shù)學(xué)較差的工程師

根據(jù)我的經(jīng)驗(yàn)，AI 能帶來罕見、短暫的 10 到 100 倍生產(chǎn)力提升。當(dāng) AI 能在幾分鐘內(nèi)為我生成一個自定義的 ESLint 規(guī)則時，確實(shí)實(shí)現(xiàn)了數(shù)量級的效率提升——否則我需要花數(shù)小時翻閱文檔和教程。這樣的時刻確實(shí)會發(fā)生，許多非編程背景的從業(yè)者在使用 Lovable 啟動應(yīng)用的頭幾天就感受到了這種魔力。

但問題在于生產(chǎn)力無法規(guī)模化。我一年寫不出超過一條 ESLint 規(guī)則。這種生產(chǎn)力爆發(fā)僅因我對這段代碼并不在意，且不會花時間讓它對下一位工程師可讀。若持續(xù)編寫 ESLint 規(guī)則成為核心工作要求，我會投入一次性成本學(xué)習(xí) ESLint 內(nèi)部機(jī)制。之后，編寫規(guī)則與親自編寫代碼所需的時間差異將不再顯著，尤其是在考慮為確保代碼在 6 個月后重新查看時易于閱讀而額外花費(fèi)的時間后。

最終，每個代碼生成工具的用戶都會達(dá)到回報大幅遞減的階段。他們的網(wǎng)站遭到黑客攻擊，不得不花時間學(xué)習(xí)安全機(jī)制；應(yīng)用程序變得過于龐大，無法在上下文窗口中顯示，界面和功能開始出現(xiàn)不一致；真正了解前端工程的工程師會被聘請來實(shí)現(xiàn)一致的設(shè)計(jì)系統(tǒng)和用戶體驗(yàn)。

還有許多簡單的偏見和盲點(diǎn)會造成生產(chǎn)力錯覺。從大型企業(yè)跳槽到初創(chuàng)公司，你會驚訝地發(fā)現(xiàn)每位工程師的生產(chǎn)力都高得多，很容易將此歸功于 AI。有些人真的很享受 AI 編程的技術(shù)新奇感，從事新事物時，往往會覺得自己做得比以往更多。我記得第一次使用 Python 時，感覺像在“暢飲火箭的燃料”，但與所有其他技術(shù)一樣，最終都會回歸現(xiàn)實(shí)。

我認(rèn)為，許多關(guān)于 AI 的 10 倍提升的炒作，其實(shí)源于人們正處于蜜月期，或是尚未靜下心來認(rèn)真思考 10 倍提升在數(shù)學(xué)上的具體含義。我不會驚訝于得知 AI 能幫助許多工程師將某些任務(wù)的完成速度提升 20%～50%，但軟件瓶頸的本質(zhì)意味著這并不會轉(zhuǎn)化為 20% 的生產(chǎn)力提升，更不用說 10 倍的提升了。

2. 激勵機(jī)制至關(guān)重要

我并非 AI 初創(chuàng)企業(yè)的反對者。如果你想將 OpenAI 的 API 集成到醫(yī)療健康初創(chuàng)企業(yè)中，我可能會對潛在風(fēng)險表示擔(dān)憂，但對于任何希望在醫(yī)療領(lǐng)域快速推進(jìn)并打破常規(guī)的初創(chuàng)企業(yè)，我都會持同樣態(tài)度。我的目的并非指責(zé)人工智能初創(chuàng)企業(yè)的創(chuàng)始人或投資者是邪惡或不誠實(shí)的。用高中經(jīng)濟(jì)學(xué) 101 教授的調(diào)侃語氣說：“激勵機(jī)制至關(guān)重要”。

如果你運(yùn)營著一家 AI 初創(chuàng)公司，而其他所有人工智能初創(chuàng)公司都在向投資者宣稱 AI 使生產(chǎn)力提升了 10 倍，那么激勵機(jī)制很簡單：你應(yīng)該在公開和私下場合都做出同樣的表態(tài)。如果公司業(yè)務(wù)建立在 AI 基礎(chǔ)上，你就有動力將 AI 吹捧為生活中各個領(lǐng)域的萬能解決方案。如果你是一名工程師，老板問你：

“嘿，你借助?AI 實(shí)現(xiàn)了 10 倍的生產(chǎn)力提升，和其他工程師一樣，對吧？”

你會有很強(qiáng)的動力說“是”。而當(dāng)其他工程師也出于同樣原因說“是”時，CEO 并非在說謊，他們只是在轉(zhuǎn)述自己聽到的內(nèi)容。

我想向那些和我一樣感到焦慮的人強(qiáng)調(diào)，這并非新鮮事。CEO 并非客觀的信息來源，高管們一直聲稱從 Agile （敏捷開發(fā)） 到 Meyers-Briggs （邁爾斯-布里格斯性格分類指標(biāo)） 都能釋放無限生產(chǎn)力。LinkedIn 上總會有新的協(xié)同效應(yīng)熱詞，別讓它影響你。事實(shí)上，干脆別再刷 LinkedIn 了，那是個愚蠢的地方。

3. 蓄意惡意

當(dāng)有人說出讓人們感到焦慮的話時，至少有時你應(yīng)該得出結(jié)論，那是因?yàn)檎f話者就是想讓這種情況發(fā)生。老板試圖讓工程師覺得自己的職位不穩(wěn)固，這也不是什么新鮮事。我們都記得那個說法：一個為期三個月的編程訓(xùn)練營就能培養(yǎng)出與四年制大學(xué)畢業(yè)生質(zhì)量相當(dāng)?shù)墓こ處煟阅阕詈脛e太得意，否則會被一個轉(zhuǎn)行做軟件工程的文學(xué)學(xué)士取代。幾年后，人們意識到訓(xùn)練營畢業(yè)生通常對實(shí)際軟件工程工作準(zhǔn)備不足，因?yàn)樗麄儧]有良好的基礎(chǔ)。

編程訓(xùn)練營和 AI 只是眾多試圖將高度專業(yè)化、高成本的軟件工程領(lǐng)域商品化的失敗嘗試中的兩個例子。它們是修辭手段，旨在暗示不穩(wěn)定性。你的老板實(shí)際上無法解雇你并用 AI 取代你，但他可以讓你覺得他可以這么做，也許這樣你就不會要求加薪了。

關(guān)于“10 倍 AI 工程師”的故事中，有一部分可能是那些僅僅想讓你感到不安的人在講述。具體有多少，我不知道。盡管在這個時代，我們彼此之間變得高度不信任，但我仍然相信大多數(shù)人本質(zhì)上是善良的，所以我傾向于認(rèn)為這個比例不高。

隔閡

我注意到， 在所有關(guān)于 AI 編程的炒作文章中，作者與實(shí)際生產(chǎn)力提升之間幾乎總是存在某種隔閡。 發(fā)帖者可能是創(chuàng)始人、經(jīng)理或投資者，他們對他人生產(chǎn)力做出夸張的聲明。使用二手資料本身沒有問題，但如果你找不到一手資料，你可能會開始質(zhì)疑信息的可靠性。

來自實(shí)際工程師的演示，展示他們?nèi)绾瓮ㄟ^ AI 實(shí)現(xiàn)更高生產(chǎn)力，要多樣化得多，贊譽(yù)也低調(diào)得多。這些演示大多將 AI 視為我們熟悉的同一技術(shù)：一個有時能施展魔法但常常需要你親自掌控的文本生成器。

在開源項(xiàng)目中使用人工智能，其生產(chǎn)過程可被公開見證，這一嘗試曾以滑稽的失敗告終。我從幾個 YouTube 視頻中學(xué)習(xí)到了如何更好地使用 AI。

效率低下也沒關(guān)系

即使我已經(jīng)接受了有一群神秘的工程師，他們的效率、力量、身高和魅力都比我高出十倍這一事實(shí)，我仍然對一個事實(shí)感到焦慮：我仍然不喜歡使用 AI 。一旦魔法消失，編碼就變得索然無味。閱讀 LLM 生成的代碼很糟糕，禮貌地要求它使用一個沒有產(chǎn)生幻覺的庫是痛苦的。但如果我，盡管有這些缺點(diǎn)，在 AI 編程方面比常規(guī)編程高效 20%，那我做“正常”編程是否錯誤？如果存在更高產(chǎn)出的路徑，我是否應(yīng)該放棄？

不。犧牲一些效率以使工作愉快是可以的。不僅可以，在我們的領(lǐng)域中，這是必要的。如果你強(qiáng)迫自己以一種你討厭的方式工作，你最終會 burn out。編碼中只有一部分是寫代碼，其余的是解決問題、進(jìn)行系統(tǒng)設(shè)計(jì)、思考抽象概念以及與他人溝通。當(dāng)你感到愉快時，你會在這方面做得更好。對自己的工作感到自豪并欣賞這門手藝是可以的。從長遠(yuǎn)來看，你的代碼庫會因此受益。

數(shù)字音樂是否客觀上比黑膠唱片更好聽并不重要，翻唱片是否比讓流媒體服務(wù)在 100 倍更短的時間內(nèi)自動切換到下一首歌更“高效”也不重要。如果你聽一張 70 年前的唱片能讓你更快樂，那就去做吧。這樣你聽的音樂會比強(qiáng)迫自己使用更“高效”的流媒體服務(wù)時聽得更多。如果你以自己喜歡的方式編寫代碼，你會花更多時間編寫代碼，而且你會寫出更好的代碼。

哦，而且這個論點(diǎn)也適用于反向情況。如果你覺得做 AI 編程很開心，那就去做吧。如果你感到如此興奮，以至于比以往任何時候都寫更多的代碼，那太棒了。我希望每個人都能感受到這種快樂，無論他們是如何達(dá)到的。

如何成為優(yōu)秀的AI領(lǐng)導(dǎo)者

讓所有工程師始終對自己的表現(xiàn)感到焦慮，這對公司不利。這會讓工程師不想為你工作。這種短期思維會鼓勵工程師追求糟糕的指標(biāo)，如代碼行數(shù)。代碼審查會被忽視，技術(shù)債務(wù)會不斷累積，長期來看，整個公司將為這些錯誤買單。

不切實(shí)際的 10 倍預(yù)期必然導(dǎo)致倉促且質(zhì)量低下的工作。工程師需要有喘息的空間，有時間把事情做好。良好的代碼庫和優(yōu)秀的公司都建立在對當(dāng)下與未來平衡思考的基礎(chǔ)上。我很幸運(yùn)能在這類公司工作，但許多公司并不如此幸運(yùn)。

不要責(zé)怪工程師沒有使用足夠的 tokens。工程師是在極具競爭力的領(lǐng)域中受過高等教育的專業(yè)人士。軟件工程師早已因過度熱衷于擁抱和放棄新語言與工具而臭名昭著。如果你支付給他們?nèi)绱烁叩男劫Y，就應(yīng)該信任他們：一旦出現(xiàn)能帶來超級生產(chǎn)力提升的工具，他們會主動向你申請專業(yè)版計(jì)劃。如果你擔(dān)心錯過其他人似乎都在獲得的 AI 編碼收益，那就注冊一個 LLM 團(tuán)隊(duì)計(jì)劃，舉辦一次培訓(xùn) session，看看會有什么結(jié)果。這就是你需要做的全部。

結(jié)論

只要你加入正確的 Facebook 群組，你就會知道沒有一種神奇的草藥能預(yù)防所有疾病。只要你開始嘗試氛圍編碼，你就會知道現(xiàn)在還沒有所謂的AI編程革命可言。 你沒有錯過任何東西。 相信自己。你已經(jīng)足夠好了。

哦，還有，不要刷 LinkedIn。或者 Twitter。永遠(yuǎn)不要。

本文來自微信公眾號： 學(xué)術(shù)頭條