Lovable、v0、Bolt对比：AI应用生成器的计费机制与退出成本

摘要：不会写代码、这周就要把能用的东西交到用户手里，选Lovable；团队在Vercel上跑Next.js且重视代码评审，选v0，但它的付费起步档已经从20美元涨到30美元；需要浏览器里的完整开发环境或者要做移动端，选Bolt。会用终端的工程师三个都不必买。决定这笔钱值不值的是三件事，功能清单排在后面：计费单位挂在什么东西上、应用变大之后成本曲线往哪走、离开时要付出多少。文中所有价格与额度都按官方定价页逐条核对过。

这个赛道的声量已经大到失真。一家成立不到三年的公司，年化收入达到5亿美元规模，估值传闻半年里翻了一倍，连在搜索框里拼错它名字的人都在暴涨。掏钱之前，先弄清楚自己买的是什么。

把这三家的营销页并排看，它们像在卖同一样东西：用自然语言生成一个能跑的应用。把账单摊开看，它们卖的是三样不同的东西，三条成本曲线的形状也完全不同。本文按速查手册的思路写，不做测评：先讲三者的定位差异，再逐个拆计费，最后讲交接和退出。

Lovable、v0、Bolt这三款AI应用生成器是竞品吗？

不是。它们属于三个不同的物种，网上对这三家的差评，追溯下去大多是用户选错了物种，产品本身并不烂。

三家集中在20到30美元的定价，强化了“它们是竞品”的错觉。拆开看，它们回答的是三个不同的问题：

代码质量已经不是三家的比较项。底层都是前沿模型，输出质量在2025年就趋同了。还在分化的只剩两样：包在模型外面的工作流，以及项目变大之后各家怎么收费。本文的重点就放在这两样上。

先用免费档判断各家的限额逻辑

掏钱之前，三家的免费档足够用来判断物种是否合适。把官方给的限额并排放，差异很清楚：

三家限制的对象不同，这一点本身就能说明问题。v0限制对话次数，假设你每次提问都经过思考；Bolt限制词元总量，默认你会频繁迭代；Lovable限制任务份额，把一次完整的产品动作当成计价单元。免费档的限额方式，基本对应付费档的计费逻辑。

用免费档做判断时，别比谁生成得好看，拿同一个具体需求在三家各跑一遍，比如“一个带邮箱订阅的产品预告页”，然后看三件事：它把代码藏起来还是摊开、改一处细节要来回几轮、你能不能看懂它选了哪些第三方服务。后面几个月用得顺不顺，主要由这三件事决定，生成质量的影响反而小。

如果你的问题更靠上游，还没定“到底用什么建站”，那这三个只是众多选项中的一类，之前那篇SaaS托管、自建、AI建站还是纯代码把四条路的取舍拆得更完整，先看那篇再回来选品牌会更省时间。

Lovable为什么适合原型孵化，却不适合长期使用？

Lovable在本文里占的篇幅最大，因为它的营销和实际情况之间落差最大，而且两个方向上都有落差。

先说好的一面。据行业报道，它在2026年中的年化收入约5亿美元，员工只有一百多人。从收入结构能看出：这笔钱来自全球那批有想法但不会执行的人，付费方并不是开发者。按“非技术创始人的孵化器”这个标准评价，它是品类里最好的产品，收入与产品价值相符。

顺带校准一个容易被传错的数字：2025年12月完成的那轮3.3亿美元B轮，对应估值约66亿美元，有官方博客可查。132亿这个数来自2026年7月初的报道，指的是正在谈的一轮，截至本文更新时仍未见官宣关闭。引用时要带上“在谈”两个字。

Lovable的credit按什么扣

官方定价页给出的消耗示例很具体，这几个数比任何评测都有参考价值：

Pro档每月25美元，给100枚credit外加每日赠送；免费档每天5枚、每月上限30枚左右；Business档每月50美元，增加的是团队管控。未用完的月度credit在订阅有效期内可以顺延，每日赠送的部分不顺延，每24小时清零。

很少被提到的计划模式：每条消息固定扣费

官方提供了两种构建模式，流传的介绍里基本只讲了第一种：

• 默认模式：credit消耗随任务复杂度浮动，就是上面那张表。
• 计划模式：每条消息固定1枚credit。

