执行摘要
十个核心判断、三类读者的行动建议，以及一份可执行的推荐路线。先看结论，再回到章节里的证据。
0.1 一句话结论#
A/B 测试平台已经从「页面优化工具」演化为「产品决策的基础设施」。 2023-2026 年的停服与并购证明：只做可视化编辑器的产品会被替代，只做 Feature Flag 的产品会被统计层卡住，只做统计的产品会被数据架构卡住。真正稀缺的能力不是「能开实验」，而是可信的统计、统一的指标口径、低延迟的分流、以及能约束组织的治理机制。
0.2 十个核心判断#
判断一：市场没有全能冠军，选型必须先画「缺口图」。
市场至少分成七类玩家：Web 优化套件、企业个性化套件、Feature Flag/交付、现代实验平台、云厂商/边缘原生、开源自建、中国大厂自建/对外输出。每类只覆盖「决策/分流/指标/统计/治理」中的几层。拿一张功能清单横向打勾，是最容易选错的起点。
判断二：2023-2026 的关键词是「整合」，而且被收购不等于更安全。
Harness 宣布收购 Split（2024-05-29 宣布、06-11 交割）、Datadog 收购 Eppo（2025-05）、OpenAI 以 11 亿美元收购 Statsig（2025-09），随后 Statsig 的产品与客户在 2026-05 转给 Amplitude；VWO 与 AB Tasty 在 2026-09 统一为 Wingify；SiteSpect 并入 Monetate。停服侧，Google Optimize（2023-09-30）与 AWS CloudWatch Evidently（2025-10-17）退出。收购方要的往往是团队与内部能力，不一定是继续经营这个 SaaS。 选型必须评估数据导出、SDK 替换与「控制权变更」条款。
判断三：统计引擎的差异不在「方法名」，而在默认参数与产品化程度。
几乎每家都宣称支持频率派、贝叶斯、序贯、CUPED；真正拉开差距的是：默认用哪种方法、是否允许 peeking、多重比较怎么校正、比率/分位数指标怎么算、SRM 能否自动定位、护栏指标是否内置、结果是否可解释。「支持 CUPED」不等于「CUPED 实现正确」，更不等于「业务方看得懂」。
判断四：Warehouse-native 是 2023-2026 最重要的架构分化。
Eppo、GrowthBook 把指标计算下推到客户数仓，解决「数据不出域、口径统一、不重复建管道」三个问题；Statsig 等自建事件管道，强调实时与开箱即用。前者适合数据成熟、指标复杂的公司，后者适合追求上线速度、实时性强的团队。没有数仓口径的公司，上 warehouse-native 是空中楼阁。
判断五：Flag 与 Experiment 在融合，但「发布安全」与「因果推断」仍是两种产品。
Harness FME、Statsig、Eppo、GrowthBook 把 Flag 与实验放在同一套 SDK/曝光上；LaunchDarkly 转向「Guarded Releases」（按护栏指标自动回滚），但它同时有独立的实验统计引擎（默认频率派，支持贝叶斯/序贯/CUPED/SRM），只是产品定位仍偏发布安全；Cloudflare Flagship 则只做 Flag、不做统计。融合是产品趋势，不是行业标准。 组织上应「同一数据模型、不同权限与流程」，不要把发布事故和实验结论绑在一起。
判断六：中国大厂的强项是「规模 + 业务耦合」，但公开资料严重不足。
字节（内部 Libra / 对外火山引擎 DataTester）、阿里（淘天/阿里妈妈/阿里云多条线）、腾讯（业务自建为主）、美团/滴滴/百度（交易与双边市场实验）都有成熟实践，但公开的架构、统计方法、实验数量远少于海外。对外产品与内部平台不能划等号；很多能力只存在于演讲和招聘 JD 中，报告已逐条标注「待核实」。
判断七：开源已能覆盖 60-70% 的标准需求，但「最后一公里」仍要自建。
GrowthBook 覆盖实验编排、频率派/贝叶斯、CUPED、SRM、warehouse-native；PostHog 强在「分析 + 实验 + 回放」一体；Unleash/Flagsmith 强在 Flag。但实验治理、超大规模分流、跨端一致性、实时指标、中国私有化仍需自建。GitHub star 严重误导：PostHog 40k star 来自产品分析，FeatureProbe 1.6k star 但已停更两年。
判断八：自建的真实成本不是服务器，而是「统计 + 指标 + 组织」。
一个 6-10 人的平台团队，3 年人力成本通常在 1900-3300 万人民币（按 80 万/人年）；开源自建（3 人 + 0.5 SRE）约 1350-2000 万，但需要接受统计与治理的二次开发。省钱的不是「不用买软件」，而是「不重复造轮子」。
判断九：采购的核心不是买功能，而是买「可信度 + 退出能力」。
实验平台的资产是实验元数据（定义、分层、Holdout、曝光、指标口径、历史结论），不是 UI。合同必须写入：数据导出范围、迁移支持期、控制权变更终止权、SLA（分流 p99、可用性、配置下发延迟）、按曝光/实验计价而非纯 MAU。不能带走的实验记录，等于没有。
判断十：AI 让实验对象从 UI 变成模型，但方法论还没跟上。
2025-2026 年厂商都在讲「AI 实验」：LLM Trace/Evals、prompt/模型版本对比、Agent 行为评估。已落地的是「用 AI 辅助写假设/生成变体/解释结果」；真正的新统计问题是「非确定性输出、会话/请求级随机化、延迟与成本护栏、LLM-as-judge 偏差」。目前多数是厂商叙事，缺少公开的方法论与可复现基准。
0.3 给三类读者的建议#
给 CEO/产品负责人：
- 不要把「实验数量」当 KPI，把「有决策的实验占比」和「实验周期」当 KPI。
- 先选一个业务做 90 天试点，用真实指标验证「可信度」，再谈全公司推广。
- 预算按「3 年 TCO」算，不要按第一年 license 算；自建的人力成本通常是软件费的 3-5 倍。
给技术架构师：
- 决策面与度量面解耦；SDK 用 OpenFeature 抽象；曝光落数仓；统计引擎可替换。
- 分流服务必须无状态、确定性、可离线求值、fail-open；p99 < 20ms 是底线。
- 不要把统计逻辑写进业务代码；不要把实验配置和发布配置混在一个权限体系里。
给实验平台负责人：
- 先建「曝光 + 指标 + SRM + AA test」四件套，再建可视化编辑器和 MAB。
- 实验治理（分层、互斥、Holdout、审批、冻结）是平台的核心资产，不要外包。
- 每季度做一次「实验结论复核」，公开失败案例；信任是平台最贵的资产。
0.4 推荐路线（针对 DAU 千万级、已有数仓的公司）#
| 阶段 | 时间 | 做什么 | 不做什么 |
|---|---|---|---|
| MVP | 0-90 天 | 服务端 SDK、单层分流、曝光管道、频率派 + SRM、10-20 个实验 | 可视化编辑器、MAB、CUPED |
| 规模化 | 90-180 天 | 多端 SDK、正交分层、互斥、Holdout、CUPED、warehouse-native、RBAC/审批 | 实时指标、AI 实验 |
| 智能化 | 180-365 天 | 实时链路、Switchback/Interleaving/MAB、CATE、AI/LLM 实验、私有化 | 纯自研统计引擎（除非有统计团队） |
最务实的组合：自建分流与治理 + 采购/复用 warehouse-native 统计（GrowthBook/Eppo by Datadog）+ OpenFeature 解耦 SDK。3 年 TCO 通常在 1000-2000 万人民币，比纯自研低 50% 以上，比纯 SaaS 更可控。
0.5 本报告的局限#
- 厂商架构与统计实现多为商业机密，本报告只能核实「官方是否宣称 + 文档是否给方法」，不能替代真实数据复现。
- 价格极不透明，报告中的 TCO 是量级估算，不是报价。
- 中国公司公开资料滞后，平台名称、上线时间、实验数量多有「待核实」标注。
- 市场在快速整合，建议每 6 个月复核一次厂商状态与合同条款。