昨天確認了不同人代墊的計算，今天接著處理另一個常見情境：大家一起出門，不代表每個人都參與每一筆消費。有人沒有喝咖啡，有人提早離開沒有搭車，如果直接把所有費用除以帳本總人數，帳雖然能平衡，卻不符合實際情況。

因此，今天要確認的是每筆支出自己的參與名單。帳本成員代表這次一起記帳的人，支出參與者則代表需要負擔這筆費用的人。兩者可以不同，而且修改某一筆的參與者，不應該改變其他支出的分攤。

原型已經有勾選參與者的功能，所以今天以既有功能驗證為主。我請 AI 協助檢查計算邏輯，再實際操作瀏覽器，核對增加、移除參與者與沒有選任何人的結果。

先使用三筆範例：晚餐 1,200 元三人均分，咖啡 280 元只有小明與小美參與，車資 350 元三人分攤。咖啡由小美代墊，小明與小美各負擔 140 元，阿哲不負擔咖啡費用。不過，阿哲仍然參與晚餐和車資，因此整本帳中的應分攤並不是零。

這個差別很重要。「不分這筆」不等於「整本帳不用付錢」。檢查結果時，除了看每個人的總額，也需要回到支出明細，確認費用到底來自哪幾筆。

第一個操作是在咖啡的編輯表單中勾選阿哲，讓三人一起分攤。儲存後，280 元依固定成員順序分成 94、93、93 元。總消費仍是 1,830 元，付款人也沒有改變，但三人的負擔重新分配，最後變成小明應收 589 元、小美應付 330 元、阿哲應付 259 元。

接著取消阿哲的勾選，再次儲存。咖啡回到小明與小美各 140 元，整本帳的結算也回到小明應收 543 元、小美應付 377 元、阿哲應付 166 元。這確認了移除參與者時，原本分給他的費用會重新分配，不會遺留在舊結果裡。

另一個案例是，保留小美為付款人，但把她從咖啡的參與名單移除，只留下小明。這時咖啡的 280 元全部由小明負擔，小美只是代墊。儲存後，整本帳顯示小明應收 403 元、小美應付 237 元、阿哲應付 166 元，符合逐筆加總的結果。

如果只看咖啡這一筆，小明需要還小美 280 元；但整本帳還有小明代墊的晚餐，因此抵銷後仍然是小美付錢給小明。這也再次提醒我，單筆分攤和整本帳的付款清單回答的是不同問題，不能只拿其中一筆的關係判斷最終結果。

接著，我把最後一位參與者也取消，嘗試儲存空名單。系統顯示「請至少選一位分攤成員」，沒有關閉表單。取消編輯回到帳本後，咖啡仍維持原本由小明一人分攤，總額與結算也沒有被錯誤輸入覆蓋。

之後重新打開表單，使用「全部選取」並儲存，咖啡成功恢復為三人分攤的 94、93、93 元。這確認了使用者遇到錯誤後，仍然能修正名單、繼續完成操作。

計算模組部分，今天共執行十一項測試，全部通過。除了兩人、三人與單人分攤，也包含付款人不參與、反向輸入參與名單、只有付款人參與、一元由兩人分攤，以及空名單、重複成員和不存在成員的拒絕處理。

反向輸入名單的案例，使用 101 元由小明與阿哲分攤。不論傳入順序如何，結果都依帳本順序分成小明 51 元、阿哲 50 元，小美不分攤。這確認零頭規則只作用在本筆參與者身上，也不會因為參與名單的輸入順序改變而換人負擔。

如果只有付款人自己參與，則由他負擔全部金額，該筆不會產生需要還給別人的差額。另一方面，一元由兩人分攤時，其中一人的份額可以是零。因此，「分到零元」也不一定代表沒有參與，還要看該筆名單與零頭規則。

我們也另外驗證，只改咖啡的參與者，晚餐與車資的分攤結果保持不變。整本帳的總額仍為 1,830 元，變動的是各人的應分攤與淨額。這比只確認三個數字加起來正確，更能確定修改沒有影響其他支出。

瀏覽器共完成七個檢查點，涵蓋原始兩人分攤、加入第三人、移除第三人、付款人退出後的單人分攤、空名單阻擋、取消後保留原帳，以及全部選取後儲存。其他邊界案例是在計算模組中驗證，並不代表所有畫面組合都已經測試過。

第十二天沒有修改產品程式，也沒有提交或發布新版。今天確認的是既有平均分攤功能中的參與者選擇；自訂金額、資料保存與跨裝置完整測試不在本日完成範圍內。

這次讓我更清楚，分錢系統需要先知道「誰參與」，才能回答「每人多少」。和 AI 協作時，把帳本成員、付款人和支出參與者分開描述，才能避免看起來合理、實際上卻把沒消費的人也算進去。下一天會處理自訂分攤，讓同一筆消費中的每個人可以負擔不同金額。