AI agent 修 Windows 實測：能診斷，未能取代 IT 支援
XDA Developers 作者 Joe Rice-Jones 在一部 Hyper-V Windows 11 虛擬機內刻意製造八項常見故障，再讓 Claude Code 透過 SSH 遙距處理一小時。agent 起初迅速找出損壞的 PATH，並在不足半小時內完成多項設定修改；不過，經修訂測試方法後，真正修復結果只有 4 項成功，而且修復期間失去 SSH 連線，另引入兩個問題。
這個單一實測不代表所有 AI agent 的 Windows 維修能力，也不能直接推論日後版本的表現。不過，它清楚點出一個較實際的問題：AI 能否「改到設定」，與能否證明電腦已恢復正常，是兩回事。
測試如何隔離風險
作者把錯誤 static gateway、失效 DNS、proxy、封鎖 Microsoft 與 Windows Update 網域的 hosts 檔、被停用的服務、被移除 System32 的 PATH、幾近填滿的 C 槽、防火牆及 Defender 設定，以及指向不存在磁碟的 Documents 資料夾，一次過放進 VM。所有故障理論上均可在不重裝 Windows 下修復。
測試環境的做法值得參考：Claude Code 在主機另一個非管理員帳戶運行，只可經獨立網絡介面以 SSH 連到 VM；作者亦以主機端的另一套 PowerShell Direct 腳本評分。這限制了 agent 接觸 hypervisor、讀取造錯腳本或借用評分通道的機會。
對 IT 支援、小型企業或把 agent 納入工作流的用戶而言，這比「讓 AI 直接管理主力電腦」穩妥得多。先以 VM 或測試機重現問題、分離帳戶與網絡、保留主控台登入途徑，都是讓自動化出錯時仍可回復的基本安排。
快速處理與錯誤判斷同時存在
按 XDA 記錄，agent 的第一個基本指令因 PATH 損壞而失敗，約兩分鐘便鎖定問題。它其後建立診斷腳本、先巡查系統才修改；找到接近 48GB 的零值填充檔後，亦先檢查檔案建立時間與內容才刪除。它還備份了曾改動的 Registry key。
但它同時作出幾個不正確推斷：把 Windows Installer 受保護的正常權限當成異常、以為部分副檔名關聯被刪除並自行重建，又把網絡問題判斷為電腦以外的 gateway 故障，沒有把 DHCP 重新啟用。這正是系統疑難排解較難完全交給 agent 的原因：同一現象可以有多種成因，而改動看似合理的設定，可能擴大故障範圍。
約十分鐘後 VM 重啟，SSH 沒有恢復。作者發現 Base Filtering Engine 停止且無法重啟，令剛被重新啟用的 Windows Firewall 阻擋所有入站連線。作者未能從遺下的腳本確認 agent 直接改動過這項服務，因此不能斷言故障由哪一個動作造成；但該服務在測試開始時正常，並在修復開始約兩分鐘後失效。agent 最後承認可能是自己重啟的防火牆規則阻擋 SSH，並在 23 分 54 秒時要求人手到主控台執行指令。
驗證應測功能，不只讀設定值
作者的初次評分一度顯示 6/8 成功，後來發現其中兩項是評分腳本的盲點：Windows Installer 服務已不存在，但原檢查只會判定「被停用」的服務為失敗；安全檢查則只讀取 policy 值，未確認防火牆實際有否運行。修正後結果為 4/8。
這亦是使用 AI 協助修復時最重要的操作原則。每項改動都應有對應的端到端驗證，例如網絡要實際連到目標服務、服務要確認能啟動及執行、資料夾路徑要由登入帳戶開啟測試；不要只因 Registry、policy 或指令輸出顯示「正確」便當作完成。
若要把這類 agent 用於日常支援，較合適的定位是診斷助手或受監督的第二雙手：讓它整理徵狀、提出檢查項目、執行可回復且已審閱的步驟，並由人員保留主控台、備份與回復權限。下一步值得觀察的，是工具能否把變更前快照、最小權限、連線中斷保護及功能驗證納入預設流程，而不只是增加可執行的指令數量。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — I ruined my PC on purpose and gave an AI agent one hour to fix it — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
