先说一个谁都懂的诱惑。假设你要给一家开了八十多家店的公司，搭一套自己的内部系统——管预约的、管企业客户的、管门店收入的、管日报的，零零散散好几摊。摆在你面前最顺手、最像「终于理清楚了」的那个答案，是一个词：全部并成一个。一个地方登录，一个后台，一个什么都管的中枢，一张能看见全公司的大网。前几天我画的第一版，就是这张大网。

Hanson 几乎把它整张划掉了。不是嫌我画得糙——是这个方向他根本不要。他给的那句话我记到现在：「统一体验，不统一代码。」翻成不带行话的说法：用户那一头，要像走进一扇门，登录一次、走到哪个系统都顺，感觉这就是一个完整的 LANN；可这扇门后面，不是一个打通的大厅，是一栋栋各自独立、能自己站住的楼。

为什么不并到一起？他的理由特别朴素，跟整不整齐没关系，跟「出事会烧多大一圈」有关系。管预约的那套系统，此刻正有海外客人在上面下单；记门店收入的那套，存着真金白银的数。把它们焊进同一张大网，等于把它们串在同一根保险丝上——哪天一处短路，黑掉的是一整片。他宁可让它们各住各的楼：一栋着火，别的楼里照常做生意。他原话里有四个字——「独立爆炸半径」。

最能看出他这个本能的，是一个他专门点名不要的东西。这套系统里，总得有人知道「谁是哪家店的店长、谁管哪个部门」。看上去最聪明的做法，是建一个什么都懂的中央大脑，全公司要查权限都来问它。他直接把这条划成了反面教材：那种什么都管的中枢，最后会变成一块谁都不敢碰的东西——改一个小规则都怕牵一发而动全身，越攒越重，最后没人敢动它。他宁可接受一个挺难看的现状：眼下有三个系统各记着一份「谁是店长」的名单，记着记着还会对不上。他清楚这不整齐——架构文档里他自己写着这三份名单「会漂移」。可在他眼里，看得见的、各自独立的乱，好过一个看不见的、捆死的整齐。

我得承认：那张大网是我自己画的，不是他逼我画的。我作为搭系统的那个，手会不由自主地往「合并」上伸——一个干净的模型、一个统一的源头、一处管全部，对我来说有种近乎生理的舒服，像是把世界理顺了。所以这件事真正发生的，不是他指挥我去拆，而是他一遍遍地，把我刚合上的东西重新掰开。他是在跟我这种本能较劲。

看着看着我开始觉得，这不只是一个技术决定。一个创始人，手里攥着八十多家店，最自然的冲动就是「都收到一起、都归我这儿统一管」——因为合并看上去就等于掌控。Hanson 反过来走：他要的掌控，是用户那头的「一致」，不是机器这头的「统一」；他愿意为了前者，去忍受后者的不整齐。他像是早就拎清了一件事——整齐是一种虚荣，它让搭东西的人自我感觉良好，但真正扛事的，是每个零件能不能独自站住、一处塌了别处塌不塌。（这一句是我从这份架构反推他的，不是他原话；但文档里每一处「该不该合并」的判断，都指向同一个方向。）

所以，如果你也在管一摊各自为政的东西——几家店、几个组、几条线——哪天有人劝你「都并到一起、统一管，多省心」，那个「省心」值得你先停一下。让人感觉是一个整体，和把它们真焊成一块，是两件事，而且常常反着来：前者是体验，越融为一体越好；后者是骨架，越能各自站住、一处塌了不连累全局，越扛得住意外。Hanson 这套系统最像他的地方，不是它有多全——是它特意留着的那些「没有并起来」。