AI 批次修改：一次放多少筆，先看出錯後救得回多少

先講結論：AI 批次修改的上限，要看出錯之後你救得回多少，不能只看它一次能處理多少。前面試做成功，也不代表下一批就可以全放。

我有一次清理網站後台的頁面段落，結果把圖片一起清掉了。後來嘗試補回的 27 張圖，只成功補回 1 張，其餘停手。

問題不只出在刪錯。等我想救的時候，後台的狀態和前台抓到的舊快取已經對不上，原本的排列也沒完整留下來。手上有一些殘片，卻拼不回原狀。

那次最難受的地方是：執行修改很快，補救卻連從哪裡對起都不確定。叫它繼續做很容易，叫它把剛才動過的東西還給我，就沒那麼容易了。

先交代這篇的邊界：我帶過團隊，但沒有企業級 AI 導入或大量資料遷移的實績。這篇的事故來自我自己的網站後台；分批與恢復的原則，另參考雲端系統的官方文件。下面的批次判準是我根據這些經驗整理的建議，沒有做過跨團隊成效實驗，也不是一套保證不出錯的公式。

試做成功，為什麼還不能直接跑完剩下的？

試做成功只能證明那些樣本在當時的條件下跑得通，不能同時證明剩下的資料都一樣，也不能證明出錯後來得及恢復。

這裡其實有兩個問題。

第一個是：這個改法能不能做？挑一些不同情況的資料試做，可以幫你找到明顯的問題。

第二個是：如果下一批出問題，我們扛不扛得住？這個問題就算前面全對，也還沒被回答。

你可能抽到的都是結構簡單的頁面，還沒碰到有圖片、舊版格式或特殊欄位的那一群。也可能修改本身沒問題，但回復時得一筆一筆找原值，根本沒有整批還原的辦法。

「跑得對」和「救得回來」，需要分開看。

AWS 的官方文件介紹分批部署：先讓部分系統使用新版本，觀察後再逐步擴大；若出現異常，就回復。這份文件談的是軟體部署，不是 AI 整理辦公資料的實驗，也沒有提供一個各種工作通用的安全筆數。

我從中借用的原則很小：擴大範圍應該是下一個決定，不該是第一批成功後自動發生的事。

否則「先試一下」很容易變成一個形式。真正有約束力的問題，應該接在它後面：這次試過了，下一次準備放多少？為什麼是這個量？

我刪掉圖片那次，缺的是能回去的原狀

批次修改能不能補救，取決於你留下的原狀是否完整、是否對得上被改的那一筆，而不只是有沒有一個叫做備份的資料夾。

2026 年 5 月 28 日，我的後台修補程式用「有沒有文字」判斷一個段落是不是空的。這個條件漏了一件事：有些段落沒有文字，但裡面有圖片。

程式把段落當成空白刪掉，底下的圖片也跟著被刪掉。當時的紀錄裡，有一條反省很直接：沒有在第一個頁面做完之後就確認結果。

如果第一個頁面改完就停下來看，我至少有機會在繼續之前發現問題。但這只能解釋「為什麼沒有更早停」，不能解決已經被改掉的部分。

補救時，我又撞上另一個缺口：操作前沒有留下完整的編輯狀態。後台已經被改過，從前台抓到的又是舊快取，用模糊比對想把圖片接回去，對不上。最後那 27 張只補回 1 張。

這是我付過代價才分清楚的兩件事：小批確認可以縮小波及範圍；可用的原始紀錄，才讓你有機會恢復。兩件事不能互相代替。

Google Cloud 在資料復原測試的官方建議裡，也把備份的一致性、可用性和實際還原分開要求。測試不只是把檔案取回來，還要確認恢復後的資料能讓系統正常運作，並檢查完整性與恢復時間。

這是系統可靠性的建議，沒有替我的事故做診斷。但它支持一個很實際的提醒：看到「備份完成」四個字，還不能把恢復能力那一欄打勾。

下一批的上限，我會先問這四件事

下一批的上限，我會根據原狀、恢復時間、可承受的停頓和影響範圍來決定；這四件事有一件說不清楚，就還沒有放大的依據。

下面是我會採用的判斷順序。這是事後整理出的做法，不是那次事故之前就已經運作良好的制度。

第一問：本批每一筆，真的找得到對應的原狀嗎？

