一句话结论：过去 3 天（7/3–7/5）平台毛利率从稳定的 ~51% 塌到 ~44%（单均利润 −20%），同时 OTP 取号失败率翻倍到 ~33%（含刷单用户 37%）。根因不是流量、不是获客、不是现金流——这三项都稳。真正的问题是：供应商侧成本上涨 + 交付质量下滑，而平台对此「经济无感知」——质量路由 scorer 在生产是关闭的，供应商健康监控只看余额（全部显示「OK」），看不到交付崩盘。利润正在从我们看不见的地方漏出去。
完成单的绝对量基本没变（~264 单/日），但每单的经济结构在恶化。下表是近 3 周完成单的单均售价 / 成本 / 毛利率——可以清楚看到 7/3 是拐点：
| 日期 | 完成单 | 单均售价 $ | 单均成本 $ | 毛利率 | |
|---|---|---|---|---|---|
| 6/25 | 345 | 0.414 | 0.198 | 52.2% | |
| 6/26 | 257 | 0.372 | 0.174 | 53.2% | |
| 6/29 | 290 | 0.351 | 0.155 | 55.7% | |
| 6/30 | 291 | 0.422 | 0.197 | 53.4% | |
| 7/1 | 291 | 0.454 | 0.214 | 52.8% | |
| 7/2 | 315 | 0.371 | 0.187 | 49.6% | |
| 7/3 | 271 | 0.383 | 0.209 | 45.6% | |
| 7/4 | 267 | 0.394 | 0.227 | 42.4% | |
| 7/5 | 254 | 0.369 | 0.203 | 45.0% |
→ 售价几乎不动（$0.37–0.45），但成本从 ~$0.18 抬到 ~$0.21。差值直接吃掉利润：单均利润 $0.212 → $0.169（−20%）。按 264 单/日算，约 $11–14/日利润凭空蒸发（≈ 全站完成单利润的 1/5）。
拆解完成单的单均成本（基线 6/28–7/1 vs 近 3 天 7/3–7/5）：
| 供应商 | 完成量占比 | 基线成本 $ | 近期成本 $ | 变化 |
|---|---|---|---|---|
| durianrcs.com | ~70% | 0.142 | 0.159 | ▲12% |
| grizzlysms.com | ~18% | 0.327 | 0.211 | ▼35% |
| 5sim.net | ~6% | 0.220 | 0.395 | ▲80% |
| sms-bus.com | ~5% | 0.378 | 0.727 | ▲92% |
→ durianrcs 承载 70% 完成量，它的成本 +12% 就是全站毛利下滑的主推力；小供应商（5sim / sms-bus）成本暴涨但量小。我们的售价对这些变化没有任何自适应。
整站失败率：中旬约 17% → 7/5 达 36.7%（剔除单个刷单用户后仍有 33.0%，说明是普遍现象）。失败几乎全部是 cross_supplier_fallback（跨供应商 fallback 全部耗尽 = 谁都给不出号）：586 单/24h vs 322 单/日基线。
致命细节：在最热门的格子里，连主力 durianrcs 都是 0% 交付（24h 窗口，scorer 若开启会读的正是这份快照）：
| 格子 | 供应商 | 尝试 | 收到短信 | 接码率 |
|---|---|---|---|---|
| whatsapp / US | durianrcs | 60 | 0 | 0.0% |
| whatsapp / FR | durianrcs | 34 | 0 | 0.0% |
| telegram / HK | durianrcs | 75 | 0 | 0.0% |
| telegram / US | durianrcs | 155 | 18 | 11.6% |
durianrcs 在这些格子拿到最多尝试量，却交付 0 条——但因为它余额充足（274k SCORE，state=OK），健康监控完全没报警。
代码里已经有一套 Smart Routing 评分引擎（backend/internal/service/supplier/scorer.go），按 24h 贝叶斯平滑接码率（权重 0.6）+ 成本 + 延迟给供应商打分重排。它读的 supplier_performance_snapshots 快照数据新鲜（20 分钟前刚算）、已就绪。但 config.production.yaml 里 supplier_routing.scorer.enabled: false——整个引擎处于关闭状态，供应商 fallback 顺序是静态的，durianrcs 交付 0% 也照样分到最多首选流量。
诚实标注：纯「明显误路由」（同格子有明显更优的兄弟供应商）经测算只占 ~2% 尝试量——所以打开 scorer 不是银弹（很多热门格子是所有供应商集体缺货）。但它是让路由「对质量自适应」的正确结构方向，且已建好、零新增成本。
健康监控周期性拉 GetBalance()，durianrcs 余额充足所以永远「OK」。但它不看接码率——一个余额满格却在热门格子 0% 交付的供应商，运营从告警侧完全看不到。这正是本次问题拖了 3 天没被发现的原因。
| 维度 | 近期 | 判断 |
|---|---|---|
| 充值现金流入 | ~$430–478/日 | 稳定 ✓ 非现金流问题 |
| 新用户注册 | ~300–342/日 | 稳定 ✓ 非获客问题 |
| GA4 活跃用户 | ~1,340/日 | 稳定 ✓ 非流量问题 |
| GA4 渠道结构 | Organic Search 第一 | 正常 ✓ organic 未崩 |
| 完成单绝对量 | ~264 单/日 | 持平（是「每单更不赚钱」而非「卖得更少」） |
→ 所有需求端指标都稳。问题 100% 在供应链经济性（成本↑ + 交付↓），且被平台的静态定价 / 静态路由放大。
今日 flipkart/IN 的 110 单全部来自 1 个用户（93 单集中在 17:00 UTC 一小时内），86% 失败。这是「对着一个供应商给不出号的死格子疯狂重试」的滥用模式——它烧供应商调用 + 污染失败率指标，而现有的「活跃订单数上限」拦不住快速失败重试（失败单不占 active 名额）。影响有限但值得加个冷却。
打开 Smart Routing scorer 的 shadow 模式（enabled: true + shadow_mode: true）。shadow 只写决策日志、不改分配，用户零影响，正是运营文档里规划的「Day 8」步骤。先跑 24–48h 看 shadow 对比日志，验证后再切 shadow_mode: false 让它真正接管路由。（本次未自动改此配置：属生产路由行为变更 + 运营明确要求先 staging 验证，交由人来扣扳机——2 行改动。）
给供应商健康告警加「交付率」维度，不只看余额。当某供应商在热门格子（≥N 尝试）接码率跌到近 0% 时，飞书告警到运维群。这能把「durianrcs 余额满格却 0% 交付」这类问题在几小时内暴露，而不是 3 天。
Review 售价 markup 是否跟得上供应商成本。3 天 margin −7pp 的直接原因是成本涨了售价没动。至少对 durianrcs 主力格子做一次成本→售价的重新校准（或引入随成本浮动的动态 markup）。属定价决策，需产品/创始人拍板，未自动改。
对「短时间高频失败重试」加冷却（如同一 user 对同一死格子 N 次失败后短暂限流），避免单用户烧供应商调用 + 污染核心指标。
方法与可复核性：所有 DB 数字来自 production 只读库 supplier_execution_attempts / orders / topups / users / supplier_performance_snapshots / supplier_balance_snapshots；时间以 UTC 计，「now」=2026-07-05 20:08。GA4 取自 property 512790783（近 14 天 activeUsers/sessions/newUsers + 渠道）。代码交叉确认：scorer.go（评分逻辑）、routing.go（候选与重排）、config.production.yaml:439（scorer enabled=false）、cmd/worker/main.go:369（wiring）。
本报告由自动化经营日报任务生成 · 数量在精不在多，本期聚焦 1 条主洞察 + 关联结构性根因。