unoPIM + Shopify B2B 實戰案例：Tenten 如何重建 15 年老 PHP PIM，打造 AI-Native Agentic B2B Commerce 堆疊

在這份 unoPIM Shopify B2B 案例記錄裡，Tenten 協助客戶用了 15 年的 PHP 老 PIM 換成 AI 原生的 unoPIM + Shopify B2B 架構，讓這家 2002 年創立、在美國服務過 26,000 家客戶、連線超過 100 萬台設備的工業電腦與 IIoT 經銷商，從「每天靠 Excel 和郵件跑單」的老式 B2B 升級成能跟 ChatGPT、Claude、Perplexity 直接對話的 Agentic Commerce 端點。切換點很準：Shopify 在 2026 年 4 月 2 日把 B2B 原生功能開放給所有付費方案，1 月 11 日 Shopify 和 Google 一起在 NRF 發表 Universal Commerce Protocol (UCP)，3 月 24 日 Agentic Storefronts 對美國 550 萬家商店預設開啟。這篇文章記錄的是 Tenten 怎麼把這些時間線接到一家真實工業客戶的骨幹上。

起點：四個商店、兩千個 SKU、一份 15 年前的 PHP PIM

這四條線背後共用一份產品資料：一套 2010 年左右寫的 PHP PIM，跑在 MySQL 5.5 上，沒有版本控制也沒有屬性繼承。單一產品在 MOXA 的規格表（含認證、工作溫度、認證號）跟 Neousys 的 GPU 平台規格差異非常大，Product Manager 在每次新品上架時要手動在四個後台重複貼規格、傳圖片、更新價格。

我們開始評估這個案子時，列出的硬痛點有六個：

1. 資料重複率超過 60%：同一顆 Intel Core Ultra 200S 處理器，在 ipc、solutions、neousys 三個商店有三份略有差異的描述
2. 圖片路徑硬編：15 年累積下來的商品圖直接塞在 /uploads/2013/products/ 之類的檔案結構，沒有 DAM 層
3. 認證資料跟規格分家：MIL-STD-810G、ATEX、IP 等級寫在自由文字欄位裡，搜尋與篩選完全靠 LIKE 查詢
4. B2B 折扣寫死在資料庫：經銷商分級（SI / OEM / EPC / Reseller / Gov）的折扣存在 user_discount 表，業務改一次要工程介入
5. 沒有 API：客戶的採購系統（ERP、eProcurement）要串，只能靠 CSV 匯出
6. 沒有多語言：PHP 檔裡直接寫英文字串，要做西語、日語版就得整份複製

這是典型的「能跑，但每多 10% 營收就要多請一個人手」的架構。營運長把我們找進去的理由就是這個：他們即將導入 Shopify B2B 的原生 Company Accounts 來支援批發客戶自助下單，但沒有一個乾淨的 PIM 可以把四個 storefront 的資料對齊。

為什麼選 unoPIM，不選 Akeneo 或 Pimcore

評估 PIM 時我們看了三套開源方案，選型邏輯很簡單：客戶的工程團隊長期用 PHP，新的 PIM 要能在現有運維體系裡活下來；同時要能接 Anthropic 和 OpenAI 的 API，不然未來三年做 agentic 會很痛。

決定性的因素是第四列：unoPIM 2026 年的版本已經把 Agentic PIM 做進核心，包括自動商品內容豐富化（Autonomous product enrichment）、目錄品質監控、審批工作流、內容回饋迴圈、持久化 agent 記憶。這些在 Akeneo CE 要另外買 App Store 模組拼湊，在 Pimcore 則要自己寫外掛。對一個要在 12 週內完成遷移的專案來說，agent 能力「開箱即用」的價值非常大。

Pimcore 的 DAM 整合比較成熟，但 unoPIM 有 DAM 模組而且持續更新，加上工業電腦的圖片資產遠少於時尚零售，DAM 的 delta 不足以讓我們選 Pimcore。Akeneo CE 則因為社群版缺了太多企業需要的功能（產品變體管理、批次操作的限制、沒有原生的 Shopify 雙向同步），被我們在第三週就排除了。

