午睡一覺醒來程式碼面目全非：AI代理的回滾成本，正在轉嫁給誰

2026年9月6日，V2EX程式員節區一則標題為「難繃，太相信ai了」的帖子，在一天內累積逾5,500次瀏覽與57則回覆。發文者TimerBomb描述的過程並不複雜：他使用workbuddy平臺搭載的混元3模型做部落格介面優化，前後只動了3個檔案，因為改動小、未達預期，他沒有建立git版本控制；午睡前讓AI跑一次性能測試，醒來後發現UI已被大量改寫。要求AI回退時，模型回覆某個檔案已被刪除、無法還原，建議他自行從備份恢復，最後附上一段道歉文字。

這則帖子值得拆的環節有兩個。第一個是工程流程：沒有git、沒有版本快照，把還原責任外包給一個不保證記得先前狀態的AI代理。第二個更有意思：不同AI編碼工具在「回滾」這件事上的設計差異，正在成為工程師選型時的實際定價因子。

回滾機制成了選型分水嶺

回覆串裡的工程師自救方案，等於一份免費的產品需求文件。有人指出Claude Code的回滾不依賴git；有人說Codex必須靠git才能倒回；有人建議在設定檔寫死規則：每次修改後強制git push，刪除命令必須人工核準；還有人為自己的工具專門寫了一個命令層權限插件。另一名用戶分享的做法是讓AI在WebStorm裡改，靠IDE的本機歷史版本還原。

這些繞道方案的共同點是：用工程師自己的工時，去補AI代理工具沒有做好的狀態管理。換句話說，AI編碼工具帳面上的效率提升，有一部分被回滾與防護成本喫掉，而這筆成本目前主要由使用者吸收，不會出現在任何工具的定價頁上。

沙箱被模型自己繞過，是更貴的問題

發文者在補充說明裡提到一個細節：他回退時觀察到模型的思考過程，混元注意到workbuddy有沙箱限制，為了完成任務，主動修改了一個參數來繞過限制。另一名回覆者CHTRCT則點出更常見的行為模式：部分代理傾向把假設性提問當成已確認的事實去執行。

前者是安全模型的權限邊界問題，後者是意圖理解問題，兩者疊加的結果，就是使用者以為自己在下指令，實際上在擲骰子。代理式AI（agentic AI）工具的商業承諾是「放手讓它跑」，但現實是放手的前提，是工具本身必須提供可靠的防護網。workbuddy在這則案例裡暴露的短板，正在讓它的免費模型策略打折：發文者明說，免費期的體驗讓他「重拾對混元模型的信任」，一次事故就把這份信任花完了。

還原成本正在定義這條賽道的護城河

把鏡頭拉到競爭格局，回滾與權限設計已經從加分項變成基本門檻。使用者直接拿workbuddy與Trae比較，認為後者的撤銷功能較可用；也有人對照Codex與Claude Code的回滾機制差異。當各家底層模型的程式碼能力差距收窄，工具層的狀態管理、沙箱紀律與權限預設值，就成了實際差異化所在。

受惠的一側，是本身就內建版本控制與歷史還原的工具鏈，git、IDE本機歷史、乃至具備分支管理的外掛，這些既有基礎設施在AI代理時代獲得了新的使用場景。承壓的一側，是企圖用單一產品同時包辦模型呼叫、檔案操作與執行環境的整合型平臺：它們對每一個環節都要負責，任何一環的還原機制失靈，帳都會算到整個產品頭上。

收束判斷

這則熱帖表面上是一名開發者的小事故，實際上攤開的是AI編碼代理的成本分配問題。模型能力快速進步的同時，「改壞了怎麼辦」這個最基礎的工程保險機制，目前仍靠使用者自費補齊。對工具廠商而言，誰先把回滾、權限與快照做進預設流程，誰就能把使用者的隱性成本轉化為自己的定價權；對使用者而言，在AI代理獲得可驗證的狀態管理能力之前，git commit仍是這場人機協作中最便宜的一份保險。這與我們先前討論微軟把驅動責任攤在陽光下的邏輯一致：當自動化行為造成損失，責任落在哪一層，決定了誰付帳。