昨天，我用一場完整的模擬聚餐確認了單帳本流程。今天開始處理更接近日常使用的問題：週末聚餐還沒結清，下週旅行又要開始記帳，兩組費用應該怎麼分開？原本的「開一本新帳」會清除目前頁面的帳目，並不能保留多場活動。這次的目標，就是讓每本帳有自己的名稱、成員與支出，切換時不會混在一起。

這次我請 AI 完成第十六天的功能、文章與 Notion 紀錄，也希望看到現在專案的樣子。實作延續既有純前端版本，在畫面上加入「我的小帳本」選單與「修改帳本名稱」按鈕。按下「開一本新帳」後會先輸入名稱，成功建立時切換到新帳本，原本那本則留在選單中。新帳本從「我」這位成員和零筆支出開始，可以再加入同行夥伴。

這裡有一個需要說清楚的差別：切換後保留資料，和重新整理後還能保留資料，是兩件事。今天完成的是同一個頁面開啟期間的多帳本管理，資料仍在記憶體中。重新整理後依然回到範例，尚未寫入本機儲存。畫面在帳本選單附近直接提醒這件事，避免使用者以為帳目已經保存。

為了把不同帳本分開，我新增了 books.js，讓帳本管理與原本的畫面、計算邏輯分工。每本帳包含自己的 ID、名稱、成員清單與支出清單，另外記錄目前正在查看哪一本帳。切換時依帳本 ID 取得對應資料，因此兩本帳即使都有叫小美的成員，也不會共用同一筆成員資料。

今天另一個重要改動，是讓成員擁有穩定 ID。原型之前以姓名表示付款人與分攤對象，如果日後改名字，所有相關支出也得一起修改。現在帳本內部把付款人記成 payerId，參與者記成 participantIds，自訂分攤金額也以成員 ID 對應。姓名負責顯示，ID 負責辨認同一位成員。

為了讓這個設計能真正被使用，我也加上修改夥伴姓名的按鈕。改名時，只修改成員的顯示名稱，支出原本記住的 ID 不變。就算這個人已經代墊款項、參與多筆支出，仍然可以改名；移除已有支出的成員則繼續受到保護，必須先處理相關帳目。相同帳本內仍不允許重複姓名，避免目前表單與畫面產生混淆。

這次沒有把已經驗證過的分攤演算法整個重寫。帳本模組保存 ID 形式的資料，再產生供現有畫面與計算模組使用的姓名資料。從畫面提交變更時，會先驗證整份帳目，再把姓名轉回成員 ID。這讓原本的平均分攤、自訂分攤和淨額結算可以繼續使用，也把帳本資料與畫面資料之間的轉換集中在同一個地方。

我用一個自訂分攤案例檢查改名。聚餐帳中，我先付一百元，自己負擔三十元，小美負擔七十元。把「我」改成「瑞秋」後，付款人、參與者與自訂金額仍指向原本的成員 ID，結算維持瑞秋應收七十元、小美應付七十元。把畫面資料再次提交回帳本後，原本成員 ID 與支出內容也保持一致。

接著建立旅行帳，同樣放入瑞秋與小美，確認新帳的成員 ID 和聚餐帳不同。旅行帳加入三百元車票，再修改為五百元、最後刪除，聚餐帳的一百元支出都沒有受到影響。來回切換也能取得各自正確的總額。這些是直接執行帳本模組的測試，不能把它描述成已經在瀏覽器點按完成。

除了正常流程，測試也包含空白或過長帳名、重複與空白姓名、無效付款人、切換不存在的帳本，以及取得資料副本後修改陣列是否污染原始帳目。移除沒有支出的成員再加入同名成員時，也會產生新的 ID。目前設定每頁最多三十本帳本，每本延續一到五十位成員、最多五百筆支出的限制；超過帳本上限會保留原資料並回報錯誤。

本次十三項帳本測試全部通過，並重新執行第十五天的六種帳目狀態與錯誤自訂加總驗證，確認既有計算結果維持正確。JavaScript 語法檢查及 Git 差異格式檢查也通過，本機預覽頁回應正常。不過，這次工具沒有可連線的瀏覽器控制介面，因此尚未完成新版介面的實際點按與視覺驗收；這項限制會保留在進度紀錄，不能以模組測試取代。

目前專案已從單帳本原型進一步加入多帳本建立、命名、切換，以及成員改名。原本的多筆支出、不同代墊者、指定參與者、平均與自訂分攤、淨額付款清單仍保留。介面延續柔和中性色與圓角卡片，新帳本區放在成員區上方，讓人先確認正在記哪一場活動，再往下操作。

今天的程式變更留在本機工作區，沒有提交、推送 Git 或部署到先前網站。文章已整理到 Notion；當日狀態記為實作與模組驗證完成、瀏覽器驗收待補。接下來可以開啟本機預覽，依序建立旅行帳、加一筆車票，再切回聚餐帳，補完實際畫面的驗收。

第十七天會處理「重新整理後，帳目還在」，將這些帳本、成員 ID 與支出資料一起保存，並考慮資料版本及載入失敗時的處理。把帳本分開只是第一步，讓使用者關掉頁面後還能找回資料，才會更接近真正能持續使用的分錢工具。