Vibe Coding:真相与误解
AI 如何改变软件创建方式,而不会让软件公司过时。
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
几周前,一家价值数亿美元的科技公司的 CXO 找到我,提出了一个有趣的请求。
他的公司依赖一长串软件产品——Asana、Microsoft Office、Adobe Photoshop、TurboTax、LinkedIn Premium 等等。这些订阅费加在一起,每年要花费公司数百万美元。事实上,他们的 ARR(年度经常性收入)大约为 4 亿美元,而在软件订阅上花费了近 2000 万美元。
他的问题很简单:
"有了 Lovable、Claude Code 和 Codex 这样的工具,我们能不能自己构建这些应用来省下那些钱?"
这个想法源于他们的 IT 团队。他们最近尝试了一个新的 AI 驱动的 vibe coding 工具,在很短的时间内就构建了一个小型内部工具。那个初步的成功让他们相信这是一个突破性的认识:
"如果我们能构建这个,为什么我们不能构建我们使用的每一款其他软件?"

他们想从替换 Asana 开始。在他们看来,Asana 只是一个任务看板,因此是最容易重新创建的应用之一。
但这个观点忽略了 Asana 的真正本质。
Asana 代表了超过 15 年关于组织如何协调工作的积累知识。 它的超能力不是代码本身——而是从多年来观察数千个组织中数百万用户的过程中提炼出的数千个产品决策、工作流规则和边缘情况。
从任务所有权和权限到依赖关系、通知、循环工作流和项目模板,所有这些都在不断的实际使用中被精炼。单独来看,这些问题每一个都看起来很简单。但集合在一起,它们代表了一个庞大的编码组织知识体系,极其难以重新创建。
为了确认这个请求,我问:
"你们公司也在销售软件。按照这个逻辑,你们的客户最终不会也这么想并替换你们的软件吗?"
回答是即时的:
"不会。我们的优势不是软件本身,而是其中存储的数据以及我们在此基础上提供的竞争情报。"
他们没有意识到的是,同样的逻辑也适用于他们希望替换的许多产品。他们把这些产品仅仅看作软件。实际上,它们远不止于此。
为了把问题说得更清楚,我问:
"你们也打算复制 LinkedIn 吗?"
回答毫不犹豫:
"为什么不呢?"
这就是误解变得明显的地方。
1、LinkedIn 的例子
大多数人认为 LinkedIn 的价值来自它的软件。不是的。
其他人则认为它的护城河来自多年来积累的用户数据。这也不完全对。
据估计,LinkedIn 大约有 13 亿注册用户,分布在 200 多个国家,每月有数亿活跃用户。但真正的资产不是用户本身——而是他们之间的关系和互动。
把 LinkedIn 想象成一个巨大的职业图谱。两个专业人士之间的每一个连接都是这个图谱中的一条边。总共有数千亿条边。
现在想象一下推出一个叫 ProfessionalGraph 的 LinkedIn 竞争对手。假设你以某种方式说服了 LinkedIn 10% 的活跃用户加入。这听起来令人印象深刻。
不幸的是,你不会获得 LinkedIn 10% 的价值。
你可能甚至获得不了 3%。
为什么?因为绝大多数的职业关系仍然在 LinkedIn 上。图谱被碎片化了。网络变弱了。价值蒸发了。
除非你能在一夜之间触发大规模迁移——类似 Facebook 取代 Orkut 那样的事件——否则你的新平台不太可能获得有意义的吸引力。
这就是使 LinkedIn 难以复制的原因。不是代码。甚至不是数据。真正的护城河是网络本身。
让我们更仔细地看一下。
作为全球唯一的职业网络,LinkedIn 会想知道平台上每个人拥有的技能。这样的信息将非常有价值。但你怎么收集呢?
简单地让用户列出自己的技能会产生质量问题。大多数人自然会倾向于以最好的方式展示自己,使得生成的技能图谱充满噪音且不可靠。
LinkedIn 的解决方案很巧妙。
它不是让用户验证自己,而是让其他人来背书。
如果有足够的人为 A 某人背书技能 S,那么 A 某人真正拥有该技能的概率就会显著提高。生成的技能图谱可能是稀疏的——只有一小部分用户积极参与背书——但它比自我报告的数据可信得多。
这里重要的是,这些信息不是孤立存在的。它产生于底层的职业网络。价值不仅来自节点(人),还来自它们之间的连接和互动。
这就是核心观点。
LinkedIn 的真正力量来自于那个巨大的互连图谱,它捕获了现实世界中的职业关系、信任信号、背书、职业历史和互动。
复制软件相对容易。复制那个图谱则极其困难。
那个图谱——而不是代码——才是 LinkedIn 的护城河。
2、软件产品远不止是代码
正如许多经验丰富的软件专业人士可能会猜到的,我没有接这个项目。
据我所知,他们的内部工程团队仍在推进这个倡议,CTO 在积极推动它。那位 CXO 仍然希望能省下 1500-2000 万美元。也许他们会成功。也许他们会在过程中学到一些昂贵的教训。
但他们的假设突显了一个关于 AI 驱动软件开发常见误解。
Lovable、Claude Code、Codex、Cursor、Ema 等工具无疑改变了软件工程。它们可以大大缩短开发时间,更重要的是,降低了技术门槛。
今天,一个几乎没有软件背景的人可以在几小时内构建一个功能齐全的应用程序。一个退休的披萨店老板可以创建一个为本地客户服务的简单订餐应用,而无需编写一行代码。
这确实令人赞叹。
但很多人在这一点上走偏了。
他们认为构建 MVP 和构建一个生产级软件产品本质上是同一回事。
它们不是。
对于非技术人员来说,软件就是屏幕上可见的功能,而实现这些功能看起来是困难的部分。
对于经验丰富的工程师来说,可见的功能往往是简单的部分。
真正的挑战在原型运作之后才开始。
一个生产级软件产品需要的远不止一堆功能:
- 身份认证和授权
- 支付和计费
- 可扩展性
- 可靠性
- 安全性
- 监控和可观测性
- 合规性
- CI/CD 流水线
- 数据治理
- 备份和灾难恢复
- 性能优化
- 用户获取和留存系统
- 第三方集成
这些是将一个周末原型与一个为数百万用户无缝服务的产品区分开来的东西。
那位 CXO 的期望与这个现实脱节了。
你能为车展造一辆概念车,并不意味着你能把它从纽约开到加州。
同样的原则适用于软件。
构建演示很容易。构建一个能在现实使用中存活下来的可靠产品完全是另一回事。

