前幾天，我確認了平均分攤、零頭分配與輸入驗證。今天把情境拉回一場真正的聚會：吃完晚餐，還可能喝咖啡、搭計程車，途中又買了點心。分錢工具需要處理的，不只是一筆金額，而是一份會持續增加、修改與刪除的帳目清單。

目前的原型已經支援多筆支出，因此今天先不增加新功能，而是實際走過新增、編輯、取消及刪除的操作，確認支出清單、總金額、每個人的負擔與最後付款清單，都能一起更新。

我先使用原本的三筆範例作為基準。晚餐 1,200 元由小明代墊，三人平均分攤；咖啡 280 元由小美代墊，只有小明與小美參與；車資 350 元由阿哲代墊，三人分攤。總金額是 1,830 元，最後小美付小明 377 元，阿哲付小明 166 元，小明收回 543 元。

先確認基準很重要。如果一開始的帳就沒有核對，後面看到總額改變，只能知道畫面有更新，卻不知道更新得對不對。今天每個主要狀態都先準備預期數字，再拿程式與畫面結果來比較。

第一步新增一筆 300 元的點心，由小明代墊，三人各分攤 100 元。儲存後，支出從三筆變成四筆，總額增加到 2,130 元。小美應付 477 元，阿哲應付 266 元，小明應收回 743 元。這不只是把總額加上 300，也要同時更新小明的代墊金額，以及三個人的分攤。

接著把同一筆點心從 300 元改成 450 元。儲存後仍然是四筆支出，總額變成 2,280 元，這筆點心改為每人分攤 150 元。最後小美付小明 527 元，阿哲付小明 316 元，小明收回 843 元。筆數沒有增加，確認這次編輯是取代原本的支出，而不是又新增一筆。

編輯流程也需要測試取消。我再次打開點心支出，把金額改成 900 元，但按下取消。回到帳本後，這筆支出仍然是 450 元，總額維持 2,280 元。使用者在表單裡輸入的草稿，不應該在尚未儲存時就改變正式帳目。

刪除也分成兩種情況。我先按下刪除點心，畫面出現包含支出名稱的確認訊息，再選擇「先不要」。結果仍保留四筆支出與原本總額。接著重新操作，這次選擇確認，點心才從清單移除，帳目回到三筆、1,830 元，付款清單也回到小美付 377 元、阿哲付 166 元。

這讓我更清楚，刪除不是只讓一張卡片消失。那筆支出的代墊與分攤，也必須一起從結算中移除。否則畫面看起來少了一筆，下面的應收應付卻可能還保留舊數字。

為了避免只測最後一筆，我們接著刪除清單中間的咖啡。剩下晚餐與車資，總額是 1,550 元，小明應收回 683 元，小美應付 517 元，阿哲應付 166 元。刪掉咖啡後，小美不再有那筆代墊，同時也不用負擔咖啡的份額，所以她的淨額需要重新計算。

之後再刪除晚餐，只剩 350 元車資。這時收款人變成阿哲，小明與小美各付阿哲 117 元，阿哲自己負擔 116 元。這個案例確認了付款清單會隨整份帳目重新產生，不會一直保留原本由小明收款的結果。

刪除最後一筆車資後，帳本顯示零筆支出、總額零元，以及每個人已平衡的狀態，並提示可以新增第一筆支出。空帳本也必須是系統能處理的正常情況，不能留下舊的付款清單，或因為沒有資料就無法繼續操作。

最後，我在這個空帳本重新新增一筆 90 元支出，由小明代墊，三人各分攤 30 元。結果是一筆支出、總額 90 元，小美與阿哲各付小明 30 元。這確認了刪除所有支出後，帳本仍然可以繼續使用。

今天除了瀏覽器操作，也針對八種帳目狀態執行計算模組測試，全部通過。每種狀態都核對總額、每人的代墊、應分攤與淨額，並確認代墊合計及分攤合計都等於消費總額。最後再模擬依付款清單交付，檢查所有人的差額都能歸零。

瀏覽器部分共完成十個檢查點，包含原始帳目、新增、編輯、取消編輯、取消刪除、確認刪除、逐步刪到空帳本，以及重新新增。計算模組測試確認的是給定帳目下的結果，瀏覽器操作則補上按鈕、表單和畫面更新的驗證，兩者的範圍需要分開說明。

今天沒有修改產品程式，也沒有提交或發布新版，而是把既有多筆支出功能走得更完整。不過，這仍然是選定流程的驗證，尚未涵蓋所有付款人與參與者變更、自訂分攤操作、跨裝置測試或重新整理後的資料保存。目前帳目仍只保留在當前頁面。

這次讓我體會到，一個記帳工具的正確性，不只在按下第一次計算時。每次新增、修改、取消或刪除，都可能改變整份帳的結果。和 AI 合作時，把操作前後的筆數、總額與個人差額寫清楚，比只問「功能能不能用」更容易確認問題。

第十天完成了多筆支出的基本操作與重新結算驗證。下一天會聚焦不同人代墊的情境，進一步檢查每個人的已付款、應負擔與最後應收應付之間的關係。