平台已经投入工程量做了两套「按接码率/成本/延迟智能选供应商」的系统——Smart Routing Scorer 和 Combo-Health 自愈下架——但两者在生产环境都是关闭状态。代价最直观地体现在 Telegram（第 2 大量服务）：主供应商 durianrcs 每次发号只有 6.3% 真正收到码，而同样在线的 sms-bus 是 12.5%（2 倍），可路由仍按静态优先级把更多流量给了更差的那家。把已建好的 scorer 打开（先 shadow 验证），Telegram 成单量有望接近翻倍。
近三周订单量在 800 ~ 2,300/日 间波动，6/19–6/21 出现明显低谷后于 6/22–6/24 回升。GA4 交叉验证：同期活跃用户从 ~1,850 跌到 ~1,000 再回到 ~1,630——订单波动 = 流量波动，转化率（订单/访问）基本稳定，排除了供给侧故障。所以量的波动不是今天要讲的事；真正的钱漏在转化结构里。
把近 24h 按服务拆开，完成率两极分化得非常干净：
| 服务 | 24h 订单 | 完成率 | 取消率 | 判定 |
|---|---|---|---|---|
| openai | 510 | 48.4% | 22.2% | 健康 |
| telegram | 370 | 9.7% | 44.6% | 漏点 #1 |
| 157 | 8.3% | 56.7% | 漏点 #2 | |
| 139 | 10.1% | 59.7% | 漏点 #3 | |
| codebuddy | 120 | 25.0% | 27.5% | 中等 |
| bybit | 26 | 50.0% | 7.7% | 健康 |
这不是临时抖动——14 天每日趋势里，telegram 稳定在 4–10%、whatsapp 3–9%、google 6–15%，而 openai 始终 40–58%。结合 GA4「中国 3,906 / 香港+台湾+新加坡 ~1,400 / 美国 1,899」的华语为主受众，telegram/whatsapp 是刚需高量服务，它们的低转化直接拖累整体大盘。
关键指标是 sms_per_alloc（成功发号后真正收到码的比例）。以 Telegram 近 7 天为例，同样把号发出去了，各供应商的收码率差到 3 倍：
| 供应商（Telegram, 7d） | 成功发号 | 收到码 | 收码率 | |
|---|---|---|---|---|
| durianrcs.com 主供应商·优先级最高 | 646 | 41 | 6.3% | |
| sms-bus.com | 416 | 52 | 12.5% | |
| grizzlysms.com | 294 | 22 | 7.5% | |
| isptelecom（自营池） | 327 | 13 | 4.0% | |
| 5sim.net | 230 | 9 | 3.9% |
矛盾点：质量最好的 sms-bus（12.5%）拿到的发号量反而比质量只有它一半的 durianrcs（6.3%）少 55%。原因是生产路由当前按静态优先级 + 跨家 fallback 选供应商，完全不看历史接码率——主供应商 durianrcs 排第一，先把流量吃掉，收码效果差也照样优先。
读 main 分支代码 + 查生产配置/数据，确认了三件事：
| 机制 | 代码状态 | 生产状态 | 证据 |
|---|---|---|---|
| Smart Routing Scorer 按 0.6·接码率 − 0.3·成本 − 0.1·延迟 重排供应商，含 Bayesian 平滑 | 已实现 scorer.go | 关闭 | supplier_routing.scorer.enabled: false；SigNoz 近 24h「scorer」日志 0 条 |
| Combo-Health 自愈下架 接码率跌破 1% 死亡线自动隐藏 supplier+service+country 组合 | 已实现 combo_health_worker.go | 关闭 | combo_health.enabled: false；combo_health_decisions 表 0 行 |
| 性能快照管道 scorer 的数据燃料 | 已实现 | 运行中 | 24h 快照 最新于 19:53 更新（查询前 15 分钟）——数据是新鲜的，开了就能用 |
也就是说：系统每分钟都在采集「哪家收码率高」的数据，也有现成的引擎会据此优选供应商——但引擎被停在灰度上线的前一步。配置注释显示这是一个分阶段 rollout（Day 8 切 shadow、Day 15 切实跑），中途停住了。
把 1,913 次发号按 sms-bus 的 12.5% 折算 ≈ 239 次收码，比当前 137 多 ~100/周（+74%），仅 Telegram 一项。绝对利润目前体量仍小（telegram ~$13/周完成利润），但同一个质量路由杠杆对所有多供应商服务通用——这是一次性「打开已建好能力」的高杠杆动作，而非新建工程。
shadow 模式只记日志、不改任何订单分配，用来对比「scorer 本来会选谁 vs 实际选了谁」，积累 24h+ 再决定是否实跑：
# backend/config/config.production.yaml
supplier_routing:
scorer:
enabled: true # 从 false 改为 true
shadow_mode: true # 保持 true：只对比、不改单
观察 SigNoz 里 scorer 决策日志，确认它对 telegram 会优选 sms-bus；shadow 数据健康后再切 shadow_mode: false 实跑。回滚成本：改回 enabled: false 即可。
让 isptelecom×google（0.9%）这类确定性失败组合被自动隐藏，停止空烧自营池产能并减少必然取消。注意现有 min_sample_size: 100 是按 24h 窗口算的，而 isptelecom×google 24h 样本仅 ~18，可能触发不了——上线时建议同时确认阈值能覆盖这类「低量但长期死亡」的组合。
orders / supplier_execution_attempts / supplier_performance_snapshots / combo_health_decisions 复算。