看到豆包再次下架“应用生成”功能,我第一反应是:字节这次是真下定决心要做减法了。继智能体功能下线后,这已经是第二刀,而且砍得毫不含糊。从技术角度看,“应用生成”本质上是基于大模型的低代码封装,用户输入需求就能生成一个简易应用,听起来很美好,但实际体验往往卡在“生成即上限”——生成的Demo无法深度定制,后续维护成本高,用户留存率低。字节保留编程功能,说明他们更倾向于让用户直接调用API或写代码来构建应用,而不是依赖黑盒式的“一键生成”。这其实是在赌:与其分散资源维护两个半成品,不如把核心对话和推理能力打磨到极致。我个人的经验是,很多“智能体”或“应用生成”产品最后都变成了玩具,真正有生产力的场景还是需要开发者介入。这让我想到一个问题:大模型公司究竟应该做平台还是做能力?豆包显然选了后者,但这是否意味着低代码AI应用这条路暂时走不通了?另外,行业里OpenAI的GPTs和字节的智能体几乎同时遇冷,是不是说明通用大模型+垂直工具的组合比“全栈AI应用平台”更靠谱?欢迎各位聊聊你们的看法。
豆包砍掉应用生成,聚焦核心AI才是正道?
全部回复
共 2 条说实话,我对字节这波操作挺理解的。之前试过豆包的应用生成功能,怎么说呢,demo阶段看着挺唬人,但真到落地环节就露怯了。比如我让它生成一个简单的数据看板,界面确实出来了,可我想改个字体大小、加个筛选条件,得,直接卡死。这种“生成即上限”的体验,对开发者来说其实挺劝退的。
字节保留编程功能,我觉得是个务实的选择。现在很多团队把AI应用生成当噱头,但真正能跑起来、能迭代的,往往还是得靠API+代码自己搭。黑盒生成的东西,你都不知道它底层怎么调用的,出了bug连排查都无从下手。与其这样,不如把核心对话和推理能力做扎实,让开发者自己决定怎么组装。
不过我也有一点担心:砍掉这些功能后,豆包会不会变得太“硬核”了?毕竟不是所有用户都会写代码,很多产品经理、设计师或者小团队,他们需要的是低门槛的快速验证工具。如果字节只盯着API和编程,可能会丢掉一部分轻度用户。当然,可能字节的目标用户本来就是工程师群体,那就另说了。
话说回来,你们觉得豆包现在的编程功能体验怎么样?我还没深度用过,如果它能把API的调用链和错误提示做得足够友好,那确实比那些半成品的“一键生成”靠谱得多。
说实话,字节这步棋我挺理解的。应用生成这个方向,从技术底层看就是个伪需求——大模型现在的推理能力还没到能稳定生成可维护应用的程度,你让LLM写个带状态管理的完整UI,最后出来的代码基本是“能跑但一改就崩”。字节保留编程功能,本质上是把选择权还给有技术判断力的人,而不是去赌那个“人人都是开发者”的叙事。
而且你提到的“生成即上限”特别到位。我试过几家类似产品,生成的Demo看起来像模像样,但一旦涉及到动态交互、数据持久化或者第三方API对接,立马露怯。用户拿到一个不能改的壳子,新鲜劲过了就流失,留存率自然难看。字节砍掉这个,更像是把资源砸在对话质量和推理深度上——这才是大模型当前最有统治力的场景。
不过有个点想讨论:他们砍应用生成但留编程功能,会不会把非技术用户彻底推开?毕竟很多人连API key和JSON都搞不清楚。我觉得字节可能是在赌“重度用户比轻度用户更有价值”,毕竟智能体那波已经证明了,低门槛进来的用户大部分都是白嫖体验,真正愿意付费的反而是那些能自己写代码调参数的。你觉得这种“技术优先”的取舍,会不会让他们在C端市场丢掉一部分潜在用户?