6.1 代码审查的错觉：为什么技术大牛容易买到烂股票

2019年一家总部设在旧金山的数据库创业公司宣布关闭。这家公司在硅谷技术圈里的口碑曾经好得不像话。它的核心产品是一个用Rust从头实现的分布式时序数据库存储引擎做了零拷贝的列式压缩查询层用上了当时最激进的向量化执行框架在单机环境下的写入吞吐量能把InfluxDB甩开一个数量级。Hacker News上每一篇关于它的技术博客下面都是工程师们的溢美之词——“这才是数据库应该有的样子”、“读他们的源码就像在读一本干净的教科书”。这家公司融了两千多万美元雇了三十多位顶尖的系统工程师运营了四年然后关门了。关门的原因不是技术不行。是没人在乎。真正需要时序数据库的工业客户要么已经在InfluxDB或者TimescaleDB上建立了完整的运维体系迁移成本高到足以覆盖所有性能差距要么压根不需要那种级别的写入吞吐量因为他们的传感器网络还没密集到那个程度。这家公司在每一个技术维度上都做到了最好但在唯一重要的维度上得了零分——没有人愿意付钱。你作为一个每天和数据库打交道的后端工程师如果在2018年看到了这家公司的技术白皮书大概率会被它圈粉。如果你当时有机会买它的股票你可能就买了。然后两年后你会和它的创始团队一样成为这个世界上最失落的Rust粉丝。技术鉴赏家综合征你买的是艺术品不是现金流机器代码审查是你职业生涯里训练得最扎实的一项技能。你打开一个Pull Request扫一眼diff能在几分钟内判断出这段代码的设计是否优雅、抽象层次是否合理、边界条件是否处理到位、性能瓶颈有没有被无意识地引入。你对“好代码”和“烂代码”的直觉判断力经过了几百个Code Review的反复打磨已经变成了一种近乎生理层面的反应——看到优美的架构你会心里一颤看到硬编码的魔数你会本能地想点那个Request Changes的按钮。这种审美能力在你的本职工作中是无价的。但当它被你不加转换地带进投资决策时它就变成了一个你完全没有意识到它存在的认知缺陷。你把一家上市公司的技术架构当成它的源代码来审查。你看到它用Rust重写了核心模块延迟降了3毫秒你在心里给它打了一个高分。你看到它的对手还在用十年前那套老掉牙的Java框架API设计得乱七八糟你在心里给对手打了一个不及格。基于这两个分数你买了前者做空了后者觉得自己做了一笔教科书级别的“基于技术护城河的价值投资”。三个月后前者跌了15%后者涨了20%。你愤怒地翻开财报发现前者那套优雅的架构投入了四千万研发费用换来的是客户续费率提升了不到两个百分点而后者那套“老掉牙的Java框架”因为客户已经深度集成、迁移成本极高反倒成了对手撬不动的护城河。你不是在做技术尽调。你是在用Code Review的标准做艺术鉴赏。你把股票账户当成了GitHub把每一笔买入当成给开源项目的Star把每一次加仓当成你对某个技术栈的信仰充值。你以为你在投资其实你在用真金白银购买参与感和身份认同。一家公司的技术好不好和它值不值得投资是两个几乎正交的维度。技术好只是意味着它把产品做出来了但产品做出来和产品能卖出去之间隔着一整套你无法通过阅读源码来评估的商业基础设施——销售团队的覆盖密度、渠道合作伙伴的利益分配机制、客户从上手到深度依赖的Onboarding流程、以及竞争对手在存量客户那里的切换成本。这些东西不会出现在技术白皮书里不会出现在GitHub的README里不会出现在Hacker News的热评第一里。它们只会出现在招股书里——出现在你因为字太多而直接跳过的那部分“风险因素”和“业务模式分析”里。工程师的“鄙视链红利”你觉得无聊的生意往往是最持久的复利你有没有发现自己有一个很难抑制的心理冲动看不起那些“没有技术含量”的生意。茅台是粮食加水。海天酱油是黄豆发酵。农夫山泉是水加瓶子。你对这些公司的本能反应可能是“这种东西有什么壁垒给我一条生产线我也能做。”你更愿意去买那些你觉得“有技术含量”的公司——芯片设计、操作系统、AI大模型、量子计算。你觉得这些才是真正在用智力创造价值的企业。这种心态在工程师圈子里有一个我称之为“鄙视链红利”的奇特现象你看不起没有技术壁垒的生意所以你从来不买它们的股票。而这些“无聊”的生意恰好在过去二十年里给它们的长期股东创造了比绝大多数“高科技”公司更稳定、更长久的复利回报。你没有想通的一件事是技术壁垒只是护城河的一种形态而且不是最宽的形态。品牌心智是护城河渠道密度是护城河网络效应是护城河监管牌照也是护城河。茅台的护城河不是它的酿造工艺——那个工艺几百年前就有了而且技术上没有任何秘密可言。茅台的护城河是它在中国人心里占据的那个“最好的酒”的认知位置。这个位置是几十年消费场景的反复强化、是无数桌饭局上的默认选择、是送礼时不用解释任何参数就能被对方识别出价值的社会共识。摧毁这个护城河需要的时间比台积电丢掉制程领先优势需要的时间可能还要长一个数量级。你鄙视“没有技术含量”的生意本质上是在用你的职业评价体系去度量一个和你的职业完全无关的世界。你因为一个生意不需要顶尖的工程师就能运营就觉得它不值得投资。但投资的回报从来不取决于一个生意需要多聪明的人来运营。它取决于这个生意能不能在尽可能长的时间里持续产生超过资本成本的现金流。而“需要极其聪明的人才能运营”在投资里通常是减分项不是加分项。它意味着这个生意的护城河高度依赖少数关键人物的不可复制的智力资本一旦这些人离开或者犯错护城河就会快速崩塌。你作为一个极其聪明的人不愿意承认你引以为傲的智力在投资这个领域里并不是核心竞争优势。但这是事实。开源社区的免费午餐幻觉技术开源不等于公司值钱你每天的开发工作有很大一部分是站在开源社区的肩膀上完成的。你用Linux做服务器操作系统用PostgreSQL存数据用Redis做缓存用Kubernetes做容器编排。这些软件都是免费的质量极高文档齐全社区活跃。你习惯了这种“顶尖技术零成本获取”的工作方式之后很难不对那些基于开源项目的商业公司产生一种错觉既然它的技术社区有几千个Star、几百个Contributor、在全球有几十万用户那这家公司一定很值钱。这个逻辑有两个断裂点。第一个断裂点开源用户不等于付费客户。一个在GitHub上获得了五万Star的项目可能有全球超过十万家公司在用它。但这十万家公司里真正愿意为它付费的可能不到五百家。剩下的九万九千五百家有的是因为根本不差那几个性能优化所以不需要企业版有的是因为自己的运维团队足够强所以不需要原厂支持有的是因为这个项目在公司技术栈里的重要性远不到需要购买商业授权的级别。你作为工程师你对一个开源项目的价值判断建立在你使用它的技术体验上——它的API设计得合不合理、文档写得好不好、Bug修得快不快。但投资人关心的价值判断建立在一个完全不同的问题上有多少客户必须买它的付费版本这个答案和Star数量没有任何正相关关系。第二个断裂点开源降低了使用门槛也同时降低了付费意愿。如果一家公司是做专有软件的客户要使用它就必须先签合同付款。付款是使用的前提。如果这家公司把核心技术开源了客户使用它的顺序就变成了先免费使用、等到用出了问题或者用了很深之后再考虑要不要付费。这个顺序的改变对商业模式的打击是毁灭性的。你把一个本来必须发生的购买决策变成了一个可以无限期推迟的“以后再说”。有多少个“以后再说”最后变成了“后来换了一家”这个比例你作为工程师应该很清楚因为你自己的团队可能也做过类似的事。一项技术被广泛使用和一家公司值得投资之间的距离比你代码里最深的那层回调地狱还要曲折。这一节讲了三个你作为技术专家最容易被自己专业知识绊倒的地方。你用技术审美代替了商业判断你用职业鄙视链过滤掉了最稳定的回报来源你用开源社区的用户活跃度混淆了商业变现的确定性。这三个认知陷阱每一个都来自你职业生涯里最值得骄傲的能力——你能分辨什么是好代码、什么是好架构、什么是好技术。这些能力没有错错在你把它们用在了不该用的地方。在下一节我要把这些能力重新校正方向从“让你亏钱的偏见”变成“让你赚钱的信息差”。你不会再去看一家公司的代码优不优雅你会去看它在供应链上的位置是不是不可替代你会去看它的API文档质量能不能反映它的工程管理能力你会去看它的离职员工在脉脉上的吐槽来推断它的技术债务是不是已经接近临界点。这些才是你能比基金经理更早看到的东西。