AI‑commerce 的全貌與 OpenAI 的角色

1. AI‑commerce 到底是什麼

如果傳統的 e‑commerce 是「進站 — 開啟目錄 — 放入購物車 — 被三個表單拖著走」的故事，那麼 AI‑commerce 的核心介面就是與 ChatGPT 的對話。使用者以自然語言提出需求，而 ChatGPT 內的代理會同時扮演顧問、陳列企劃，某種程度上甚至是產品經理的角色。

請求不再像「category=襪子&price_max=20」，而更像「幫我挑一個有趣但不要太尷尬的同事禮物，預算到 20 美元，可以用 email 發送」。代理會解讀任務、提出澄清問題、查閱商品目錄、說明各選項的優缺點，接著引導使用者直到完成購買——而這一切都不需要把「購物車」當成獨立頁面呈現給使用者。

從架構觀點來看，ChatGPT App 此時不再只是「聰明的禮物目錄」，而會變成一個commerce 應用，能夠：

1. 理解使用者意圖與限制（預算、禮物類型、國家、數位/實體商品）。
2. 從 product feed 挑出具體的 SKU 並解釋選擇理由。
3. 透過標準化協議 ACP（Agentic Commerce Protocol）啟動購買流程。

AI‑commerce 的觀念在於「catalog + checkout」不再是獨立網站，而是對話的自然延伸——使用者本來就在與 GPT 對話。

2. 傳統 e‑commerce 與 AI‑commerce 的差異

為了更直觀地感受差異，把兩種做法放在一起比較。下面是簡化過的表格，未必面面俱到，但能清楚凸顯典範的轉變。

實務上的結論：在 AI‑commerce 中，焦點會從「目錄與購物車」的視覺設計轉移到資料的結構與品質，以及 ChatGPT、你的 backend 與支付服務提供商之間的正式互動協議。Product feed 與 ACP 端點會和 widget 本身一樣成為關鍵的「UI」。

如果在傳統商店裡可以在瀏覽器端修一些 UX，那在 AI‑commerce 裡，模型幾乎完全依賴你提供的資料與結構：從商品描述到 checkout 工作階段的狀態。

3. OpenAI Commerce 的組件

OpenAI 並未提供「會魔法的 GPTPay」來把所有事都包辦。取而代之的是一套規格與指南，說明如何正確把現有商家與支付服務提供商接到 ChatGPT 世界。在這些文件裡，對我們最重要的有四個積木。

其一，Product Feed Specification。這是商家用來描述商品目錄的官方格式： id、title、description、價格、幣別、可售狀態、圖片等等。 Feed 充當「結構化的真相來源」，OpenAI 會驗證、索引，並在 ChatGPT 內用於搜尋、排序與 checkout。

其二，Agentic Checkout Specification。這是用於 checkout_session 實體的 REST 合約： API 說明如何建立 payment session、如何更新（例如變更地址或配送方式）與完成它，以及後端需要回傳哪些欄位（金額、稅金、履約選項、退貨政策連結等）。

其三，Delegated Payment Specification。這是一個協議，代理平台（ChatGPT）從支付服務提供商取得被授權的支付權杖（例如 Stripe Shared Payment Token），並將其轉交給你的後端，而不暴露實際的支付憑據。該權杖在金額、存活時間與其他參數上受限，並由你的後端用來在 PSP 建立真正的支付。

最後，ChatGPT 內的 Instant Checkout——它是上述規格之上的一層 UX。聊天介面會出現精簡的 checkout 介面：已選商品、價格、地址、付款方式。在底層，它依賴 Product Feed、呼叫你的 /checkout_sessions（依 Agentic Checkout Spec），並使用 Delegated Payment 來在 PSP 端完成交易。

好消息是，這些都不是「ChatGPT 的祕密 API」，而是開放的 ACP 規格（Agentic Commerce Protocol）。這表示同一套後端在理論上也能和其他支援 ACP 的 AI 平台協作。

4. 角色與責任邊界

接下來是最有意思的部分：當系統涉及金流時，監管與法務會突然成為你最好的朋友。為了不被繞暈，務必清楚劃分角色。

最關鍵的角色是代理平台，在我們的情境中——ChatGPT。它掌握使用者體驗：聊天、widget、Instant Checkout UI。平台啟動 commerce 流程、從 Product Feed 選品、呼叫你的 ACP 端點，並將結果展示給使用者。但 ChatGPT 既不是商品所有者、也不是支付服務提供商，並不把你的 product 資料當作「自己的」目錄來保存——它只使用你提供的 feed。

