地址清錯了怎麼回復？每次更正要留下哪些紀錄
要能回復，紀錄必須回答「哪一列、從什麼改成什麼、為什麼、依據在哪、誰在何時做」。只寫「地址已修正」沒有辦法重播，也無法分辨是格式整理、來源更正還是人工猜測。
| 欄位 | 虛構內容 |
|---|---|
| change_id | CH-20260926-004 |
| record_id | R0088 |
| before | 範例市學習路12號 |
| after | 範例市學習路21號 |
| change_type | 門牌更正 |
| evidence | 收件人回覆紀錄 E-19 |
| operator / time | reviewer-A / 2026-09-26 |
| status | 待第二人確認 |
門牌 12 改成 21 是高風險更正，沒有證據時不能執行；若已誤改，回復也不要刪除 CH-004，而是新增 CH-005 記錄 21 回到 12，讓歷史完整。
可回復流程
- raw_address 永久保留，工作值另欄。
- 每次改動先用地址比較工具產生可讀差異。
- 對行政區、道路、門牌與樓室變更要求具體依據。
- 低風險格式轉換也要記規則版本，避免日後無法解釋。
- 回復時依 change_id 建反向更正，不覆蓋歷史。
- 定期比對目前值與更正紀錄最後狀態，找出未完整套用的列。
- 若多人共用 Google Sheets，可用版本紀錄輔助查人與時間，但逐列理由仍要自己保存。
版本歷程能協助找回整份檔案狀態，不能取代業務層的逐筆依據。若一個更正影響上千列，先停止發布與寄送，找出共同規則與影響範圍，再從原文重建。
原始值、候選值與狀態欄位可參考Excel 地址批次整理指南；單筆格式解析用地址格式檢查。更正紀錄證明有人做過什麼，不等於地址存在或一定正確；證據不足時應撤回候選並標無法確認。
兩種回復情境要分開
第一種是整批規則錯誤，例如程式把所有「12之1號」改成「121號」。這時可依 run_id 找出同一批變更，先暫停下游使用，再用 before 值產生回復候選。第二種是單筆人工更正錯誤，例如客服把 R0088 的門牌抄成 21 號；這時只回復該 change_id，不能把同一批其他已確認修改一起撤掉。
回復也要新增一筆紀錄，而不是刪除原錯誤紀錄。可使用 reversal_of 指向被撤銷的 change_id，before 寫目前值，after 寫回復候選，reason 說明錯誤原因。這樣能看出地址先被改、後被撤回的完整過程，也能防止之後又重播同一個錯誤修正。
真正執行前的四道檢查
先確認 record_id 沒有因排序或合併改變，再核對目前值仍等於該變更的 after；若別人後來又修過，就不能直接套舊回復。接著計算預計影響列數，抽查門牌、樓室和行政區等高風險欄位。最後先在副本演練，驗證列數、唯一鍵和狀態，再由第二人核准寫回。
完成後不要只看檔案能開。應比對回復前後差異、確認下游匯出是否需要重做、通知已取得錯誤版本的使用者，並保存 affected_run、驗證人與結案時間。若沒有可靠 before 值，只能從版本紀錄或原始來源重建，不能憑印象填回一個看似合理的地址。
防止同一變更被重複套用
批次更正應有 idempotency_key 或唯一 change_id。再次匯入同一修正檔時，系統要辨認已處理紀錄並停止，不能把「12之1號」又轉一次。若回復後需要重新套用修正版規則，建立新的 change_id 並指向原事件，讓審查者能區分重播、回復與重新處理。
對外已交付錯誤名單時，還要記錄 recipient、delivered_version 和 replacement_version。只修主表不會自動收回舊附件；必須通知接收者停止使用舊版，並確認後續配送或匯入是否已受到影響。
回復後不要立刻關單
至少等下游重新讀取正確版本，並確認舊的寄件檔、客服附件或匯入批次已停止使用。若錯誤資料曾產生標籤或通知，另列補救狀態，不能只因主表恢復就視為沒有影響。結案摘要寫清楚根因、偵測方式與防止再發措施，讓下次審查能驗證控制是否真的生效。