3、"自建一切"的隐藏成本
许多高管认为,即使他们无法完美复制商业软件,他们仍然能消除大部分软件支出。
不一定。
构建和运行生产级软件与构建 MVP 是完全不同的事情。 它既不容易也不便宜。
当系统崩溃时怎么办?
当发现关键安全漏洞时怎么办?
当法规变化时怎么办?
当一个关键工作流在周日凌晨 2 点停止工作时怎么办?
这些问题不会仅仅因为软件构建得更快就消失。
当你购买软件时,你不仅仅是在购买代码。
你购买的是多年的维护、bug 修复、安全补丁、可靠性工程、客户支持、运营流程和机构专业知识。
在许多方面,你购买的是站在产品背后的整个组织。
这是大型企业通常选择商业软件而非开源替代品的主要原因之一,即使开源版本在技术上同等甚至更强大。软件可能是免费的,但在大规模运行和支持它时很少是免费的。
还有一个没有得到足够关注的问题。
我们仍然不完全了解大规模 AI 生成代码的长期后果。
这些系统正在创造什么样的技术债务?
五年后,大型 AI 生成的代码库的可维护性如何?
当最初提示代码的工程师不在了时会发生什么?
诚实的答案很简单:
目前没有人知道。AI 驱动 SDLC 仍处于早期阶段。
我们仍处于这场实验的早期阶段。
这让我想起了为 500 位宾客举办婚宴。
仅仅因为机器人可以帮助烹饪,并不意味着突然自己准备所有饭菜是明智的,而不是雇佣专业餐饮服务商。
机器人可能会减少一些劳动力。
但你仍然负责采购、规划、质量控制、卫生、后勤、服务,并确保当 500 位饥饿的客人到来时,晚餐确实摆在了桌上。
软件没有什么不同。
AI 可能会(今天)大幅降低编写代码的成本。它并不能消除拥有、运营和支持一个生产系统的成本。
4、AI 驱动的开发并不便宜
还有一个日益增长的神话,认为 AI 驱动的软件开发很便宜,随着时间的推移会变得更便宜。极不可能。相反,它很可能会变得更加昂贵。经济学比大多数人意识到的要复杂。
最近,Uber 的 CTO 提到公司在短短几个月内就用完了年度工程预算。今天,AI 驱动 SDLC 工具提供商仍在大量补贴使用以加速采用并占领大份额市场。今天的定价结构不太可能代表这些系统的中长期真实成本。
具有讽刺意味的是,在许多场景中,人类开发者的成本仍然比人们想象的要低。未来这会改变吗?有可能。但这需要 AI 成本大幅下降,同时能力持续提高。这不是有保证的。恰恰相反,它可能只会上升。(我将专门写一篇文章讨论这个问题)
5、那么 Vibe Coding 的真正价值是什么?
这并不意味着 Vibe Coding 被过度炒作了。远非如此。这是几十年来我们在软件创建领域看到的最重要的转变之一。
但它最大的影响不在于大多数人认为的地方。它的超能力是最小可行产品(MVP)的创建。构建 MVP 已经永远改变了。
CTO 不再需要花几天时间解释他想要什么或编写需求文档来验证一个想法。
产品经理不再需要仅依赖 PRD、模型和线框图来传达意图。相反,他们可以构建一个可工作的原型。这就是新的 PRD。项目提案的 PPT 现在已经被 Vibe Coding 的 MVP 所取代。
创始人可以在不构建产品或筹集资金之前非常快速地测试市场机会。设计师可以演示用户体验而不是描述它。内部团队可以在投入工程资源之前验证假设。在软件开发方面,想法/愿景与可工作原型之间的距离已经坍塌。能够 Vibe Coding 一个 MVP 现在是每个专业人士必须具备的技能,无论你属于哪个职能部门。这才是真正的革命。
不是替代每个软件公司。
不是重建 LinkedIn。
不是消除工程团队。(将在另一篇文章中详细讨论)
赢家不会是那些使用 AI 来重新创建现有软件的组织。赢家会是那些使用 AI 比其他所有人更快地验证、迭代和学习的组织。
想想那些超级聪明的增长黑客、参谋长、营销和销售人员——他们快速 Vibe Coding MVP 和变体来测试他们的假设和市场,而不依赖工程团队的带宽。这将释放一种全新的增长黑客方式。在硅谷,Vibe Coding 已经成为这些人的必备技能。
另一个重大解锁将是数据产品和数据收集应用。更多内容将在下一篇博客中讨论。
原文链接:Vibe coding, AI Powered SDLC - Advantages & Misconceptions
汇智网翻译整理,转载请标明出处