今天被工作上的一件事情震惊了，切身感受到了字节的卷的程度：同一份产品需求文档，同时在两个技术团队产出了两套技术方案，并行开发，先后上线。

回来之后认真思考了下，又回想起南门老师谈论内卷必然性的文章，有点感想。

阿里为什么不这么卷，因为业务已经既定成型，团队和边界都比较清晰，梯队上都均匀有侧重长处的人选，团队的 SCOPE 和 OKR 都相对自洽，业务团队不提倡造轮子，提倡体系化的业务理解和思考，崇尚古典的技术架构方案论，很多资深的开发同学都进入了产品或者业务团队。

字节的卷，本质源于对技术的崇拜，这是字节的文化基因决定的。但是，你的方案能不能解决，跟我想不想通过你的方案来解决，是两回事情。说白了，就是很多在卖力输出的团队，误判了别人解决这个问题的 Justifiability 。

Justfiability的意思是：你能不能讲清楚你重复造轮⼦背后的逻辑，你造这个轮⼦是不是justifiable的（即能不能被justify）。

-南门

在阿里为什么比较少人犯这个错误（工程团队不造轮子），因为这个观点已经成为了一种群体无意识。

逻辑在于：你作为一个工程团队的同学，在开发过程中顺手实现的一个解决方案，必然是不昂贵的（副产品）。其他人想要来复用你这个方案，必然是昂贵的（理解成本，维护成本，扩展成本），所以这是一件性价比很低的事情，注定不会成功。

所以归根到底，业务（或者说工程）同学，最重要的素质，是对业务问题的快速理解，对业务扩展性的预判，落地到系统架构的设计，带来长远的技术收益，包括技术的 ROI 的思考，是否需要一直背负着镣铐（使用别人方案的扩展性/长期维护性风险/开发排期匹配/交流沟通成本），而不干脆付出很小的成本单独定制一份呢？

凭借解决方案对外输出的非业务线同学，要多想想自己是不是纸老虎，别人实现一套你的方案，付出和收益的比例到底是怎么样的？

这样想想，对自己马上要重复造的一个轮子心安理得了起来，甚至觉得应该克服借鉴别人方案的 “偷窃” 心态，大胆的偷，多多的偷，来造好自己手上的轮子。