Item Master 白話說明

日期：2026-03-19 目的：用最白話的方式說明這個專案真正要做的事，以及 barcode、通路資料、群眾蒐集各自扮演的角色。

一句話版

這個系統不是在做「barcode 主檔」，而是在做一本「發票名稱群組對到哪個商品」的對照字典。

你真正要解的題目

你真正要回答的不是：

• 這個網站上的 barcode 對不對。

而是：

• 這個發票名稱，最後應該對到哪個商品代碼。

所以主角是 發票名稱，不是 barcode。

barcode 為什麼不能直接當答案

barcode 很重要，但它不是最後答案，因為現況裡還有這些問題：

• 有些碼是店內碼、書碼、或 placeholder。
• 同一個碼可能被店家拿去標單品、組合包、箱購頁。
• 同一個碼在不同來源可能對到不同名稱或不同圖片。
• 有些商品根本沒有收回 barcode。

所以 barcode 比較像很強的證據，不是永遠唯一的真相。

BI / SI 是什麼

這套設計把商品分成兩層：

• BI：商品家族
• SI：可售版本

例子：

BI：白蘭氏雞精

SI-U001：白蘭氏雞精 單瓶
SI-B001：白蘭氏雞精 6 入組
SI-C001：白蘭氏雞精 24 入箱

白話講：

• BI 回答「這是什麼東西」
• SI 回答「消費者實際買的是哪一種版本」

你真正要審的是什麼

真正要審的是：

這個發票名稱群組，應該對到哪個 SI？

不是：

這筆通路網站資料本身有沒有百分之百正確。

通路名稱、barcode、圖片、crowd 回報，都是幫你做這個判斷的證據。

最簡單的流程圖

若要看多視角完整版，請改看 C16-architecture.md。

原始發票名稱
  ↓
把很像的名稱放成一群
  ↓
找 2 到 5 個最可能的候選商品
  ↓
看證據
  - barcode
  - 通路資料
  - 圖片
  - 群眾回報
  - 歷史已確認結果
  ↓
如果很明確，就決定 SI
如果不明確，就送人工或群眾確認
  ↓
寫回正式對照
發票名稱群組 -> SI

你原本的兩個思路怎麼看

1. 還沒有 barcode 時，用發票名稱做 ML

這個方向沒有錯，而且很合理。

它最適合做：

• 品牌辨識
• 品類辨識
• 同商家名稱聚類
• 候選生成

它不適合單獨當最後答案，因為發票名稱常常太短、太模糊、太依店家習慣。

2. 收到 barcode 後，把 PN-barcode 當 key

這個方向在過渡期也有用，但不適合直接拿來當最終 key。

它最適合做：

• 強證據連結
• 候選縮小
• 快速提高同商家場景下的命中率

它不適合直接當最終 key，因為同碼重用、組合包污染、錯掃錯拍都會讓它變脆弱。

brand 和 category 放在哪裡

也很重要，但它們不是身份。

• BI / SI 是身分證
• category 是貨架
• brand 是招牌

同一個商品可以放很多貨架，也可以被很多分類系統收納；這不代表它換了一個身份。

一句話收尾

先守住 發票名稱群組 -> SI 這個決策，再讓 barcode、通路、圖片、群眾蒐集去幫你支持這個決策，item master 才會越做越穩。