Base44 的案例，最值得独立开发者复盘的，不是“一个人用了 AI 就能卖出高价”，而是它把收费讨论从“调用了多少次模型”拉回到一个更实际的问题：用户究竟在为什么付费。公开页面能够确认的是，Base44 目前把套餐与消息积分、集成积分、应用数量和支持服务组合在一起；但“按可用应用收费”并不是现有公开定价页上唯一、或可以直接概括全部机制的表述。因此，复盘时需要把已披露的事实、合理的分析和没有公开的数据分开。

从一个人的内部工具开始：先验证应用价值

公开采访摘录称，Base44 创始人 Maor Shlomo 最初是为了给妻子构建一个 CRM，后来逐步发展为应用生成平台。采访还提到，Base44 强调从前端到后端的整合，并通过公开构建和社区传播获得增长。

这条时间线的重要之处在于：最初的产品并不是“提供模型调用”，而是帮助一个具体的人完成一项具体工作。用户想要的不是生成若干段代码，而是一个能够承载工作流程的应用。

从独立开发者的角度看，这种起点至少包含三个可验证的问题：

1. 用户是否有明确的业务流程，而不是只有一个模糊想法；
2. 应用是否减少了搭建、配置和维护的工作；
3. 用户是否愿意持续使用，而不仅仅是第一次尝试时觉得新鲜。

这也解释了为什么应用构建平台很难只用模型调用量来讲价值。调用量是平台的成本和使用信号，却不一定是客户感知到的结果。

事实边界：上述创始人经历来自一篇标注为 AI 自动翻译的采访整理稿，原文页面也提示译文可能无法完整保留语气和细节。关于“从为妻子构建 CRM 开始”等信息，应视为该采访中的公开说法，而不是经过独立审计的公司经营数据。

三种计费单位：结果、应用和调用量

设计 AI 产品定价时，可以先把价值单位拆成三类。

按结果收费

按结果收费，关注的是客户最终完成了什么。例如：

• 完成一份合规报告；
• 处理一批发票；
• 交付一个可上线的内部工具；
• 让某个业务流程从人工处理变成自动运行。

这种方式最接近价值定价，但也最难执行。结果通常受到客户自身流程、数据质量和人工配合程度影响。独立开发者如果无法控制交付边界，就容易承担超出产品能力范围的责任。

按应用收费

按应用收费，关注的是客户获得了几个可运行的工作载体。对应用构建平台而言，一个应用可能包含页面、数据模型、权限、集成和部署能力。客户购买的不是一次生成动作，而是一个可以继续使用和修改的产品空间。

这种单位比调用量更接近用户的认知。客户通常会问：

• 我能不能做出一个完整应用；
• 应用能不能持续运行；
• 能不能接入自己的域名或外部服务；
• 后续修改是否还需要重新付费；
• 一个套餐可以承载多少个项目。

Base44 官方定价页的公开摘录显示，其套餐强调“无限数量的应用”，同时按照月度消息积分和集成积分分层，并提供代码编辑、域名、GitHub 集成及支持服务等功能。由此可以看出，应用数量并非当前页面展示的唯一收费依据，平台实际上在组合“应用承载能力”和“使用资源额度”。

按调用量收费

按调用量收费，通常以模型消息、积分、接口请求或计算资源作为单位。它的优点是容易与平台成本对应，也方便限制滥用；缺点是用户很难提前判断自己要花多少钱。

对普通用户来说，一次复杂修改可能需要多轮对话，也可能触发不同的后台操作。即使两名用户都“构建一个应用”，消耗的消息积分和集成积分也可能不同。于是，调用量更像是平台的计量单位，而不一定是用户的价值单位。

Base44 的公开定价更像“价值入口加资源边界”

截至公开定价页摘录，Base44 提供免费起步，并设置按月或按年计费的套餐。摘录中，Pro 套餐标示为按年付费每月 80 美元，包含每月 500 条消息积分和 20,000 条集成积分；Elite 套餐标示为按年付费每月 160 美元，包含每月 1,200 条消息积分和 50,000 条集成积分。Elite 还包括无限数量应用、应用内代码编辑、模型选择、域名、GitHub 集成和高级支持等权益。

这些信息可以支持几个有限判断：

• 平台没有把价格简单写成“每次模型调用多少钱”；
• 消息积分和集成积分仍然是重要的资源约束；
• 应用数量、部署能力、集成能力和支持服务构成了套餐价值的一部分；
• 更高档套餐不只是增加调用额度，也增加了面向持续构建的功能。

但这并不能证明 Base44 采用了纯粹的“按可用应用收费”。更准确的说法是：它把应用构建能力作为产品价值入口，再用消息积分、集成积分、功能和支持服务划定套餐边界。

对一人公司而言，这种组合有一个现实好处：用户可以先以一个相对容易理解的目标开始——“我要做一个应用”，平台则在后台通过积分管理高成本操作。用户不必在第一次购买时精确预测每一次推理成本，平台也不必承诺所有使用行为都拥有相同成本。

“采用替代模型”不等于可以直接降低价格

AI 产品经常会讨论模型替代：简单任务使用成本更低的模型，复杂任务再调用能力更强的模型。这个方向可能降低平均推理成本，但它不能自动推出更低售价，也不能自动推出更高利润。

原因至少有四个。

第一，模型成本只是单位经济的一部分

推理成本之外，平台还要承担：

• 应用运行和数据库成本；
• 文件存储、带宽和日志成本；
• 第三方集成费用；
• 安全、风控和滥用检测；
• 客服与技术支持；
• 失败重试、人工介入和退款成本；
• 产品研发与获客成本。