我們蓋的整體架構：PIM 當真相來源，Shopify B2B 當交易層，Agent 當營運員

用一張架構圖來看比較直觀。unoPIM 作為中央真相來源，往下連到四個 Shopify Plus 商店；agent 層同時連 unoPIM 和 Shopify，透過 MCP 協定跟外部的 AI 客戶端（ChatGPT、Claude、Perplexity）對話。

┌───────────────────────────────────────────────────────────┐
│                     AI Agent Layer                         │
│  Claude / GPT / Perplexity / OpenClaw (Tenten internal)   │
└───────────────────┬───────────────────────────────────────┘
                    │ MCP (Model Context Protocol)
        ┌───────────┴───────────┐
        │                       │
┌───────▼────────┐      ┌───────▼────────────┐
│  unoPIM MCP    │      │ Shopify MCP Servers│
│  (custom-built)│      │ Dev / Catalog /    │
│                │      │ Storefront /       │
│  32+ tools:    │      │ Checkout           │
│  search/create/│      │                    │
│  enrich/export │      │                    │
└───────┬────────┘      └────────┬───────────┘
        │                        │
┌───────▼────────────────────────▼──────────┐
│            unoPIM (source of truth)        │
│  Laravel 12 · MySQL 8 · Redis · Vue 3      │
│  Agentic PIM Core · DAM · 30+ locales      │
└───────────────────┬────────────────────────┘
                    │ unoPIM Shopify Connector
    ┌───────┬───────┼───────┬────────┐
    ▼       ▼       ▼       ▼        ▼
┌──────┐┌──────┐┌──────┐┌──────────┐
│shop- ││neou- ││ipc   ││solutions │
│moxa  ││sys   ││      ││          │
│Plus  ││Plus  ││Adv   ││Adv       │
└──────┘└──────┘└──────┘└──────────┘
   └───────┴── Shopify B2B: Company Accounts, Custom Catalogs

三層的職責拆得很乾淨：

• unoPIM：唯一的商品規格、圖片、認證、多語描述來源。所有屬性都有結構化 schema，包括 MIL-STD-810G、ATEX、IP67、CE、FCC、UKCA 等認證欄位，以及工作溫度、MTBF、輸入電壓、I/O 介面數量等技術規格
• Shopify B2B：交易層。依客戶類型（SI、OEM、EPC、Gov、Reseller）產生對應的 Company Profile，每家公司可以有多個 Location（總公司、分支、倉庫），每個 Location 可掛到專屬 Custom Catalog
• Agent 層：不直接存資料，只透過 MCP 呼叫 unoPIM 和 Shopify 的能力

Shopify 在 2026 年 4 月把 B2B 拉到 Basic、Grow、Advanced 三個方案，每個方案最多 3 個 catalog；想要無上限 catalog 和 per-location 直接指派，就得跑 Plus。如果你想自己試算，我們寫過的 Shopify B2B 全面指南 把各方案的界線列得比較完整。

12 週的遷移：不是重寫，是 agent 帶人做

Tenten 這幾年做過的遷移專案，從 BigCommerce 到 Shopify 的 OpenClaw agentic 遷移 到 Webflow 靜態頁轉 Shopify Theme，我們學到一件事：AI 可以把遷移專案的時間砍掉一半以上，但前提是你願意把 AI 當成資深同事來安排工作，不是當成腳本跑。分成六個 sprint：

Sprint 1（週 1–2）：Schema 考古

讓 Claude Code 跑過整份 15 年 PHP PIM 原始碼，建出一份 ER 圖和 attribute inventory。我們發現 1,847 個 SKU 中有 31% 的欄位實際從來沒被填過，56% 的商品描述是從 MOXA 原廠 PDF 複製後用 regex 清洗的產物。這份盤點直接決定了 unoPIM 的 Family / Attribute Group 設計。

