别等完美：YC用一堆“脏办法”做出大公司

这场YC对谈反复强调一个反直觉结论：真正推动软件公司起飞的，往往是那些明知“不可规模化”的做法。通过Google、Facebook、Twitch等早期真实案例，Dalton Caldwell和Michael Seibel解释了为什么先把水打开、让系统暴露问题，才是创业者最务实的增长方式。

先把水打开：测试产品最残酷也最诚实的方法

为什么很多产品在“精心测试”后依然失败？在视频一开始，Dalton Caldwell就给出了一个极具画面感的比喻：如果一栋房子里布满了管道，其中一些已经坏了，你可以花很长时间逐根检查、猜测哪里会漏水；但更直接的方法是——“把水打开”。

他原话是这么说的：“你可以转开水龙头，你会立刻知道哪里在漏水，也就知道该修什么。”这段话几乎概括了YC对产品验证的核心态度。与其在发布前反复做假设、推演和‘安全测试’，不如尽早让真实用户进来，用真实流量把问题冲出来。

这背后的方法论非常明确：早期软件系统几乎一定是‘坏的’，区别只在于你是被动等到灾难发生，还是主动让问题尽早显形。Caldwell强调，这种做法看起来粗糙、甚至有点鲁莽，但它能在最短时间内给创始人提供最有价值的信息——哪些地方真的重要，哪些只是心理安慰。

“Things That Don’t Scale”为何让创始人不舒服

Michael Seibel在对谈中直言，这个话题之所以重要，是因为“创始人普遍不喜欢它”。他们讨厌听到有人告诉自己：你现在要做的事情，未来肯定不会这么做。那听起来像是在浪费时间。

但正是这种不适感，构成了YC反复强调该理念的原因。Seibel点出一个关键问题：为什么我们要听那些‘让人不舒服的建议’？他的回答很简单——因为这些建议来自真实经历过从混乱到规模化的人。

在YC的语境里，“不具规模化”的事情并不是错误，而是一种阶段性策略。它们的目标不是长期效率，而是短期生存与学习速度。只要能更快验证用户是否真的需要你的产品，就值得去做。哪怕这意味着手工操作、复制粘贴，甚至人为干预系统行为。

Google 和 Facebook：复制粘贴撑起的早期奇迹

对谈中提到的第一个重量级案例来自Google。Caldwell提到，Gmail的发明者PB，在早期实际上是通过一系列“不可规模化”的方式推动产品前进。最典型的例子就是邀请制。

在今天，这种机制常被解读为‘增长黑客’，但在当时，它的真实原因非常朴素——服务器扛不住。邀请制不是营销技巧，而是“服务器限制的解决方案”。这意味着，Google早期并不是完美运转的系统，而是“秘密地处于损坏状态”。

Facebook的故事同样直接粗暴。为了扩展到更多学校，团队的做法是：为每一所学校单独运行一个PHP实例，然后不断复制、粘贴代码。没有统一架构，没有优雅抽象，但它确实让Facebook活了下来，并持续扩张。

这些例子共同指向一个事实：在云计算和自动扩容尚未普及的年代，创业意味着直面硬件和成本限制，而解决方式往往是最笨、但最快的。

Twitch 与“超级脏”的工程决策

如果说前面的例子已经够‘野’，Twitch的早期故事则更进一步。Seibel分享道，为了应对访问压力，团队会把任何页面直接变成静态页面。“超级脏，但它能用。”

更极端的是，当某个主播变得特别受欢迎时，团队会提前把他的直播流“预填充”好，以避免实时系统被打爆。这种人为干预在成熟公司几乎不可接受，但在当时，它解决的是一个生死问题。

类似的决策还出现在音乐和视频领域：曾经有人尝试做“一个没有视频的视频网站”。这听起来荒谬，但正如视频中所说，这些都是“在巨大压力下做出的决定”。

直播视频成本极高，于是有人选择直接屏蔽视频，让社区来完成翻译和内容补全。这些做法的共同点在于：它们不是理想解法，而是让系统暂时能呼吸的解法。

总结

整场对谈反复回到一个简单却困难的原则：别急着做优雅的系统，先让真实世界进来。无论是Google的邀请制、Facebook的代码复制，还是Twitch的静态页面，这些“不能规模化”的做法，本质上都是在为学习速度让路。对今天的创业者来说，最大的启发或许是：不要害怕暂时的混乱，只要你清楚自己为什么这么做，以及下一步要修什么管道。

关键词: Things That Don’t Scale, Y Combinator, 创业方法论, 早期产品验证, Google

事实核查备注: 涉及公司：Y Combinator、Google、Facebook、Twitch；涉及人物称呼：Dalton Caldwell、Michael Seibel、PB（Gmail发明者，视频中未给出全名）；技术细节：PHP实例、静态页面、邀请制作为服务器限制方案；核心比喻原话：管道与开水测试产品。