只追加的事件紀錄：錯了也不改，而是更正

一家連鎖品牌的會員資料，某天被發現有三百位會員的生日欄位全部變成同一天。大家開始追查：是誰改的？什麼時候改的？是人手動改的，還是某個 AI 助理在整理資料時順手改的？改之前的值是什麼？

如果這家公司的系統只保存「現在的資料」，這些問題幾乎沒有答案。資料就是現在這個樣子，至於它是怎麼變成這樣的，沒有人說得清楚。最多只能去翻某個人的聊天紀錄，或是去問那天值班的同事記不記得。

當越來越多工作交給 AI 處理，這類問題會越來越常見。AI 做事很快，一個晚上可以改上千筆資料；如果中間有一個小錯，它也會很快地把錯放大。我們需要的不是更小心的 AI，而是一份不會說謊的紀錄：每件事是誰做的、在什麼時候、用什麼權限、結果是什麼，而且這份紀錄本身不能被改。

這篇文章說明我們怎麼設計這份紀錄。它的核心規則只有一句話：只准追加。

只准追加，是什麼意思

一般的資料表，資料可以新增、修改、刪除。事件紀錄不一樣，它只允許一種動作：在最後面加上一筆新的事件。已經寫下的事件，不能修改，也不能刪除。

一筆事件代表一件已經發生的事。「建立了一份名單」、「名單加入一百二十人」、「排定週五晚上八點寄出」、「寄出完成」，每一句都是一筆事件。它們依照發生的順序排成一列，就像一本只能往後寫的帳簿。

這個規則看起來很嚴格，甚至有點不方便：如果真的寫錯了怎麼辦？但正是這個不方便，讓紀錄變得可信。一份可以被修改的紀錄，你永遠不知道它是不是被修改過。一份只能追加的紀錄，你看到的就是事情發生的順序，不多也不少。

只准追加還有一個常被忽略的好處：多個寫入者可以同時工作而不互相覆蓋。兩個 AI 同時在處理同一份名單時，如果大家都直接改「現在的資料」，後寫的那一個會把前一個的修改蓋掉，而且沒有人知道。如果大家都只是往紀錄後面追加事件，兩邊的動作都會被保留下來，順序也清清楚楚，衝突可以被看見、被處理，而不是悄悄消失。

寫錯了，不改，而是更正

人會寫錯，AI 也會。只准追加，並不是假裝錯誤不存在，而是用另一種方式處理它。

假設第三筆事件把寄送時間寫成了週五早上八點，正確應該是晚上八點。我們不會回頭把那一筆改掉，而是在最後面追加一筆新的事件：「更正第三筆，寄送時間應為週五晚上八點，原因是輸入時把早晚寫反」。這筆更正事件會明確指向它要更正的那一筆。

這樣做有幾個好處。第一，錯誤本身被保留下來，日後可以分析為什麼會寫錯，是表單設計不清楚，還是某個 AI 的規則有漏洞。第二，誰在什麼時候發現錯誤、怎麼更正的，也一併被記下來。第三，任何讀紀錄的人或程式，只要遇到更正事件，就知道要以更正後的值為準，不需要額外的判斷。

在日常裡，這和會計的做法很像。帳記錯了，會計不會用修正液塗掉，而是開一筆沖銷分錄，把錯的抵掉，再記一筆正確的。帳簿上兩筆都看得到，帳卻是對的。

更正事件本身也是一筆普通的事件，同樣要記下是誰、在什麼時候、依據什麼權限更正的。如果更正也寫錯了，就再追加一筆更正去更正它。聽起來有點囉嗦，但實際上這種情況很少發生，而且每一層都清楚可查，比起一份被改過好幾次卻看不出痕跡的資料，要讓人放心得多。

每一筆要記下什麼

一筆事件不只寫「發生了什麼」。為了讓日後能回答問題，我們要求每一筆至少包含這幾件事：

• 誰：做這件事的是哪一個人，或是哪一個 AI、代表哪一個人在做。
• 何時：精確的時間，而不是「今天下午」。
• 用什麼權限：當時是根據哪一項授權或哪一張裁決卡做的。
• 做了什麼：動作的種類與對象，例如「在會員名單加入一百二十人」。
• 結果：成功、失敗，或是結果不明。

其中最容易被忽略的是「用什麼權限」。很多紀錄只寫誰做了什麼，卻沒有寫他為什麼可以做。等到出問題時，大家才發現沒辦法區分「依規則做的」和「沒經過同意就做的」。把權限一起記下，紀錄就從單純的流水帳，變成可以拿來檢查的證據。

另一個重點是：被拒絕的請求也要記。如果一個 AI 想改會員資料，但被權限擋下來，這件事同樣寫成一筆事件。被擋下來的次數突然變多，往往是某個地方出了問題的第一個訊號。

我們也讓這些欄位的名稱，盡量對齊業界通用的寫法，而不是自己發明一套。這樣日後要把紀錄接到別的工具上分析，不需要先翻譯一遍。

有了這些欄位，很多日常問題都能直接從紀錄裡回答，而不必去問人。例如「這份名單最後一次被誰改過」、「上週有哪些對外動作還沒有結果」、「某個 AI 這個月總共被擋下幾次」。紀錄寫得越一致，這些問題就越容易被一個簡單的查詢回答。

