先放结论：某跨境团队在引入AI选品Agent之前，一个月测款20个，最终能跑出来的只有3个，成功率15%上下，这个数字卡了大半年。重构选品流程之后，同样的测款数量，成功率爬到42%，月利润增加8万左右。这套方案的内部代号叫OpenClaw，不是某个现成软件，而是用公开数据接口、开源模型和一堆业务规则拼出来的全栈系统。文章不吹指标，只想把整个实战链路拆开：为什么以前成功率低，Agent怎么设计，每一层在做什么，以及从15%到42%的过程中，真正起作用的是哪些迭代。

如果你是做跨境选品的运营或供应链负责人，这篇能帮你看清楚AI选品的边界：它不能替你拍板，但能把80%的低效工作干掉。如果你是个开发者，想了解Agent怎么落地到具体业务，这里有完整的架构、代码、参数设置和踩坑记录。我不打算堆概念，直接按项目真实推进的顺序写。

1. 先算一笔账：选品成功率卡在15%，到底是怎么亏的

1.1 15%的“成功”是怎么定义的

很多团队谈选品成功率，口径完全不一样。有的人把“上架后出过单”算成功，有的人把“首批库存卖完”算成功，最后数据对不上。这个项目里，我们把成功定义为：测款商品上架后，连续4周日均出单不低于5件，同时按全口径成本计算净利润为正。注意，是“连续4周”，不是某一天爆发，也不是毛利率为正，而是把广告、退货、物流损耗全部摊进去之后还能赚钱。

按这个口径，团队当时一个月测20款，能达标的只有3款，成功率正好15%。表面上看是运气问题，但复盘之后发现，选品流程里有大量环节在系统性制造失败：数据看走眼、利润算漏项、错过时间窗口。成功率低不是单点原因，而是整条流水线在漏水。

1.2 人工选品流程的三大死穴

传统做法并不复杂。运营每天花三四个小时翻榜单、看评论、刷趋势，把自己觉得不错的商品登记进表格，然后挨个找供应商问价，等报价回来再做一轮感觉层面的筛选，最后小批量空运测款。整个过程有几个结构性bug。

第一是数据滞后。大家看的榜单和热搜是“已经发生的结果”，等运营看到某个品在涨，供应链端早就跟进了。团队每周都在追上一波的趋势，等货到了，窗口期通常已经过去一半。

第二是判断维度太单一。人工筛选时，最习惯看销量、评论数和价格区间，但差评里的质量问题、竞品上架时间、实际退货率、广告竞争强度这些关键信息，很难靠肉眼在几个小时内处理完。结果就是“看起来能卖”的商品一大堆，“算下来能赚”的没几个。

第三是反馈断裂。测款失败之后，团队很少系统回答“为什么失败”。是产品不行，还是广告没跑对？是季节性误判，还是利润模型乐观了？没有归因，就没有修正。同一个坑，每个月都要踩好几遍。

1.3 我们决定做成什么样

项目目标定得很朴素：月测款数量保持20款左右，成功率从15%至少翻一倍，同时把单次选品决策周期从3天压到1天。约束条件也很明确：不靠大量囤货试错，不碰平台规则之外的灰色手段，所有数据来源必须合规。基于这个定位，选品Agent要能回答四个问题：需求是不是真的、竞争是不是能进、利润是不是达标、风险是不是可控。如果这四个问题都能用数据回答，选品就从“赌”变成了“筛”。

2. OpenClaw的整体设计：把选品拆成Agent能干的事

2.1 从自动化脚本到Agent，差别在“闭环”

很多团队以为写个脚本定时抓数据、按规则算分就算是Agent了。实际跑下来，这两者的差别非常大。传统脚本是单向流程：数据进来，规则跑完，结果输出，然后结束。选品Agent必须多一个“反馈环”：上架后的销售数据要能流回来，自动修正下一轮的打分权重。

选品本质上是一个“假设-验证-复盘-修正”的循环。今天选出的品，要等一个月甚至更久才能验证对错；如果结果不回传给系统，那么每一次选品都是独立事件，成功率永远不会系统性地提升。OpenClaw在设计时把反馈层放在最高优先级，而不是把评分模型捧到天上。后面会看到，真正把15%拉到42%的，正是这个闭环。

2.2 五层架构与每个模块的输入输出

整个Agent按数据处理链路分成五层，每一层只做一件事，接口清晰，出了问题也好排查。

