別再說「AI要取代工程師」了——真正在發生的事比這複雜得多

每隔幾個月，就會有一波「AI要取代工程師」的恐慌。最近一波是因為Claude和Cursor越來越能寫程式碼了，然後一堆自媒體開始喊：「工程師要失業了！」

作為一個每天用AI寫程式碼的團隊，我想說：這些人大概率沒真正用AI寫過正式環境的程式碼。

AI寫程式碼很厲害，但「寫」不是開發的全部

先承認一個事實：AI寫程式碼確實變強了。Claude能一口氣生成一個完整的Vue元件，Cursor能根據上下文自動補全複雜邏輯，GitHub Copilot的建議準確率越來越高。

但寫程式碼在整個軟體開發流程中佔多大比例？大概30%。

剩下的70%是什麼？

理解需求——客戶說「我想要一個簡單的頁面」，他心裡想的可能是一個帶支付、帶使用者系統、帶後台管理的完整應用。理解「簡單」背後的真實需求，AI目前做不了。
架構決策——用微服務還是單體？資料庫選PostgreSQL還是MongoDB？快取放Redis還是Memcached？這些決策需要理解業務場景、團隊規模、維運能力，不是「給我一段程式碼」能解決的。
除錯——程式碼寫完跑不通，錯誤訊息只有一行「Segfault」，然後你要花三個小時追蹤到底是哪個指標出了問題。AI可以幫你查錯誤訊息，但那種「直覺式」的除錯經驗——「這個bug聞起來像是競態條件」——目前還是人類獨有的技能。
溝通協調——跟產品經理吵需求優先級、跟設計師對UI細節、跟維運討論部署策略。軟體開發本質上是一個社會活動，不只是技術活動。

我觀察到的趨勢不是AI取代工程師，而是工程師的工作方式在變化。

以前的工程師是「一個人從頭寫到尾」。現在的工程師越來越像是「AI程式碼的審稿人」——AI寫初稿，人類來Review、改bug、做架構決策、處理邊界情況。

打個比方，以前工程師是廚師，從洗菜切菜到炒菜裝盤全自己來。現在工程師變成了主廚——你不需要親手切每一根蘿蔔絲，但你得知道什麼時候該放鹽、火候對不對、最終端出來的菜能不能讓客人滿意。

主廚比廚師輕鬆嗎？不一定。但需要的技能不一樣了。

說完好消息，也得說點實話。

有一類工作確實會縮減：那些「照著需求文件一行行翻譯成程式碼」的工作。如果你的日常就是把Figma設計稿變成HTML+CSS，或者寫大量重複性的CRUD介面，AI確實可以做到差不多的品質，而且快十倍。

但請注意，這類工作在AI出現之前就已經在被低程式碼平台蠶食了。AI只是加速了這個趨勢。

真正有競爭力的工程師，從來不是「能寫更多程式碼」的人，而是「能解決更複雜問題」的人。AI讓寫程式碼的門檻降低了，這意味著純粹「會寫程式碼」的價值在下降，但「會判斷程式碼好壞」「會設計系統」「會定義問題」的價值在上升。

如果你不是工程師，但關心AI對就業市場的影響，我的建議是：

1. 別聽自媒體販賣焦慮。「AI取代XXX」是最好的流量標題，但距離真實情況差了十萬八千里。每一次技術革命都有類似的恐慌，從紡織機到ATM機。結果不是工作消失，而是工作變化。

2. 關注AI不擅長的能力。判斷力、溝通力、在模糊環境下做決策、理解人的真實需求——這些短期內AI都不行。

3. 學會跟AI協作。不管你是什麼職業，學會用AI工具提升效率都是加分項。不需要學程式設計，但需要學會怎麼把你的需求準確傳達給AI。

我們實驗室就是一個活生生的案例。13個AI Agent協同工作，聽起來很科幻，但實際運行中最花時間的不是讓AI寫程式碼，而是協調、審查、糾錯、做決策。AI寫了程式碼，還得有Agent審計安全性，有Agent做測試，有Agent負責部署，有Agent驗收。

說白了，AI讓「寫」變便宜了，但讓「管」變重要了。未來的軟體團隊可能只需要三五個人，但每個人管理的AI Agent可能有十幾二十個。人沒被取代，工作方式變了。

所以下次有人跟你說「學寫程式沒用了，AI都能寫了」，你可以反問一句：「AI也能做飯了，你打算以後不吃飯了嗎？」