开发速度不是瓶颈

摘要

本文挑战了"开发速度决定产品成败"这一普遍认知。作者指出，vibe coding工具虽能加速代码生成，但产品成功的真正瓶颈在于验证和沟通。从Amazon的大量实验、Gmail的多次重写，到Google近300个已下线产品，历史证明：没有人能预先知道什么会成功。开发速度再快，也无法跳过等待统计显著性、理解用户需求和团队协调的时间成本。

内容框架与概述

文章开篇回应了一个挑战：有人声称可以仅用AI vibe coding工具构建成功的技术业务。作者将此作为切入点，系统性地解构了"开发速度是产品瓶颈"这一误解。他首先区分了原型与产品的本质差异——原型是可丢弃的、以速度换质量的验证工具，而产品必须持续交付价值且质量不可妥协。

接着，作者通过Amazon和Gmail的案例论证产品开发本质上是持续发现的过程。Paul Buchheit虽能在数小时内完成Gmail原型，但实际开发中前端重写了六次、后端三次，历经2.5年才发布。Google拥有近乎无限的工程资源，却有近300个产品被淘汰——这证明开发火力无法保证产品成功。

文章最后指出两个真正的瓶颈：一是验证需要时间（等待实验达到统计显著性可能需要数周甚至数月），二是沟通成本（需求理解、跨团队协作、技术债务处理）往往占据项目大部分时间。即使开发成本降低十倍，这些瓶颈依然存在。

核心概念及解读

原型与产品的区别：原型是用质量换取快速验证的可丢弃工具，而产品必须长期稳定交付价值。Vibe coding适合前者，但不能替代后者对工程质量的要求。

持续发现（Continuous Discovery）：产品开发的本质是不断试错、验证、迭代。没有人能预先知道什么会成功，即使是Google这样的巨头也需要通过大量实验来找到正确方向。

验证瓶颈：真正制约产品进展的是等待实验结果达到统计显著性的时间。即使拥有海量用户流量，复杂的漏斗深层变更也可能需要数周甚至数月才能得出结论。

沟通瓶颈：项目中大量时间消耗在需求理解、跨团队协调和技术债务处理上。作者估计，在传统项目中开发本身可能仅占整体工作量的20%左右。

Vibe Coding的定位：作为原型验证工具极具价值，但无法解决产品成功的核心问题——弄清楚该构建什么。

原文信息

此摘要卡片由 AI 自动生成