Sprint 2（週 3–4）：unoPIM schema 建構

設計了七個 Product Family：

• Industrial Ethernet Switch（MOXA EDS、SDS、TSN 系列）
• Industrial Computer Rugged（Moxa BXP、DRP、Neousys Nuvo）
• Industrial IoT Gateway（UC、AIG）
• Industrial Wireless（AWK、OnCell、Cellular）
• Storage & Memory（Innodisk SSD、DRAM）
• Industrial Accessories（Cables、PoE、Power）
• Solution Bundles（BMS、EPMS、DCIM 整案）

每個 Family 下的 attribute 數量從 48 到 112 不等，其中「認證」這個 group 是所有 Family 共用的 11 個布林＋文字欄位（MIL-STD-810G、IP67、ATEX、CE、FCC、UKCA、UL、EN 50155、IEC 61850-3、DNV、TÜV）。

Sprint 3（週 5–6）：AI 豐富化

這是 unoPIM 2026 版最加分的地方。我們配置了 Claude Sonnet 4.7 當主要 enrichment agent（透過 Anthropic API），Ollama + Qwen 3 做本地 fallback。Agent 的任務清單包括：

• 讀 MOXA 原廠 datasheet PDF（OCR 後的 markdown），抽出結構化規格
• 根據工作溫度、認證組合、I/O 配置，產出 GEO 友善的 long description（800–1,200 字）
• 產出三個長度的 short description（80 / 160 / 280 字元）對應不同通路
• 根據 AEO 檢查表產出 FAQ 三題、Answer Target Block 一段
• 比對同系列產品，找出 cross-sell 建議

關鍵是我們沒讓 agent 自動提交——所有產出走 unoPIM 的 Maker-Checker Workflow，由 Product Manager 審過才會進正式目錄。這個節流設計避開了 agent 幻覺導致規格錯誤的風險（工業客戶對這件事非常敏感——一個輸入電壓寫錯可能燒掉客戶的現場設備）。

Sprint 4（週 7–8）：Shopify B2B 設定

四家店都跑 Shopify CLI 本地開發（為什麼 Shopify CLI 能把開發效率拉起來，我們另外寫過一篇）。B2B 層的設計：

• 以 CRM 資料為準，預建 340 家 Company Profile，分 SI / OEM / EPC / Gov / Reseller 五個 tier
• Plus 店（shopmoxa、neousys）每家建了 11 個 catalog 對應不同折扣級距
• Advanced 店（ipc、solutions）的三個 catalog 分別對應「一般 Reseller」、「大額客戶」、「政府標案」
• 支付方式：信用卡 + Net 30/45/60 + ACH + Wire Transfer，所有 B2B checkout 要求 PO Number

Sprint 5（週 9–10）：unoPIM → Shopify 同步

用 unoPIM 官方 Shopify Connector 做初始 bulk export，1,847 個 SKU 分 14 個 queue batch 推上去，單店同步時間平均 52 分鐘。之後改成事件驅動：unoPIM 任一商品屬性變動，透過 Laravel Queue + Webhook 推到 Shopify GraphQL Admin API。

Sprint 6（週 11–12）：Agent 上線

把 unoPIM 包成一個內部 MCP server（程式碼走 Anthropic MCP SDK 的 Node 實作），讓內部的 OpenClaw agent 和銷售團隊的 Claude Desktop 可以使用。同時在 Shopify 側接上 Shopify Storefront MCP，讓 ChatGPT 和 Perplexity 能在 Agentic Storefronts 啟用後找到商品。

Shopify B2B 的 MCP 生態：為什麼 agentic commerce 不只是 chatbot

這一層很多人搞混。把 ChatGPT widget 嵌在店裡叫「chatbot」；把商店做成 AI agent 能透過協定直接操作的端點，才叫「agentic commerce」。兩者架構不一樣。