第二個角色是商家（seller, merchant‑of‑record）。這是商品或服務的擁有者。商家負責 product feed（結構、品質、價格與可售狀態的即時性）、正確實作 ACP 端點（如 /checkout_sessions、webhooks）、建立與保存訂單，以及配送、客服與退貨。ACP 文件強調，在法律上你仍是賣方記錄（merchant of record），而不是代理平台。

第三個角色是支付服務提供商（PSP），例如 Stripe。PSP 負責處理支付、遵循 PCI DSS 與其他規範、保存支付憑據、對抗詐騙與拒付。在 Delegated Payment 的情境中，PSP 會發給代理平台一個特殊權杖（SPT），然後由你的伺服器使用它在 PSP 端建立真正的支付（例如在 Stripe 建立 PaymentIntent）。

第四個、也是最重要的角色是使用者。他提出需求、對購買做出最終決策、同意付款，並且在理想情況下會閱讀你在 checkout UI 中誠實展示的 Terms / Privacy Policy。為了增加信任與透明度，Product feed 可以包含這些文件與退貨政策的連結。

為了方便，我們把它們彙整成一個小表格：

角色分工不僅對法務重要，對架構也一樣關鍵。舉例來說，如果明天你接了第二家 PSP，就不需要重寫 ChatGPT App：只要在自己的後端調整 Delegated Payment 層即可。而若出現另一個同樣理解 ACP 的 AI 平台，你也能重用 product feed 與 checkout 端點。

5. 「全在對話中」的購買場景長怎樣

現在把一切拼起來，看看在 ChatGPT 中購買數位禮物的 end‑to‑end 情境，從架構角度會長什麼樣。這是簡化版本，但能反映核心。

sequenceDiagram
  participant U as 使用者
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as 商家後端
  participant P as PSP（Stripe）

  U->>C: "幫我買一個不超過 $50 的數位禮物"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: 符合條件的 SKU 清單
  G-->>C: 禮物候選項 + 中繼資料
  C-->>U: 說明選擇並提供選項
  U->>C: "就買這個"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: 請求支付權杖（SPT）
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: 執行支付
  B-->>C: 訂單建立的 webhook
  C-->>U: 購買確認

用 ACP 的乾式語言來說，這裡發生了以下事情：

1. 代理透過 Product Feed（經由你的後端）挑選合適的 SKU。
2. 當決定「要買」時，ChatGPT 會依 Agentic Checkout Spec，透過你的 /checkout_sessions 建立 checkout_session。
3. 在 Instant Checkout 過程中，ChatGPT 向 PSP 申請針對特定金額與商家的委任支付權杖。
4. 該權杖會被傳入 POST /checkout_sessions/{id}/complete，你的後端在 PSP 端建立支付並形成訂單。
5. 當訂單就緒，你的伺服器透過 webhook 通知 OpenAI，之後使用者會看到最終的確認。

在本講座中，我們更在意你是否看懂結構： feed → 挑選 SKU → checkout_session → 支付 → 訂單 → webhook。接下來的課程會逐一拆解每個部分，包括 feed 欄位、checkout 工作階段欄位與委任支付的格式。

6. GiftGenius：我們的 App 如何融入 AI‑commerce

在此之前，GiftGenius 一直扮演「禮物推薦助手」的角色。它會：

• 詢問使用者要送給誰、什麼場合需要禮物；
• 使用 MCP 工具搜尋自己的目錄；
• 在 widget 中展示候選卡片，並在聊天裡送出 follow‑up 按鈕。

從 commerce 的角度看，這只是「聰明的 discovery」，沒有真正結帳。在 OpenAI commerce 的語境下，這對應於在 feed 中把某個 SKU 的 enable_search = true 但 enable_checkout = false： 可以被找到與討論，但不啟用 Instant Checkout。

在 AI‑commerce 模組中，我們會逐步把 GiftGenius 變成完整整合的商家：

• 依 OpenAI 規格新增結構化 Product Feed；
• 設計可與 checkout_sessions 協作的 ACP 後端；
• 透過 Stripe Shared Payment Token 接上 Delegated Payment；
• 讓 App 告訴使用者，他不只可以挑禮物，還能直接在聊天裡完成購買。

為了避免看起來像「黑魔法」，我們在程式裡加入一個小小的技術層，明確建模 commerce 流程中的角色與步驟。這對日誌與內部測試都很有幫助。

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

這些型別能讓我們在 TypeScript 層面也清楚劃分「誰在做什麼」。例如可以用在測試或 widget 內的除錯 UI。

