專案正式上線體驗與開源倉庫

線上體驗 Live Demo：https://410355-collab.github.io/Premium-Business-Calculator/
(強烈建議使用 iPhone Safari 或 Android 手機開啟體驗！)

GitHub 開源倉庫：https://github.com/410355-collab/Premium-Business-Calculator
歡迎提出建議與指導
(開發環境：Google Antigravity IDE + Google Gemini 協同開發)

出國旅遊或日常記帳時，最令人煩惱的往往不是價格算不出來，而是記帳分類頻頻出錯。當你在東京的松本清買了果汁軟糖或伴手禮餅乾，許多記帳軟體單純看到糖果字樣就自動分類為餐飲支出；相反地，當你在松屋點了外帶便當回飯店吃，系統卻又因為外帶二字把它當成了購物。傳統記帳工具僅憑孤立的商品品名做關鍵字匹配，完全忽略了消費場景背後的真正意圖。

為了解決這個長年困擾記帳愛好者的痛點，我們在高階商務計算機的 ai-scan.js 模組中，設計了一套結合「店家屬性」與「食用時效」的雙維度語意判定演算法。即使發票上的品項五花八門，系統也能精準辨識出使用者究竟是在當下解決一餐，還是採買日常用品與伴手禮，讓記帳分析與後續匯出的報表具備最高水準的資料純淨度。

為什麼單看品名分類注定會失敗

在傳統記帳軟體的實作中，工程師通常只會針對提取出的文字進行簡單的詞彙匹配。只要字串中含有水、餅乾或糖果，就直接打上餐飲標籤；若是出現藥品、毛巾或衣服，則貼上購物標籤。這種單維度的字串判斷，在真實的跨國消費情境中存在致命的邏輯缺陷。

以最常見的日本旅遊為例，旅客走進大國藥妝或松本清，購物籃裡裝的往往除了眼藥水與合利他命之外，還順手抓了兩包抹茶 KitKat 與膠原蛋白軟糖。如果系統將軟糖歸類為當天的餐飲費用，這張整併記帳的報表就會瞬間失真，使用者甚至會疑惑自己今天明明只吃了拉麵，為什麼飲食開銷高達上千日圓。

同樣的情況也發生在咖啡廳與連鎖快餐店。使用者在星巴克購買咖啡時，收據明細上經常印有隨行杯、保溫瓶或濾掛包等商品名稱。若不結合開立發票的店家資訊綜合研判，單純依賴品名分類只會帶來無止境的手動修正負擔。

店家屬性權重覆蓋機制

為了解決上述情境矛盾，我們在 inferCategoryFromName 函式中引入了權重分級架構。演算法不再一開始就檢驗單一商品名稱，而是優先檢驗該張收據所屬的店家名稱與通路類型。

// ai-scan.js 核心判定流程
function inferCategoryFromName(name, storeName) {
    const s = String(storeName || '').toLowerCase();
    const n = String(name || '').toLowerCase();

    // 1. 若店家為藥妝店、免稅店、百貨公司 -> 優先歸類為 shopping
    if (/(藥妝|藥局|松本清|大國|sundrug|matsukiyo|donki|唐吉訶德|免稅|duty free|百貨|美妝|藥房)/.test(s)) {
        return 'shopping';
    }

    // 2. 若店家為餐廳、食堂、速食、咖啡廳 -> 歸類為 food
    if (/(松屋|吉野家|すき家|sukiya|一蘭|拉麵|麥當勞|肯德基|摩斯|摩斯漢堡|星巴克|starbucks|壽司|藏壽司|壽司郎|餐廳|食堂|居酒屋|カフェ|cafe|coffee|鐵板燒|火鍋|便當|麵店|燒肉)/.test(s)) {
        return 'food';
    }

    // 3. 次階規則：當店家屬性不明或為一般超商時，啟動細項品名語意解析
    // ...
}

當正規表達式命中藥妝、免稅或量販店的關鍵字時，無論使用者購買的是營養口嚼錠還是零食，演算法皆會將店家權重置於最頂層，強制將整筆支出錨定為購物屬性。這項設計徹底終結了藥妝店雜項商品被碎形拆分至餐飲類的混亂現象。

與此相對，當店家名稱包含松屋、吉野家、一蘭拉麵或各類咖啡餐酒館時，系統會立即判定這是一筆專注於解決當下生理需求的用餐消費。即使發票上印著加點的伴手禮盒或紀念便當盒，依然能穩定歸入餐飲支出，保證日常三餐統計的連貫性。

