秒哒们的路子可能走错了

这两天一键生成应用的智能编程赛道很火，先是Bolt New 4周从0干到400万美金的 ARR，然后李厂长的One More Thing——秒哒。两家都在鼓吹未来人人都是开发者，十亿级别的开发者，大家玩得也很开心（不然不会有400万美金ARR呐）。

但我认为，李厂长可能高估了大众对开发软件的需求，也高估了AI的能力。

死磕一键生成应用不是正确的道路，生成模块才是

无代码这个行业做了很多年了，一直以来没有取得非常大的成功。无代码开发在所有的软件开发里面的占比始终比较小。这是技术不足的原因呢，还是可能已经证明了所谓的碎片化的应用开发并不是一个非常普遍的需求。更有可能是后者，因为Bolt New已经400万美金ARR了，但show出来的例子看起来也还是以图个新鲜为主，不是真实需求。真实情况是，很可能普通大众对自己开发个软件这事就没那么多需求。

如果AI没法取得特别大的再次突破，这条路能开发高度复杂软件的可能性是很低的，我们现在99%以上时间在用的软件，没一个搞得定。

这样看起来在这条路上走下去没啥意思？并不是，关键是要找到正确的使用姿势，这个正确的姿势我认为就是用这样的技术来自动化开发软件模块。

这是因为软件模块的复杂度是可控的。无论软件多复杂，架构师和专业的软件工程师都可以把软件拆解成一个又一个模块。除了少量模块高度复杂，大多数模块的复杂度都是可控的。

OK，有经验的工程师可能会发现这里有一个问题，就是随着软件复杂度的增加，一个模块和其它模块之间的交互的复杂度似乎会持续增加，似乎会失控。

我觉得理论上讲这个问题确实存在，但实际上，因为模块对外的接口复杂度毕竟相对低很多，也比较稳定。AI能在自动编程时学会用那么多的库和函数，学会软件其它模块的使用应该不是问题。工程师也可以约束一下模块能够使用的其它模块范围，降低难度。

让编程大模型称为巨大且灵活的组件库

这样做，智能编程大模型还可以成为一个巨大且灵活的组件库，而且这个组件库和之前所有的组件库的使用方式都不一样，灵活的多。 之前都是用组件，没法改。要定制组件的行为，只能通过配置、参数等有限的方法。组件为了支持更多使用场景，往往做得越来越抽象，易用性也越来越差。现在的用法变成copy-and-modify，我们不再需要把组件设计得那么抽象和难用。这是一个软件复用机制的paradigm-shift。当然，这样的机制有利有弊，我知道不少人（尤其是老程序员）对这种到处拷代码的方式嗤之以鼻，但我觉得，多一条路是好的，因为相比之前的复用方式（函数、类库、控件、组件或微服务等等），智能大模型的复用能力具有以下显著优点：

1、不需要特别的设计，没有额外的成本；2、所有的资产（文档、代码）都可以实现复用 3、细粒度， 可以做到字符级的复用；4、能够实现自适应的复用，不是简单的拷贝粘贴，而是先将资产沉淀成知识，再根据需求进行针对性得生成。