洗車問題：為什麼您的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代理重啓到黑屏之前，你的組織是否建立了應對系統？