Shopify 從 2025 下半年起，用半年時間蓋了四個 MCP server：

Shopify 同時跟 Google 在 NRF 2026（1 月 11 日）一起公布 Universal Commerce Protocol (UCP)，定義 agent、merchant、支付服務商、身分服務商之間的共同語言。Shopify 的 Checkout MCP 就是 UCP 跑在 MCP 傳輸層上的實作。2026 年 3 月 24 日，Shopify 對所有合格的美國商店預設啟用 Agentic Storefronts，把 550 萬家商店接到 ChatGPT 的 8.8 億月活用戶。

這次專案的核心價值在於：它是工業 B2B，不是 DTC。當一個工程師在半夜兩點跟 Claude 說「幫我找一台能在 -40°C 運作、通過 IEC 61850-3 認證、支援 16 個乙太網口的交換器，要求 12 週內能到美國西岸」，agent 透過 Catalog MCP 可以直接查到 shopmoxa 的 MOXA PT-G7828 系列，透過 Storefront MCP 查庫存，透過 Checkout MCP 開 draft order（B2B 的話可以附 PO Number 和 Net 30）。這整個流程不需要 BDR 介入，但因為是 B2B 大額（單筆 5,000–120,000 美元，draft order 會回到業務手上審核才變成正式訂單。

這是工業 B2B 在 agentic commerce 裡的真正角色：不是全自動，是把業務從「找規格、打報價、排出貨」這三個 80% 時間都在重複的事情裡拉出來，讓他們專心處理剩下那 20% 真正需要人判斷的案子。我們在 Shopify AI + MCP CTO 技術架構指南 裡把這個技術堆疊拆得更細。

這套堆疊解決了什麼具體問題

我們在專案結束後，跟客戶團隊一起對了六個關鍵指標（以下數字是上線後 60 天的平均，用舊系統的三個月均值做 baseline）：

數字來自客戶內部 Shopify Analytics、HubSpot Service Hub 的 ticket 系統，還有 unoPIM 的 job log。不是行銷素材上的誇大數字，是我們跟客戶一起在 Looker Studio 上盯了兩個月的實際結果。

需要誠實揭露的部分：新品上架時間的 89% 縮短裡，有一部分（約 30%）來自前期的 schema 標準化工作，不完全是 agent 的功勞。如果沒有 Sprint 1–2 的 schema 考古，直接套 agent 反而會因為資料結構混亂產生更多錯誤。

常見問題

unoPIM 適合我們這種只有 500 個 SKU 的 B2B 公司嗎？

適合。unoPIM 的運維成本主要落在初期 schema 設計跟 DAM 遷移上，跟 SKU 數量弱相關。一個單機 Docker 部署在 4 vCPU / 8GB RAM 的 VPS 上就能撐住 500–5,000 SKU 的規模，月成本約 30–60 美元（約 NTD 960–1,920）。真正要考慮的是：你有沒有至少一個工程師願意維護 Laravel 棧，以及願不願意花 4–6 週做 attribute 結構化。如果都沒有，Shopify 原生的 Metafields + 一個 Google Sheets 可能更適合你。

unoPIM 跟 Shopify Metafields 差在哪？為什麼不直接用 Metafields？

Metafields 只是 Shopify 原生的自訂欄位擴充，沒有審批工作流、沒有多通路分發、沒有 DAM、沒有 AI enrichment，改一個屬性定義要跑遍所有相關商品。對只有單一 Shopify 店、產品結構穩定的商家，Metafields 夠用。客戶的情況是四個 storefront 共用商品資料，還有 ERP 同步、多語言、多認證的結構化需求，Metafields 無法承擔這種複雜度。一個實務判準：如果你每週要跟 Excel/CSV 打超過 5 小時交道，你需要的就是 PIM，不是 Metafields。

Agentic B2B Commerce 什麼時候會在我的產業真正發生？

