> 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-hant/2024/essay-collection-informal-talks.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%決定的，行百里者半九十。聯想到質量控制裡的六西格瑪理論，要想達到高水平的結果，過程能力要達到六個標準差的水平。就是要專注於消除最後的、難以察覺的設計缺陷，對邊緣長尾問題的關注和解決才能帶來顯著的質量提升或競爭優勢。

引以為鑑，也是我們在做一些標準和治理工作需要格外注意的。