拆解 Lovable 积分系统：AI 建应用的真实成本

积分不只是用来生成代码的

多数人以为 AI 建站平台的积分只对应「生成代码」这一件事，但一位 YouTube 创作者反向拆解 Lovable 的积分系统后发现，积分的消耗范围远比想象中宽。据该创作者引述 Lovable 官方文档，积分不仅用于生成代码，还可能覆盖托管、后端使用，以及应用内部的 AI 功能。

这意味着你为「一次对话」付出的积分，背后可能对应着运行时资源的持续消耗。对刚接触这类工具的人来说，最需要调整的认知是：积分不是「生成次数」的代币，而更像一张覆盖多种成本的通用额度。

这里的「托管」指平台替你把应用部署到服务器上并保持可访问状态，通常包含域名解析、SSL 证书、静态资源分发等；「后端」则指数据库、用户认证、文件存储、API 网关等运行支撑服务。传统开发中这些多由 Vercel、Supabase、Firebase 等专门服务按用量计费，而一体化 AI 建站平台把它们打包进同一套积分体系，所以「聊天生成代码」的积分实际上还预支了后续运行所需的部分资源。理解这一点，才能明白为什么有些操作看起来只是改了几行代码，扣分却明显偏多。

任务不同，积分消耗差距悬殊

更值得关注的是消耗量级的差异。该创作者给出了 Lovable 文档中的两个例子：修改一个按钮的颜色消耗半个积分，而添加身份认证功能则需要 1.2 个积分。同样是「让 AI 改一下」，成本可以相差两倍以上。

这个对比说明，简单的前端样式调整与涉及逻辑、依赖、安全流程的功能开发，在系统内部的计费权重并不相同。如果你习惯用「多问几次 AI」来试错，那么在大功能上反复迭代的代价会明显高于反复调整 UI 细节。理解了这一点，才能对自己的积分消耗做出合理预估，而不是等到额度见底才回头找原因。

「身份认证」是应用中负责确认「你是谁」的模块，典型功能包括注册登录、密码加密存储、邮箱验证、会话管理、第三方 OAuth 登录（如 Google、GitHub）以及权限校验。它涉及数据库表结构、密钥管理、安全流程与前后端联调，AI 需要改动多个文件并引入外部依赖，因此计费权重远高于只改一行 CSS 的按钮颜色。这也解释了为什么带认证、支付、权限控制的功能在 AI 建站平台上往往更「贵」——消耗的不是字符数，而是需要协调的模块数量与出错后返工的概率。

过期规则才是隐形变量

初学者最容易忽略的一点是积分的时间属性。该创作者指出，部分赠送积分按日过期，另一些积分则适用不同的过期规则。也就是说，你不仅要搞清楚自己拿到了多少积分，还要搞清楚这些积分能用在什么地方、什么时候失效。

这条规则对使用节奏有直接影响。按日过期的额度意味着「攒着不用」本质上是浪费，而不同来源的积分有效期不一，又让额度管理变得复杂。合理的做法是把需要消耗大量积分的功能开发安排在额度充足、且即将过期的批次之前完成，而不是凭感觉随意分配。

「按日过期」的赠送积分通常指平台以每日签到、活动奖励等形式发放的额度，未在当日使用即清零，类似优惠券的限时逻辑；而付费购买或套餐内包含的积分往往按月或按更长周期结算。两类额度混在同一账户里时，系统一般优先消耗最先过期的那部分。因此查看账户时不能只看总数，还要区分来源与有效期，把大功能开发排在临期额度用完之前，避免「有积分却用不上」或「积分悄悄归零」的情况。

代码写完，成本未必结束

这次拆解最核心的结论，落在一个容易被忽略的时间维度上：如果你构建的是一个带 AI 能力的应用，成本并不会在代码完成那一刻停止。托管、后端、应用内 AI 功能都在持续消耗积分，你在规划「怎么把应用做出来」的同时，也得规划「怎么让它继续跑下去」。

这个视角把 AI 建站工具的成本结构，从一次性支出拉回到了运营支出。对独立开发者和小团队来说，这直接影响到技术选型：是接受平台的一体化计费换取省心，还是在关键模块上选择更可控的外部方案，取决于你对长期运行成本的容忍度。

需要说明的是，以上结论均来自单一创作者的公开拆解，具体计费细则仍应以 Lovable 官方文档的最新说明为准。该创作者也在视频结尾向观众征集下一个希望被拆解的 AI 建站工具，说明这类平台的计费透明度仍是普遍痛点。