AI 精神錯亂：為何快速恢復無法取代系統韌性

在最近一次具挑釁性的觀察中，Mitchell Hashimoto 警告了一種他稱之為「AI 精神錯亂」的現象正滲透整個公司。這種心態的特徵是對於 AI agent 無理地過度依賴，用以維護軟體系統，進而導致基本工程原則的危險侵蝕。

其核心不僅僅是關於工具採用的辯論，而是關於我們如何確保運行現代世界的軟體可靠性的根本分歧。隨著公司急於將 AI 整合到開發生命週期的每個階段，他們面臨著重複雲端基礎設施早期昂貴錯誤的風險。

MTBF 與 MTTR 的清算

為了說明目前的危險，Hashimoto 將其與雲端自動化轉型期間，平均故障間隔時間 (MTBF) 與 平均修復時間 (MTTR) 之間的歷史緊張關係進行類比。

MTBF 專注於韌性——建立從一開始就不會故障的系統。MTTR 則專注於恢復——建立在故障發生後可以快速恢復的系統。雖然雲端時代教會了我們快速恢復至關重要，但也揭示了一個關鍵事實：你不能為了恢復而完全放棄韌性。

Hashimoto 主張，業界目前正將一種扭曲的「僅限 MTTR」心態應用於整個軟體開發流程。被推動的邏輯是：發布帶有 bug 的程式碼是可以接受的，因為 AI agent 可以以遠超人類能力的的速度與規模來識別並修復它們。然而，這種做法忽略了當焦點從「防止」故障轉向「應對」故障時所累積的系統性風險。

健康的幻象

這種「精神錯亂」最陰險的面向之一，是它通常隱藏在表面上看起來很正面的指標背後。Hashimoto 指出，系統在整體衰退的同時，仍可能看起來很健康的多種方式：

• 測試覆蓋率： 一個專案可能顯示 100% 的測試覆蓋率，但如果 AI 同時編寫程式碼與測試，系統的「語義理解」就會下降。測試可能會通過，但它們可能在測試錯誤的東西，或者反映了程式碼中存在的相同幻覺。
• Bug 報告： Bug 報告的減少通常被視為成功的跡象。然而，這可能是一個滯後指標；潛在的風險可能正在表面之下爆發，等待特定的條件觸發災難性的故障。
• 架構衰退： 當變更以 AI 加速的速度發生時，底層架構可能會在不經意間衰退。系統會變成一台「災難機器」——高度自動化，卻對負責監督它的開發者而言根本無法理解。

「精神病院裡的囚犯在管理」

圍繞 Hashimoto 警告的社群討論突顯了對 AI 生成「閉環」日益增中的擔憂。正如一些觀察者所指出的，當 AI 被用於流程中的每一步時，危險性會增加：編寫初始程式碼、生成測試，以及進行程式碼審查。

"對於編寫程式碼使用 AI，但進行人工程式碼審查是合理的。或者，人工編寫程式碼，但使用 AI 生成測試案例……一旦它被用於所有事情，人們就失去了方向，就像是精神病院裡的囚犯在管理。"

當人類從驗證流程中被移除時，系統就會失去與現實的連結。防止系統性崩潰的交叉檢查機制，被一個反映 AI 本身偏見與錯誤的鏡像所取代。

經濟與文化壓力

為什麼會發生這種情況？有人認為這不僅僅是技術問題，更是財務問題。隨著大量風險投資流入 AI 商業化，公司感到有一種生存性的需求，必須完全轉向 AI 驅動的流程。在這種環境下，對於那些與資金掛鉤的人來說，接受失敗的可能性並非選項，這導致了一種近乎妄想的強迫性樂觀主義。

結論：對形式化驗證的需求

雖然有些人將其視為另一種企業跟風或「貨物崇拜 (cargo cult)」現象，最終會自我修正，但其中的利害關係比以往更高。AI 部署的速度意味著這種「學習經驗」可能是災難性的。

未來的路徑可能需要回歸嚴謹性。隨著生成式 AI 的熱潮退去，業界可能會發現自己渴望進入一個新的軟體工程新時代——在這個時代，AI 的輸出不再是被盲目信任，而是基於精妙的架構與嚴格的標準進行形式化驗證。在那之前，工程師的挑戰是在一個過度追求恢復的自動化時代，維持對韌性的理性對話。