即時食用與商品時效的多重過濾網

當發票來源於一般便利超商（如 7-Eleven、全家）、無印良品或沒有明確通路名稱的獨立小店時，演算法便會自動降級至第三層的品名特徵深度辨識矩陣。此時，演算法的核心邏輯在於辨別該項目的實體屬性與使用壽命。

    // 3. 依據商品名稱與品項類型推斷
    if (/(藥|保健|維他命|維生素|化學|面膜|保養|洗面|眼藥水|軟膏|貼布|貼膏|補品)/.test(n)) {
        return 'shopping';
    }

    if (/(便當|餐|飯|麵|咖啡|茶|奶|鮮乳|牛乳|拿鐵|歐蕾|麵包|吐司|餅乾|糖|水|果汁|飲料|肉|菜|蛋|湯|酒|餐包|壽司|漢堡|薯條|沙拉|冰|點心|零食|排骨|雞腿|豬排|丼)/.test(n)) {
        return 'food';
    }

    if (/(衣|衫|褲|鞋|襪|帽|外套|裙|包|皮夾|內衣|皮帶|飾品|衛生紙|面紙|洗髮|沐浴|牙膏|牙刷|洗衣|清潔|紙巾|電池|燈泡|垃圾袋|掃把|拖把|碗|盤|洗碗|家飾|家具|購物|買|玩具|藥妝|化妝|紀念品|伴手禮)/.test(n)) {
        return 'shopping';
    }

    if (/(捷運|公車|高鐵|台鐵|車票|加油|汽油|柴油|停車|計程車|悠遊卡|一卡通|過路費|維修|機票|地鐵|JR|電鐵)/.test(n)) {
        return 'transport';
    }

    if (/(文具|筆|紙|影印|印表機|電腦|滑鼠|鍵盤|螢幕|發票|公務|辦公|碳粉|筆記|講義|書|課本|參考書|教材)/.test(n)) {
        return 'business';
    }

    return 'other';

在這套品名判定陣列中，我們將消耗時效極短的食品、鮮乳、便當與熱飲歸類為餐飲類別；而具有保存期限較長、耐用品特質或日用品特性的物件，如保養品、清潔用品、衣物與伴手禮包裝，則精確分流至購物類別。

此外，為了因應商務出差與跨城市移動情境，交通維度涵蓋了鐵路車票、計程車、加油與電子票證加值；商務維度則專門攔截影印耗材、文具辦公用品與電腦週邊，讓企業差旅報帳與個人生活消費彼此涇渭分明。

結構化落地與歷史紀錄連動

分類演算法不僅存在於純文字判斷階段，它更是連貫發票掃描、匯率折算與最終報表輸出的核心樞紐。當使用者的發票經過影像辨識或電子發票解碼後，系統會自動在記憶體物件中標註 category 屬性。

// 在辨識與匯入流程中動態套用智慧分類
const storeName = extractedData.store || '';
const catKey = item.category || inferCategoryFromName(item.name || '', storeName) || 'shopping';

// 注入歷史紀錄物件
const historyEntry = {
    id: Date.now(),
    type: 'invoice',
    category: catKey,
    store: storeName,
    amount: convertedAmount,
    currency: originalCurrency,
    timestamp: new Date().toISOString()
};

當這筆資料寫入 localStorage 並呈現在計算機的歷史明細卡片時，前端介面會依照這個分類代碼，即時渲染出對應的高對比晶體膠囊標籤。在後續點擊匯出 Excel 報表時，報表產生器即可直接引用這個分類代碼，透過試算表公式自動彙整出精緻的圓餅圖統計表，完全不需要使用者在匯出後耗費時間手動重新整理分類。

明日預告

當發票上的每一個品項都能被精確分類後，緊接著面臨的挑戰便是：如果一張在大型超市採買的長發票裡同時包含了十幾樣商品，直接一口氣全部塞進計算機的歷史紀錄裡，豈不是會讓整個記帳面板瞬間被長長的清單嚴重洗版？

在明天的文章中，我們將為大家揭曉一套兼顧細節與版面簡潔的發票聚合架構，深入解析多品項發票如何依據店家與時間自動凝聚為一張獨立卡片，並透過優雅的折疊面板讓所有外語細項在彈指之間隨需展開。