很多人第一次接触 Zion 时，都会问同一个问题：

“我这个项目做出来到底要花多少钱？”

这个问题看似简单，却是我们最难回答的问题之一。

因为 Zion 的计费方式和绝大多数 SaaS 都不一样。

它不是按席位收费，不是按员工数量收费，也不是简单的套餐价格。

一个项目最终花多少钱，取决于：

• 你要做什么产品
• 有多少用户使用
• 用户怎么使用
• 后端工作流如何设计
• AI 调用频率有多高

同样是一个商城：

• 100 个用户和 10 万个用户成本不同
• 图文商城和短视频商城成本不同
• 普通搜索和 AI 推荐成本也不同

所以每当用户问：

“多少钱？”

我们不得不反问：

“你的业务场景是什么？”

而当一个用户问价格，你却回答另一个问题时，信任感往往就开始下降了。

于是我们决定做一件事：

让 AI 帮用户算价格。

问题来了：AI 其实不擅长算价格

很多人以为价格计算器就是：

用户输入需求 → AI 输出报价

实际上这恰恰是最容易翻车的方案。

因为 AI 擅长的是：

• 理解语义
• 推断场景
• 补全上下文

但不擅长：

• 多步骤计算
• 复杂规则运算
• 精确数学推导

举个简单例子。

让 AI 算：

3+5

基本不会错。

但让 AI 同时处理：

• 套餐规则
• 数据库存储
• 带宽流量
• RPS 峰值
• AI Token 消耗

再经过十几个步骤计算。

它迟早会开始“拍脑袋”。

而价格这种东西最怕拍脑袋。

所以我们最终采用了：

AI 负责理解业务场景

代码负责精确计算

的混合方案。

一个卖鞋商城，AI 是怎么推算成本的？

假设用户输入：

我想做一个卖鞋的商城

5 万注册用户

每天 100 个订单

用户点击「开始计算」后。

系统并不会直接算价格。

而是先进入第一阶段：

Step 1：让 AI 设计这个项目

AI 会把一句自然语言描述，转换成结构化数据。

例如：

用户故事

• 浏览商品
• 查看详情
• 加入购物车
• 下单购买

数据模型

• 用户表
• 商品表
• 订单表

API

• 商品查询
• 订单创建
• 短信通知

ActionFlow

• 下单流程
• 支付流程
• 发货流程

用户角色

• 游客
• 注册用户
• 商家后台

这一步的目的只有一个：

把模糊需求翻译成程序能理解的数据。

Step 2：推断真实资源消耗

接下来 AI 开始模拟用户行为。

例如：

一个用户打开商城时：

• 加载商品列表
• 请求商品图片
• 查看详情页

加入购物车时：

• 写数据库
• 调用后端 ActionFlow

支付时：

• 创建订单
• 更新库存
• 发送通知

这些动作看起来只是点击按钮。

但背后对应的是：

• 数据库读写
• API 请求
• 带宽消耗
• 对象存储访问

最终 AI 会推导出：

• 每月数据库增长量
• 图片流量消耗
• API 请求量
• ActionFlow 执行次数
• AI 调用次数

这时候才进入真正的价格计算。

为什么我们把 AI 任务拆成了两步？

这是整个项目里最大的坑之一。

最初版本只有一个 Prompt。

AI 同时负责：

• 理解业务
• 推断用户行为
• 计算资源消耗

结果经常出现：

前面说需要某个 ActionFlow。

后面计算时又忘了这个 ActionFlow。

输出前后矛盾。

后来我们把流程拆成：

Step 1：理解项目

Step 2：推断资源

准确率明显提升。

这其实也是我们做 AI Agent 的一个经验：

不要让 AI 一次完成太复杂的任务。

把一个大问题拆成多个小问题。

往往比不断优化 Prompt 更有效。

最难算的，其实是数据库

很多人以为数据库大小很好估算。

实际上并不是。

以订单表为例。

计算时不仅要考虑：

• 每条订单占多少字节
• 一年产生多少订单

还要考虑 PostgreSQL 的一个特性：

Database Bloat（数据库膨胀）

很多开发者第一次接触 PostgreSQL 都会踩这个坑。

删除数据后：

磁盘空间不会立刻减少。

数据库会保留原来的空间。

未来有新数据时再尝试复用。

如果复用不了。

就会继续扩容。

于是：

业务数据 100MB

最终磁盘占用可能是：

120MB

150MB

甚至更多。

因此我们的计算逻辑里会加入膨胀系数。

让最终结果更接近真实线上环境。

我们甚至允许用户“反驳”计算结果

这是我最喜欢的设计。

大部分价格计算器的逻辑都是：

算完了，你信就信。

但我们希望做到另一种状态：

算完了，你可以质疑我。

未来版本里会加入一个功能：

「我要反驳」

用户可以直接指出：

• DAU 不对
• 流量预估不合理
• 数据库太小了

然后让 AI 解释：

为什么这么算。

哪些假设导致了这个结果。

因为我们认为：

一个能够被证伪的结论，往往比一个绝对正确的结论更值得信任。

这个价格计算器真正解决的是什么问题？

表面上看。

它是在算价格。

实际上它解决的是：

信任成本

以前用户问价格。

需要人工介入。

一个销售花 20 分钟了解业务。

再给出预估。

成本非常高。

而且无法规模化。

现在：

AI 可以完成绝大部分场景分析。

虽然准确率可能不如最资深的解决方案顾问。

但成本下降了几个数量级。

原来：

一次咨询可能成本 20 元。

现在：

可能只需要几毛钱的 Token。

对于企业来说。

很多过去：

做一次亏一次

的流程。

在 AI 出现之后。

第一次变成了：

做一次还能赚钱

的流程。

这或许才是 AI 最大的商业价值

很多人讨论 AI 时。

都在讨论：

• 替代程序员
• 替代设计师
• 替代运营

但在我们看来。

更现实的问题其实是：

哪些原本边际成本过高的流程，能够因为 AI 而变得值得做？

价格计算器就是一个典型案例。

过去需要人工完成。

现在 AI 能承担大部分工作。

于是：

• 用户获得更透明的信息
• 企业降低服务成本
• 产品获得更高转化率

这才是 AI 真正改变商业的地方。

不是创造全新的需求。

而是让原本不划算的事情变得划算。

Zion 为什么坚持 No-Code，而不是纯 AI 生成？

最后聊聊很多人问的问题：

Zion 是 AI 产品，还是 No-Code 产品？

我们的答案其实很简单：

Zion 首先是 No-Code，其次才是 AI。

AI 是一种新的交互方式。

但真正重要的是：

精准、可控、可重复。

因为我们服务的不是一次性生成内容的人。

而是要长期运营产品的人。

当你的产品每天都在运行。

每天都有用户访问。

每天都在处理订单。

任何一个小错误都会被无限放大。

所以最终决定产品价值的。

不是 AI 能生成多少东西。

而是：

你能否在 AI 带来效率的同时，依然保持对系统的控制力。

而这，也是我们做这个价格计算器时最深的感受。

它看起来只是一个报价工具。

但背后其实是：

AI 推理能力、结构化输出、代码计算、数据库设计、产品信任机制，以及商业效率的一次完整实践。