> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2024-nian/sui-bi-ji-he-man-tan-pian.md).

# 随笔集合——漫谈篇

年前调研了AB平台的建设，详细内容汇总在[AB问题域](https://km.sankuai.com/collabpage/2103469706)。

1. 我们所处阶段的判断。从实验成熟度模型看，鲸湾大约在行走阶段，其余业务在爬行阶段。爬行就是成熟度模型的第一个阶段了，再往前，我觉得可以叫觉醒或者启蒙阶段。爬行阶段的目标是构建基本的实验条件，特别是工具和基本的数据科学能力。
2. 公司内身位靠前的AB平台。团平台的Horizon和到家履约的AB平台重点交流过。大约处在奔跑阶段，演进方向都是规模化地降低实验门槛，确保实验置信。避免实验者将大量精力放在方案的论证上和人为因素导致的实验置信问题。引入了数据科学相关岗位。从衡量指标上就可以体会到，是从接入、分流、实施、决策通盘看的。比如平台新上实验客观性可判断率，重要实验结果的客观率。
3. **从到家履约AB平台的发展历程得到的启示。这些信息来源于我与其中一名核心成员的交流，在我看来这是一个典型的技术服务业务的样本。持续迭代技术与业务之间的特定关系，最可贵的是“业技融合”的思维和人才。**像这样的专业领域，业务是描述不清问题的，甚至有时候也意识不到问题。想服务好业务，就必须走出自己的领域，深入前线、了解业务、切换视角。履约是到家的核心，所以履约的效率提升至关重要。LBS的多边模型需要大量的算法和策略实验，所以对高水平的AB实验平台的诉求更强烈。最开始是平台和业务松耦合的方式运转，平台化的轻快特征更显著。2022年转向专注服务履约，做全托管式的服务。业务只需要提需求，实验设计、实施、分析都会闭环在数据团队。提供的不仅仅是能力，而是解决方案，包括能力、工具、方法等。在业务挑战足够大的深水区，履约也较早的探索了与科研合作这条路。在开放方面，履约AB提供了三个开放层次，平台全托管、平台半托管，以及分析引擎开放。分别对应，平台统一管理、实验设计与实验评估能力的开放，原子分析方法粒度的开放三种方式。

***

最近回顾组件库专项，尝试回答一个很模糊的问题，如何成为一个极具生命力的组件库？组件库太常见了，通常来讲这个事情是清晰简单易理解的，但其实能做到流行、好用、活得久的屈指可数，尤其是能活得久的。尝试从两个角度来回答。

**解决给定范围内的真问题，保持正向的投入产出比。**

在目标价值层面找到自己面临的真问题，详实的调研后，切实解决真问题。关注解决什么范围下的问题，不同范围下面临的成本、方案选择不同。比如面向美团、金服、团队内的组件库，在目标价值上可能都不一样。

对于价值爆破面本身就有限的项目，投入产出比是需要时刻警惕的，因为很可能不知不觉地维护成本超出了真实价值，这在中长期是会得到纠偏的。最近大家感叹YAPI这种体验更优的接口mock工具停止维护，PAPI依然是官方首推。且不论两款工具在组织层面的异同，就投入产出比讲，我推测YAPI带来的维护成本已经高出给开发者带来的体验价值增量。我没有数据论证，仅凭大多数项目没有选择迁移到YAPI这个结果来看，可以佐证体验价值增量是微小的，甚至都没有抵消迁移成本。

**在正确的抽象层次解决问题。**

问题的本质+所处的范围，才是真问题。组件库其实已经是一种解决方案了，在一些高层次的范围下，组件库可能不是最优解。随着抽象层次的递进，可以粗略的把解决方案划分为实现、库、框架、标准。组件库是第二个抽象层次的方案，我认为这是MTD为什么没搞成的原因。社区里有一个叫[A Global Design System](https://component-odyssey.com/articles)的项目，愿景是为全球的设计师和开发者提供通用组件，事实上它不是一个组件库，它是一个System，但也不是一个像Material Design的设计系统。这样的项目不必在意能不能成，重点是学习如何在一个高抽象层次的命题下进行探索。

***

业务团队的技术事项可以分为两大类。一类是解决当前阶段的突出问题，需要集中兵力各个击破，往往以技术专项的形式推进。一类是需要长期建设和运营的，比如组件库、Infras等工程基建，这类事情绵密持续，需要久久为功，缺少合适的运行机制。事实上，这种运行机制也可以部分回答如何保持基建活性和生命力这个重要的课题。

随着团队规模的增长，以及工程基础的不断夯实，也要求我们的工作重心逐渐从运动式转向长效式。

我们的基建走过了从0-1的阶段，需要探索从1-∞的经验。目前的运行机制偏向封闭，封闭就会依赖个人。团队内贡献积极性不高，依赖行政指令。我的思路是向成熟的开源项目取经，建立开放可持续发展的工作机制，激发团队的创造力。

草拟版本[工作组机制 Working Group](https://km.sankuai.com/collabpage/2610619313)。采用了Working Group这个概念，引入了RFC、Membership等机制。同时结合团队规模，平衡效率与开放，做了裁剪和定制。对此有想法的同学，欢迎多提意见。

***

最近随着业务在账本上的调整，前后端都面临架构合理性的问题。架构合理性可以直接反映到质量上，生意卡的重构始于此。聊聊有关前端业务架构的理解。

1. 架构，在前后端是一个不对等的存在。前端在业务架构设计上还没有充分共识，大家更多聊的是框架和工具链的选择。一个主要的原因可能是前端在架构方面受到的挑战更少。业务架构决策所带来的瓶颈，在很多项目的生命周期中永远遇不到，一套脚手架搭出来的通用工程就能满足业务的天花板要求。
2. 什么属于架构决策？什么不属于架构决策？架构是通过沟通、分析和推理的结果，而非简单的工具选择。只关注最终交付的目录结构和文档，容易忽视诸如隔离与复用、状态管理、依赖倒置等重要的架构概念，这些方面更关乎实际质量和业务需求的支持能力。比如游戏领域的ECS架构，解决的就是特定领域的可维护性问题。
3. 是否有必要将前后端架构分开，还是说只需一个通用的架构团队即可？这个问题很庞杂，系统结构会自然反映团队的沟通方式，康威定律的部分不展开。有两个观点可以讲讲。第一，整体架构设计会慢慢把前端考虑进去。我们还处在小众语言让主流语言理解工作内容的过程，看到质效上已经开始考虑前端了（虽说技术风险防控考试还像是一份脱产的软考试题），架构上是不是也不远了。第二，前后端是可以相互借鉴的。前端可以从DDD等后端设计思想中获益，以更好地理解业务问题。后端可以学习前端高效的原型设计方法以及组件即服务的思维方式。
4. 理解前端架构必读[What is Frontend Architecture?](https://ducin.dev/what-is-frontend-architecture)，这个领域可以持续关注作者Tomasz Ducin。

***

关于物理极限、工程极限、体验极限。尝试解答上周观察到的一个问题，我们聊优化是聊的什么层面的优化，做优化是在什么边界内做优化。

物理极限的意义在于了解根本限制，在复杂的创新过程中保持清醒，做出更明智的资源投入。至今还有民间科学家在搞永动机，19世纪的卡诺就证明了热机效率存在理论上限，所以搞永动机注定徒劳。现在也有不少人认为随着AI的发展会解决所有问题从而替代人类，20世纪的图灵其实就能明确回答这个问题。世界上有很多问题，其中只有一小部分是数学问题，再其中一小部分是有解的，再其中一部分是图灵机可计算的，再其中一部分是现有计算机能实现的，AI能解决的问题只是以上的子集。物理学的极限几乎不可能推翻，数学上的极限，属于完全不可能推翻，因为数学是严格建立在逻辑之上的，不是根据实验观察得到的。

工程极限的意义在于让工程实践更具方向性和效率。在已知的物理边界下，通过多维度优化提升性能，在工程层面找到最优解。比如用蓝光代替红光做的DVD，就利用了蓝光更短的波长，实现了更大的容量。从2G到6G的发展，也没有突破香农设定的一定带宽和信噪比下，信道容量的理论上限。每一代都是在频谱、编码调制、网络架构等方面做工程优化。摩尔定律如今还在上演，在逐渐逼近的硅材料物理极限下，我们看到工程上还可以通过3D堆叠等封装技术改进，SOC、异构计算等架构优化来不断提升性能。

体验极限的意义在于认清这是一场无限游戏，体验是在和边界玩。因为人类的需求、期待和想象力本身就在不断进化，无论技术进步到何种程度，围绕MOT 、人因的体验优化是永远做不完的。这样就不存在技术发展到什么程度就不用优化什么的问题了。

***

读过《现金为王》。收入是虚空的，利润是明智的，而现金才是王道。这尤其适用于现在的存量时代，效率为王。竞争不再是单纯的规模扩张、追求增长，而是效率的深度挖掘。

书中用体重管理来类比“现金为王”的逻辑结构。

1. 用更小的盘子。节俭，把运营成本框在一个合理的有限资源内。有一个叫帕金森定律的经验法则，说人们对某物的需求会随着供给的增加而增加。这就是为什么扩建道路以减少交通拥堵永远不会奏效，因为总有更多司机开车来填满那些扩建出的车道。
2. 先吃蔬菜，再吃碳水。把会计中的经典公式“营业收入-成本费用 = 利润”，改写为“营业收入-利润 = 成本费用”。先把利润割出来，再看剩下的钱怎么花。这个依据是首因效应。
3. 消除诱惑，藏好不该吃的。把留出来的利润、股东收益、收税等放到一个单独的账户里，最好不太方便提取。
4. 少食多餐，削峰填谷。每月两次查阅银行余额，从可支配的现金倒推经营情况，最简单的银行余额记账法。

联想到苹果的睡眠管理对闹钟的重新设计，记不清是从iOS几开始的了。一般定闹钟的逻辑都是关注几点叫醒。苹果的睡眠闹钟在交互上是让用户先关注睡眠时长的目标，根据这个目标再调整应该几点睡，几点起。这就属于理念变化在产品设计上的投射，利润为先应该在小账本上也有如此投射。

***

半浮层收银台重构后放量一直是一件悬而未决的事情，现在到正面决战的时候了。面对一件消磨团队意志快一年的事情，再次面对，我有两个选择，我把这事解了，或者我带人把这事解了。从胜任管理的角度看，我觉得组织还是期望我带人把这事解了。带人攻坚，需要我按次序想清楚，心智、人、目标、策略。首要解决的是心智重构的问题。以什么样的态度、心性，面对同样的挑战，要产生新的面相，并传达给团队。

刚好看到一本新书《Reframe Your Brain》。所谓 reframe，就是重新设定框架，主动把现实解读成一个对自己更有用的新故事。是对大脑的再编程，就像FPGA芯片。心理学也有一个类似的概念叫认知重建，面对一个情境，或者一段经历、一个想法、一个情绪，要识别出自己是怎么看它的，然后挑战自己的看法，换一个看法。比如，可以把困难看成挑战，挑战看成是探险，探险最终是一场游戏。

书中介绍了很多重构技巧，其中很重要的一个是把被动心态变成主动心态。几年前记得Jerry和我说过类似的话，从要我做什么事情，变成我要做什么事情。更进一步地，从我想要（want to）做什么事，变成我决定（decide to）做什么事。决定是绝对的主动，决定是自己对自己的commitment。想做一件事，可能条件变了就不想了。但决定做一件事，那就会想方设法做成，没有任何东西能阻挡。

所谓的心智重构是否是 “精神胜利法”般的心灵鸡汤？这就像营销和传销，表面上都是在卖东西，本质的区分是看谁产生最终价值。重构出来的说法不在于对不对，而在于有没有效。有些说法不对，但是对自己有效就好。

***

上周收银台业务接入的一个case，由于平台容器的限制业务方被迫切换收银台产品类型，付出了相当大的沟通成本。我们借机梳理了历史上平台容器切换对业务造成的影响，按时间线梳理下来，关键问题也浮出水面。有如tiange签名中所说的，“尽力避免标准化过程中的对象空泛化、规范简单化、动作机械化”。我认为“对象空泛化”的问题最为突出。金服可能是标准化容器的最大客户，历史上众多技术决策，从来没见过主动找我们一线同学调研访谈。深入到业务中、沉到业务中做出的设计才是务实的设计。

平台推行的技术产品或标准，一般可以很好的覆盖90%的场景。最让人挠头的是，后10%的长尾场景一般都是因为“不知道”，需要业务以体验or成本填平设计缺陷。我们对平台工作的感受和评价恰恰是最后这10%决定的，行百里者半九十。联想到质量控制里的六西格玛理论，要想达到高水平的结果，过程能力要达到六个标准差的水平。就是要专注于消除最后的、难以察觉的设计缺陷，对边缘长尾问题的关注和解决才能带来显著的质量提升或竞争优势。

引以为鉴，也是我们在做一些标准和治理工作需要格外注意的。