做電商的品牌，幾乎沒有例外，都會走到同一個坎：剛開站的時候商品沒幾支，SKU 想怎麼編就怎麼編，甚至直接拿廠商的料號來用也沒事。但只要生意做起來，顏色多了、尺寸多了、開始上第二個第三個通路，再加上換季改版、停產又復刻，原本那套隨手編的商品編碼就會開始反咬你——庫存明明有貨卻顯示缺貨、報表把兩支不同的品項算成同一支、廣告 feed 抓錯規格、客服查半天找不到客人買的到底是哪一款。
我在替國際品牌和台灣品牌做電商代營運時，接手新客戶第一件想看的，往往不是廣告成效，而是他們的商品主檔。因為商品結構是整個電商營運的地基，地基歪了，上面蓋的庫存、定價、頁面、廣告全都會跟著歪，而且越晚整理越貴。這篇文章我想把 SKU 架構與變體管理這件看似瑣碎、其實影響深遠的事完整拆開，從最基本的觀念一路講到可擴充的編碼規則、層級關係與跨通路整合，讓你在品項還沒爆炸之前，先把結構打好。
先分清楚：SKU、商品（Product）與變體（Variant）不是同一件事
很多亂象的源頭，是把 SKU、商品、變體這三個層次混為一談。先把定義釐清，後面才不會繼續錯下去。
商品（Product）是消費者認知裡的「那一款東西」，例如「經典款素T」。變體（Variant）是這款商品底下實際可選的規格組合，例如「黑色／M」「白色／L」，通常由一到多個屬性（顏色、尺寸、容量、口味）交叉組成。而 SKU（Stock Keeping Unit，庫存單位）則是最小的、可以獨立管理庫存與出貨的單位——原則上每一個變體，就對應一個唯一的 SKU。
換句話說，一款素T如果有 4 色 3 尺寸，那它是 1 個商品、12 個變體、12 個 SKU。庫存是記在 SKU 這一層的，因為你真正要盤點、要補貨、要出貨的，是「黑色 M」這個具體的東西，而不是「素T」這個抽象概念。這個層級關係聽起來理所當然，但實務上非常多品牌是把整款商品當一個 SKU 在管，或者反過來，同一個變體在不同通路各有一組編碼，導致庫存永遠對不齊。把這三層先切乾淨，是所有後續工作的前提。
品項一多就亂，通常亂在這四個地方
在正式談怎麼建之前，先認得亂象長什麼樣子，你才知道自己有沒有中。根據我接手的經驗，商品結構失控幾乎都是這四種問題的組合：
第一，SKU 命名沒有規則。有的品項用中文、有的用廠商料號、有的日期加流水號，同一個資料庫裡風格五花八門。人腦要靠記憶去對，系統要靠人工去查，只要負責的人一離職，這套「口耳相傳的規則」就斷了。
第二，同一支商品在多平台編碼不一致。Momo 一組碼、蝦皮一組碼、官網又一組碼，中間沒有一張對應表。結果就是總部想看「這款素T在所有通路一共賣了多少」，得靠人工比對貼標，一比就是半天，還常常比錯。
第三，變體拆錯造成庫存與報表混亂。最常見的是「該拆沒拆」和「不該拆亂拆」兩種極端。前者把不同顏色塞在同一個 SKU，庫存數字是一坨，根本不知道哪個色缺貨；後者則是把同一個實體品項因為包裝盒不同、贈品不同就硬拆成好幾個 SKU，結果庫存被切碎，明明總量夠卻各自顯示不足。
第四，停產品項沒清。舊款、季拋款、絕版品長年掛在商品主檔裡，也沒標記狀態，新人分不出哪些還在賣、哪些早就下架。商品清單越滾越肥，搜尋、報表、盤點全都被這些殭屍品項拖慢。
這四個問題有個共通點：它們在品項少的時候都不痛，痛的時候通常已經上百上千支，要回頭整理成本極高。所以正確的順序是趁早立規則，而不是等亂了再救。關於品項規模化之後的內容與資料維護，我在〈商品內容規模化〉裡有更完整的討論。
怎麼設計一套可擴充的 SKU 編碼規則
編碼規則是整個架構的核心，也是最多人做過頭或做不足的地方。我的原則只有一句話：讓 SKU 有意義，但不要過度編碼。
有意義，指的是光看編碼就能大致辨認這是什麼類別、什麼系列、什麼變體，方便人工快速判讀與揀貨。過度編碼，則是把太多會變動的資訊塞進碼裡——例如把價格、供應商、上架年份、行銷檔期通通編進去。這些資訊一旦異動，SKU 就得跟著改，而 SKU 一改，所有歷史訂單、報表、通路對應全部要重新接，等於自找麻煩。SKU 一旦產生就應該終身不變，這是鐵則。
一個實務上好用的結構，通常是「類別－系列／款號－變體屬性」的分段組合，各段用固定位數或分隔符切開。舉例來說，上衣類的某款素T黑色 M 號，可能長成類似 TS-CLA-BKM 這樣：前段標類別、中段標款、後段標顏色與尺寸。重點不在用什麼符號，而在於：
- 每一段的意義固定、位數固定，方便系統解析與排序。
- 屬性用代碼而非全名（黑色用 BK 不用 BLACK），縮短長度也統一格式。
- 預留擴充空間。類別碼、流水號的位數要抓寬一點，想像三年後品項成長十倍還夠不夠用，別讓自己兩年後就要換編碼系統。
- 不把會變動的東西編進去。價格、檔期、庫存狀態這些，交給欄位（attribute）去記，不要進碼。
還有一個常被忽略但極重要的東西：跨通路對應表。你的內部 SKU 是唯一真實來源，但各通路平台往往有自己的商品編號規則，甚至限制你能用的字元。所以你需要一張對照表，把「內部 SKU」對應到「Momo 商品編號」「蝦皮貨號」「官網 handle」「GTIN／條碼」。這張表就是你日後做多通路庫存同步、跨通路報表合併的關鍵樞紐，一開始就要當成正式資產在維護。多通路的庫存與編碼怎麼串，可以參考〈多通路庫存同步〉。
商品、變體、組合包的層級關係怎麼建
編碼規則搞定後，下一步是把層級關係立起來。一個健康的商品結構，至少要能清楚表達三層：商品層、變體層，以及組合包層。
商品層放的是共用資訊：品名、品類、品牌、共用的行銷文案與主圖。變體層放的是差異化資訊：顏色、尺寸、各自的 SKU、各自的庫存、可以各自不同的價格與圖片。這兩層的關係前面已經講清楚，一個商品下掛多個變體，庫存記在變體（SKU）這層。
真正容易出錯的是第三層——組合包（Bundle）。組合包是把多個既有 SKU 打包成一個對外販售的單位，例如「買素T送購物袋」的套組、或「三入優惠組」。這裡的關鍵觀念是：組合包本身應該有自己的銷售 SKU，但它不該獨立持有庫存，它的可售量要由底下組成的元件 SKU 動態算出來。也就是說，賣掉一組三入裝，系統要自動從那支素T的庫存扣三件，而不是另外開一個「三入裝」的獨立庫存去進貨盤點。
很多品牌就是在這裡把庫存搞爆的：把組合包當成一支獨立商品進貨，結果同一批實體貨被單品和組合包重複計算，帳面庫存永遠對不上實體。組合包一定要用「元件關係（BOM，物料清單概念）」去建，扣的是底層 SKU。把這層關係建對，促銷組合、季節套組才敢放心大量開。組合包的商業設計面，我另外寫在〈商品組合銷售策略〉。
主檔與單一真實來源：所有連動的起點
前面所有的努力，最後要收斂到一個核心觀念：商品主檔（Product Master）與單一真實來源（Single Source of Truth）。
意思是，一支 SKU 的所有基本資料——它是什麼、屬於哪個商品、什麼變體、條碼多少、對應各通路哪組碼——只能有一個權威來源，其他系統都從這裡讀，而不是各自維護一份。因為 SKU 不是孤立的，它會往外連動一長串：
- 庫存：SKU 是庫存扣減與盤點的最小單位，SKU 錯，庫存必錯。
- 定價：不同變體、不同通路的售價都掛在 SKU 上，價格政策才好統一管理。
- 商品頁：頁面上的規格選擇器（選顏色選尺寸）背後對應的就是變體與 SKU，拆錯了消費者會選到不存在的組合。
- 廣告與購物 feed：投放到 Google、Meta 的商品目錄，是用 SKU／GTIN 當識別。編碼不一致，feed 就會出現重複品項、比價錯亂、甚至被平台判定違規。
一旦有了單一真實來源，這些連動才有辦法自動化。反過來說，如果 SKU 資料散在 Excel、各平台後台、倉庫系統各一份，任何一次改動都要手動同步好幾個地方，人一忙就漏，錯誤就是這樣長出來的。這也是為什麼商品品項一到一定規模，就該認真評估用 ERP 或商品資訊管理系統把主檔集中起來，相關的選型考量我整理在〈如何選擇 ERP 系統〉。
上架前立規範，上架後管生命週期
好的結構不是建完就沒事，它需要兩套配套：上架前的規範，和上架後的生命週期管理。
上架前，要有一份明文的命名與分類規範。誰有權開新 SKU、編碼各段怎麼填、屬性代碼對照表在哪、新品類要不要先跟主檔負責人確認——這些都要寫下來，不能靠默契。我通常會建議客戶做一個簡單的「開品申請」流程，哪怕只是一張共用表單，也好過每個人各憑本事亂開。規範的價值在於，它讓正確變成預設，而不是靠個別員工的自律。
上架後，則要管品項的生命週期：新增、改版、停產。新增前面談過了。改版要特別小心一個判斷——什麼程度的改動算「同一支 SKU 的更新」，什麼程度算「該開一支新 SKU」。原則是：只要影響到庫存辨識或消費者選購的實體差異（例如配方改了、容量變了、尺寸規格不同），就該開新 SKU 並讓舊 SKU 走停產流程；如果只是文案、主圖、行銷包裝這類不影響實體辨識的調整，維持原 SKU 更新即可。
停產也不是把商品刪掉就好。刪掉會讓歷史訂單、報表失去對應。正確做法是給每支 SKU 一個明確的狀態（在售、停售、缺貨、已停產），停產的品項改狀態、下架、退出對外通路與 feed，但資料保留在主檔裡供歷史查詢。有了狀態欄位，商品清單就能隨時篩出「目前實際在賣的」，殭屍品項再也不會拖累報表與盤點。整個庫存與品項的日常維護節奏，可以延伸看〈電商庫存管理〉。
匿名實務案例：從一團亂到品項翻倍卻更好管
分享一個實際案例（品牌名稱這裡略去）。這是一個服飾配件品牌，我們接手時大約有 300 多支在售品項，同時掛在官網、Momo、蝦皮三個通路。
接手前的狀況大致是：SKU 命名混用中文品名和廠商料號，同一款商品在三個通路各有一組不同編碼、沒有對應表；很多顏色被塞在同一個 SKU 底下，庫存只有一個總數，客服常常無法確認客人買的是哪個色；組合套組被當成獨立商品進貨，庫存重複計算。當時光是月底要合併三通路的銷售報表，人工作業大約要花掉兩到三天，而且缺貨誤判（顯示有貨實際沒貨）每個月都會發生好幾次，退款和客訴跟著來。
我們做的事情，其實就是這篇文章講的那套：重新設計一套分段式編碼規則，把商品、變體、組合包三層切乾淨，一個變體對一個 SKU；建立內部 SKU 對三通路的對應表當單一真實來源；把所有組合套組改成用元件關係扣底層庫存；並替每支品項補上狀態欄位，把累積多年、大約上百支的停產殭屍品項一次清出在售清單。
整理完之後，過了大約一年，這個品牌的在售品項成長到 600 多支，幾乎翻倍。但因為結構是對的，月底跨通路報表從兩三天縮短到大約半天內就能產出，缺貨誤判的情況也大幅減少到偶爾才發生。這裡我想強調的重點不是那些數字級距本身，而是那個對比：品項數量翻倍、營運卻更輕鬆。這正是可擴充結構的價值——它讓你敢成長，因為你知道多開品項不會把自己埋掉。
常見問題 FAQ
Q：SKU 一定要有意義嗎？直接用流水號不行嗎？ 兩種做法都有人用。純流水號（無意義碼）的好處是絕不會因為資訊變動而需要改碼，交給系統管理最單純；缺點是人工揀貨、客服查詢時完全無法從碼判讀。實務上我偏好折衷：保留少量固定、不會變動的辨識段（類別、款），其餘交給流水號與屬性欄位。重點不是有沒有意義，而是別把會變動的東西編進碼裡。
Q：不同顏色、尺寸到底要不要各開一個 SKU？ 要。只要是消費者會分開選、你會分開盤點與出貨的實體差異，就該是獨立 SKU。把顏色尺寸塞在同一個 SKU，庫存就變成一坨無法辨識的總數，缺貨判斷和報表都會出問題。這是最常見也最該避免的錯誤。
Q：組合包（Bundle）該不該有自己的 SKU？ 組合包應該有自己的「銷售 SKU」用來對外販售與掛頁面，但它不該獨立持有庫存。它的可售量要由底下組成的元件 SKU 動態計算，賣出時扣的是元件庫存。若把組合包當獨立商品進貨盤點，就會造成同批實體貨被重複計算、帳實不符。
Q：商品改版了，要開新 SKU 還是更新舊的？ 判斷標準是有沒有影響「實體辨識」或「消費者選購」。配方、容量、規格這類實體變了，開新 SKU、舊的走停產；只是換文案、換主圖、換行銷包裝這類不影響辨識的，更新原 SKU 即可。拿捏這條線，才能兼顧歷史資料的連貫與品項的清爽。
Q：品項還很少，現在就花時間建這套會不會太早？ 恰恰相反，品項少的時候正是立規則的最佳時機，因為成本最低。等到上百上千支才回頭整理，要動到歷史訂單、報表與通路對應，工程浩大得多。趁早把編碼規則和層級關係定好，是最划算的投資。
Q：多通路編碼不一致，一定要導入系統才能解決嗎？ 不一定。核心不是工具，而是「有沒有一份單一真實來源」。品項不多時，一張維護良好的對應表（內部 SKU 對各通路編碼、條碼）就能撐一段時間。但當品項與通路數量到一定規模、手動同步開始頻繁出錯，就該認真評估用 ERP 或商品資訊管理系統把主檔集中、自動同步。工具是用來放大好結構的，不是拿來替代結構的。
結論
SKU 架構與變體管理，表面上是很技術、很瑣碎的事，實際上它決定了一個品牌能長多大。結構對了，你敢一直開新品、上新通路、做組合促銷，因為每多一支品項都被乾淨地接住；結構歪了，品項一多就處處是坑，庫存對不上、報表算不準、廣告 feed 亂跳，最後把團隊的時間全耗在救火上。
把這篇的重點收成幾句話：先分清楚商品、變體、SKU 三層；編碼有意義但別過度、產生後終身不變；組合包用元件關係扣底層庫存；所有資料收斂到單一真實來源；上架前立規範、上架後管生命週期。這些原則不難懂，難的是趁早做、持續守。如果你正打算擴品類、上多通路，或已經被亂掉的商品結構卡住，歡迎先看看我們的服務內容與實用工具，或直接聊聊你目前的狀況。
林克威長期協助國際品牌與台灣品牌進行電商代營運、品牌代理與通路拓展，累積超過十年實務經驗，服務涵蓋 Momo、PChome、蝦皮、LINE 禮物、品牌官網及實體零售通路。若您希望了解品牌進入台灣市場或電商成長策略，歡迎與我們聯繫。
