代购源码AI选品引擎深度评测：用户行为驱动订单转化闭环
做代购系统的朋友应该都遇到过这个场景：商品列表一到中午就卡死，后台一查，又是那个 `LIKE '%keyword%'` 在全表扫描——二十多万行数据，跑得比蜗牛还慢。但说实话，这根本不是什么性能问题，真正的病因出在选品策略上：上架了一堆没人搜的SKU，白白占着数据库的资源。
说白了，问题的根源不在服务器配置，而是选品策略出了偏差——你上架了太多根本没人搜的SKU，结果就是白费力气。代购团队每天都在1688和淘宝上“凭感觉”找爆款，今天觉得这个好卖，明天觉得那个有潜力，最后要么滞销占库存，要么热销款跟不上补货节奏。
后来在一次系统迭代中，我们在代购源码里加入了一套AI智能选品与推荐引擎，算是把选品决策从“拍脑袋”拉回到了“数据驱动”的轨道上。这套引擎的核心其实并不复杂，简单说就是三个闭环：用户画像 → 商品趋势 → 个性化推荐。
一、用户行为采集与特征工程
推荐引擎的第一步，绕不开埋点。用户在代购站点上的每一次搜索、浏览、加购、下单甚至弃单，都需要记录下来。按事件类型写入Kafka当然是最正规的做法，但如果日单量没破千，中小规模直接用Redis List就够了。关键字段就那么几个：user_id、product_id、event_type、timestamp、source（PC/微信/小程序）。
离线处理阶段，要聚合出每个用户的“商品类目偏好权重”。比方说，某个用户浏览过3次日韩美妆、2次轻奢包、1次母婴，那美妆类目的权重就是3/6=0.5。这个权重每天凌晨用Spark或者简单的PHP脚本更新到MySQL的user_preference表里，够用就好。
这里有个设计上的小窍门，得单独拎出来说说：弃单事件比下单事件更重要。用户把商品加入购物车但没有支付，说明价格或者运费超出了他的心理预期。系统可以把这类商品打上“价格敏感型”的标签，推荐时优先展示优惠券或者折扣信息，转化效果往往会好不少。
二、商品趋势挖掘：1688热销数据 × 站内转化率
单纯靠站内数据，就像一个人只照镜子不看窗外，永远不知道外面流行什么。新用户没有历史行为，冷启动问题怎么解决？答案是把外部数据引进来。对接1688开放平台的商品搜索接口，按类目拉取“成交指数”和“飙升榜”。不过要注意，1688 API有调用频率限制（企业认证账号大约50次/秒），所以拉取任务得分散在全天，每次只拉Top 200的热门商品ID，别一口气吃成胖子。
站内趋势计算反而简单很多：统计最近7天每个商品的“加购率 = 加购次数 / 浏览次数”和“转化率 = 下单次数 / 浏览次数”。这两个指标组合起来能看出不少门道——加购率高但转化率低，说明运费或者关税有问题；两者都高，那才是真爆款。
```php // 计算商品趋势分（PHP） function computeTrendScore($productId, $days = 7) { $stats = DB::selectOne(" SELECT SUM(view) AS views, SUM(cart) AS carts, SUM(order_completed) AS orders FROM product_stats WHERE product_id = ? AND date >= DATE_SUB(NOW(), INTERVAL $days DAY) ", [$productId]); if ($stats['views'] < 10) return 0; // 数据不足 $cartRate = $stats['carts'] / $stats['views']; $orderRate = $stats['orders'] / $stats['views']; // 趋势分 = 加购率*0.4 + 转化率*0.6 return round($cartRate * 0.4 + $orderRate * 0.6, 4); } ```趋势分超过0.15（也就是15%的浏览最终转化为加购或下单）的商品，可以标记为高潜力商品，推送到选品建议列表供运营参考。这个阈值可以根据实际数据微调，但经验上看0.15是个不错的起点。
三、个性化推荐引擎：协同过滤 × 实时排序
有了用户画像和商品趋势，推荐算法就可以上场了。我们采用最轻量的Item-based协同过滤。离线阶段计算商品之间的相似度矩阵（基于用户行为共现），存入Redis。在线推荐时，根据用户最近浏览/购买的3个商品，找到最相似的Top 10候选商品，再结合商品趋势分和用户类目权重重新排序。
```php // 在线推荐（PHP + Redis） function getRecommendations($userId, $limit = 10) { // 1. 获取用户最近浏览的3个商品 $recent = DB::select("SELECT product_id FROM user_events WHERE user_id = ? AND event_type = 'view' ORDER BY timestamp DESC LIMIT 3", [$userId]); if (empty($recent)) { // 冷启动：返回趋势分最高的热门商品 return DB::select("SELECT product_id FROM product_trend WHERE trend_score > 0.15 ORDER BY trend_score DESC LIMIT ?", [$limit]); } // 2. 从Redis获取每个浏览商品的相似商品列表 $candidates = []; foreach ($recent as $item) { $sims = $redis->zrevrange("sim:{$item['product_id']}", 0, 20); foreach ($sims as $simId) { $candidates[$simId] = ($candidates[$simId] ?? 0) + 1; } } // 3. 按共现次数排序，取前30个 arsort($candidates); $candidateIds = array_slice(array_keys($candidates), 0, 30); // 4. 按趋势分和用户类目权重二次排序 $userPref = DB::selectOne("SELECT category_weights FROM user_preference WHERE user_id = ?", [$userId]); $weights = json_decode($userPref['category_weights'] ?? '[]', true); $products = DB::select("SELECT * FROM products WHERE id IN (" . implode(',', $candidateIds) . ")"); usort($products, function($a, $b) use ($weights) { $scoreA = $a['trend_score'] * ($weights[$a['category']] ?? 0.5); $scoreB = $b['trend_score'] * ($weights[$b['category']] ?? 0.5); return $scoreB <=> $scoreA; }); return array_slice($products, 0, $limit); } ```这套算法的推荐效果肯定比不上大厂那套深度学习方案，但在日活几千的站点上表现相当稳定，够用且轻量。
四、多端订单统一与支付聚合
AI引擎选出来的商品，最终要通过订单系统转化为收入。代购站点的入口通常不止一个：微信小程序、PC商城、WhatsApp私域下单，后台必须有一套订单处理中心来统一聚合。否则各端数据割裂，选品的闭环就断了。
```php // 订单创建时自动识别渠道 function createOrder($channel, $userId, $items, $paymentMethod) { $orderId = generateOrderId(); DB::insert("INSERT INTO orders (id, user_id, channel, payment_method, total_amount, status) VALUES (?, ?, ?, ?, ?, 'pending')", [$orderId, $userId, $channel, $paymentMethod, $items['total']]); // 调用统一支付网关 $paymentUrl = UnifiedPaymentGateway::pay($orderId, $items['total'], $paymentMethod); return ['order_id' => $orderId, 'payment_url' => $paymentUrl]; } ```支付网关这块，需要聚合PayPal、Stripe、微信支付、支付宝等多种方式。不同渠道的汇率和手续费差异很大，所以价格计算引擎要实时调用汇率API（缓存10分钟足够了），并加入缓冲系数来规避汇率波动风险。
通过插件市场的设计，新支付渠道可以随时接入。推荐、订单、支付数据统一回流，形成完整闭环，整个系统的数据也就活起来了。
隐性知识点：防止推荐系统的“信息茧房”
纯协同过滤有个硬伤：用户只会看到相似的商品，长期下去推荐列表越来越窄，用户也容易腻。解决办法其实很简单——在推荐列表中混入10%-20%的热门新品（趋势分高但从未被该用户浏览过）。这20%的曝光数据同时可以用来做A/B测试，看看新品的转化潜力到底怎么样。
另外还有个现实问题：1688接口升级签名算法时，推荐引擎的商品信息拉取可能会失败。需要在定时任务中加入重试和降级逻辑——如果连续3次拉取热门商品失败，就完全依赖站内趋势分，确保推荐位不会空在那。系统稳定比什么都重要。
这套流程上线后，选品效率和爆款命中率都有明显改善，客户看到的推荐也更贴合个人兴趣。当然，物流追踪和仓库合包的自动化，那是选品之后要解决的另一个环节了。