项目变大之后，这个区别很关键。默认模式最受诟病的那条曲线是：应用越复杂，每次修改要带的上下文越多，单次扣得越多。固定档把这条曲线拉平了。项目小的时候用默认模式更省；项目大到单次动辄扣两三枚时，切到固定档更划算。

评估这类工具时有一条通用经验：厂商往往已经提供了缓解手段，只是没放在营销页的第一屏。抱怨账单之前，先把定价页的常见问题逐条读完，比读十篇测评有用。

托管费用构成第二条成本曲线

还有一笔更隐蔽的费用。Pro和Business订阅除了credit，还包含一份用于构建与托管的赠额。官方明确写着：应用的访问量或体积达到一定规模后，会在赠额之外产生费用，这笔费用从你的credit余额里扣。

直白地说：应用越成功，托管消耗的credit越多，而且消耗的正是你原本用来继续开发的那部分。托管确实有成本，这谈不上黑幕，但它决定了该怎么看待这笔钱：它是为短期冲刺付的，不是为长期运行付的。

团队使用时建议先打开一个设置：工作区的所有者和管理员可以设定默认的月度credit上限，还能按成员单独覆盖。不设上限的话，一个人一晚上就可能用光整个团队的额度，这在共享额度的产品里很常见。

国内使用Lovable的三条硬约束

官网可以正常访问，但付费需要国际信用卡；底层后端服务在国内的访问延迟明显，面向国内用户的应用体验会打折；部署产物默认在海外节点，无法备案。

因此它适合做面向海外用户的产品验证或内部演示。要做国内C端产品，要么验证完导出代码部署到国内云，要么直接考虑后文提到的国产替代。最差的做法是用海外工具的默认部署链路服务国内用户，等于把产品体验押在一条完全不可控的网络路径上。

Bolt的词元计费为什么随项目体积上涨？

Bolt有一个整个品类里最少被讲清楚的事实。先说它是什么，再讲这一点。

Bolt如何在浏览器里运行Node.js

从技术上看，Bolt是三者中最有意思的。它背后的容器技术在浏览器里实现了一整套Node.js运行时，相当于在浏览器沙箱里跑一台微型虚拟机，不需要远程服务器，也不用等容器启动。文件树全部可见，任何文件都能手动修改，还有终端。

三个工具里只有它用起来像IDE，另外两个更像聊天产品，这也明确了它的目标用户：想要AI的速度、又不愿放弃代码可见性的开发者。

Bolt的Expo移动端路径止于哪一步？

它还有整个品类最明确的差异化能力：移动端。通过与Expo的官方合作，它能生成带路由和样式方案的React Native项目脚手架，几分钟内扫码就能在真机上运行。另外两家都没有原生移动端路径。

边界要说清楚，营销页不会写：浏览器里的运行时跑不了Xcode、Android Studio和云构建管线。它交付的是React Native代码，不是签名后的安装包。上架应用商店仍然要在自己的机器上配置构建环境。“不写代码从想法到应用商店”这句话只覆盖前八成路程，最后两成没有提。

Bolt的词元消耗取决于项目体积

Bolt的词元消耗跟项目大小挂钩，跟这次要改什么关系不大。大部分开销花在把项目文件同步进模型上下文：同样是改一行字，第六周的花费远高于第一周，原因只是代码库变大了。

官方定价是Pro档每月25美元、起步每月1000万词元，未用完的付费词元顺延一个月；Teams档每人每月30美元；年付最多能省28%。额度听起来很多，但中等规模项目的单条消息就可能消耗六位数词元。Bolt用词元顺延和差异同步来缓解，曲线的走向不变：项目小的时候便宜，项目开始成功时变贵。

Bolt免费档与Pro档的差别主要在词元之外

定价页上还有一组常被跳过的数字，对独立站主更关键：免费档每天30万词元、每月100万词元、单文件上传10MB、托管站点最多约33.3万次网络请求，页面会带品牌标识。Pro档取消每日词元上限，上传放宽到100MB，请求配额提高到100万次，并解锁自定义域名、可选数据库供应商、扩展的数据库容量与AI图片编辑。