先拿出準備修改的清單，確認原始資料和每一筆對得起來。光有一份大檔案，卻不知道哪一段屬於哪個項目，出事時還是得重新找。

如果要動的東西包含圖片或附件，原狀就不能只剩文字；如果原本的排列會影響使用，恢復時也不能只把內容塞回去就算完成。

我那次最缺的，就是能完整對回去的狀態。這一問過不了，增加筆數只會讓待補的洞變多。

第二問：在類似條件下，恢復一批實際要多久？

先在不影響正式工作的地方，用相近的資料試一次恢復，並把檢查恢復結果的時間一起算進去。你需要的是實際試過的時間，不能只憑感覺抓一個數字。

計時不能只算下載備份或按下還原。找出受影響清單、確認哪份才是正確版本、處理沒恢復成功的項目，以及確認原本的工作能繼續，都會佔時間。

如果只試過結構簡單的一筆，就不能直接用它的時間乘上整批筆數。圖片比較多的、曾被別人改過的、互相牽動的資料，補救方式可能完全不同。資料差異很大時，我會先分開處理，讓每一批的條件比較接近。

第三問：出錯之後，這件工作最多能停多久？

可接受的停頓，要由正在使用這些資料的人一起判斷。負責操作的人覺得「晚點修就好」，不代表等著用的人也有這個空間。

這句話可以問得很白：如果這批現在壞掉，到什麼時候之前得恢復，才不會卡住你的下一件工作？

拿這個時間，去對照實際試過的恢復過程，再留下處理意外的餘裕。不要把可用的時間全部塞滿；也不要把「某位同事願意留下來救」當成恢復能力的一部分，除非那個安排真的存在。

我沒有可以交給每個人的固定比例。資料相似、恢復方式熟悉，和第一次碰到的新系統，不能用同一個數字。

第四問：改這幾筆，真的只影響這幾筆嗎？

有些工作表面上一筆一筆改，底下卻連著同一份分類、同一個版型或同一個共用設定。你只動一個地方，其他地方也可能跟著變。

遇到這種情況，筆數就不是很好的上限單位。我會先找出真正一起變動的範圍，再決定能不能分開做。

能在可接受的停頓內恢復的量，才有資格成為下一批的候選上限。 這個上限仍要留餘裕，也不能取代修改前後的檢查。

只改一個欄位，為什麼整個頁面也變了？

操作的實際影響範圍，可能比畫面上看起來的修改範圍大；一旦發現這種落差，我會先停止放出下一批。

2026 年 9 月 7 日，我在後台調整頁面的排序並儲存時，碰過另一種副作用：表面上只改排序，儲存的過程卻把整段內容重新處理了一遍，連某些區塊的格式屬性都被拿掉。

這次不是整批刪除事故，也沒有前一例的圖片損失數字。它留下的提醒是：「我只改一個欄位」，說的是我的意圖，不見得是系統實際做的事。

所以我會把「不該變的東西也變了」列為暫停訊號。排序改好了，區塊格式卻不見，這就已經超過原本預期的範圍。這類變化一出現，就要先弄清楚同一個動作還碰了哪裡。

這時候，把下一批從大批縮成小批，也未必夠。若同一個儲存動作會改寫整個頁面，先搞清楚改寫範圍，比繼續試更多筆更有幫助。

方法的限制也在這裡：恢復過去的版本，可能蓋掉這段時間別人新增的修改；某些動作還會連動其他系統，原資料改回來，外面的結果不會自動跟著收回。遇到這些情況，需要另外確認恢復方式。分小批可以降低一次碰到的量，卻不能把不可逆的動作變成可逆。

「每一批都等，還用自動化做什麼？」

分批確認確實會降低連續執行的速度，對可以丟掉重做、沒有外部影響的工作，限制得太細可能反而不划算。

這是我認為最有力的反駁。假設你只是把一份完整保留的原始資料轉成另一種格式，結果寫進新檔，出錯就刪掉新檔重做，並不需要和直接修改正在使用的資料採取同樣的上限。

恢復方式如果已經反覆試過，資料也夠一致，後面的批次可以比前面大。批次可以隨著有把握的範圍增加，也不需要人一直盯著進度條。

但如果提速的方法是「先全跑，錯了再想怎麼救」，省下來的其實是前面的確認時間，後面的補救時間還沒算進去。我的圖片就是卡在後面那筆帳。

