做一个 AI 产品，别只计算模型调用费

当一个产品通过模型 API 提供能力时，调用费通常是最容易看到的一项支出，但它未必足以描述完整的交付成本。

本文不提供任何供应商的实时价格，也不假设一个固定的利润率。我们只讨论怎样建立一套可替换假设、可对照真实账单的计算口径。

先定义一笔交付是什么

对于文档处理产品，一笔交付可能是一份文件、一批材料，也可能是一个通过人工确认的结果。选择哪个单位，会影响你怎样统计重试、失败与审核时间。

尽量使用与客户价值相对应的单位，并同时保留内部使用量。客户购买一份整理好的报告，并不需要理解底层发生了多少次调用，但你需要知道。

列出随交付量变化的成本

• 输入获取与预处理，例如转写、识别和格式整理。
• 模型使用，包括多个步骤、长输入以及失败重试。
• 存储、传输与结果导出。
• 人工检查、修订与异常支持。
• 为完成这一笔交付而发生的外部服务费用。

把人工时间写进模型很重要。一个需要反复修订的输出，可能在调用账单上很便宜，却无法按预期交付。

再看持续经营的投入

开发、监控、备份、文档更新、客户沟通和获客，都需要有人承担。它们不一定随着每一笔任务同比例增长，但不能因为暂时由创始人完成，就被当作不存在。

可以把成本表分成「已经支付」「由自己承担的时间」与「尚不确定的投入」，避免把估计值混同为实际支出。

用情景替代一个乐观数字

建立三组可解释的假设：正常使用、较长输入，以及需要较多人工修订的情况。将相同计价单位代入，观察哪一种变化最容易影响交付。

单位交付的贡献
  = 对应收入
  - 该笔交付的可变支出
  - 相关人工时间 × 选定的时间成本口径

这个计算还不是净利润。你仍需要处理固定投入、获客与税费等真实经营项目，并使用适合自己业务的专业口径。

用真实记录更新模型

为每笔任务记录处理步骤、重试原因和人工修订时间。积累实际使用之后，再判断收费方式是否覆盖了你承诺的服务。

不要用一次顺利的演示推算全年成本。一张能够被事实修正的成本表，比一个看起来精确的预测更有帮助。