请求配额这一条要单独关注：它是第三条“应用成功后才开始收费”的曲线。一个真有流量的落地页，几十万次请求会比预想中更快用完。把Bolt当草稿工具，这个配额完全够；把它当正式托管，迟早要面对这笔费用。

国内访问方面，Bolt的架构反而有优势：计算在本地浏览器里完成，网络依赖比另外两家轻，主要瓶颈在模型请求和包管理源，后者可以换成国内镜像。

Bolt浏览器运行时的能力边界

把Node.js放进浏览器运行，这个架构有几条绕不开的边界，选它之前要想清楚。

能跑的是纯JavaScript和TypeScript生态里的绝大多数东西：常见的前端框架、服务端渲染、接口路由、包管理、开发服务器、热更新。跑不了的是所有依赖原生二进制的东西：需要本机编译的模块、图像处理库的原生绑定，以及非JavaScript的后端语言。想用Python写个数据处理服务，这条路走不通。

这条边界也解释了它的用户画像为什么这么清晰。它服务的是全栈JavaScript这一类开发，而这一类正好覆盖独立站、落地页、轻量后台这些最常见的需求。超出这个范围，它的优势就变成了限制。

Bolt正在转向企业采购渠道

另一个变化会影响这个工具未来的形态：从2026年年中起，Bolt开始把云厂商的应用市场作为采购渠道，并推进与主流办公套件的集成。团队档里几条不太起眼的能力，包括私有包仓库支持、按包注入设计系统知识、集中计费与成员权限管控，都指向同一个方向。

对个人用户影响不大，负责团队采购的人则要留意：一个工具开始认真做企业采购后，定价结构和功能优先级往往会随之上移。现在这个价位能拿到的功能，未必会一直留在这一档。

v0改版后的Git工作流和定价有哪些变化？

v0的篇幅最短，并不是因为它弱（在自己的生态位里，它可能是三者中最专业的），而是选它的决策没有中间地带。团队用Vercel和Next.js，它就是最优解；不用，就不必考虑。

v0的每个会话对应一条Git分支

这个产品在2026年2月有了关键变化。更早的两年里，它一直被看作“React组件生成器”，当时这个定位是准确的。改版之后它成了另一个物种：沙箱运行时与真实部署环境对齐、原生代码托管集成、编辑器风格的界面、数据库连接，以及战略意义最大的一条：可以导入已有代码库，不再只能从零生成。

Git语义是它最硬的差异点。每个会话自动新建一条分支，分支名带哈希后缀，它从不直接写主干，产出始终是一个可以走正常评审流程的合并请求；合并之后由平台自动重建并重新部署。

这一设计解决了AI生成工具最麻烦的问题：产出物锁在一个团队里没人能审查的封闭环境中。一个跑在Vercel上的团队，设计师或产品经理打开v0描述一个新的设置页，工程师收到的是一个正常的合并请求，而不是一句“你去看看这个链接”。

v0现行定价与流传价格不同

这是本文最需要先纠正的一处。网上大量对比文写的还是“每月20美元的Premium档”，而官方定价页现在的档位是：

Premium这个档名已经取消，付费起步价从20美元涨到了30美元。常见问题里还留着一条“Ultra档去哪了”，说明档位结构近期调整过不止一次。按旧价格做预算的团队，签单时会发现对不上。

另一个很少被提到的变化是v0公布了自有模型的分档价目：从轻量档的每百万输入词元1美元、输出5美元，到最高速档的输入10美元、输出50美元，中间还有缓存写入和缓存读取两档单价。有了这张价目表，v0的额度不再是黑箱，你可以自己估算一次生成大概花多少。三家里只有v0公开到这个程度。

v0的两项实际代价

第一是生态绑定。合同上没有锁定，但所有默认假设都是Next.js加Vercel，想用它做部署到国内云或其他云的项目，会处处逆着它的设计。

第二是国内使用的一个致命细节：生成的项目默认部署到平台自有域名，而这个域名在国内长期无法直接访问。不少人快速做了个落地页发到群里，才发现国内同事全都打不开。解决办法是绑定自定义域名并配置解析，但这已经超出非技术用户的能力范围。国内业务可以用它写组件、拿代码，不要依赖它的部署链路。

v0的数据训练条款：企业用户关注的分界