我比較願意接受的取捨是：把等待放在影響範圍改變、資料種類改變，或準備增加批次的地方。 規律、可恢復的部分繼續做；遇到沒試過的條件，就重新決定上限。

這套批次判斷適合誰、不適合誰

這套批次判斷，最適合已經準備修改一批現有資料、而且修改會直接影響使用中的工作的人。

適合你，如果：

• 你已經試過幾筆，現在正要決定剩下的怎麼分批。
• AI 或腳本會直接修改後台欄位、既有檔案或共用資料。
• 別人會問你「如果改壞，什麼時候可以恢復」，但目前還沒有具體答案。

不適合你，如果：

• 你只是在複本上試做，原始資料完整保留，結果可以直接捨棄重建。
• 操作無法恢復，或一筆就會連動整個共用系統；光決定筆數不足以處理這類風險。
• 你還沒確認修改方法本身是否正確；分批上限不能代替這一步。

代價：

你得先花時間試恢復。 這段時間在進度表上看起來沒有多處理任何一筆資料，但它決定了你後面敢放多少。

整批完成的時間可能拉長。 分段看結果、有異常先停，會打斷一次跑到底的順暢感。要事先把這段確認時間排進工作裡。

原狀會佔空間，也需要整理。 留了一堆分不清對象和時間點的檔案，不會自動變成好用的退路。保存、對照和清理都有人要做。

決定上限後，怎麼讓執行時照著做？

批次上限要和明確的處理清單放在一起，執行的人才知道這一輪到哪裡停。

我會在開始前留下一張簡單的工作便條，寫清楚五件事：本批包含哪些項目、原狀放在哪裡、這個量的恢復依據、看到什麼變化先停，以及恢復後由誰確認能繼續用。這些欄位是本文整理的建議，不是已經替團隊驗證過的制度。

如果連「本批包含哪些項目」都只能回答「剩下的全部」，我會先把清單拆出來。說清楚這一輪做什麼，比在工作結束後猜它動過哪裡省事。

工具層還有另一件事：讓程式實際能碰到的範圍，和這份清單盡量接近。我在自己的部落格整理過 AI agent 刪檔風險與工具防線，內容包含隔離工作環境、限制可操作範圍等做法。那篇可以接著看，但工具防線仍不能替你回答「這批出錯，來不來得及救」。

FAQ 常見問題

批次修改的決策，最常卡在趕時間、沒有恢復紀錄，以及已經看到異常卻還沒停下來的時候。

主管要今天全部改完，我該先做哪一件事？

先把預計完成量和出錯後的恢復能力放在一起說明，不要只報處理速度。如果恢復時間還沒試過，就直說目前不知道。可以先完成條件清楚、可恢復的那一部分，把還沒確認的項目列出來，讓期限和風險一起被看見。

已經有每日備份，還需要限制每批筆數嗎？

需要先確認那份備份能不能只恢復受影響的部分，以及恢復後會不會蓋掉今天其他人的工作。如果只能整份倒回去，少量修改也可能牽動很多人。備份頻率本身回答不了單批上限。

前幾批都成功，什麼時候可以加大？

當下一批的資料條件相近、實際影響範圍沒有改變，而且更大的量仍在可承受的恢復範圍內，可以考慮逐步增加。如果換了資料種類或操作方式，我會重新判斷，不把前幾批成功當成新條件的通行證。

已經發現非預期變化，要先修完這批，還是先停？

先停止新增修改，留下目前的受影響清單和狀態，再確認恢復方式。不要一邊讓後面的繼續跑，一邊猜前面的怎麼修。至於要原地修正還是回復原狀，得看哪一種更可控，不能只因為已經做了一半就選繼續。

參考資料

批次與恢復原則參考以下官方文件；文章中的批次判準是作者整理的建議，文件沒有驗證通用的安全筆數。

AWS，Deployment methods（《Practicing Continuous Integration and Continuous Delivery on AWS》，頁面未列發布日期，2026-10-03 查閱）：說明分批部署、小範圍觀察與異常回復；適用範圍是軟體部署。

Google Cloud，Perform testing for recovery from data loss（Well-Architected Framework，2024-12-30 審閱）：支撐備份需一致且可用、應演練還原，並確認資料完整性與恢復後的系統功能。