SaaS终结论背后被忽视的逻辑断层
最近读到一篇基于No Priors播客的文章，Sarah Guo和Elad Gil讨论AI对软件行业的影响。最讽刺的是，他们指出当前市场最大的误判在于混淆了两个根本不同的维度：代码生成能力的提升，与企业软件价值的来源。工程师群体容易陷入一个认知陷阱——既然AI能生成代码，那么软件产品就可以被轻易复制甚至替代。
但这个推理漏掉了一个关键事实：企业软件的价值从来不在于代码本身有多复杂，而在于它承载了对客户业务流程的深度理解、跨部门协调能力、合规性处理、以及长期的维护承诺。Elad用Samsara举例很有说服力——一个提供车队管理解决方案的公司，涉及硬件集成、传感器部署、客户支持、销售网络等复杂环节，这些都不是"生成一段代码"能解决的。Sarah提到他们投资组合里收入数亿美元的公司，工程师团队保持在50人以下，但销售团队扩张到了近100人，这个数据直接反驳了"AI取代软件只需要技术"的假设。
小团队行为与大企业采购的结构性差异
另一个被严重低估的维度是企业规模对软件需求的影响。五人创业团队用vibe coding快速搭建一个CRM来替代Excel，这确实是效率提升，但这与财富100强企业替换Salesforce是完全不同性质的问题。大型企业的软件系统经过多年定制，嵌入了特定的业务逻辑、权限管理、合规要求、与其他系统的集成关系，背后还有成千上万的用户和复杂的变更管理流程。Sarah举了一个很生动的对比：问工程师愿不愿意为每个Jira座位付10美元，他可能觉得贵；但如果问他愿不愿意在美国银行做变更管理、处理安全审计、协调各部门对工作流程变更的意见、并长期维护这个系统，答案基本是否定的。这揭示了一个核心洞察：企业软件卖的不是功能，而是"把复杂性从客户那里接过来"的能力。那些高喊"SaaS终结"的人，往往是没在大型企业中负责过软件采购和部署的人——他们没经历过在5万人组织中推行新系统的痛苦，没面对过合规部门几十页的安全要求清单，所以低估了这种复杂性的深度。
软件需求的指数级增长悖论
Elad提出了一个反直觉的观点：AI提升代码生产力不会减少对工程师的需求，反而会刺激更多需求的释放。这背后的逻辑是类比修高速公路——你以为修路会减少拥堵，但实际上会产生更多的交通需求，因为更多人发现原来可以去更远的地方了。当软件开发成本下降，之前因为成本太高而无法实现的想法突然变得可行，整体需求会呈现超线性增长。这让我想起Jevons悖论（杰文斯悖论），19世纪经济学家发现燃煤蒸汽机效率提升后，煤炭总消耗量反而增加了，因为效率提升降低了使用成本，刺激了更广泛的应用。软件行业可能正在经历类似的动态。Elad还提到工程师群体内部的分化：一类把编程视为精致的手工艺，追求代码的优雅和质量；另一类把代码视为构建产品的工具，只关心快速解决问题。AI工具的普及会加速这种分化，产品型工程师会如鱼得水，而手工艺型工程师可能在大型科技公司越来越难以适应，因为那里的首要KPI是效率和规模，而非代码美感。
"Slop Problem"：被忽视的代码质量危机
Sarah在讨论中提出了一个我认为至关重要但被严重低估的问题：当AI能生成大量代码而没有人真正仔细阅读时，代码质量如何保证？她称之为"slop problem"（垃圾代码问题）——不是非技术人员随便生成的网站代码，而是出现在生产环境中的、由每一个"偷懒"的工程师生成的垃圾代码。传统软件开发中，代码审查是保证质量的关键环节，有经验的工程师会仔细审查新提交的代码，检查逻辑错误、性能问题、安全漏洞。但当AI一次性生成几千行代码时，这个审查过程变得几乎不可能——人类注意力是有限的，没人能认真审查几千行他们没有参与编写的代码。结果是大量未经充分审查的代码被合并到生产环境，积累成为技术债务，甚至埋下安全隐患。Sarah提到目前这个领域"完全开放"，没有人真正解决。这让我意识到，AI时代的工程管理核心问题已经从"如何加快代码生产"转向"如何在海量AI生成代码中保证质量"，这是一个全新的管理维度，需要全新的工具和方法论。
数据背后的矛盾：成本暴跌与收入暴涨的共存
Elad分享的两组数据放在一起看很有意思。第一组是收入增长速度：AI实验室从10亿到100亿只用了约1年，对比ADP和Adobe用了20多年、Salesforce和SAP用了8-9年、Google和Meta用了3-5年。第二组是token价格：GPT-4级别模型21个月内从每百万token 37美元降到25美分，降幅150倍；o1级别模型11个月内从26美元降到30美分，降幅88倍。通常的认知是成本下降会刺激竞争、压低利润，但这里看到的是成本暴跌的同时收入暴涨。这说明需求的增长速度远远超过了价格的下降速度，AI不是在简单地替代现有软件市场，而是在创造全新的、规模更大的市场。这也印证了软件需求可能是"无限"的假设——生产力的提升不是减少需求，而是释放更多被压抑的需求。
多产品捆绑的防御逻辑
Sarah提出了一个与SaaS时代主流智慧相悖的观点：最好的防御策略是构建产品捆绑（bundle），而不是"做好一件事"。SaaS时代流行专注单一产品，但在AI时代技术变化太快，单一产品公司面临的风险太大——AI实验室可能向前整合到你的垂直领域，竞争对手可能用新技术快速超越你。历史上成功的平台公司都是多产品策略：Microsoft在操作系统基础上向前整合构建Office套件，Google从搜索引擎出发整合到垂直搜索领域。捆绑的价值在于，当你为同一个客户提供5-10种不同的产品或功能时，你就变成了他们工作流程中不可或缺的一部分，竞争对手很难轻易替代你。这不是简单的交叉销售，而是一种降低客户切换成本风险、提高生态系统粘性的结构性防御。
Demo与产品的鸿沟：为什么真实的变革比炒作慢
Sarah和Elad都强调，我们刚刚经历了一个充满炒作的月份，很多东西被过度渲染。她直言不讳地指出，很多"新兴行为"实际上是为营销目的刻意制造的。一个典型例子是所谓的AI agent自主做软件采购决策——真实情况可能只是AI产品通过合作伙伴关系默认使用了某个底层服务，就像Airtable后台自动使用AWS一样，这是商务合作的常规操作，不是AI的自主决策。这让我想起自动驾驶领域的情况：多年来无数炫酷的演示，但真正大规模商业化的产品很少，因为从demo到产品之间有一道巨大的鸿沟，需要解决可靠性、安全性、边界情况处理、成本控制等一系列复杂问题。股票分析师似乎还没理解这个区别，看到一个炫酷演示就以为产品已经成熟，忽略了实际部署到企业环境中需要解决的大量工程和组织问题。长期来看AI确实会带来根本性变革，但短期对变革速度和范围的高估是明显的。
工程师角色的分化：产品型与系统型
基于这些讨论，我越来越清晰地看到工程师角色在未来会分化为两个方向。一类是"产品工程师"——把AI工具用到极致，关注快速构建和迭代产品，为用户创造价值。这类工程师的数量会大幅增加，因为AI降低了编程门槛，使更多人能参与到软件开发中。另一类是"系统工程师"——深入理解底层系统，负责确保AI生成的代码是可靠的、可维护的、符合质量标准的。这类工程师会变得更加稀缺和重要，因为在AI生成大量代码的环境下，我们比以往任何时候都更需要能够理解和控制复杂系统的专家。前者的价值在于速度和创意，后者的价值在于深度和质量保证。这不是高低之分，而是两种不同的专业路径，分别对应不同的组织需求和个人能力倾向。