昨天討論常用收件資訊與出貨資訊的修改流程，哪些檢查可以共用，哪些規則應該各自處理。接著往資料看：兩邊都有姓名、電話與地址，為什麼還要分開保存？

程式是否共用，與資料是否分開保存，需要分別判斷。電話格式檢查可以共用，但客戶的常用電話與這次配送的收件電話，仍然各有用途。

今天想聊的是理解資料的業務含義與生命週期。知道一份資料為什麼存在、何時可以修改，才能與AI討論它應該如何保存，以及修改時有哪些限制、應該影響哪些紀錄。

建立時相同，之後各自代表不同的事情

沿用前一篇的示意情境：建立出貨單時，系統把常用收件資訊帶入，保存成這次配送使用的資料。兩份內容一開始相同，但常用資料供之後建立單據時使用，出貨資料則屬於這一次配送。

這裡用到的是資料快照（Snapshot）的概念：把帶入當下的收件資訊獨立保存，不隨客戶主檔後續更新。快照保留了當時的資料；至於單據上的收件資訊之後能否修改，仍要依出貨流程決定，不能把獨立保存直接理解成建立後一律不可修改。

例如客戶平常都寄到家裡，這次想改寄公司。客服修改這張待出貨單的地址，就只影響這次配送，不表示客戶希望往後都寄到公司。

反過來，客戶搬家後更新常用地址，之後建立出貨單時就能帶入新地址；既有出貨單仍保留自己的收件資訊。若某張尚未交付的出貨單也需要改寄，就針對那張單據另外確認與修改。

這就是分開保存的原因：兩份資料各自表達一件事，也有不同的修改範圍。即使此刻的姓名、電話與地址完全相同，它們仍然屬於不同的業務對象。

資料可以修改到什麼時候？

常用收件資訊會隨客戶需求更新。出貨單上的資訊，則跟著出貨流程走：依本文的規則，交付物流前可以修改，交付後就不能再透過原編輯功能更改，要保留此次配送使用的資訊。

所以出貨地址有自己的生命週期。建立時從常用資料帶入，待出貨時可依規則調整，交付後留下配送紀錄。把資料獨立存下來，只是其中一步；允許哪些操作修改、修改到哪個階段，也必須在程式裡落實。

這些背景會影響查詢使用哪份資料。建立新單據時，可以讀取常用收件資訊；查看某次出貨內容時，則讀取該出貨單保存的資訊。同樣都是查地址，目的不同，資料來源就不同。

保留出貨資料，不等於保留所有修改歷史

再往下看一層。假設客服在交付前修正了門牌號碼，出貨單保存修正後的地址，讓這次配送使用正確資訊。交付後查詢，也能看到配送時採用的地址。

但如果要問「最初填的是什麼？誰在什麼時候改過？」，就需要查修改歷史。出貨單上的目前值回答的是這張單據現在採用什麼內容，異動紀錄則用來追溯它如何變成現在這樣。

這些紀錄也能協助處理客訴與釐清物流責任。例如客戶反映「我明明改過地址，為什麼還寄到舊地址？」，就要查明改的是常用資料還是這張出貨單、修改發生在何時，再對照交付物流的時間與資料，才能還原處理過程。

因此，要先確認需要回答哪些問題，再決定保留哪些紀錄。若規格要求追查地址更動，就核對既有異動紀錄是否包含對應單據、修改前後內容、操作者與時間戳記。這些資訊可作為客訴查證與稽核的依據；保存配送資訊與保存修改過程，是兩個需要分別確認的需求。

不過，有異動紀錄不等於已具備不可否認性（Non-repudiation），也不等於已滿足所有合規要求。若需要證明某個操作確實由特定人執行，還要確認身分如何驗證、紀錄的完整性如何保護，以及是否能被事後竄改。不能只因為資料表多了操作者與時間，就認為證據已經充分。

AI可以閱讀規格、分析兩份資料的用途，也能協助調整結構與程式。工程師理解這些差別，才能具體討論：這次改的是常用資訊，還是某張單據？會影響未來建立的資料，還是既有紀錄？需要保留的是配送內容，還是每一次修改？

這些檢查把資料的用途、修改規則與實際行為連在一起，也讓我們有依據判斷AI提出的方案是否符合需求。

「下次要用的」叫常用資料，「這次在跑的」叫單據資料，「吵架要查的」叫異動紀錄。內容再怎麼像，也是三個不同的平行世界；搞混了，就是工程師和客服的惡夢。

「這個地址是誰改的？」
「我查一下。」
「查到了嗎？」
「查到了，最後修改時間是下午三點。」
「誰改的？」
「下午三點。」