每一筆都帶著前一筆的指紋

只准追加是一條規則，但規則可能被違反。如果有人直接打開檔案，偷偷改掉中間某一筆，要怎麼發現？

我們的方法是讓每一筆事件都帶著前一筆的指紋。指紋是一段由內容計算出來的短字串，內容只要變動一個字，算出來的指紋就完全不同。第 n 筆事件除了自己的內容，還會記下第 n−1 筆的指紋，然後再算出自己的指紋，交給第 n＋1 筆。

這樣一來，每一筆都被後面那一筆「鎖住」。如果有人改了第五筆，第五筆的指紋就變了，第六筆記著的舊指紋就對不上；要掩蓋，就得連第六筆一起改，接著是第七筆，一路改到最後。只要有一份檢查程式定期從頭走一遍，或者把最新一筆的指紋另外存一份，任何一次偷改都會被發現。

這個做法不需要複雜的設備，也不是什麼新技術，很多版本管理工具和帳本系統都用了類似的原理。它的價值在於，紀錄可不可信，不再取決於「大家都很守規矩」，而是可以被程式檢查出來。

指紋還有另一個用途：確認內容沒有在核准之後被換掉。當一張裁決卡同意寄出某一版促銷信時，紀錄裡會寫下那一版內容的指紋。真正寄出時，再算一次指紋比對；如果有人在中間偷偷改了文案，兩個指紋就會不同，寄送會被擋下來，等人重新確認。

從事件重播出現況

事件紀錄存在的目的，不只是出事時拿來追查。它還有一個每天都用得到的作用：重建現況。

因為每件事都被記成事件，所以只要從第一筆開始，依序套用每一筆，就能算出任何一個時間點的狀態：這個工作做到哪裡、現在由誰持有、哪些對外動作還在等結果。遇到更正事件，就套用更正後的值。這個過程叫做重播。

重播帶來兩個好處。第一，現況不會和紀錄不一致，因為現況本來就是從紀錄算出來的。我們不需要另外維護一份「目前狀態」的表格，再擔心它有沒有忘記更新。第二，當新的 AI 或新的同事接手工作，它不需要問前一個人做到哪，只要讀紀錄、重播一次，就知道現在的狀態。

回到開頭那三百位會員的生日。如果有這樣的紀錄，追查只需要幾分鐘：找出生日欄位被改動的那幾筆事件，看是誰、在什麼時候、依據什麼權限做的，再看改之前的值是什麼。要復原，也只要追加一批更正事件，把值改回來，並寫明原因。

重播也讓「試算」變得容易。想知道如果某一筆事件沒有發生，現在會是什麼樣子，只要在重播時跳過那一筆就好。想知道上個月底某個工作的狀態，就重播到那一天為止。這些問題在只保存現況的系統裡很難回答，在事件紀錄裡卻只是換一個停止點。

敏感內容只記編號與指紋

紀錄越完整，越有可能把不該記的東西也記進去。客戶的合約條款、會員的聯絡方式、內部的報價，如果原文寫進事件紀錄，紀錄本身就變成一個需要嚴格保護的地方，而且因為只准追加，寫進去之後也刪不掉。

所以我們依資料的敏感程度決定紀錄怎麼寫。公開或內部的資料，可以直接記內容；機密的資料，事件裡只記它的編號和指紋，不記原文；最敏感的資料，則完全不進入事件紀錄。

只記編號與指紋，仍然足以回答大部分的問題：哪一份文件在什麼時候被誰動過、動過之後內容是不是和核准時一樣。真正的內容則留在有權限控管的地方，需要時再依權限調閱。

這個安排要在設計紀錄的第一天就決定，而不是等到出事才補救。因為紀錄只准追加，任何一次不小心把機密原文寫進去，事後都很難乾淨地處理。所以我們讓寫入紀錄的程式自己檢查資料等級，等級不符的內容在寫入前就被擋下，而不是依賴每一個寫入者記得這條規則。

誠實面對紀錄的邊界

我們也想坦白說明一件事：事件紀錄只能記下經過它的動作。透過統一入口執行的每一個動作，都會自動留下事件；但如果有人或某個 AI 繞過入口，直接修改檔案，紀錄就看不到。

對這種缺口，我們不假裝它不存在。我們把它明確列出來，一方面用定期的檢查比對檔案的實際狀態和紀錄重播出來的狀態，兩者不一致就提出警示；另一方面持續把更多動作收進統一入口。紀錄的價值，來自於它說的都是真的，也包括它說清楚自己沒看到什麼。

紀錄不怕寫錯，怕的是被悄悄改掉。

重點回顧

• 事件紀錄只准追加；寫錯了就追加一筆更正事件，指向原本那一筆並寫明原因。
• 每一筆記下誰、何時、用什麼權限、做了什麼、結果如何，被拒絕的請求也要記。
• 每一筆帶著前一筆的指紋串成一條鏈，偷改任何一筆都能被程式發現。
• 現況由事件重播算出，接手的人讀紀錄就知道狀態；機密內容只記編號與指紋。