刚开始做的时候，最容易犯的错是在特征层堆了太多花哨指标，结果决策层算不过来。我们最终沉淀下来的核心特征只有二十多个，背后都是有明确业务含义的。比如“需求热度”用搜索趋势和榜单排名变化率，“竞争强度”用头部商品销量集中度和评论增速，“利润空间”用净利测算结果，“风险系数”用差评关键词命中率、合规类目标记和供应链交期。

2.3 决策层：评分公式和硬性门槛怎么定

决策层是整个Agent最敏感的部分。评分公式不能搞黑盒，必须能回溯——任何一个候选品被打分后，运营要能看到分数由哪几项构成。我们用的加权公式长这样：

综合评分 = 需求分 × 0.30 + 竞争分 × 0.15 + 利润分 × 0.35 + 风险分 × 0.20

权重不是拍脑袋拍的，是根据一个月的失败样本反推出来的。需求分权重刚开始是0.35，利润分是0.30，后来发现“看起来需求很大但算下来不赚钱”的品被放进来太多，就把利润权重提到最高。原因是：小团队绕不开竞争，但可以避开不赚钱的品；利润不合格，后面全是白忙。

光有加权分还不够，我们设了四条一票否决的硬门槛：

• 预估净利率低于30%，直接淘汰，不参与评分排序；
• 综合评分低于75分，取消自动进入测款清单的资格；
• 首单采购金额超过3万，转人工复核；
• 预计交期超过20天，转人工复核。

硬门槛的意义在于防止评分“平均化”。之前有的品需求分很高，但利润分不及格，总分还是被拉到了76分，结果上架就亏。加了硬门槛之后，短板商品进不来，成功率自然往上走。

3. 全栈实战：从数据接入到选品报告的关键实现

3.1 数据源怎么选：合规、稳定、可交叉验证

我们坚持一个原则：不用黑数据，不碰非公开字段，所有数据源都必须有明确的使用授权。第一路数据来自主流跨境平台的官方开放接口，包括商品信息、搜索热度、榜单和合规的结构化评论字段。第二路来自社交媒体和搜索引擎的关键词趋势接口，用来验证需求是短期爆发还是长期稳定。第三路是团队自己的店铺后台数据，广告点击率、转化率、退货率、实际运费，这些是利润模型的地基。

有个经验值得强调：数据源的稳定性比数据量重要。某个趋势接口偶尔返回超时，第一天没当回事，结果当天所有候选品的需求分全部偏低，选品清单被带偏。后来我们给每个数据源加了存活检测，失败时跳过该来源并回填最近7天均值，同时打上“数据不完整”的标记，让评分带着置信度一起输出。采集任务每天固定时间跑两次，保留快照，方便排查历史问题。

3.2 评论数据变成特征：情感打分与风险识别

评论是选品里信息量最大、也最容易被浪费的数据。只看好评率远远不够，“质量差、掉色、尺寸不对”这些高频差评关键词，往往藏着真实的退货风险。OpenClaw对评论做了两层处理：第一层用差评关键词规则和情感词典做粗筛，速度快、成本低；第二层只对粗筛命中的可疑文本调用大模型复核，避免把“质量好得不得了，用了三天就裂了”这种反讽判成正向。

def review_risk_score(reviews: list[str]) -> float: # 返回0~100的风险分，越高代表差评风险越大 risk_keywords = ["质量差", "掉色", "尺寸不对", "容易坏", "客服不理"] risk_count = 0 for text in reviews: text = text.lower() risk_count += sum(1 for word in risk_keywords if word in text) hit_rate = risk_count / max(len(reviews), 1) return min(100, round(hit_rate * 100 * 1.5))

这个函数只是示意，落地时关键词要按类目单独维护。比如服饰类重点看“尺码偏小”“褪色”，电子类重点看“无法开机”“充电慢”。类目不同，风险特征完全不同，一套关键词打天下会出大问题。

3.3 利润模型：把“看起来赚钱”变成“算出来赚钱”

市面上很多选品工具算的是毛利率，但毛利率不是真的利润。运营失败最常见的原因，是漏算了广告成本和退货损耗。我们把利润公式拆成了：

单件净利 = 售价 - 采购成本 - 头程物流 - 平台佣金 - 尾程配送 - 广告成本 - 退货损耗 - 汇率损耗

