豆包继智能体功能后，又下线了应用生成功能，这波操作其实早有预兆。从技术角度看，应用生成功能本质上是一个低代码+LLM的拼凑方案，用户输入需求后生成前端界面和简单逻辑，但实际效果往往不如预期。我在部署类似方案时发现，LLM生成的应用存在严重的状态管理问题——用户对话历史一长，生成的代码就开始逻辑混乱，而且缺乏有效的错误处理机制。豆包保留编程功能而砍掉应用生成，说明他们意识到通用AI应用生成目前还无法达到生产级稳定性。
个人经验是，这类功能看似降低了开发门槛，实则把复杂度转移到了模型推理上。用户期望的是像专业软件一样流畅的体验，但当前LLM的推理延迟和输出一致性根本支撑不了这种需求。豆包这步棋虽然显得反复无常，但从技术落地角度看反而是明智的——与其维护一个体验不佳的功能消耗口碑，不如集中资源优化核心对话和编程能力。
这引出一个值得讨论的问题：AI产品的功能边界到底该怎么划？是应该像豆包这样快速试错然后收缩，还是从一开始就谨慎克制？另外，应用生成这类功能是否真的需要独立的LLM能力，还是说应该通过更好的Agent编排来实现？对行业来说，豆包的反复调整提醒我们：AI产品经理别被Demo迷惑，落地时要多想想状态管理和异常处理这些工程细节。