v0的档位表里有一行容易被跳过：付费的较高一档明确写着默认不用于训练，最高档进一步承诺数据永不用于训练。个人用户可能不在意这一条，但对代做客户项目的人，或者手里有商业敏感逻辑的团队，这是能否使用的前提。

三家在这件事上的表述详细程度差别很大，这也反映了它们各自主要服务谁。把这一条写进档位表的产品，面向的是企业采购流程；只在服务条款里含糊带过的，说明它目前还不需要通过这一关。做决策时，可以把它当作产品成熟度的一个指标。

三款AI应用生成器的计费模式分别在哪里让账单失控？

抛开功能清单，计费模式才是三个产品真正分开的地方。下面这张表不比功能，比的是各自在哪里超支：

三家有一个共同规律：入门定价按第一周的用量设计，单位进度成本则随应用成熟而上涨。上下文确实贵，厂商只是把前沿模型的成本转嫁给用户，这算不上黑幕，但它决定了正确的用法：为冲刺付费，不为长期维护付费。

三个工具的最佳使用期都在项目生命周期的前两到四周。开工前就规划好退出点，这个价格很合理；拖到第四个月还在里面维护生产应用，就是用聊天机器人的操作方式，付外包公司的价钱。

把计费表折算成验证预算

只看单价意义不大，折算成一次验证的总成本才有用。按三到四周的验证冲刺算，一个人的开销大致如下：Lovable 25到50美元（Pro档通常够用，复杂一点可能要补买credit）；v0 30到60美元（额度用完按需购买，复杂的多文件生成几个回合就能用掉一大块）；Bolt 25到50美元（前期便宜，后两周明显变贵）。

拿这个数和外包对比，结论很清楚：一个MVP外包出去通常三五万人民币起，交付周期以月计。这类工具的价值主要不在省钱，在于把验证的最小成本从万元级降到百元级，让你敢多试几个想法。从这个角度看，纠结三家谁便宜十美元，是盯错了变量。

同一个算法反过来也成立：项目一旦进入维护期，每月固定的几十美元加上不断上升的单位成本，一年下来就是四位数人民币，换来的还是一套你无法完全掌控的架构。验证期它便宜得出奇，维护期它同样贵得出奇，两者并不矛盾，说的是同一条曲线的两端。

代码可导出，为什么AI应用生成器仍有迁移成本？

三家都支持代码托管同步，营销页都写着“代码归你所有”。这句话技术上没错，实践中却有误导性，是最需要拆开的一个误区。

拿到仓库只占容易的那两成，拿不到的是架构独立性。Lovable生成的应用，登录流程、行级安全策略、存储规则、边缘函数都深度依赖某个后端服务的特定模型，换后端远不止导出几张表，需要重新设计架构。v0的产出默认遵循Next.js约定，最顺的部署去处是它自家平台。Bolt最容易迁移，产出是标准框架的普通代码，这也是开发者偏向它的又一个原因；但即便是Bolt，项目也继承了AI在第一分钟替你选定的那些服务绑定。

一条可以长期使用的原则：评估这类工具，看离开的成本，别看加入的成本。加入只花25美元，带着一个成功的产品离开却要做一次真正的工程改造。这种不对称才是真实价格，公平地说，这也是那个百亿级估值背后完整的商业模式：离开成本就是护城河。

迁移时具体卡在哪几层？

把“迁移很难”说具体一些更有用。按实际难度排，离开时要处理的东西大致分四层。

第一层是代码，最容易。三家都能同步到代码托管平台，克隆下来就是标准项目结构。这一步一两个小时能完成，也是唯一符合“代码归你所有”这句宣传的一层。

第二层是数据，难度中等。导出数据表本身不难，麻烦在于表结构往往是AI在第一分钟替你定的，字段命名、关联关系、索引都未必符合后续需求。迁移时通常要顺带重构一遍数据模型，这才是最花时间的部分。

第三层是鉴权与权限，很难。登录流程、会话管理、行级安全策略属于配置在后端服务里的规则集，不在代码里。换一个后端就得整套重写，而且这部分一旦写错就是安全事故，不能抱着“先跑起来再说”的态度处理。