端視你的客戶在哪裡下單。工業電腦、電子元件、MRO 耗材這三類 B2B，現場工程師已經習慣用 ChatGPT 找規格。判斷的關鍵不是你家產品是不是夠「高科技」，是你的終端買家的年齡層和日常工具。Gen X 採購主管現在普遍用 AI 做初步調研，這部分流量你沒接到就流失了。

PHP 老系統遷移到 unoPIM，風險最大的地方是什麼？

是圖片和歷史訂單，不是商品資料。商品資料最多就是 schema 不齊，跑 AI enrichment 補起來；圖片如果檔案路徑是硬編碼的，遷到 unoPIM DAM 或 S3 時要維持 redirect 避免破壞舊 SEO；歷史訂單在工業 B2B 常常綁了合約價和付款條件，要跟 Shopify B2B 的 Company Profile 對齊要花功夫。我們在案子裡 Sprint 4–5 有 40% 的工時是花在這兩件事。

為什麼是 unoPIM 不是 Akeneo CE？Akeneo 名氣比較大

Akeneo 的品牌認知度確實高，但 2024 年 Akeneo 把很多關鍵功能（包括 Shopify 原生雙向同步）鎖進 Growth 和 Enterprise 版，Community Edition 的 roadmap 在我們評估的當下看起來是放養狀態。unoPIM 2026 年最顯眼的變化是 Agentic PIM 做進核心、支援 10 個以上 AI provider、明確的 Laravel 12 升級路線。對一個要在 12 週內上線、長期要運行 agentic workflow 的客戶來說，unoPIM 的方向比 Akeneo CE 更清楚。如果你已經有 Akeneo 的工程能力而且只看 DTC，Akeneo EE 仍然是好選擇——這是工具選型問題，不是品牌問題。

Author Insight

Tenten 的團隊過去三年協助過十多家從 2010 年以前的老系統（Magento 1、早期 Shopify Classic、客製 PHP）遷到 AI 原生堆疊的 B2B 客戶，累積下來一個不太上檯面的觀察：agentic commerce 的真正瓶頸不是 AI，是資料結構。

AI agent 能不能幫你的業務產出準確的 long description、能不能正確回答「這台 IPC 能不能在北非戶外全年無休運作」，取決於你 PIM 裡的 attribute 有沒有結構化。一個寫在自由文字描述裡的 -40°C to 70°C 對 agent 沒有意義；一個獨立欄位 operating_temperature_min: -40, operating_temperature_max: 70 才能讓 agent 做 range query 和 cross-product 比較。

這也是為什麼我們過去一年的客戶諮詢，有七成最後都花在 schema 工程——agent 本身反而只佔預算 15%。如果你正在評估「要不要上 AI agent」這個問題，我的建議是先花四週做 attribute audit，把所有非結構化文字欄位拆成可查詢的 schema，再談 agent。顛倒過來做，AI 只會放大你現有資料混亂的後果。

如果你的 B2B 正在經歷類似的階段——老 PIM、多 storefront、想導入 Shopify B2B 但卡在資料層——我們最近兩季做了五個類似規模的案子，包括北美的工業電腦分銷商、台灣的精密機械 OEM、馬來西亞的電子元件經銷。歡迎透過 Tenten 預約諮詢 跟我們聊聊你的堆疊，一小時的對話通常就能讓你對「該先動 PIM 還是該先上 Shopify B2B」有清楚判斷。

參考來源

• Shopify — B2B for all: expanding native B2B features to all paid plans (2026/04/02)
• Shopify Dev — Agentic Commerce with Universal Commerce Protocol
• Shopify — AI-native, developer-ready: Unpacking Winter '26 Edition
• UnoPim Official — Scaling UnoPIM for 10 million products
• GitHub — unopim/unopim (MIT License, Laravel 12)
• GitHub — unopim/shopify-connector
• Model Context Protocol — Anthropic Open Standard
• PYMNTS — Shopify Expands Availability of B2B Tools to All Merchants (2026/04)