客户让 AI 找到一只合适的滤杯，和客户真的收到这只滤杯，中间还隔着不少事：选的是哪个规格，送到哪里，总共多少钱，谁确认付款，订单有没有进入商家后台。
以前，我们容易把 AI 购物理解成“多一个推荐入口”。现在，工具已经开始往交易里走。对商家来说，准备工作的重点也要跟着变：商品要让 AI 选得准，付款要让客户看得明白，最后还要能查清这笔订单到底走到了哪一步。
但这不意味着每家 Shopify 商店都该马上开发一个购物助手。先分清现成渠道已经提供什么，以及自己的业务还缺什么，才能把钱花在真正影响成交和履约的地方。
Shop MCP 已经能做什么，边界在哪里？
Shopify 在 2026 年 10 月 13 日公布了 Shop MCP：支持兼容的 AI 助手或应用连接 Shopify Catalog，查商品、建购物车和结账，并在相应条件下使用 Shop Pay 完成购买。MCP 可以简单理解为让助手调用外部工具的一套连接方式。这是已经提供的开发能力，不只是概念演示。Shopify 更新说明
这里要区分两个入口。Shop 的开发文档给出了在 ChatGPT 等 MCP 客户端配置连接的办法；客户端还要兼容相应协议，并启用连接。与此同时，Shopify 当前面向商家的 ChatGPT 渠道说明，仍把它定义为商品发现和导流入口：客户到商家网站的结账页完成购买。不能把“某个客户端可接入 Shop MCP”写成“所有 ChatGPT 用户都已能原生代下单”。客户端连接文档、ChatGPT 渠道说明
Catalog 的规模也不等于你的全店商品已经开通。商店状态、商品发布状态、图片、价格及品类等都有资格要求；即使被收录，也不保证进入某次推荐或获得某个排名。商家应在后台的 Sales channels → Agentic → Sources → Shopify Catalog 查看自己店铺的实际情况。收录要求、Catalog 说明
从推荐到付款，先把这三件事分开
假设一家商店销售陶瓷滤杯，有小号、大号和不同颜色。下面是教学假设，不是真实客户项目。客户想买“白色小号，送到加拿大”，问题已经不只是推荐哪一款。
先确认买的是哪件。 搜索结果可能只展示一个代表性 Variant，也就是具体规格。官方还提醒，查询某组规格时，返回结果可能放宽部分条件，且不一定给出警告。因此开发者不能只看商品标题，就认定白色小号有货；需要重新读具体选项、实际返回的选择和库存。搜索时能配送到某国，也不能证明能在客户要求的日期送达。商品选择文档
这会直接影响商品整理方式。若后台把大小写在标题里、颜色放在图片里，商品页又用另一套称呼，客户和工具都容易选错。先让后台规格、商品页选择器与库存指向同一件商品，价值比给助手增加一段漂亮的推荐话术更实在。
看看真实商品页就更容易理解。我们在 Kurasu 的 ORIGAMI Dripper 页面观察到，Size 分为 S、M，Color 单独列出，当前选中项显示为 S 与 White；价格和剩余数量紧靠选择区。客户说“白色小号”，对应的是一组具体选项，不只是商品名。Kurasu 商品页
这张截图只能说明观察时的前台表达，不能证明这家店已接入 Shop MCP，也不能把页面标价当作送往加拿大的含税运总额。对自己的店，值得学的是把选择、价格与库存放在一起核对，再用真实结账确认配送和费用。
再确认结账条件。 未连接 Shop 账号，也能搜索、建购物车和发起结账；连接后可以读取保存的地址，并在结账中使用可提供的 Shop Pay。账号连接不应成为浏览商品的强制门槛，也不等于客户已经同意某笔付款。Shop 账号文档
客户只是说“这款不错”，还不够。创建购物车或结账应当基于客户的请求；真正付款前，再展示卖家、商品和数量、当前总额与可用付款方式，让客户自己选择。缺少付款方式或需要客户处理额外步骤时，就交给返回的商家结账链接继续。结账与客户确认
滤杯标价可能符合预算，加上运费和税后却超了。此时应该让客户重新决定，不能沿用刚才对商品的认可。一个清楚的确认界面，应当让客户看到“白色小号 × 1”及到手总额，而不是只放一个“继续”按钮。
最后确认订单成立。 创建购物车、打开 Checkout，都没有下单；一个结账只属于一个商家。客户从三家店选东西，不能把它们描述为一笔统一结账。工具返回 completed，并带有 order，才是这条购买流程确认成立的依据。工具说明、购买流程
付款后卡住，最危险的动作是再下一次
比如客户已经确认付款，助手却遇到超时。此时屏幕没出现成功提示，不能证明付款没发生。重新调用一次付款，或者另建一笔结账“再试试”，都可能把不确定结果变成重复交易。
Shop MCP 的官方处理要求很明确：不要重复调用 complete_checkout，即使使用相同的防重复标识也不行；应读取原结账状态。只有查到完成状态和订单，才能确认购买。若仍查不清，就如实告诉客户，并提供原结账入口，停止继续付款。错误与重试规则
对商家来说，这要求系统能记住当前交易对应的结账记录，而不是每一轮对话都重新开始。给客服的提示也要写清“结果待确认”，不能随意变成“付款失败，请重试”。这是集成质量的一部分，会影响客诉和对账。
确认下单之后，还要看支付状态。Shopify 把订单、支付和履约分开管理：例如 Pending 可能仍在等待支付处理，Authorized 表示款项已获授权、尚待捕获。业务系统不能看到订单编号，就直接给仓库发出“已收款可发货”的指令。订单状态说明
AI 能报物流，不代表它能包办售后
通过助手下的订单会进入商家的 Shopify 后台。客户关系和后续体验仍由商家负责，不能因为入口换成 AI，就把延迟、破损或退款问题留给一段聊天记录。订单落地说明、商家责任说明
当前 Shop MCP 可以在客户连接 Shop 后搜索其订单和追踪信息，但不能直接向商家按订单查询，也不能发起退货或取消订单。返回的退货入口和订单页面，应当交给客户继续处理。物流显示已创建面单，也不能说成包裹已经发出。订单查询与限制
通知能力要按所选接口核对。10 月 13 日的 Shop MCP 上线说明要求读取结账状态，当时没有 Webhook 自动通知；其他订单接口的通知能力，需要接入方另外实现，不能当作 Shop MCP 已经提供。上线限制、UCP 订单接口
商家先做好现成能力，再决定开发到哪里
如果目标只是让符合条件的商品被发现、让客户顺利回站结账，不需要为了这条新闻自建 MCP 服务。先完成三件可检查的工作：
- 商品对应得上。 在 Products 核对规格、库存和价格；检查页面上的容量、尺寸、配件与后台实际出售的内容一致。Catalog 自动收录不等于资料自动变正确。
- 结账解释得清。 在 Settings 检查配送、税费、付款和政策；用目标市场、真实规格组合走一遍流程，确认客户能看懂最终金额与交付条件。页面里答应的内容，要能在结账里兑现。
- 售后有人接。 在 Orders 核对支付与履约如何流转；明确谁处理待确认交易、取消、退货和物流异常，客户能从哪里找到入口。
只有当你要运营自己的购物助手，或需要把交易接进现有库存、仓库和客服系统时，才进一步评估授权连接、确认界面、状态同步和异常处理的集成开发。WESWOO 在这类项目中的工作，可以落在商品数据整理、商品页与结账衔接，以及必要的系统集成；能够由 Shopify 现成设置解决的部分，应先用好现成能力。
验收时，可以拿这只滤杯连续问四个问题：选错规格会不会被发现？总额变化会不会重新确认？付款超时会不会重复下单？售后请求有没有明确去处？这四个问题答得清，才说明商店准备到了交易这一层。推荐、点击和加购可以观察兴趣，不能替代真实订单与支付状态来算成交。
资料核对截至 2026 年 10 月 20 日。文中流程示例用于解释业务判断，不代表已测试某家商店或承诺流量、排名与成交。