以下是「數位禮物，不超過 $50」情境的一個簡單步驟陣列：

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "撰寫請求與預算" },
  { id: "search", role: "chatgpt", description: "從 Product Feed 挑選 SKU" },
  { id: "checkout", role: "merchant", description: "建立 checkout_session" },
  { id: "payment", role: "psp", description: "使用權杖進行支付" }
];

這段程式暫時還不會對外呼叫，但已經建立出一條有用的「座標軸」，我們將在接下來的課程把真正的 ACP 程式碼堆疊上去。

7. 迷你練習：拆解「幫我買一個不超過 $50 的數位禮物」流程

在課程結尾，動手拆解剛剛講過的內容最有幫助。拿使用者的請求：

「幫我買一個不超過 $50 的數位禮物」。

任務是用 3–5 個邏輯步驟描述接下來會發生什麼，並為每個步驟指出執行者：ChatGPT、你的商家後端、支付服務提供商或使用者本人。可以參考上面圖示與 digitalGiftFlow 陣列，但不必逐字相同。

例如，你可以從 ChatGPT 解析請求並向使用者澄清細節開始（數位禮券、收件區域、要送誰）。接著是你的後端根據 Product Feed 尋找合適 SKU，然後建立 checkout_session、向 PSP 取得支付權杖，並完成購買。

若想更進一步，可以直接用程式呈現，幫 digitalGiftFlow 再補幾個步驟，並在 widget 內的簡易除錯元件裡把它們渲染出來。這種練習能培養你不只思考「寫程式」，也同時思考協議中的角色。

下面是能接收這種「流程計畫」並記錄的簡單 API 端點（暫無真正商務邏輯）：

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

在真實場景中，你不會用 console.log，而是寫結構化日誌，甚至把這類情境保存為文件或測試的一部分。但即便是這樣的小示例，也能把抽象的架構和你在 Next.js 應用裡的具體 TypeScript 程式碼緊密連結起來。

只要把本講座整理出的角色圖時時放在心上，後續的技術細節——Product Feed 欄位、checkout 工作階段的結構，以及委任支付的結構——都會更順手，也不會再對「全能的 GPT」過度浪漫化。

8. 對 AI‑commerce 與角色常見的誤解

錯誤 1：以為「ChatGPT 會自己把一切都做好」。
有時開發者會認為只要「接上 Stripe」並「讓模型存取 API」，接下來 GPT 就會搞定一切。事實上，圍繞 ChatGPT 的 AI‑commerce 依靠的是正式規格：Product Feed、Agentic Checkout、Delegated Payment。若你沒有用結構化 feed 描述商品、沒有實作 /checkout_sessions、也沒有設定 Delegated Payment，再強的模型也不會替你憑空生出來。

錯誤 2：混淆 ChatGPT 與商家的角色。
另一個常見誤區是以為 ChatGPT 成為「商店」，而你只是「接上你的目錄」。實際上剛好相反：你仍是商家，保存 product feed、建立與維護訂單、處理退貨。ChatGPT 僅負責對話的 UX 與正確呼叫你的 ACP 端點。若把系統設計成「GPT 會自己發訂閱、寄商品」，早晚會陷入法律與技術的死胡同。

錯誤 3：忽視支付服務提供商是獨立實體。
有時會想把 PSP「藏」在後端裡，像對任何 REST API 一樣與之溝通，卻忘了支付層有自己的遊戲規則（PCI、詐騙、拒付、額度）。在 ACP 的做法裡，才會特地把 Delegated Payment Spec 抽出來：代理平台與 PSP 在自己的層級互通，取得 SPT 權杖並傳給你，而你再去建立支付。若試圖繞過這套機制、在 App 內直接收集卡片資訊，你很快就會被合規要求擊倒。

錯誤 4：把 product feed 當成「行銷設定」，而不是 LLM 的 API。
很多人帶著 Google Shopping 的背景而來，把 feed 視為更接近廣告後台的東西，而非工程。可是在 AI‑commerce 的世界裡，feed 本質上就是模型的商品知識庫。若裡面有壞掉的圖片連結、不一致的屬性、奇怪的計量單位、以及行銷話術取代事實，模型就會提供你不想要的建議，轉換率也會下滑。

錯誤 5：想用「一步到位」的方式上線 Instant Checkout。
很容易被誘惑：「我們直接把 enable_checkout 打開，讓使用者在聊天裡買。」但如果沒有良好的 discovery（高品質 feed）、沒有可靠的 checkout 後端、沒有與 PSP 的周延整合，你很可能得到一套脆弱的系統，一半訂單卡在中途。更合理的路徑是依 OpenAI 的台階前進：先是高品質 Product Feed，接著打磨 ACP 端點，再來是 Delegated Payment，最後才在正式環境啟用 Instant Checkout。