Vibe coding是人工智能研究员 Andrej Karpathy 于 2025 年推广的一种软件开发方法开发人员使用自然语言指导大型语言模型 (LLM) 生成、优化和调试代码，将重点从手动编码转移到更具对话性、更高级的问题解决和应用程序开发方法。
把“功能交付速度”当成产品开发的最大瓶颈，是一种误解。
Vibe 这类编码工具的真正优势在于：不需要工程团队就能快速搭建出东西。很多宣传也是这样说的：
“有人在没有雇任何软件工程师的情况下，仅靠 AI 打造出有效的科技业务，并做到百万美元规模。”
听上去很诱人。但我们需要把问题拆开来看。
原型设计 vs. 产品
在原型阶段，Vibe 确实很有用。它能让想法快速落地，判断是否值得继续。但原型的本质是一次性的。
即便方向正确，原型也不能直接转化为产品。因为原型的目标是“便宜、快”，而不是“稳定、持久”。它可能很丑，有 bug，甚至会崩溃，但这都没关系——它只是用来传达想法。
产品则完全不同。
它必须持续交付价值。
- 体验差，用户会转身去找替代品。
- bug 太多，用户会放弃。
- 一旦彻底崩溃，更没人会为它付费。
最终，质量是不可妥协的。客户留存才是产品的生死线。
成功产品的路径
很多成功的数字产品并不是线性演进出来的，而是无数实验后的结果。
拿亚马逊来说：从卖书开始，后来进入音乐、视频、硬件、云，似乎是一条“必然的”路径。但如果你看他们的文化，会发现背后是成千上万的试验和迭代。
关键点：没人能预先知道哪个功能或方向会成功。
我们只能不断尝试，把有效的保留，把无效的砍掉。
Gmail 的故事
Paul Buchheit 因在短短几个小时内构建了第一个 GMail 原型而闻名。之后，他又在 AdSense 上重复了这一技巧。所有这些代码都必须手动编写，就像你懂的，用手写一样。 是的，我们正在谈论谷歌的两款惊艳产品。然而，如果你仔细阅读这个故事，就会发现这绝不是一个精心策划的计划的执行。 “在Gmail 发布前的两年半开发过程中，我们做错了很多事情。” “到发布时，我们重写了前端大约六次，后端重写了三次。” “我只是编写代码，发布功能，然后观察反响。通常情况下，每个人（包括我）最终都会讨厌它（尤其是我的想法），但我们总能从经验中吸取教训，并且能够迅速转向其他想法。” 保罗·布赫海特.
换句话说，他们探索过无数个死胡同，推翻了无数个，最终还是走了出来。事先什么都不知道。 它适用于产品功能，也适用于整个产品 同样的模式也适用于产品，而不仅仅是产品功能。例如，我们可以继续使用谷歌。它以一系列符合其整合全球信息的使命的产品而闻名。搜索、Gmail、Google Workspace 等等。 然而，除了搜索之外，许多此类产品最初都只是实验性质的。上文提到的 Gmail 和 AdSense 就是两个值得注意的例子。
这种逻辑不仅适用于某个功能，也适用于整个产品线。
Google 除了搜索以外，大量产品最初都是实验：Gmail、AdSense、甚至 Workspace。
成功的背后有十几个失败的，失败的背后还有成百上千个从未公开的尝试。
Google Reader、Microsoft Math Solver…—但它们都已经消失了。Tech companies依旧不断试错，因为那是找到真正“长青产品”的唯一方式。
你这段补充正好把前文的逻辑闭环补上了，我帮你压缩和打磨一下，让结尾更锋利，更能打出主题：
验证与沟通
产品开发的本质就是持续探索：先验证想法，再验证改动是否带来增长、收入或留存。
问题在于——验证需要时间。
Leah Tharin 分享过她在数千万用户产品中的经验：
即便流量巨大，团队的瓶颈也在等待实验达到统计显著性。修改首页文案，几个小时就能看出结果；但调整漏斗深处的复杂功能，往往需要数周，甚至数月。
想象一下，如果开发速度缩短十倍，增长会更快吗？除了落地页这种最简单的测试，大部分实验依旧需要等待数据沉淀。你也不能无限增加实验数量，否则只会让指标噪音更大、难以解释。
真正的瓶颈在于：我们不知道该做什么。没有哪个团队能一开始就锁定有效路径。
那如果方向明确呢？理论上，确定范围、签合同、开始开发，一切顺理成章。
可实际情况是：
- 我们常常在全速构建错误的东西。
- 或者因为沟通不清，返工成本翻倍。
- 开发了大量不必要的功能，事后才发现价值极低。
难道我们就不能用我们经常吹嘘的20年经验，用通俗易懂的语言告诉大家成本是多少吗？不行。我们还不知道合作会是什么样子，而单是这一点，就足以比任何与范围直接相关的因素，对实际成本产生更大的影响。 沟通不畅会导致返工。沟通质量差，或者更确切地说，缺乏沟通，往往会使工作量增加100%，这种情况并不罕见。 再加上所有不必要的功能的开发，情况就更加糟糕了。事后想想，这些增值工作可能只占总投入的几个百分点。 加快开发速度只会加剧问题。返工成本并非线性增长。一旦你重新开始返工，它就像一个复利，只不过是反向的。想想它对成本的影响吧。
for example：初始工作量 100 小时，每次返工增加 30%，四轮下来就是 285 小时。加快最开始那 100 小时的开发速度，对整体影响几乎可以忽略。AI 的重写只能推迟问题，糟糕的抽象、监控缺失、集成脆弱——迟早会爆炸。
编码速度从来不是瓶颈
Vibe coding 承诺两件事：
-
我们能更快拿到代码
-
我们不需要雇昂贵的工程师
如果目标只是“把界面堆出来”，当然 vibe coding 是捷径。
但产品开发从来不是“写完代码就完事”，而是 能否持续、可靠、规模化地解决用户问题。这依赖验证实验、长期可维护的系统、合理的激励结构，以及对增长、收入、留存等指标的清晰把握。写代码快，本来就不是瓶颈。
听起来很诱人，但它们只是在回答一个容易的问题，而避开了真正的难题：我们到底要解决的是什么问题？
所以，问题从来不在“写代码太慢”，而在于：开发速度从来不是决定性的短板
- 我们不知道哪些方向值得尝试（验证的瓶颈）。
- 我们没能清楚对齐（沟通的瓶颈）。
