一家公司能承受几次技术冒险?Dan McKinley在2015年写下的答案是三次——他把这叫做「创新代币」,每家公司大概只有三枚,花在NodeJS、MongoDB,或者自研一个数据库上,代币就用完了。这篇博客后来被硅谷工程师奉为经典,但很少有人注意到,这套理论自己也在十年里悄悄改过口径。
三枚代币,和一个会漂移的作者
McKinley提出「创新代币」模型时,身份是刚离开Etsy的工程师。同年7月,他在OSCON大会上把这套理论讲成了演讲,当时他已经跳槽到Stripe,演讲里举的例子也带着Stripe的语境。
但流传更广的boringtechnology.club修订版,把他的工作单位悄悄换成了Mailchimp。同一个人,同一套理论,不同版本里换了不同的东家背书。
这不是什么阴谋,更像是一个巧合的提醒:连提出「选无聊技术」的人,自己都没能在一个稳定的身份里把这套话讲到底。理论要求别人克制冒险,作者自己的叙事框架却在持续修订。
Etsy的两个样本,一正一反
McKinley最有说服力的证据来自Etsy内部的两桩往事。
一桩是教训:公司招了一批Python程序员,为了给他们找活干,硬造了一个没什么必要的中间层,后来花了好几年才把它拆掉。这几年里,搜索延迟一度长达两分钟,产品几乎没有新功能上线。
另一桩是佐证:Etsy的活动流(activity feed)系统建在公司已有的PHP、MySQL、Memcached这套「无聊」基础设施上。此后数年没人特意维护它,用量却涨了20倍,系统照样稳定运行。
- 结论.省下来的不是开发时间,是往后几年不用盯着这套系统吃饭的注意力。
这组对比撑起了McKinley的核心判断:技术选型的真实成本,不在写代码那几周,而在后面几年要不要为它专门配人维护。
Monzo的反例:合规压力比工程师喜好更硬
「无聊技术」原则最大的挑战不是理论漏洞,是Monzo这家银行。
Monzo从创立起就用Go、Kubernetes、Cassandra、Kafka搭起数百个微服务的架构,几乎是McKinley清单的反面教材。但银行业务对故障隔离、审计追溯、监管合规的要求,远高于一般互联网公司——一个服务出问题,不能拖累整个交易链路。
这套「反例」的价值不在于反驳McKinley,而在于给「无聊」画出边界:当行业本身自带强隔离、强合规的硬需求时,选择成熟度更高但架构更笨重的单体系统,风险可能比拆细的微服务更大。
无聊不是免检牌,是默认选项,例外需要证据。
技术选型该不该冒险,最终问的其实是同一个问题:你的业务里,有没有一个环节,出错的代价比维护成本高得多?Monzo的答案是交易隔离,大多数创业公司的答案是——没有。
幸存者偏差:成功案例都是活下来的那批
Hacker News上对这篇文章的长期讨论里,有一种质疑一直存在:Etsy、Stripe这些「无聊技术」的成功样本,可能只是幸存者偏差的产物。
- 提醒.失败的创业公司很少公开复盘自己是被过度冒险的技术栈拖垮的,活下来的公司才有空写博客总结经验。
大公司的复杂技术栈「看起来」稳定,也可能只是因为有钱养得起团队去填坑,而不是架构选择本身正确。反过来,选了无聊技术却依然做死的公司,同样不会写文章解释「我们选对了技术但还是死了」。
这层怀疑不该推翻McKinley的判断,但该提醒读者:「选无聊技术」的因果链,证据链条比想象中薄。它更像一条经过验证的经验法则,不是一条被证明的因果律。
落到今天:LLM基础设施算不算例外
十年后再看这套框架,最现实的问题是:面对向量数据库、Agent框架、LLM推理层这些新东西,团队该按老规矩把它们当作「花代币」的冒险项,还是该单独给AI基础设施留一份配额?
McKinley原文给的判断工具其实很简单——先问自己一句:不用这个新东西,能不能解决眼下的问题?如果答案是「能,但麻烦」,那大概率还没到非花代币不可的地步。
对正在扩张期的技术负责人来说,这句话依然管用:决定选型的不是这项技术多新,是你的业务里到底有没有一个环节,值得为它单独承担未知风险。