第四层是那些你根本不知道存在的绑定。文件存储用了哪个服务、邮件从哪里发、支付回调指向哪里、定时任务挂在哪里，这些都是AI在你没参与的情况下选定的。要找齐它们，只能逐个功能走一遍，看哪里报错。

迁移的工作量与你在生成器里停留的时间成正比，与你对它的了解程度成反比。所以最省钱的做法是从第一天就维护一份“它替我选了什么”的清单，边做边记，别等到不得不走时再处理。这份清单十分钟就能开始写，将来能省掉几周。

AI生成代码的安全通过率有多低？

很多对比文会略过这一节，但对要上线收钱的人来说，它比功能差异重要得多。

常被引用的数字是“约45%的AI生成代码存在漏洞”。这个数没错，但出自2025年的报告；2026年3月发布的春季版更新了统计口径，还给出了比单个百分比有用得多的分布。

总体安全通过率两年没有变化

报告累计测试了150多个大模型，整体安全通过率约55%，仍有约45%的样本带有漏洞。同期的语法正确率超过95%。报告里有一句判断说得很重：能跑的代码和能安全运行的代码之间的差距不仅在持续，还在扩大。

按漏洞类别看，模型防住了最知名的那几类

按漏洞类别拆开后的数据最有价值：

这张表比那个45%提供的信息多得多。模型基本能防住SQL注入，对跨站脚本和日志注入却几乎不设防。一个合理的解释是：SQL注入是过去二十年里每本教材、每篇博客都会写的经典问题，训练语料里的正确示范非常多；后两类的知名度低得多，语料里的错误示范反而更多。

这对独立站主为什么格外严重？因为跨站脚本的高发位置正是电商站最离不开的几个模块：用户评论、问答区、商品描述里嵌入的富文本、第三方评价插件回填的内容。这些地方都在把不受控的输入渲染进页面，恰好是模型最不擅长防御的一类。

按语言拆分还有一组数据：Java的通过率只有29%，Python 62%、C# 58%、JavaScript 57%。

生成器产出的JavaScript代码处在中间档，意味着什么？

这三个生成器的产出基本都在JavaScript和TypeScript生态里，对应57%这一档，不算最差，但离免检上线还差得远。四成多的样本带漏洞，换算下来就是每做十个功能，大约有四个里藏着至少一处需要修复的问题。

Java的29%值得多分析一步。原因未必是语言本身更不安全，更可能是Java的典型场景是企业级后端，代码里的鉴权、序列化、模板渲染更密集，出错点本来就多。由此可以推出一条更通用的规律：通过率与让模型写什么强相关，与用哪种语言写的关系是次要的。

落到实际使用上：让它生成展示型页面、静态内容、简单表单，风险相对可控；一旦需求是“加个登录”“接个支付”“做个后台管理”，就进入了通过率最低的区域。需求描述里只要出现权限、支付、上传、用户输入这四个词中的任何一个，都应该触发一次人工复核。

还有一个反直觉的现象：这几年模型的语法正确率升到95%以上，安全通过率两年没有变化。这个剪刀差本身就是风险来源：代码看起来越专业，人越容易跳过审查。过去初级开发者写的代码连缩进都不整齐，审查者自然会警惕；现在生成的代码格式整洁、命名规范、注释齐全，反而更容易被一路点击通过、直接合并。

怎样把安全审查纳入开发流程？

结论是继续用，但要把安全审查作为流程里的固定环节，别等出事之后再补救。有三件成本很低的事：涉及支付、用户数据、文件上传的代码，上线前必须人工审查一遍；把渲染富文本的位置单独列出来，逐个确认转义；把现成的静态扫描工具接入代码托管，让它在合并前运行。

更根本的问题在于：这类工具的目标用户，恰恰是最没有能力发现这些问题的人。能力和风险错配是这个品类的结构性问题，模型再强一点也不会让它自动消失。

独立站上线前的六项安全检查

把上面的漏洞分布表转成检查动作，对做电商和内容站的人大致是这六条：

