# Lovable 如何处理计费：完整拆解

> 详细拆解 Lovable 的预付费计费模式，涵盖定价层级、消息预付额度、每日奖励、云计量，以及如何使用 Dodo Payments 构建相同系统。
- **Author**: Ayush Agarwal
- **Published**: 2026-04-10
- **Category**: AI, Billing
- **URL**: https://dodopayments.com/blogs/zh/lovable-billing-model

---

Lovable 按消息对 AI 输出收费：你发送的每条提示都会从月度订阅额度池中消耗一个预付额度，而应用运行所需的云基础设施则按照完全独立的计量方式收费。它是一款 AI 驱动的 Web 应用构建工具，能够将自然语言提示转换为可运行的 React 应用，并已成为 [vibe coding](https://dodopayments.com/blogs/vibe-coding) 运动中增长最快的工具之一，让非技术创始人和开发者可以通过聊天界面发布全栈应用。但从计费角度来看，Lovable 有趣的地方不在于它构建什么，而在于它如何收费。

Lovable 没有采用传统的按席位或固定费用订阅，而是使用混合式预付费计费模式。用户支付月度订阅费，并获得一组消息预付额度。每条发送给 AI 的提示都会消耗预付额度。除此之外，Lovable 还叠加了每日奖励额度，以及一条针对云基础设施的独立按量计费轨道。对于需要管理实时推理成本的 [AI 原生初创公司](https://dodopayments.com/blogs/adaptive-pricing-ai-native-startups) 来说，这种订阅稳定性与按使用量灵活性相结合的方式正变得越来越普遍。

本文将详细拆解 Lovable 的计费方式、它为何有效、会在哪些地方造成摩擦，以及如何使用 [Dodo Payments](https://dodopayments.com) 从零构建同样的模式。

## Lovable 的定价层级

Lovable 提供四种方案，价格以本文撰写时公布的价格为准。所有付费方案都允许工作区中的不限数量用户共享预付额度，也就是说没有按席位定价。

| 方案       | 价格   | 月度预付额度 | 每日奖励             | 主要功能                                                      |
| ---------- | ------ | ------------ | -------------------- | ------------------------------------------------------------- |
| Free       | $0/月  | 0            | 5/天（每月最多 30）  | 仅限公开项目、5 个子域名、20 位协作者                         |
| Pro        | $25/月 | 100          | 5/天（每月最多 150） | 预付额度结转、按需充值、自定义域名、按使用量计费的 Cloud + AI |
| Business   | $50/月 | 100          | 5/天                 | SSO、团队工作区、设计模板、安全中心、基于角色的访问控制       |
| Enterprise | 定制   | 定制         | 定制                 | SCIM、专属支持、审计日志、发布控制、设计系统                  |

按年计费可享受约 16% 的折扣：Pro 降至 $21/月，Business 降至 $42/月。

这里有几件事值得立即注意。Pro 和 Business 都包含每月 100 个预付额度，这意味着价格从 $25 跳到 $50，完全是为了协作和治理功能，而不是为了提供更多 AI 使用量。这是一个有意为之的选择，说明 Lovable 将预付额度视为标准资源，而将工作区工具视为高级差异化功能。

## 预付额度如何运作：计费单位

Lovable 的核心计费单位是"预付额度"，一个预付额度等于向 AI 发送一条消息。这是一个重要的设计决策。许多 AI 工具按 token 计费，这会给用户带来理解负担，因为他们无法直观判断 1,000 个 token 到底意味着什么，也会迫使服务商采用完整的 [token 级计量架构](https://dodopayments.com/blogs/metering-llm-token-usage-architecture)。Lovable 完全避免了这一点。

用户在聊天界面中输入提示并点击发送时，就会消耗一个预付额度。无论提示是"把按钮颜色改成蓝色"，还是"帮我构建一个带身份验证和 Supabase 后端的完整 CRUD 仪表盘"，结果都一样：一条消息，一个预付额度。

这里有两种计费方式，消耗的预付额度不同：

- **计划模式**：每条消息消耗 1 个预付额度。这是标准交互方式：你输入提示，Lovable 生成代码。
- **代理模式**：根据任务复杂度消耗不定数量的预付额度。AI 会将任务拆分为多个子任务并自主执行，因此会消耗更多预付额度。

有一个例外："尝试修复"按钮免费。当 Lovable 生成的代码抛出错误时，你可以点击此按钮而不消耗预付额度。这是一个聪明的用户体验设计，避免用户因为 AI 的错误而产生被惩罚的感觉。

### 每日奖励额度

包括 Free 方案用户在内的每位用户，每天都会获得 5 个奖励预付额度。这些额度用过即失效。如果你周一没有使用当天的 5 个额度，它们会在周二消失。

对 Free 用户而言，每日奖励就是整个产品。每天 5 个额度，每月约为 30 个额度，足够进行尝试，但不足以构建真正复杂的项目，因此形成了自然的升级路径。

对 Pro 和 Business 用户而言，每日奖励会叠加在月度额度池之上。Pro 用户拥有 100 个每月预付额度，算上每日奖励后，最多可获得 150 个额度（按 30 天计算，每天 5 个，共 150 个；其中月度额度贡献 100 个）。每日奖励实际上为付费用户提供了每天可用的最低参与额度，鼓励他们定期回到产品中。

> 每日奖励不只是计费机制，也是留存工具。它会形成一种每日习惯循环，让用户想："我今天有 5 个免费额度，应该用掉它们。"这与游戏中的每日登录奖励背后的心理机制相同。
>
> - Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO

### Cloud + AI：第二条计费轨道

Lovable 为云基础设施运行一条独立的按量计费轨道。当你部署 Lovable 项目后，就可以使用托管、数据库（通过 Supabase 集成）、边缘函数和存储。这些资源按使用量计费，并消耗与 AI 消息预付额度不同的另一组额度。

这种双层计费模式将"思考"成本（AI 预付额度）与"运行"成本（云计算）分开，但前提是每条轨道都必须按照自身规则进行 [准确计量](https://dodopayments.com/blogs/metered-billing-accurate-billing)。由于成本结构存在根本差异，这种模式正在 AI 开发平台中成为标准做法。AI 推理具有突发性且成本高昂，而云托管则更加稳定，成本相对较低。将两者合并到同一个额度池中，要么会让托管定价过高，要么会让推理定价过低。

## Lovable 模式为何有效

### 基于消息的简单性

Lovable 抽象掉 token、模型权重和上下文窗口大小，让用户层面的计费变得可预测。用户清楚知道这个月可以发送多少条提示。在计划模式下，他们不需要计算复杂提示是否会比简单提示花费更多。这种简单性降低了 [计费焦虑](https://dodopayments.com/blogs/billing-ux-usage-caps-alerts)，并鼓励用户进行尝试。

### 团队共享额度池

工作区中的不限数量用户可以共享预付额度。这是对按席位定价的一种有意替代，因为按席位定价会惩罚不断成长的团队。五人的初创公司与单人创始人在 Pro 方案上支付相同的费用。无论团队人数多少，价格都保持不变，团队共享同一个 100 额度池。这让 Lovable 对注重成本、希望避免 [按席位计费断层](https://dodopayments.com/blogs/subscription-pricing-models) 的早期团队很有吸引力。

### 不收取超额费用

当预付额度归零时，使用量就会停止，不会产生意外账单。这是一种硬上限模式，也是建立信任的有意选择。许多 [按使用量计费系统](https://dodopayments.com/blogs/usage-based-billing-saas) 允许超额使用并收取按单位计算的附加费，这可能导致账单冲击。Lovable 牺牲了高级用户带来的潜在收入，换取所有用户都能享受的成本可预测性。

### 预付额度结转（Pro 及以上）

付费方案中未使用的月度预付额度会结转到下一个计费周期。这减轻了月度额度池"用过即失效"的压力，也奖励那些使用量较少的月份。与不会结转的每日奖励结合后，它形成了一套平衡系统：用户始终有可用额度，同时仍会受到鼓励，保持每日使用节奏。

## 挑战与摩擦点

### 固定额度成本掩盖了价值差异

"把这个按钮改成红色"和"帮我构建一个完整的身份验证系统"各消耗一个预付额度，但它们带来的价值显然并不相等。在计划模式下，两者的成本完全相同。这意味着用户会学着在一条消息中塞入尽可能多的指令，以最大化每个额度的价值。同时，Lovable 承担了成本差异，这种方式在规模化运行时可行，但复杂提示会消耗更昂贵的推理资源，从而对利润率造成压力。如何设置能够承受这种差异的单位价格，是 [AI 封装产品定价](https://dodopayments.com/blogs/price-ai-wrapper) 中最困难的部分。

代理模式通过针对多步骤任务收取不定数量的预付额度，部分解决了这个问题。但代理模式交互的确切成本不会提前显示，这又引入了一些固定额度模式原本试图避免的计费不确定性。

### 100 个额度并不多

对于认真构建项目的用户来说，每月 100 个额度可能在几次专注的工作中就消耗殆尽。一个典型项目可能需要在布局、逻辑和集成方面进行几十次迭代。按每条消息一个额度计算，用户可能在一个高强度构建的下午就用完整个月的额度。

每日奖励有所帮助，但每天只增加 5 个额度。达到上限的用户只能选择：等待第二天的每日奖励、购买充值包，或升级到下一层级。由于 Pro 和 Business 都只提供每月 100 个额度，升级实际上并不能解决额度不足的问题。这会将高级用户推向 Enterprise 或反复购买充值包，从而使 [总成本难以预测](https://dodopayments.com/blogs/billing-credits-pricing-cashflow)。

### Business 层级没有增加更多额度

从 Pro（$25/月）升级到 Business（$50/月）会让价格翻倍，却不会增加额度。两个层级都包含每月 100 个额度。额外的 $25 用于购买 SSO、团队工作区和设计模板等协作功能。对于主要需要更多 AI 使用量的团队而言，这会造成缺口：他们支付了可能并不需要的治理功能，却仍然会用完额度。

### 无法查看代理模式的额度成本

使用代理模式时，用户无法提前看到一项任务会消耗多少额度。系统根据复杂度收费，但复杂度要在任务执行后才能确定。这会造成摩擦：由于无法预测成本，用户会不愿意使用更强大的模式。即使只是粗略的执行前估算，也能显著降低这种摩擦。

## 如何使用 Dodo Payments 构建 Lovable 式计费系统

订阅层级、额度权益、每日奖励逻辑和独立云计量的组合，可以通过 Dodo Payments 的 [预付费计费](https://docs.dodopayments.com/features/credit-based-billing) 与 [按使用量计费](https://docs.dodopayments.com/features/usage-based-billing/introduction) 功能复现。架构方式如下。完整实现流程请参阅 Dodo 文档中的 [Lovable 计费拆解](https://docs.dodopayments.com/developer-resources/billing-deconstructions/lovable)。

### 第 1 步：定义预付额度权益

在 Dodo Payments 控制台中创建代表消息预付额度的额度权益：

- **额度类型**：自定义单位
- **单位名称**："Messages"
- **精度**：0（仅支持整数消息）
- **额度有效期**：30 天
- **超额使用**：禁用（余额为零时设置硬上限）

这与 Lovable 的模式直接对应：1 个额度 = 1 条消息，额度用完后停止使用。有关配置结转、有效期和低余额提醒的详情，请参阅 [预付费计费文档](https://docs.dodopayments.com/features/credit-based-billing)。

### 第 2 步：创建附带额度的订阅产品

创建你的 [订阅](https://docs.dodopayments.com/features/subscription) 产品，并为每个产品附加额度权益：

```typescript
import DodoPayments from "dodopayments";

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
});

// Create a checkout session for the Pro plan
const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: "prod_pro_plan", quantity: 1 }],
  customer: { email: "user@example.com" },
  return_url: "https://yourapp.com/dashboard",
});
```

订阅激活后，Dodo 会自动向客户发放 100 个消息预付额度。每个计费周期都会刷新额度。

### 第 3 步：实现每日奖励

每日奖励属于应用层逻辑。运行一个 cron 作业，在 UTC 午夜为每位用户重置 `daily_bonus_used` 计数器：

```typescript
// When a user sends a message, check the daily bonus first
async function handleMessage(userId: string) {
  const user = await db.users.findUnique({ where: { id: userId } });

  if (user.daily_bonus_used < 5) {
    // Consume from daily bonus pool (tracked in your DB)
    await db.users.update({
      where: { id: userId },
      data: { daily_bonus_used: { increment: 1 } },
    });
    return; // No Dodo credit deduction needed
  }

  // Daily bonus exhausted - deduct from subscription credits
  await client.usageEvents.ingest({
    events: [
      {
        event_id: `msg_${Date.now()}`,
        customer_id: userId,
        event_name: "ai.message",
        timestamp: new Date().toISOString(),
        metadata: {
          project_id: "proj_abc",
          mode: "plan",
        },
      },
    ],
  });
}
```

这样，每日奖励额度会优先消耗，只有奖励用完后才会使用月度订阅额度池。每日奖励通过你的 cron 作业重置，而订阅额度则完全由 Dodo 管理。

### 第 4 步：为云基础设施添加使用量计量器

对于第二条计费轨道（云计算），在 Dodo 中创建一个 [按使用量计费的计量器](https://docs.dodopayments.com/features/usage-based-billing/introduction)：

```typescript
// Ingest cloud usage events
await client.usageEvents.ingest({
  events: [
    {
      event_id: `compute_${Date.now()}`,
      customer_id: "cust_123",
      event_name: "cloud.compute_seconds",
      timestamp: new Date().toISOString(),
      metadata: {
        compute_seconds: 3600,
        project_id: "proj_abc",
      },
    },
  ],
});
```

为订阅产品附加此计量器，并设置按单位计价。Dodo 会将云账单与预付额度扣除分开计算，为你提供与 Lovable 相同的双层计费结构。

### 第 5 步：通过 Webhook 处理低余额提醒

设置 [额度 Webhook](https://docs.dodopayments.com/developer-resources/webhooks/intents/credit)，在余额下降时通知用户：

```typescript
app.post("/webhooks/dodo", async (req, res) => {
  const event = client.webhooks.unwrap(req.body.toString(), {
    headers: {
      "webhook-id": req.headers["webhook-id"] as string,
      "webhook-signature": req.headers["webhook-signature"] as string,
      "webhook-timestamp": req.headers["webhook-timestamp"] as string,
    },
  });

  if (event.type === "credit.balance_low") {
    const { customer_id, available_balance } = event.data;
    await sendEmail(customer_id, {
      subject: "Your message credits are running low",
      body: `You have ${available_balance} credits remaining.
             Top up or upgrade your plan to keep building.`,
    });
  }

  res.json({ received: true });
});
```

当客户余额低于你配置的阈值时，`credit.balance_low` Webhook 就会触发。这样你可以在用户余额归零前提示其购买充值包或升级方案，从而减少额度耗尽带来的流失。

### 架构概览

下面是从消息到计费的完整流程：

```mermaid
flowchart LR
    A[User Sends Message] --> B{Daily Bonus Available?}
    B -->|Yes| C[Deduct from Daily Pool]
    B -->|No| D{Subscription Credits Available?}
    D -->|Yes| E[Ingest Usage Event to Dodo]
    D -->|No| F[Block - Show Upgrade Prompt]
    E --> G[Dodo Deducts Credit]
    C --> H[Call LLM Provider]
    G --> H
    H --> I[Return AI Response]
    I --> J[Ingest Cloud Usage Separately]
```

这种架构让计费逻辑保持清晰。你的应用负责每日奖励，Dodo 负责订阅额度、计量、Webhook 和 [结账](https://dodopayments.com/blogs/checkout-optimization)。两层逻辑互不重叠。

## 结合上下文看 Lovable 的模式

Lovable 的计费处于一个有趣的交叉点。它不像 token 定价那样完全基于使用量，也不像传统 SaaS 那样完全基于订阅，而是融合了两者的优点。

按消息计费的额度模式与其他 [AI 计费平台](https://dodopayments.com/blogs/ai-billing-platforms) 正在采用的方式相似。Bolt、Cursor 和 Replit 等工具都在订阅之上叠加了某种额度或按请求计费模式。在移动端遇到同样限制的消费级应用，则会采用不同的技术栈；因此，发布到应用商店的创始人最终会比较订阅和付费墙基础设施的 [RevenueCat 替代方案](https://dodopayments.com/blogs/revenuecat-alternatives)。趋势很明确：[仅靠固定费用订阅无法适用于 AI 产品](https://dodopayments.com/blogs/usage-based-billing-vs-flat-fees-ai-saas)，因为服务每个请求的边际成本太高。预付额度能够形成自然的使用节流，在保护利润率的同时，让用户可以预测自己的月度预算。

如果你正在构建 AI 产品，并考虑如何为其 [定价](https://dodopayments.com/blogs/ai-pricing-models)，Lovable 的模式值得研究。订阅基础（带来可预测收入）、额度池（匹配使用量）、每日奖励（促进留存）和独立云计量（隔离成本）结合在一起，几乎覆盖了 AI 原生初创公司面临的所有计费挑战。

> 预付费计费不只是管理成本，更是创造符合用户产品认知的计费体验。如果用户以"消息"为单位思考，就按消息计费；如果他们以"生成次数"为单位思考，就按生成次数计费。抽象层非常重要。
>
> - Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO

如需包含完整代码示例的分步实现指南，请参阅 Dodo Payments 文档中的 [Lovable 计费拆解](https://docs.dodopayments.com/developer-resources/billing-deconstructions/lovable)。你还可以了解如何为 AI 应用 [添加额度计费](https://dodopayments.com/blogs/add-credits-billing-ai-app)，或在更广泛的场景下学习 [订阅计费](https://dodopayments.com/blogs/set-up-subscription-billing-afternoon)。

## 常见问题

### Lovable 如何对 AI 使用量收费？

Lovable 使用预付费计费系统，在计划模式下 1 个预付额度等于 1 条消息。代理模式会根据任务复杂度消耗不定数量的预付额度。额度来自月度订阅额度池，以及每天 5 个额度的奖励。托管和数据库等云基础设施则根据使用量单独计费。

### Lovable 额度用完后会发生什么？

使用量会停止。Lovable 采用硬上限模式，不收取超额费用。你可以等待第二天获得 5 个奖励额度，购买按需充值包，或升级方案。如果 Pro 方案的额度未用完，也会结转到下一个计费周期。

### 为什么 Lovable Pro 和 Business 的额度数量相同？

两个方案都包含每月 100 个额度。价格差异（$25/月与 $50/月）用于支付 SSO、团队工作区、设计模板和基于角色的访问控制等协作与治理功能。每月需要超过 100 个额度的团队，只能选择 Enterprise 或按需充值。

### 可以构建类似 Lovable 的预付费计费系统吗？

可以。使用 Dodo Payments，你可以创建用于按消息计费的额度权益，将其附加到订阅产品，并通过应用层的 cron 逻辑处理每日奖励。按使用量计费的计量器则可以独立处理云计费轨道。完整实现指南请参阅 [Lovable 计费拆解](https://docs.dodopayments.com/developer-resources/billing-deconstructions/lovable)。

### Lovable 的计费模式适合 AI 产品吗？

订阅加预付额度的混合方式很适合 AI 产品，因为它在可预测收入与可变计算成本之间取得了平衡。基于消息的预付额度简化了用户的计费体验，而独立的云计量则隔离了基础设施成本。主要限制在于，固定的每消息价格无法反映简单提示与复杂提示之间实际存在的成本差异。

## 最后总结

Lovable 的计费模式是一个关于如何为 AI 生成价值收费的实用案例。按消息计费的方式以精细准确性换取了对用户友好的简单性。每日奖励推动留存，团队共享额度池避免了按席位定价带来的摩擦，而独立的云计量则将基础设施成本与 AI 使用成本分离。

如果你正在构建类似的 AI 产品，并希望实现这种混合计费模式，[Dodo Payments](https://dodopayments.com) 为你提供了所需的基础模块：[额度权益](https://docs.dodopayments.com/features/credit-based-billing)、[订阅管理](https://docs.dodopayments.com/features/subscription)、[按使用量计量](https://docs.dodopayments.com/features/usage-based-billing/introduction) 和 [由 Webhook 驱动的自动化](https://docs.dodopayments.com/developer-resources/webhooks/intents/credit)。你无需从零构建计费基础设施，可以将精力集中在产品本身的功能上。

查看完整的 [定价明细](https://dodopayments.com/pricing)，了解 Dodo 的透明费率。
---
- [More AI articles](https://dodopayments.com/blogs/category/ai)
- [All articles](https://dodopayments.com/blogs)