def estimate_net_profit(price, purchase_cost, shipping, commission_rate, ad_cost, return_rate, fx_loss_rate=0.02): commission = price * commission_rate return_loss = price * return_rate fx_loss = price * fx_loss_rate net_profit = price - purchase_cost - shipping - commission - ad_cost - return_loss - fx_loss return net_profit

举个例子：某候选品售价19.9，采购成本4.2，头程物流2.5，平台佣金率15%，广告成本每个1.8，退货率8%，汇率损耗按2%算。代入之后单件净利是6.1左右，净利率约30.6%，刚好过门槛。如果退货率从8%提到15%，单件净利就掉到不足4块，净利率跌破20%，直接淘汰。这个测算过程必须在选品报告里自动展示，运营才能知道每个分数背后的钱是怎么来的。

3.4 选品主流程与报告输出

主流程不复杂，就是加载候选、逐项算分、过硬门槛、输出决策。

candidates = load_candidates() scored_items = [] for item in candidates: item.features = compute_features(item) item.score = scoring_model(item) if (item.score >= 75 and item.net_margin >= 0.30 and item.purchase_amount <= 30000 and item.lead_time <= 20): item.decision = "进入测款" elif item.score < 60: item.decision = "淘汰" else: item.decision = "人工复核" scored_items.append(item) generate_report(scored_items, sort_by="score", output="选品看板")

报告不是给机器看的，是给人看的。每行候选品都带评分构成、风险标签、利润测算明细和“建议下一步动作”。选品师打开看板，先看“待人工复核”区域，再看Agent直接推荐的Top候选，有异议可以一键否决并填写原因。这个否决原因会进入反馈层，成为下一轮权重调整的依据。

4. 从15%到42%的三轮迭代：真正涨成功率的是运营动作

4.1 第一轮：评分规则上线，成功率只到20%

系统第一版上线后，成功率没有立刻起飞，只从15%爬到20%。问题出在好几个地方。首先是利润模型太乐观，广告成本按历史平均填，但新品的广告启动成本通常更高。其次是评论风险特征太少，很多差评点没被覆盖。还有一个隐蔽问题：不同数据源采集时间不一致，比如榜单是上午的数据，趋势是昨天的数据，放在同一个特征表里算分，时间维度对不上，评分自然失真。

这些问题靠看代码发现不了，必须把Agent推荐的候选品和最终测款结果放在一起对照。第一轮迭代给我们的教训是：模型上线只是起点，后面每一周都要拿真实结果去校准系统。

4.2 第二轮：让失败样本回流，修正评分偏见

第二个月做了一件看起来不性感但极其关键的事：建失败样本库。每个测款失败的商品都强制填写归因记录，包括失败表现、当时评分、哪项指标虚高、推测原因。每周跑一次归因统计，直接回溯到评分公式。

跑了两周，数据说话：失败商品里，需求分虚高的比例最大。很多商品在榜单上看着热闹，但等我们上架时，需求已经见顶了。于是把需求分权重从0.35降到0.30，利润分权重从0.30升到0.35，同时对上架超过12个月且销量增长平缓的商品，在需求分上做衰减处理。又过了一个月，成功率从20%爬到了28%。这个阶段验证了一件事：成功率不是调参调出来的，是把失败原因真正送回系统之后长出来的。

4.3 第三轮：人机协同SOP，42%不是模型单独跑出来的

到第三个月，我们意识到追求“全自动选品”是个伪命题。Agent适合做初筛和信息整合，但最终要不要测款，必须有人拍板。于是定了一个人机协同SOP：

• Agent评分80分以上：直接进入测款清单，每周不超过5个；
• 75到79分：需要选品师人工审阅；
• 60到74分：只作为信息参考，不触发测款；
• 60分以下：自动淘汰。

选品师每天固定花一小时处理Agent的推荐结果，重点看利润测算是否合理、风险标签是否漏判。刚开始人工否决率接近一半，后来随着反馈越来越准，否决率降到30%左右。但这个“否决动作”本身极其重要——它把人的经验变成了系统的训练信号。第四个月实测，成功率到了42%。

我想强调一点：42%不是Agent单独跑出来的，也不是选品师单独跑出来的，是人把决策权和系统反馈机制咬合在一起之后的结果。纯靠模型，可能永远停在30%。

4.4 月利润+8万是怎么算出来的