1. 所有渲染用户输入的位置逐个确认转义，尤其是评论、问答、商品描述里的富文本，这是通过率只有15%的那一类。
2. 日志里不要直接拼接用户输入，这是通过率13%的那一类，而且它的危害不在页面上，而是在事后排查时让你读到被伪造的记录。
3. 文件上传要限制类型、大小和存储路径，生成器默认给的规则通常最宽松。
4. 支付回调必须验签，不要相信任何“回调里带了订单号就当成功”的实现。
5. 把接口密钥、数据库连接串从代码移到环境变量，并检查有没有被顺手提交进仓库。
6. 把静态扫描工具接入代码托管，让它在合并前自动运行，这一步几乎零成本，却能拦下大半问题。

前两条排在最前，是因为它们同时满足两个条件：模型最不擅长防御，电商站又最避不开。其余四条属于通用的工程规范，但生成器的用户恰好最不熟悉这些，所以更需要明确列出来。

什么情况下不该用AI应用生成器？

大多数对比文章不写这一节，因为写了就不方便放返佣链接。但对很大一部分读者来说，正确答案就是“都不用”。

边界可以这样划：应用生成器打包出售三样东西，即AI编码模型、托管环境，以及把代码隐藏起来的聊天抽象层。模型已经不构成差异，你实际付钱买的是环境和抽象层。如果这两样你本来就有，这个打包对你来说纯属额外开销。

具体来说，满足下面任意一条，就可以跳过这三个生成器：

• 你已经每天在用编码智能体。终端原生的智能体配上数据库服务的连接器，能完成Lovable九成的后端接线，而且是在你自己的机器、自己的仓库、自己的评审流程里。
• 项目是存量改造，不是从零开始。三家里只有v0勉强支持导入已有代码库，而智能体本来就是为这类工作设计的。
• 这个应用是你的长期核心产品。架构决策、测试、持续集成、可观测性，聊天抽象层都做不好。
• 有合规、备案或数据本地化要求。托管生成器提供的便利，正是监管要求你必须自己掌握的那部分控制权。

反过来也要承认：如果动手的人是设计师、产品经理，或者永远不会打开终端的创始人，终端智能体再强也用不上。对这些人来说，抽象层就是产品本身，谈不上额外开销。选工具，先判断用户是谁。三种编程范式在架构上的根本差异，终端代理、编辑器内嵌与多代理指挥中心的对比那篇拆得更细，那是这条边界的另一侧。

面向国内用户的国产替代方案

面向国内用户的产品，三个海外工具的短板会叠加放大：付费门槛、访问延迟、默认域名不可达、无法备案。这时国产方案值得认真评估：有的支持用自然语言直接生成小程序，这是国内的高频需求，三个海外工具都覆盖不了；有的对标“从想法到上线”的全链路，依托国内云生态，备案流程顺畅；还有一类严格来说是智能体搭建平台而非应用生成器，但很多“我要个AI应用”的需求实际上是智能体需求，在这类平台上实现成本更低。

判断标准很简单：用户在哪里，工具就选哪里的。海外用户用海外工具加自定义域名；国内用户要么用国产平台，要么把海外工具只当作代码草稿工具，生成后导出，自己部署。

挑选国产方案时，建议多问四个问题，它们比生成质量更能决定产品能否真正上线：备案流程顺不顺（能否在同一家云上一站办完）、支付能否接入（主流支付渠道的商户资质与回调）、是否支持小程序（很多国内需求的入口根本不是网页）、数据存放在哪里（涉及个人信息就要满足本地化存储的合规要求）。这四条里任何一条卡住，生成得再漂亮也上不了线。

中间路线：生成器做原型，终端智能体负责落地

二选一之外还有第三条路，而且成本很低：把生成器当设计稿工具，把实现交给终端智能体。

具体做法是用免费档或最低档快速生成几版界面和交互，作为可交互的原型给团队和客户看，收集反馈、确定方案；真正要写进自己代码库时，把界面截图和生成的组件代码作为参考素材，让终端智能体在你自己的技术栈里重新实现一遍。

这条路能同时利用两边的长处：生成器最擅长把模糊想法变成可视化的东西，而这恰好是终端智能体最弱的环节，它能写对代码，却很难在你说不清需求时替你做决定。反过来，工程规范、测试、部署是智能体的强项。

代价是多了一道转换工序，所以只在两种情况下划算：你的技术栈本来就不是生成器默认的那套，或者项目从一开始就确定要长期维护。两条都不满足时，直接用生成器做到验证结束更省事。

