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 vs. AI‑commerce

为了更直观地感受差异，把两种方式放在一起最方便。下面是一张简化的表格，不求面面俱到，但足以凸显范式的变化。

一个实际影响是：在 AI‑commerce 中，关注点从“目录与购物车”的视觉设计转移到数据的结构与质量，以及 ChatGPT、你的后端与支付服务提供商之间的正式交互协议。Product feed 和 ACP 端点与小部件本身一样，都是关键“UI”。

如果在传统商店里还能在浏览器端修修补补一部分 UX，那么在 AI‑commerce 里，模型几乎完全依赖你提供的数据和模式：从商品描述到 checkout 会话的状态。

3. OpenAI Commerce 的构建块

OpenAI 并没有提供“万能的 GPTPay 支付系统”。取而代之的是一组规范与指南，说明如何把现有商户与支付服务提供商接入 ChatGPT 的世界。其中有四个对我们尤为重要的构件。

首先，Product Feed Specification。这是商家用于描述商品目录的官方格式： id、title、description、价格、货币、库存、图片等。 Feed 充当“结构化的真实来源”，OpenAI 会对其进行校验、索引，并用于 ChatGPT 内的搜索、排序和结账。

其次，Agentic Checkout Specification。这是与 checkout_session 实体交互的 REST 合同： API 规定如何创建支付会话，如何更新（例如更换地址或配送方式）并完成它，以及你的后端需要返回哪些字段（金额、税费、履约选项、退货政策链接等）。

第三，Delegated Payment Specification。该协议用于代理平台（ChatGPT）从支付服务提供商处获取委托支付令牌（如 Stripe Shared Payment Token），并把它传递给你的后端，而不暴露原始支付信息。令牌受额度、有效期等参数限制，由你的后端用于在 PSP 侧创建真实支付。

最后，ChatGPT 内的 Instant Checkout——是上述规范之上的一层 UX。聊天中会出现紧凑的结账界面：已选商品、价格、地址、支付方式。其底层依赖 Product Feed，按 Agentic Checkout Spec 调用你的 /checkout_sessions，并使用 Delegated Payment 在 PSP 侧完成交易。

好消息是，这些都不是“ChatGPT 的秘密 API”，而是公开的 ACP（Agentic Commerce Protocol）规范。这意味着，如果其他 AI 平台也支持 ACP，同一个后端理论上可以与它们协同工作。

4. 角色与职责边界

接下来是最有意思的部分：当系统里出现了“钱”，监管与法务会突然成为你的好朋友。为了不混乱，务必清晰区分各方角色。

最关键的角色是代理平台，在我们的场景里就是 ChatGPT。它掌控用户体验：聊天、小部件、Instant Checkout UI。平台发起 commerce 流程，从 Product Feed 中选择商品，调用你的 ACP 端点，并向用户展示结果。但 ChatGPT 既不会成为商品所有者，也不是支付提供商，也不会把你的产品数据当作“自有目录”存储——它只使用你提供的 Feed。

第二个角色是商户（seller, merchant‑of‑record）。即商品或服务的所有者。商户负责 product feed（结构、质量、价格与库存的时效性）、正确实现 ACP 端点（/checkout_sessions、webhooks）、创建与保存订单、履约、客服与退货。ACP 文档强调，在法律意义上，商户才是交易卖方，而非代理平台。

第三个角色是支付服务提供商（PSP），如 Stripe。PSP 负责支付处理、遵循 PCI DSS 等要求、存储支付信息、对抗欺诈与拒付。在 Delegated Payment 场景中，PSP 向代理平台签发特殊令牌（SPT），随后由你的服务器用它来创建真实支付（例如在 Stripe 创建 PaymentIntent）。

第四个、也是最重要的角色是用户。他提出需求、做出最终购买决策、同意支付，并且理想情况下会阅读你在结账 UI 中呈现的条款与隐私政策。为了增强信任与透明度，Product feed 里可以包含这些文档和退货政策的链接。

为方便起见，我们把它们汇总成一张小表：

职责划分不仅关乎法律，也关乎架构。比如明天你接入第二个 PSP，不必重写 ChatGPT App：只需要在自己的后端适配 Delegated Payment 层；如果出现第二个也支持 ACP 的 AI 平台，你可以复用 product feed 与 checkout 端点。

5. “全在对话中完成”的购买场景是什么样

现在把所有内容拼在一起，从架构角度看看在 ChatGPT 中购买数字礼物的端到端流程。虽然是简化版，但能抓住要点。

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 通过你的 /checkout_sessions 按 Agentic Checkout Spec 创建 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 工具在自有目录中搜索；
• 在小部件中展示候选卡片，并在聊天里发送后续跟进按钮。

从 commerce 的角度，这只是“智能发现”，没有真实购买。在 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 层面把“谁在做什么”分隔清楚。例如可用于测试，或在小部件内部的调试 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 增加几个步骤，并在小部件里的一个小调试组件中渲染出来。这个练习能培养不仅“写代码”，也“思考协议中角色分工”的习惯。

一个可接收这种“流程计划”并进行日志记录的简单 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 作为独立规范：代理平台在自己的层面与 PSP 通信，获取 SPT 令牌并传给你，然后你再创建支付。如果试图绕开这套机制、在 App 里直接接收卡信息，你很快就会被合规要求“狙击”。

错误 4：把 product feed 当作“营销配置”，而不是 LLM 的 API。
不少人带着 Google Shopping 的背景来，把 Feed 当作比代码更偏向广告后台的东西。在 AI‑commerce 世界里，Feed 本质上是模型的商品知识库。如果图片链接失效、属性不一致、单位混乱、用营销夸张替代事实，模型就会推荐不合适的东西，转化率会直线下降。

错误 5：妄图“一步到位”上线 Instant Checkout。
很容易心动：“我们把 enable_checkout 直接打开，让用户在聊天里买单”。但如果没有好的发现能力（高质量 Feed）、没有可靠的 checkout 后端，以及没有与 PSP 的稳健集成，你很可能得到一个脆弱的系统，半数订单卡在中途。更明智的路线是按 OpenAI 的台阶来：先打磨高质量 Product Feed，再调通 ACP 端点，然后接好 Delegated Payment，最后才在生产环境开启 Instant Checkout。