Lovable 的巧思：先停在计划里，再指着界面改

很多 AI app builder 把产品做成一个大输入框：用户说一句，系统改一轮。Lovable 的有趣之处，是把这条看似顺滑的路径拆开了。Lovable 文档把它定义为用自然语言构建、迭代和部署 Web 应用的全栈 AI 开发平台，生成的应用包含前端、后端、数据库、认证和集成，并且代码可以编辑、同步到 GitHub。1

这类产品最容易出问题的地方，不是模型不会写代码，而是用户常常还没想清楚，AI 已经开始改文件。Lovable 的设计选择，是在「想清楚」和「动手改」之间加一道可审查的门；等界面生成出来，又把修改入口放回预览画面本身。

Lovable 把工作分成 Plan mode 和 Build mode：Plan mode 用来探索、比较方案和做决定，Build mode 用来实现并验证结果。官方文档明确写到，Plan mode 不会修改代码；只有用户批准方案后，Lovable 才切换到 Build mode，并且实现会基于已批准的方案开始。2

这不是简单地把「聊天」改个名字。Plan mode 会在有清晰实现方向时生成一个结构化计划，计划里通常包含方案概览、关键决策、假设、约束、组件、数据模型、API 和实施顺序；用户可以在 Plan view 里直接编辑这份 Markdown 计划，再决定是否批准。2

这里的巧思在于，Lovable 没有把用户的第一段提示词当成最终规格。AI 编程工具常见的坏体验，是用户说「加一个登录」，系统马上改出一堆文件；等用户发现登录态、重置密码、权限边界都没说清楚，代码已经散落在项目里。Lovable 先产出一份可读计划，相当于把模糊需求临时冻结成一个中间件：用户审查的是方案，不是事后猜 AI 改了什么。

Build mode 的执行也没有完全黑箱化。Lovable 文档说明，Build mode 会直接修改项目，所有修改通过文件 diff 和摘要呈现；执行时，界面会显示当前步骤、被修改文件、使用的工具和多步骤任务进度。3 这个设计把「AI 正在工作」从一句状态提示拆成了更细的观察点。用户不一定要懂每一行代码，但至少能判断它是不是在朝正确方向跑。

这道门也有代价。Plan mode 的每条消息都会消耗一个 credit，方案审批会让极小改动显得更慢。2 但对真实项目来说，这个代价可以接受。AI 先写错再回滚，看起来快，实际常常把用户拖进排错；先确认方案，反而让后面的自动化更敢放手。

Lovable 的另一处设计，发生在应用预览区。Preview toolbar 取代了原来的 Visual edits：用户不再打开一个单独编辑面板，而是在预览里选择工具模式，指向想改的地方，再用自然语言描述更新。4

Preview toolbar 有四种主要动作：选择元素、就地改文字、画注释、添加评论。选择元素时，用户可以点击一个或多个页面元素，这些元素会作为引用附到主聊天输入框，随后一句提示会应用到所有被选中的元素；画注释时，用户直接在预览图上圈、画箭头或框选区域，Lovable 会同时收到文字和带标注的截图。4

这解决的是一个很细但很常见的问题：界面修改里，最难说清楚的往往不是「改成什么」，而是「改哪里」。用户写「把右边那块卡片往下挪一点」时，AI 需要猜「右边那块」是哪一个组件；用户点选元素或在画面上圈出来，定位问题直接消失。Lovable 把预览区变成输入设备，用户的手势、选择和涂鸦都能进入提示词上下文。

同样的思路也出现在 Design guidance 里。面对视觉方向开放的请求，Lovable 会先生成三个轻量 HTML/Tailwind 设计方向，让用户并排比较布局、字体、颜色、间距和整体调性；用户选定方向后，Lovable 才锁定这个视觉方向并进入完整构建。5 如果用户已经有偏好，Lovable 还会通过字体、色板和布局问题生成一份包含字体名、十六进制颜色和布局方案的设计 brief。5

这比「生成一个版本，再让用户反复骂它不好看」更聪明。视觉方向在第一次完整构建之前就被分叉，用户不必用很长的审美形容词去纠偏；页面出现以后，用户又可以用点选和画注释处理局部问题。Lovable 把审美选择和局部修正都做成了可指认对象。

Lovable 值得拆的地方，不在它能把一个想法变成多少文件。更具体地说，Lovable 把三个容易失控的环节都做成可审查对象：方案、视觉方向和页面元素。用户不必把所有意图压进一段提示词，也不用等代码改完才发现方向错了。

这个设计牺牲了一点「一句话全自动」的爽感，换来更清楚的责任边界。Lovable 允许 AI 执行复杂任务，但执行之前有计划，视觉投入之前有方向，界面修改之前有指认。对 AI app builder 来说，这比单纯把生成能力堆得更强，更接近一个可长期使用的产品界面。