从原型到生产，交接管线为什么要提前排期？

所以真正要推荐的是“设计一条带交接点的管线”，而不只是“选一个工具”：

1. 验证阶段（第1到3周）。用生成器把想法变成真实用户能点击使用的东西，收集真实反馈。这一段要快，不必纠结代码好坏。
2. 交接阶段（第3到4周）。导出或同步到代码托管，做一次安全与架构评审，人工或用智能体都可以。上一节的漏洞分布表就是这一步的检查清单。
3. 建设阶段（第2个月起）。换用终端智能体补测试、接入持续集成、做重构，把基础设施迁到自己可控的环境。

整条管线里影响最大的一步，是按时执行第二阶段的交接：要赶在成本曲线上升之前，也要赶在没人记录的架构决策固化之前。长期看，把生成器当一次性草稿用的团队，总是比想把它当永久平台的团队做得好。

另外，如果你的目标是内容站或独立站而不是应用，这条管线的第一阶段有更省事的替代路线，用AI终端一句话生成完整站点那篇讲的就是成熟建站生态里的同类做法，底层用的是同一批模型，但产出物直接就在你自己的技术栈里。

AI应用生成器在扩大软件工程的入口

持续观察这个赛道十八个月，最反直觉的结论是：它们没有在取代开发者，反而在打开一个有史以来最宽的软件工程入口。数以百万计经过验证的原型，最终都需要工程师补上聊天抽象层给不了的东西：测试、架构、可观测性、合规。

保哥给客户的建议一直是同一句：按物种选工具，按用户选物种。别急着问哪个最好，先问你是谁、你的用户在哪、这个东西你打算维护多久。想先动手做个小工具再决定，用对话式编程做一个SEO小工具那篇的八步流程可以作为一次低成本的实际体验。

常见问题解答

问：完全不会写代码，三个里该选哪个？

选Lovable。只有它把数据库、登录鉴权、文件存储和一键部署打包成一整套，工作单位是产品决策，不是代码。前提是接受一个结果：验证成功之后，要把仓库交接给工程师，不能一直留在Lovable里。

问：v0现在到底多少钱？

付费起步档是每用户每月30美元，含同等金额的月度用量，另有每天登录赠送的部分；再往上一档是每用户每月100美元。流传很广的每月20美元Premium档已经取消，按旧数字做预算会对不上。

问：Bolt的账单为什么越到后期越贵？

因为它的词元消耗与项目体积挂钩，与这次要改什么关系不大。大部分开销花在把项目文件同步进模型上下文，所以同样一处小改动，第六周比第一周贵得多。项目超出原型规模后，就该导出代码迁走。

问：代码能导出，是不是就没有锁定风险？

不是。导出的只是文件，拿不到的是架构独立性：鉴权流程、行级安全策略、存储规则、边缘函数往往深度依赖特定后端服务的模型，换后端等于重新设计架构。评估这类工具要看离开的成本，别看加入的成本。

问：AI生成的代码能直接上线收钱吗？

不能免检上线。最新一版行业报告显示，整体安全通过率约55%，而且分布很不均匀：SQL注入的通过率有82%，跨站脚本只有15%、日志注入只有13%。电商站的评论、问答、富文本描述正是跨站脚本的高发区，上线前必须人工审查一遍。

问：做面向国内用户的产品，这三个能用吗？

能用，但别用它们的默认部署链路。付费需要国际信用卡，托管节点在海外，无法备案，其中一家的默认部署域名在国内还长期无法访问。可行的做法是只把它们当代码草稿工具，生成后导出到国内云自己部署，或者直接选国产平台。

问：什么时候该跳过生成器，直接用编码智能体？

满足以下四条中任意一条就该跳过：你已经每天在用编码智能体、项目是存量改造、这个应用是长期核心产品、有合规或数据本地化要求。生成器卖的是环境和抽象层，如果这两样你本来就有，它对你来说纯属额外开销。

问：这三个工具的最佳使用周期是多久？

项目生命周期的前两到四周。三家的入门定价都按第一周的用量设计，单位进度成本随应用成熟而上涨。开工前就定好交接点，比事后被账单逼着迁移要便宜得多。

权威参考资料