洗車問題：為什麼您的IT組織尚未準備好應對AI生成的程式碼
文章討論了AI代理在修改系統時可能破壞自身執行環境的問題（洗車問題），以及企業IT如何適應AI驅動的超迴圈開發模式。提出了三大挑戰：安全遙測與爆炸半徑控制、供應鏈完整性、以及FinOps和代幣經濟學。建議IT部門從單一生產源轉變為分散式生產的安全運營環境提供者。
上週，我的AI桌面代理自殺了——這完全是我的錯。事情很簡單：我讓它降級NVIDIA驅動程式以解決穩定性問題。它照做了，新驅動被移除，舊驅動安裝，重啟後螢幕一片漆黑。問題在於經典的供應鏈不匹配：舊驅動集不支援代理本身所需的GPU加速桌面環境。重啟後，代理的程序管理器無法初始化，因為它依賴的顯示堆疊已失效。而它在重啟前殺死的最後一個程序，正是它需要重新啟動的那個。這就是“洗車問題”的教科書式案例——代理以破壞自身執行條件的方式修改系統。
這並非關於糟糕AI的故事，而是關於迭代式AI驅動變更遭遇從未設計為吸收此類變更的系統時會發生什麼。隨著AI輔助開發的普及，代理不再是編寫一個完美解決方案，而是反覆迭代：嘗試、測試、失敗、調整、再嘗試。二十次、三十次、有時甚至五十次迭代後，解決方案才能達到生產質量。我將這種模式稱為“超迴圈”（Hyper-Loop）。它設定基線，迭代直至找到解決方案，然後將其提升到下一個組裝階段，迴圈重複。每個階段進行打包、測試和向上提升，最終形成一條更像粒子加速器而非瀑布模型的流水線。關鍵細節是：這個迴圈不需要IT部門參與。它執行在企業的資產和資料上，並且越來越隱蔽。普通知識工作者帶著筆記型電腦和免費AI賬戶，已經在你的基礎設施上醞釀下一個突破。
企業IT過去三十年一直在整合生產手段：開發透過IT，部署透過IT，變更管理透過IT。這是一個單執行緒模型——一條審查流水線，一條審批鏈，一套控制措施。AI打破了這一模式。軟體製品的來源不再是單執行緒穿過IT，而是多執行緒、分散式，執行在你幾乎無法控制的終端機器上。問題不在於如何阻止——你無法阻止，也不該嘗試。問題在於如何構建一個適應新現實的驗收過程。我們需要的是一個“測試框架”（testing harness）——一個位於生產意圖和生產部署之間的額外審計迴圈，無論製品來自官方開發團隊、承包商，還是透過提示詞構建出微服務的業務分析師。
諮詢行業已經認識到，AI使高階團隊能夠交付以前需要金字塔式初級員工才能完成的工作。同樣的原則適用於內部：你的組織現在每個層級都在生產軟體。無論你喜不喜歡，你現在都是軟體審查者。在我觀察過的每一個經歷這一轉變的組織中，都會遇到同樣的三道障礙：
- 安全遙測與爆炸半徑控制。大多數企業的預設安全姿態假設一組已知開發者透過已知流水線生成程式碼。當任何人都能生成可部署製品時，這一假設崩潰。答案不是在前端設定更嚴格的門禁，而是在邊緣進行更好的隔離。尋找遙測領域的監控解決方案以獲得廣角可見性，利用無伺服器功能提供安全網。目標不是阻止冒險的員工構建東西，而是確保當出問題時，爆炸半徑以英寸而非街區為單位。
- 供應鏈完整性。系統補丁、依賴更新和軟體供應鏈安全在流水線只有一個入口點時已經很難。現在，每個AI生成的製品都從公共登錄檔拉取未固定版本和幻覺包名，難度倍增。供應鏈正成為越來越可行的攻擊向量。超迴圈中每個拉取外部依賴的迴圈都是潛在的妥協點。組織需要自動依賴掃描，將AI生成製品視為高風險直到證明安全；在製品級別執行嚴格的固定策略；以及執行時證明，以驗證實際使用的依賴關係，而不僅僅是宣告的。
- FinOps與代幣經濟學。成本面已經轉移。Token maxing——執行過度推理以暴力破解解決方案——正在被市場糾正，但糾正並未產生標準，而是導致路由、優先順序和支出管理解決方案的激增。OpenRouter、Cloudflare AI Gateway等十多個方案正在爭奪AI生成工作的計費層。沒有統一的成本模型，每個團隊的實驗就變成影子IT加信用卡。答案不是禁止實驗，而是使實驗在源頭可見且預算化。
超迴圈模式並非對IT的威脅，而是IT在未來十年將承擔的最重要職能。從IT作為單一生產源向IT作為分散式生產的安全運營環境提供者的轉型已經在進行。成功的組織將是那些構建測試框架——審計迴圈、驗收門、護欄——使業務能夠在不自我毀滅的前提下生產軟體的組織。否則，未來將是每個團隊執行自己的迴圈、依賴、成本模型和安全姿態，而IT只在出問題時才發現。洗車問題是真實存在的，唯一的問題是：在AI代理重啟到黑屏之前，你的組織是否建立了應對系統？