Hook It Up to the Machine
低速過熱的二手車預示了未來：人類必須依賴 AI，才能修復 AI 寫的程式碼。
- 傳統物理檢查經驗，無法用於診斷電腦化汽車的數位感測器故障。
- AI 生成的龐大程式碼，未來將超越工程師獨立理解與除錯的極限。
- 未來軟體除錯，必須依賴另一套 AI 模型才能完成診斷與修復。
在 2000 年代初期，一台只要時速低於 40 英里就會發生引擎過熱的二手綠色廂型車，意外預示了當今 AI 輔助軟體工程的發展軌跡。當機械零件被看不見的數位感測器取代，即使經驗豐富的修車技師沒有專用診斷電腦也只能束手無策。這段從類比跨越到數位時代的童年回憶，如今正精準對應到由 LLM（大型語言模型） 驅動的程式開發領域：未來我們是否必須完全依賴機器，才有能力看懂並修復另一台機器所寫出來的龐大程式碼？
蒙大拿州冰河國家公園的 40 英里時速散熱挑戰
故事發生在 2000 年代初期，當時作者的父母帶著全家人前往蒙大拿州的冰河國家公園展開公路旅行。他們駕駛的是一台剛買來的二手綠色 Dodge Caravan（道奇卡拉凡） 廂型車，這款車型在後來很快就被大眾貼上了「瑕疵車」的標籤。對於當時還是青少年的作者來說，並未對周遭發生的瑣碎細節投入太多關注，但唯一讓他印象深刻的，就是這台廂型車在旅途中不斷出現引擎過熱的狀況。車輛在州際公路上高速行駛時一切運作正常，引擎溫度也保持穩定。但只要脫離高速路段，車速一旦降到每小時 40 英里以下，儀表板上的溫度計指針就會迅速攀升至危險的紅區。為了確保後續的行車安全，他們選擇在蒙大拿州的一個小鎮暫停，找了一位當地的汽車修理技師來檢查這台狀況百出的車輛。
技師對車輛進行了詳細的檢查，也親自把車開出去進行試駕測試。最終他向作者的父親說明了車輛過熱的根本原因：引擎前方的怠速風扇無法正常啟動。在州際公路上維持高速行駛時，迎面而來的強烈氣流足以替代風扇保持引擎冷卻，因此溫度不會異常。然而一旦進入低速行駛狀態或是停下等紅綠燈，缺少了風扇的主動散熱機制，車輛的冷卻液就會沸騰並陷入過熱危機。
傳統技師面對 Dodge Caravan 數位感測器的無力感
這位蒙大拿州的小鎮技師坦言，他完全不知道為什麼怠速風扇無法順利啟動。就他肉眼所及的機械結構來看，整台車沒有任何實體零件發生故障或損壞。風扇馬達狀態完好，相關的線路連接看似正常，但他就是無法找出版法來修復這個散熱問題。過去他習慣透過聽覺與視覺來判斷零件磨損，但這次面對毫無異狀的實體結構，他的傳統診斷方式完全失效。
他無奈地向作者的父親解釋，這台 Dodge Caravan 屬於當時越來越普及的「電腦化」車款。面對這類新世代的汽車，傳統的肉眼檢查與物理測試已經遠遠不夠用。技師必須把車輛的中央控制系統連接到另一台專用的外部電腦，才能準確讀取錯誤碼並診斷出問題的源頭。而這位習慣處理純機械車輛的小鎮技師，當時手邊剛好還沒有採購這種先進的電腦診斷設備。於是，這家人只能帶著尚未修復的車子繼續未完的國家公園旅程。
接下來的行程中，作者的父親被迫不斷選擇「繞遠路」，專挑能夠維持較高車速的外環道路或鄉間小路行駛，以避免車速過慢導致引擎再次過熱。對當時坐在後座的孩子們來說，這反而成了一件非常有趣甚至刺激的經歷。因為父親終於有了一個名正言順的正當理由可以一路飆車，不用理會速限帶來的拘束。儘管坐在副駕駛座的母親對這種無奈的行車方式感到相當不悅，這卻成了全家人難以忘懷的旅行記憶。
經銷商維修廠裡的電腦對話與數位零件替換
當這趟橫跨蒙大拿州的公路旅行正式結束並返回家鄉後，作者的父親終於有機會把這台綠色廂型車開進正規的汽車經銷商維修廠。在那裡，專業技師拿出了檢測設備，將車輛內建的電腦系統與維修廠的專用電腦成功連接起來，這才順利診斷出並修復了問題。雖然作者如今已經記不清確切的技術細節，但故障的原因似乎只是一個小小的數位感測器發生了失效。
正是這個肉眼看不見的數位錯誤，阻斷了系統發送啟動怠速風扇的電子指令。一旦技師將那個故障的感測器找出來並替換成新品，整台車的散熱系統就立刻恢復了正常運作，不再有低速過熱的問題。這個看似簡單的維修過程，本質上就是「電腦與電腦之間的對話」。機器之間互相交換了數據與錯誤碼，才替人類找出了隱藏在硬體深處的邏輯瑕疵。
成長在一個將許多事物從類比轉向數位、從純粹機械轉向電子元件的過渡時代，作者表示自己經常回想起這趟特別的公路旅行。那個年代見證了傳統技術的侷限性，也預告了未來設備將變得越來越黑箱化。在如今這個使用 LLM 來建構軟體與應用程式的新時代，這段童年回憶再次浮現，並帶來了更深層的技術叩問。
肉眼無法辨識的數位開關與舊知識的淘汰
回顧那位蒙大拿州的小鎮技師，他的整個職業生涯都圍繞著傳統機械汽車打轉，對每一個齒輪與閥門的運作都瞭若指掌。在那個純粹機械的時代，車輛的任何毛病都可以透過實體檢查來觸摸、拆解、診斷並修復。如果是一個實體的機械開關壞了，技師憑藉敏銳的肉眼與手感就能輕易看出端倪。但如果是一個隱藏在線路板上的數位開關失效，肉眼在外面根本無從察覺任何異狀。
面對一台高度電腦化的汽車，這位技師過去累積了數十年的豐富經驗與專業知識，在數位感測器面前瞬間變得毫無用武之地。缺乏外部電腦介面的協助，他甚至連風扇為何不轉的最基本原因都摸不著頭緒。這是一個極具歷史象徵意義的時刻：人類已經無法單憑自身的感官來理解機器的內部狀態。你必須依賴另一台電腦，透過資料傳輸協議，才能幫助你理解眼前這台電腦正在發生什麼事。
這種從實體可視性到數位隱蔽性的轉變，徹底改變了人類維修機器的邏輯與門檻。程式碼與微控制單元取代了機械連桿，使得問題的排查不再依賴技師充滿油污的雙手，而是依賴螢幕上跳動的除錯代碼。而如今，軟體工程領域正在經歷一場規模更大、影響更深的類似轉變。
LLM 時代的軟體開發是否將重演依賴機器的診斷困境
在當前這個開發者普遍依賴 LLM 來撰寫程式碼的新時代，作者不可避免地再次想起了那位充滿無力感的修車技師。這引發了一個關於軟體工程未來的關鍵提問：在 AI 程式碼生成工具日益普及的趨勢下，未來的工程師是否會陷入一模一樣的技術盲區？當程式碼的生成速度與複雜度呈指數級上升，開發者可能逐漸失去對底層邏輯的完全掌握。
如果一個龐大的程式碼庫是在 LLM 的深度參與和協助下建構出來的，其整體的複雜度與隱藏的錯誤，將會發展到超出人類大腦所能獨立理解的極限。未來的開發者在面對自己或團隊打造的系統時，可能無法再像過去一樣逐行檢查、理解邏輯、找出 Bug 並手動修復。這些由 AI 生成的程式碼，可能只有透過另一套 LLM 的介入與分析，才能夠被有效檢查、理解與診斷。就如同當年必須依賴外部電腦才能修好廂型車的風扇一樣。
未來的軟體除錯場景，或許將不可避免地演變成一段荒謬卻極度真實的對話。一位工程師可能會求救：「嘿，你能幫我看一下嗎？我的程式碼庫出了一個未知的問題。」而另一端的資深同事或技術顧問將會無奈地回答：「好的，我可以確認這個問題確實存在，但如果不把你的程式碼庫連接到一個 LLM 進行運算分析，我根本無法修復它。」當人類必須依賴 AI 才能理解 AI 所創造的系統，我們將正式邁入一個全新的技術依賴時代。
面對 AI 生成的龐大程式碼，我們終將步入必須依賴機器診斷機器的全新時代。