一个止于选型，一个补上交付：两个项目复盘以及咨询顾问的价值定位
选对平台，只解决了"用什么"；完成交付，才能回答"有没有拿到业务结果"。顾问不跟 SaaS 抢生意，也不跟技术团队抢活——在采购、自建、交付、拿结果的全过程里，提供专家经验和指引。 作者：zhanbo · 2026-07-13 tl;dr 两个 Studio 都采购过火山引擎 ABTester：一个项目我参与到选型，一个项目我补上了后续交付。它们恰好说明，顾问的价值不在于"卖平台"或"替研发写代码"，而在选型和交付两端提供专家指引，把工具转化为业务结果。 我推出了「实验平台落地诊断」和「发行平台提效诊断」，本季度限 2 家。邮件 zanhe@139.com 或加微信 zanhe1984，主题写"实验落地"或"发行提效"，帮你判断采购、自建、交付这条链上，专家经验应该补在哪一段。 两个 Studio，两种参与方式 2025 年，我先后接触了两个游戏团队的实验能力建设项目。为保护客户信息，本文分别称其为 Beta Studio 和 Alpha Studio。 Beta：研发资源有限，选择 SaaS 快速起步 2025 年中，Beta 希望升级实验能力。 当时业务部门有明确需求，但缺少足够的专项研发资源。在内部自建与采购 SaaS 之间，团队最终选择了火山引擎 ABTester，希望借助成熟产品更快建立实验能力。厂商的行业影响力和已有案例，也是选型的重要因素。 我参与了前期咨询和选型讨论，但没有继续跟进后续交付，因此无法评价项目最终效果。 这段经历留下的核心问题是： 买到平台，只是确定了实验能力的技术载体，并不代表企业已经获得了实验能力。 选型结束后，仍有一系列问题需要解决： 业务数据和实验参数如何接入； 参数配置是否依赖软件版本发布； 指标口径和验收标准如何定义； 流量框架是否适合实际业务； 谁负责平台运营和实验复盘； 实验结论如何进入业务决策。 这些问题不会随着合同签署自动解决。 Alpha：有了自建分流，为什么仍然跑不快？ Alpha 在 2024 年上半年也采购了火山引擎 ABTester。由于实验参数与软件发版耦合较重，团队随后自建了分流能力。 但第一版只支持互斥桶。 互斥桶可以避免实验冲突，却会把流量切割成相互独立的区域。随着实验数量增加，可用流量很快成为瓶颈。平台虽然"能跑实验"，却难以支持产品、算法和商业化团队同时开展大量实验。 我是在这个阶段作为顾问参与项目的。 后续迭代中，团队引入了类似 Google 重叠实验基础设施的分层、分域和正交流量框架。只要实验修改的参数和影响范围不同，就可以在控制冲突的前提下共享流量。 升级之后，平台能够支持上千量级的实验并发，产品交互、算法和商业化实验得以大规模并行，并最终明显推动了北极星指标。 真正产生价值的不是"并发数字"本身，而是团队建立了一条完整链路： 业务假设 → 实验配置 → 并行验证 → 指标分析 → 上线或回滚 → 收益追踪 ...