Booking.com 将每个产品改动都置于 A/B 测试之中——同时进行超千个测试

随着 Booking.com 成长为最大的旅游市场之一，产品团队面临凭主观意见做决策的风险。公司开展在线受控实验已超过十年，希望不只是产品经理，所有人都能低成本、安全、有可靠数据地验证想法。

让实验成为默认的决策系统：每个改动，哪怕是修复 bug，都包裹在 A/B 测试中上线，任何人都能发起测试、查看历史记录、停止有害测试。

工程师搭建了内部实验平台，包含可搜索的历史仓库，记录以往每次成功和失败；提供通用的招募、追踪和指标 API；两套独立监控管道；A/A 测试池；以及预注册和成功同行评审等保障措施。每个部门都有专属支持团队，任何人都能端到端地负责实验。

在移动应用、酒店老板工具、客服电话线及内部系统上同时进行的实验超过一千个；每个重新设计、基础设施改动和 bug 修复都在测试中上线，产品决策从主观意见转向实证，且学习经验在团队间共享。

在 Booking.com，实验不是某些团队使用的工具，而是公司决策的方式。十多年来，这家旅行平台一直推行基于证据的产品开发，到 2017 年，各部门每天并行运行并分析超过一千个实验，覆盖移动应用、酒店老板工具、客服电话线和内部系统。

刻意的选择是去中心化。实验平台作为可搜索的仓库，记录从第一个实验起的每次成功与失败，任何人都能查阅历史、提出新假设。通用 API 抽象了招募、随机化和报告，每个部门有专属支持团队，因此运行测试无需产品管理层的许可。

信任来自工程纪律：两套独立维护的管道计算相同指标并互相对照，一组 A/A 实验验证统计有效性，预注册和成功同行评审等措施遏制 p-hacking。公司内任何人都有权自行停止有害实验。

结果正如工程师在 2017 年论文中所写，“每一个改动，从整个重新设计到基础设施改动，再到 bug 修复，都包裹在实验中”——产品开发变成一系列可衡量的赌注，而非一连串主观意见。

去中心化的实验让数千人能测试想法，而无需等待产品经理安排优先级。

可搜索的成败历史让团队能够回顾并借鉴彼此的经验。

可信的基础设施（双管道、A/A 组、预注册）使得证据成为决策的仲裁者。

保持实验平台与业务逻辑松耦合，让推出成功改动变得像移除一个 API 调用那样简单。

授权任何人停止有害实验，使安全与速度兼容。

如果每个人都能进行低成本、安全的实验，就不需要达成意见一致：基础设施加上实证文化，将决策变为测试，将失败变为共享、可搜索的学习。

这一由阿姆斯特丹工程师在 2000 年代中期开发的内部框架，不断扩展但从未重写；到 2026 年，据 Silicon Canals 报道，Booking.com 仍在生产环境预订页面同时运行超千个测试，每年累计实验数万次，0.1% 的转化率变化就相当于八位数金额。这种模式以“实验文化”传播到整个行业——第三方平台、公开手册和其他科技公司都采用了 Booking.com 开创的默认测试模式。