一个工程师的自白：AI 让我几乎忘了怎么写程序，产业技能空洞隐忧浮现

軟體工程師 James Pain 在個人部落格坦承，使用 AI 輔助程式開發一至兩年後，他幾乎「忘記了如何寫程式」。這不只是個人危機，當整個工程師族群都依賴 AI 生成程式碼，誰還記得讀懂它、修正它？（前情提要：加州大學研究「AI 腦霧」現象：14% 上班族被Agent、自動化搞瘋，離職意願高四成）（背景補充：OpenAI 傳將起訴蘋果「違約」！怒轟 Siri 整合 ChatGPT 未達標、百億訂閱落空）部落格寫道：「我已經一至兩年沒有親手寫過一行程式碼。我幾乎忘記了怎麼寫程式，而這讓我感到非常悲傷。」體工程師 James Pain 在他並非抱怨 AI 工具難用，恰恰相反。他說 AI 太好用了，好用到他已經完全靠「下指令」來產出程式碼，而不再動手寫任何一行。現在，他正在從頭教自己重新編碼。 Pain 的描述精準而令人不安：他每次想寫作或寫程式，腦子裡第一個念頭都是「讓 AI 來」。當他事後讀 AI 生成的文字，感覺「完全不像我說的話」；當他試著自己寫程式，也發現手感已經生疏。這種現象有個認知科學基礎，稱為「認知解除安裝」— 大腦在長期仰賴外部工具後，會降低對應功能區域的神經活化頻率。翻譯過來就是：不用就會退化。這在 GPS 導航取代空間記憶、計算機輔助設計取代手繪等領域早有研究記錄，AI 程式輔助工具帶來的可能是同一類效應的加速版。問題的規模不只是個人層級。根據 GitHub 在 2024 年的調查，超過 92% 的美國軟體開發者在工作中已使用 AI 程式輔助工具；Stack Overflow 同年調查顯示，76% 的開發者正在使用或計畫使用 AI 工具。如果「Pain 的現象」即便只在其中 10% 的人身上發生，那也意味著數十萬名工程師正在以不同速度喪失主動編碼的能力。且更值得關注的是：這不是個別懈怠，而是理性的短期決策。用 AI 生成程式碼更快、更少出錯（在初版階段），產出符合交付要求。在商業壓力下，工程師選擇 AI 是合乎邏輯的。但長期而言，誰來審查這些 AI 生成的程式碼？誰能在 AI 出錯時（它確實會出錯）找出問題所在？ Pain 在文章中引用了《Clean Code》作者 Robert Martin 的一個歷史觀察，恰好為當前困境提供了更長的視角。 Martin 指出，在電腦科學成為獨立學科之前，寫程式的人是物理學家、數學家、學術研究者，他們本身就具備嚴謹的專業訓練。1970 至 1990 年代，隨著個人電腦普及、軟體需求爆炸，業界快速擴張，招募大量沒有傳統「電腦科學」背景的開發者，程式開發的專業性開始被稀釋：檔案寫得越來越少、程式架構越來越難以維護、技術債越堆越高。如今，AI 工具對應用層程式碼的高度替代，正在形成第二波稀釋。這一波的特殊之處在於：它不只是「人才素質的平均化」，而是「現有人才的去技能化」。已經在職的工程師，正在因為長期使用 AI 而喪失底層能力。 AI 工具的設計邏輯也在助長這個趨勢。現行主流的 AI 程式助理（包括 GitHub Copilot、Claude、Cursor 等）的核心價值主張是「讓你更快交付」，而非「讓你更深入理解」。 Pain 在文章中還提到一個細節，揭示了更深的認知困境：當他完成這篇文章後，「幾乎下意識地想把它貼進 Claude 看看 AI 怎麼說」，因為他不確定自己寫得夠不夠好。這不只是技能退化，更是「認知自信的轉移」：人開始把 AI 的判斷當作真相的驗證標準，而非自己的判斷。當一個工程師看到 AI 生成的程式碼，第一個念頭是「這應該沒問題」而不是「讓我讀懂它再決定」，這才是更結構性的危機。在此背景下，業界也開始出現反向操作的聲音。部分資深工程師團隊開始推行「AI 禁食日」，要求成員每週保留若干時間純手寫程式碼；某些技術面試已明確禁止 AI 輔助，目的不是為了刁難，而是要確認應聘者仍具備基礎閱讀與除錯能力。 Pain 本人也不認為程式開發作為職業將消失。他引用 Martin 的觀點指出，總會有人需要真正讀懂並修改程式碼。只是人數會更少，標準會更高。問題是：如果整個產業都在 deskilling，那批「更少但更強」的人從哪裡來？ Pain 選擇回到前者：重新學習親手寫程式，不是因為 AI 不好，而是因為他意識到這個能力不能外包。