如果一个用户的模型调用成本下降了，但他使用了更多集成、部署和支持服务，单个客户的总服务成本仍然可能上升。

第二，成本下降可能被更多使用抵消

当用户感觉产品更便宜、更快或更稳定时，往往会增加使用频率。一个应用从“偶尔试用”变成“每天运行”，可能带来更多数据库、集成和支持消耗。

因此，不能仅凭“单次推理成本下降”推断毛利率必然上升。需要观察的是每个付费客户的收入、总服务成本、留存周期和支持负担。

第三，模型替代可能影响结果质量

如果低成本模型无法稳定完成代码修改、数据建模或错误修复，平台可能需要追加多轮调用，甚至由人工处理。表面上每次调用更便宜，完成一个有效任务的总成本却未必更低。

更合理的核算单位不是“每次调用”，而是：

完成一个可接受结果所需的总成本。

第四，公开资料没有披露足够的成本数据

现有资料摘录提到模型选择、积分和成本讨论，但没有披露 Base44 的具体模型组合、各任务路由规则、平均推理成本、客户结构或利润率。外部文章中关于估值、收入、增长速度和获客成本的说法，也不能替代公司的财务披露。

所以，独立开发者可以把“模型替代”当作成本优化方向，却不应把它包装成已经被 Base44 公开验证的利润公式。

成本下降与收入增长，为什么不能画等号

可以用一个简化公式检查 AI 产品的经营变化：

单客户贡献 = 客户收入 − 模型与基础设施成本 − 支持成本 − 获客及支付成本

模型成本下降，只影响公式中的一项。收入是否增长，还取决于三个问题：

1. 客户是否因为产品更好而愿意付费；
2. 客户是否愿意持续使用；
3. 平台是否能够以可控成本获得和服务这些客户。

以应用构建平台为例，降本可能带来三种不同结果：

因此，独立创业者在做 AI 产品定价时，不能只问“模型调用一次多少钱”，还要问“客户完成一次有价值任务需要多少钱”。

公开案例中，哪些可以借鉴，哪些不能照搬

Base44 的公开故事确实能提供一些启发。采访摘录提到，创始人在 AI 能够生成大量代码的环境下，把瓶颈转向验证、设计和决定做什么；平台也通过公开构建和社区传播积累关注。这说明一人创业的关键约束，可能从写代码转向产品判断、质量控制和分发。

但以下结论目前不能从公开摘录直接推出：

• Base44 的典型客户究竟是个人、团队还是企业；
• 付费客户主要购买应用数量、积分还是支持服务；
• 各套餐的转化率和续费率；
• 平均每位客户的推理成本；
• 公司的毛利率和净利润；
• 早期增长中社区、产品传播和付费投放各自贡献多少。

有些二级文章把 Base44 描述为“一个人、几个月、获得高额收购”，不同来源对金额和时间的表述并不一致。与其复述一个看似完整的成功数字，不如只保留可以相互对应的过程线索：个人项目、应用构建平台、公开传播、快速迭代，以及后来出现的收购相关报道。

这对独立创业者尤其重要。单个案例的结果通常由产品时点、创始人能力、分发渠道、市场热度和交易条件共同造成，不能直接变成“只要采用同样定价就能复制”的方法。

给独立开发者的定价复盘框架

如果你正在设计一个 AI 产品，可以按照下面的顺序测试，而不是先决定“每次调用收多少钱”。

先写出客户购买的结果

用一句话描述客户购买后的变化，例如：

• 把一套重复流程变成可运行的内部应用；
• 在一天内完成原本需要数周的原型搭建；
• 让自由职业者能够独立交付某类定制工具；
• 将分散在表格和邮件中的信息集中到一个工作流中。

如果只能写出“让用户调用更强的模型”，说明价值单位还停留在技术层。

再确定用户能理解的收费单位

可以同时保留两层计量：

• 对外：按应用、工作区、项目、席位或完成的业务结果收费；
• 对内：按消息、集成、计算时间和存储量核算成本。

对外单位负责让客户理解价格，对内单位负责保护经营边界。两者不必完全相同，但必须能够相互校准。

最后设置使用上限和升级条件

一个可执行的套餐需要回答：

• 包含多少应用或项目；
• 包含多少消息与集成额度；
• 超额后是暂停、加购还是自动升级；
• 哪些功能需要更高套餐；
• 人工支持的边界是什么；
• 客户能否导出数据和迁移。

这套框架并不适用于所有 AI 产品。高频 API、内容生成工具、企业自动化服务和定制交付项目的成本结构不同，可能需要按调用、按任务或按结果组合收费。

最后：把“可用”定义清楚，再谈怎么收费

Base44 案例真正值得一人公司借鉴的，不是某个具体价格，也不是“用更便宜的模型就能提高利润”的简单叙事，而是把产品从模型能力转向可使用的应用能力。

对客户来说，“可用”至少意味着应用能运行、能接入真实流程、能继续修改，并且出现问题时有人或系统负责处理。对开发者来说，“可用”则必须同时满足成本可控、质量可控和支持边界可控。

公开页面能够说明 Base44 正在把应用能力、积分额度、集成资源和支持服务组合进套餐；至于客户结构、真实利润率以及模型替代带来的具体收益，资料并未充分披露。独立开发者在复盘时，最稳妥的做法是把这些未知项保留下来，再用自己的用户访谈、使用日志和单位经济数据验证。

这比单纯追逐“按调用量收费”或“按应用收费”更重要：先找到客户愿意持续购买的价值单位，再用推理成本和资源额度把它经营起来。

参考： Base44 官方定价页；公开采访整理页。