不只搭建商店，也设计交付之后的体验。

我也曾被 AI 服务的购买流程挡在门外。

我是 Codex 和 Claude 的深度用户，也遇到过购买 AI 服务麻烦、订阅受阻的情况。PookerAI 从这个真实需求出发：先帮自己和身边有同样需要的朋友，用更简单、快捷的路径完成购买与订阅，再把服务提供给更多人。

平台已经真实收款并完成交付，正在持续运营。因此要解决的不只是“怎么买”，还包括购买后如何拿到服务、怎样跟进进度，以及出了问题如何售后。兑换码、资料与人工服务需要不同的交付方式，但都要留在同一笔订单的上下文中。

SKU 的定义，先于商品页的布局。

当前实现以一条 Product 表示一个可售 SKU，地区、时长与交付形式不同则分别建 SKU。价格与库存不再同时散落在另一套 SPU 模型中。产品范围也明确限定为单 SKU、单件和全额退款，不让页面暗示尚未支持的组合交易。

付款、发货与服务完成，是不同的状态。

一次真实纠偏：退款应从买家的问题开始。

项目审查明确记录了早期错误：由管理员代填原因并直接退款。修正后的链路是买家申请、商家审核、二次确认，再进入渠道处理或完成状态；拒绝也需要给出解释。

这不是多加一张表单，而是重新明确谁有权发起、谁需要决策、每一步向谁反馈。人工服务在退款申请期间暂停，阶段消息也不能提前把服务标为完成。

界面的承诺，怎样进入后端约束？

私密交付不是公开订单号的附属页面。

订单查询需要与私密交付权限分开：联系方式和公开订单号不能直接暴露交付资料。后台还需要库存去重、SKU 草稿保护、人工服务进度和退款队列，来承接前台已作出的承诺。

经营看板，先定义口径，再画曲线。

项目记录区分实际毛利与订单商品毛利；成本未知不能按零处理，退款也不等于采购成本自动冲回。付款率不能被称为访客转化率。这些语义会直接决定空值、说明和图表如何呈现。

交付与复盘

全栈产品设计意味着不仅想清楚用户按下按钮之前，也要想清楚按钮之后会发生什么。