【OpenCart × AI Ready 之三】開發智慧導購模組：讓自然語言需求轉成可查詢條件

直接答案：OpenCart 智慧導購不應讓 AI 憑空推薦商品，而應讓 AI 把消費者的自然語言需求拆成預算、分類、用途、規格與限制條件，再由 OpenCart 真實商品資料與庫存過濾推薦結果。

這篇文章適合誰？#

• OpenCart 第三方模組開發者。

• 想改善站內搜尋與商品發現體驗的商家。

• 正在規劃自然語言導購或語意搜尋的產品團隊。

傳統 OpenCart 搜尋為什麼容易卡住？#

許多消費者不是用商品名稱搜尋，而是用情境搜尋。例如：

• 「適合送工程師朋友的實用生日禮物」
• 「小坪數租屋可以用的安靜除濕機」
• 「看起來像皮鞋但下雨也能穿的男鞋」

傳統搜尋通常依賴品名、分類、標籤或簡單關鍵字比對。當使用者不知道商品名稱，或描述方式和商品欄位不一致時，搜尋結果容易不足。

智慧導購的核心：意圖解析加資料庫查詢#

AI Ready 智慧導購應分兩步：

1. AI 解析需求：把自然語言轉成結構化條件。

2. OpenCart 查詢商品：用真實商品資料、分類、屬性、價格與庫存產生結果。

範例解析結果：

{
  "intent": "find_products",
  "filters": {
    "category_candidates": ["shoes", "rain gear"],
    "budget_max": 3000,
    "use_case": "commuting in rainy weather",
    "attributes": {
      "water_resistant": true,
      "style": "formal"
    }
  },
  "ranking_preferences": ["in_stock", "high_rating", "fast_shipping"]
}

這比讓模型直接列出商品名稱更可靠，因為最後結果仍由 OpenCart 資料庫決定。

模組架構建議#

前台 UI#

提供自然語言輸入框，但要保留傳統分類與篩選器。AI 導購是輔助入口，不應取代所有搜尋方式。

Controller#

接收使用者查詢，送到 AI Ready Gateway 做意圖解析。注意節流與防濫用。

Model#

根據 AI 回傳的條件查詢商品、分類、屬性與庫存。查詢必須使用參數化方式，避免 SQL 拼接風險。

Ranking#

排序時可考慮庫存、價格、評價、轉換率、退貨率與毛利，但要避免使用敏感個資或不可解釋規則。

Explanation#

推薦結果應附上簡短理由，例如「符合防潑水、正式外觀、預算內且目前有庫存」。

導購結果需要防呆#

• 不推薦缺貨商品，除非明確標示可預購。

• 不推薦使用者所在區域不可配送的商品。

• 不使用不存在的商品屬性。

• 不把 AI 解析結果直接當 SQL 條件拼接。

• 不用敏感屬性做個人化排序。

AEO 與 SEO 的延伸價值#

智慧導購查詢紀錄可以反饋內容策略。例如站內大量使用者搜尋「通勤防水鞋」，但分類只有「男鞋」與「雨鞋」，商家就可以新增分類頁、FAQ 或 Blog 文章回答這類需求。這對長期 SEO/AEO 比單次推薦更有價值。

FAQ#

智慧導購會取代 OpenCart 原本搜尋嗎？#

不建議。應讓自然語言導購和傳統搜尋並存。AI 適合理解模糊需求，傳統篩選則適合精準比較。

AI 推薦商品會不會產生幻覺？#

若讓模型直接生成商品名稱，風險較高。比較好的方式是讓 AI 只生成查詢條件，商品結果由 OpenCart 真實資料產生。

導購模組需要保存使用者對話嗎？#

若要保存，需明確告知用途並遵守隱私政策。多數情況只需要保存彙總後的搜尋意圖，用於改善分類與內容。

參考資料#

• OpenCart Developer Documentation: Module，https://docs.opencart.com/developer/module/
• Google Search Central: AI Search guidance，https://developers.google.com/search/blog/2025/05/succeeding-in-ai-search