项目复盘时，我们把收益拆过一遍。月测款20款，成功率42%，意味着大约8款产品能跑过“连续4周日均出单不低于5件且净利为正”这条线。该团队所在类目的单款月均净利大约1.2万，8款就是9.6万。扣除服务成本、数据接口费用、开发摊销大概2万，月利润净增接近8万。

需要说清楚：这是特定类目、特定团队节奏下的结果。放到低客单价红海类目，单款月净利可能只有两三千，成功率即使提上去，利润也不会有这么好看。这套方法的价值在于“把选品从碰运气变成可迭代的系统”，利润数字只是结果之一。它不是一个可以照抄的收益承诺。

5. 常见问题排查实录：这些坑不解决，成功率会反复

5.1 数据源波动导致评分忽高忽低

有段时间评分系统经常出现“昨天推荐的品，今天分数掉了20分”的怪事。排查后发现不是模型问题，而是某一个趋势接口当天返回了空数据，清洗层把缺失值填成了0，导致所有相关候选品的需求分瞬间归零。修复办法分三步：第一，数据源增加存活检测，失败时自动跳过；第二，缺失值不回填0，改为使用最近7天均值；第三，候选品某个来源数据缺失超过50%时，整个打分结果标记为“低置信度”，降低排序优先级。数据质量问题的优先级永远高于模型调参。

5.2 评论情感分析水土不服

差评反讽是常见翻车点。“质量好得不得了，用了三天就裂了”这句话，普通情感模型会判成好评。我们加了一个前置规则：如果文本里同时出现质量相关正向词和损坏类负向词，就先把这一段挑出来，标记为“疑似反讽”，交给大模型复核。这个规则不复杂，但把评论风险分从“仅供参考”变成了“可进入评分模型”的状态。关键词表要按类目维护，每周从新增差评里补充新词，否则覆盖度会慢慢失效。

5.3 高利润低周转：资金链比选品更现实

Agent曾经推荐过一个净利率超过40%的商品，各项评分都很漂亮。但运营下单时发现，该商品国内交期长达45天，首单就要压15万资金。如果同时上3个这样的品，现金流直接断裂。后来在评分公式里加入两个约束：预计交期超过20天必须人工复核；首单采购金额超过3万必须人工复核。同时还增加了一个“周转天数”指标，不是所有高利润商品都值得做，要在利润和回款速度之间找平衡。

5.4 常见问题速查表

5.5 三条独家避坑心得

第一，失败样本库比成功案例库值钱得多。成功案例会让你复制错觉，失败样本才会告诉你哪里算错了。我们的规则是，测款失败的商品必须记录“当初为什么通过”，这个动作逼着团队承认判断失误，也逼着Agent暴露评分盲区。

第二，成功定义必须和评分标准对齐。如果系统按净利率打分，但团队实际把“出单量”当成功标准，两边永远对不上。先统一口径，再调模型，顺序不能反。

第三，别在初期追求全自动。我们踩过的坑是在系统还不稳的时候就关掉了人工审核，结果连续推了几个问题商品。让Agent当三个月参谋，确认它能稳定提供高质量初筛结果之后，再考虑放开部分自动化。自动化的前提是反馈闭环已经跑通，而不是模型分数好看。

6. 最后说点大实话：这套方法并不适合所有团队

6.1 哪些团队不建议直接照搬

如果你的团队一个月测款不到5个，先别急着上Agent，把人工选品SOP先标准化更有价值。系统有固定开发成本，样本量太小，连权重都校准不了。如果你的店铺后台数据还没打通，销售和广告数据靠手工导出，那利润模型就是空中楼阁，先把埋点和数据仓做好。如果你做的类目合规资质非常复杂，比如涉及特殊认证和准入，Agent再强也代替不了资质审核，把它当辅助工具就好。

6.2 真正值钱的不是代码，是复盘机制

从15%到42%，代码层面的技巧其实没有秘密：一个加权评分公式、几个硬门槛、一组数据管道，任何有经验的工程师都能写出来。真正的壁垒在于，团队是否愿意每周坐在一起，把失败商品摊在桌面上，逐条追问当初为什么通过。这套复盘机制一旦运转起来，选品水准是线性上升的。最后分享一个小技巧：把失败样本单独建一张表，每条记录必须回答“当初为什么通过”，两个月后回头看，你会发现自己对选品的理解比任何模型更新都更深刻。