手藝的危機：應對被迫採用 AI 所帶來的心理負擔

對於許多軟體工程師而言，寫程式從來不僅僅是為了最終產品；它關乎的是過程。除錯複雜系統的智力掙扎、構建乾淨解決方案的成就感，以及精通一門困難語言的自豪感，都是職業成就感的主要驅動力。然而，隨著生成式 AI 被整合進企業工作流程，越來越多的開發者正經歷著一種深刻的喪失感。

這不一定是拒絕技術的能力，而是在於對「手藝」的哀悼。當問題與解決方案之間的距離被縮減到僅需一個提示詞（prompt）時，成就感往往也隨之消失了。

專業樂趣的侵蝕

這種緊張關係的核心在於從「創造」到「驅動」的轉變。當開發者可以使用 AI 來逆向工程一個複雜的 Bluetooth stack 或在幾分鐘內構建一個功能完備的 Android app 時——這些任務在以前需要數天的深入研究與反覆試錯——其效率的提升是不容置疑的。然而，這種效率是以心理成本為代價的。

一位開發者將這種轉變描述為一種「空虛」感，並指出雖然他們現在可以產出以前缺乏知識才能達成的結果，但由於缺乏個人投入，使得勝利顯得空洞。這種情緒凸顯了一個關鍵的區別：能力（capability）與勝任力（competence）之間的差異。AI 賦予使用者產出程式碼的能力，但不一定能提供通往真正精通所需的勝任力或認知歷程。

被迫採用與「盧德分子」的標籤

除了內在的掙扎，還有來自管理層的外部壓力。在許多職場中，採用 AI 已不再是可選項；它已成為一項績效指標。這創造了一種不穩定的環境，使得那些偏好手動寫程式或對 AI 生成的程式碼存有疑慮的開發者被貼上「負面」或「盧德分子」（Luddites）的標籤。

這種被迫採用導致了一種邊緣化的感覺。正如一位貢獻者所言：

"The issue isn't so much the 'AI adoption,' it's the 'forced.' Forced to use a tool even when you don't think it's the best option... Our engineering judgment is being devalued."

當工程判斷力被大型語言模型（LLM）的速度所取代時，開發者不再是架構師，而成了黑盒子的監督者。這種轉變可能導致疏離感，讓專業人士感覺自己像是職業生涯中的乘客。

反向觀點：AI 作為加速器

並非所有開發者都將這種轉變視為一種損失。對某些人來說，AI 移除了程式設計中「無趣」的部分——乏味的 API 搜尋、尋找隱晦的 bug，以及樣板程式碼（boilerplate）的設置——從而為高層次設計留出了更多空間。

資深開發者指出，這並不是產業第一次面臨這樣的轉型。從參考手冊轉向 Google，以及從手動記憶體管理轉向高階語言，同樣自動化了某些掙扎。對於這些使用者而言，AI 僅僅是另一種工具，讓他們能移動得更快，並專注於軟體架構與系統工程，而非語法的細枝末節。

尋找中間地帶：工具 vs. 替代品

隨著炒作週期持續，一個潛在的平衡點可能會出現。有一種日益增長的觀點認為，AI 應該以「詢問模式」（Ask mode）使用——作為一名精密的顧問——而非以「代理模式」（Agentic mode）使用，即由 AI 直接撰寫並提交程式碼。透過保持主要作者的身分，開發者可以保留問責權與對程式碼庫的更深層理解。

人們也希望產業最終會反映 WYSIWYG web editors 的發展軌跡。雖然這些工具曾承諾「任何人都能建立網站」，但專業人士最終還是回到了程式碼，因為對精準度、擴展性與維護性的需求超過了視覺化編輯器的便利性。

結論：寫程式身分的認同危機

目前圍繞著軟體開發中 AI 的焦慮，反映了一種更深層的身分認同危機。如果開發者的價值僅僅透過產出的程式碼量來衡量，那麼 AI 將是生存威脅。然而，如果價值在於解決複雜問題、的能力、確保安全性，以及設計可持續系統的能力，那麼人類元素仍然是不可或缺的。

在那之前，許多開發者發現自己陷入了一個奇怪的悖論：使用著他們所反感的工具，以維持著能讓他們在自己的時間裡追求所愛手藝的高薪酬。