这种小米加步枪的状态下，负责技术的老师傅就比较惨：

今天A团队为了把这堆数据捞回来，要请技术老师傅写一堆代码；明天B团队要把那堆数据捞回来，又得请老师傅重新写一堆代码。。。

老师傅长期被“请”，疲于奔命，秀发早晚不保啊。。。

不行，老师傅们一合计，得赶快开发出一套“A/B测试工具”——甭管是哪个团队，想测啥事儿，直接把系统拿去用，最好别霸占俺们的“肉身”。

Albert，就在这个“秀发保卫战”前不久加入字节，负责开发这个名叫“Libra”（天平）的A/B测试工具。

造这个工具的难点是啥呢？

你看，A/B测试最早是用在推荐算法的改进上，推荐算法团队的同学肯定是懂代码的，所以设计给他们用的A/B测试系统并不难；

可是后来，App 的设计团队也想用A/B测试来改进 App 的外观和逻辑，他们就不是那么懂底层代码了；

再后来，运营推广团队也想用A/B测试，决定哪种推广策略拉新效果更好，他们就完全不懂代码了。。。

所以，为了照顾所有人的使用，Libra 的界面就得尽量傻瓜，最好用鼠标拖拽的方式就能创造一个实验。

Albert 回忆。

于是，一群搞底层代码开发出身的老师傅坐在一起，把数据接入、实验设置这些核心功能搞定后，还得围成一圈开始研究怎样做出一个易用的界面。毕竟不是科班出身，搞出来的第一版界面蠢萌蠢萌的。

当时的界面找不到了，给你们看看现在的界面吧（局部）

很快，各个团队就七嘴八舌地对界面和逻辑提出了各种改进意见——底层数据怎么调度他们不太关心，但是界面和逻辑改进他们很有心得。

在各个团队的“威逼”下，Albert 他们只好硬着头皮继续改进，甚至还专门招聘了前端工程师。

一个给内部用的产品，真的值得在易用性上下这么大功夫么？

可能连 Libra 团队自己也没想到，这恰恰会演变成为后来故事的一个重要伏笔，我们一会儿再说。