Lovable：让用户选模型是条死胡同

AI 应用构建平台 Lovable 发表长文，提出一个反直觉的观点：在产品中向用户暴露「模型选择器」并不合理，真正重要的是背后的编排能力。该公司主张「模型独立」（model-independent）而非「模型无差别」（model-indifferent），并以工程实践阐述了其控制面（control plane）如何为不同任务匹配最合适的模型与上下文。

为何不再让用户挑模型

打开大多数 AI 产品，角落总有一个模型下拉框。用户必须先选一个模型、再决定是否启用深度思考，然后才能开始工作。Lovable 认为这种设计本身就有问题：前沿模型各有所长——有的擅长调试复杂 bug，却在界面设计上失准；有的能输出漂亮 UI，却在长链路构建中丢失主线；新模型一发布，榜单轮番变动，价格也随之调整。「把某一个模型称为『最好的』，等于默认存在一个王座，但前沿并不存在王座。」

如果换模型会直接决定应用能否跑通，那么让用户在开工之前先去猜对答案，是不合理的。Lovable 因此把模型选择权收回系统内部，由专门的团队为每个模型定制指令、工具与项目上下文，并在完整构建链路中做评测。

模型独立 ≠ 模型无差别

「模型无差别」是把所有模型放在同一接口后，给同一段指令，把名字换一换就当作切换。「模型独立」则是深入研究每个模型的特性：它在长 debug 循环里容易卡在哪里？配置后端时表现如何？打磨界面时是否掉链子？团队围绕这些观察调整指令、工具和上下文，再做端到端测试。

文章给出的一个评测示例：某款前沿模型相对上一代完成同一任务快 15%，回合数减少 40%，得分高出 2–3 个百分点，这些数据使其在当时成为更优选项。但即便在某一模型上做了大量调优工作，Lovable 也强调「可移植性」——一旦出现更好的模型，必须能平稳迁移，而不必推翻此前积累的工程经验。

控制面才是产品本身

「给我的应用加上支付功能」听起来像一句指令，但在 Lovable 内部，这会触发一个 app-building agent 跑完整条构建链路：理解意图、定位项目相关部分、规划改动、写代码、运行应用、判断是否真的可用。一旦出错，恢复路径并不显然——是重试、改计划、换工具、引入不同推理风格的模型，还是反问用户？答案取决于构建过程暴露出的实际情况。

控制面正是为这种不确定性而存在。它实时观察：用户想做什么、任务难度如何、agent 是否在原地打转。基于这些信号，它可以把同一构建中的不同环节分给不同模型，而不是让一个模型扛下整条链路。

控制面还会调整模型周围的环境。例如有评测发现某模型会反复重读已在上下文中的文件，并在成功编辑后再去校验一次。Lovable 重新组织了指令：信任上下文、信任编辑结果、跳过冗余的工具调用。除此之外，他们也会更换工具、改写工具说明、调整注入的项目上下文量级，并在长构建中为下一轮生成摘要。

文章特意强调「这不是模型轮盘赌」——他们不会把同一段提示丢给五个模型再挑最喜欢的回答，而是为每个模型定制指令、工具和上下文，再看应用本身是否变好。

不频繁切换，而是按需恢复

中途换模型会让事情变糟，因为长链路项目会形成「历史」：agent 已经探索过文件、试过方案、踩过坑、记下了关键点。模型只是这个 agent 的一部分，换模型往往要压缩历史、重建缓存上下文，部分细节只能以摘要形式存活。这意味着：一个模型在孤立评测中更好，并不等于它适合当前这个正在进行的构建。

控制面必须权衡可能收益与上下文损失、重复劳动之间的关系。换模型的判断往往从失败原因出发：agent 通过一个「vent tool」直接上报难以外部观察的问题；如果某模型服务商过载，Lovable 可以把同一模型的下一次调用切到另一服务商，缓解可用性问题；但如果上下文错了、工具令模型困惑、或者模型误解了任务，换服务商只是丢掉了缓存，并未触及失败根源。这时带用户反馈的重试、或换模型换思路，可能更有效。

应用本身就是基准

一个模型可以给出漂亮回答，却留下一个跑不通的应用；可以写出看起来完整的结账页，却把数据存到了错误的位置。基准测试上的高分，到了浏览器里可能是另一个故事。因此 Lovable 把「成品应用」作为优化单位，关注整条轨迹——系统尝试过什么、在哪里恢复、构建耗时多少、成本如何，最终应用是否真的完成用户请求。

这也重塑了「快」与「便宜」的定义：响应快但要三轮才能做完，不算快；单次调用便宜，但把构建引到错误路径，整体就不便宜。围绕应用而非单次回复做优化，正是该平台选择把模型选择权收归系统内的核心理由。