AI功能成本结构：为何按量计费会颠覆你的架构决策

当一个 AI 功能在立项时写下的估算，通常都是工程估算：模型调用需要多长时间，围绕它构建 UI 需要多长时间，到达可演示状态需要多长时间。这个估算在构建阶段几乎从不会出错。但在构建之后的一切方面，它几乎总是不完整的。

为什么会遗漏这么多？

传统软件的成本曲线是工程师熟悉的：构建它，部署它，新增一个用户的边际成本趋近于零。AI 功能打破了这一假设，而且这种方式在立项时并不总是显而易见的。模型调用不是固定成本的函数，而是按量计费的。每多一个用户、多一个会话、多一次重试，都会产生真实的、可变的成本——这些成本随使用量增长，而非保持平稳。

正是这一个差异，使得 AI 功能的成本值得拥有自己独立的科目，而不是被归入一般基础设施开支。

实际成本包含哪些类别？

模型成本是最直观的部分：输入和输出 token、在廉价快速模型和昂贵强大模型之间的选择、当主模型失败或超时时的降级调用，以及每次请求附带的大 prompt 或检索上下文的 token 开销。一个工作流为了完成一次用户操作而调用模型三四次，会悄无声息地倍增这一成本。

数据和检索成本潜藏在大多数超越 prompt 本身的 AI 功能之下：Embedding 生成、向量存储、用于排名和返回相关片段的搜索基础设施，以及为保持检索数据与其来源真相同步而进行的持续工程工作。检索质量不会自行保持良好；它会随着源数据变化而退化，必须主动维护。

产品成本是模型调用本身之外的那些 UI 和 UX 工作：输出所在的页面、教用户了解功能能做到什么和不能做到什么的上手引导、当输出错误时的纠错流程，以及必须向习惯了确定性 Bug 的支持团队解释概率性行为的支持文档。

运营成本涵盖上线后发生的事情：监控静默故障、在新边缘案例出现时运行评估、当模型行为异常时处理事故，以及随着行为随时间漂移而更新 prompt 或切换模型。这是大多数排期最低估的类别，因为它不像构建阶段那样有明确的结束日期。

风险成本是最难量化、也是一旦发生时后果最严重的部分：发送到模型的数据带来的隐私泄露、错误推荐对业务的影响，以及当这些问题大规模发生时随之而来的合规和声誉风险。

这如何改变了 AI 产品的利润计算？

传统 SaaS 的毛利率多年来稳定在 70–80% 左右，因为托管成本随客户规模扩大基本保持平稳。AI 打破了这个模式，因为推理成本与使用量挂钩，而非与客户数量挂钩。ICONIQ 的《2026 AI 现状报告》发现，AI 产品构建者现在预期的平均毛利率接近 52%，这一显著压缩反映了模型和检索成本随每次请求变动而非保持固定。

这种压缩也并非在客户间均匀分布。一个重度使用 AI 功能的用户产生的推理成本可能显著高于同一计划下的轻度用户，这是传统按月收费的 SaaS 定价模式从未设计用来吸收的问题。某家公司在一项 AI 功能的使用量超过其定价模型后，毛利率从 36% 骤降至 -14%，这提醒我们："无限"AI 访问和不可预测的成本暴露几乎是同一回事。

大多数团队最终采用的实用做法是追踪每次请求成本、每个会话成本和每次成功结果成本，而不是孤立地审视 AI 账单总额——后者掩盖了哪些具体功能和哪些具体用户在驱动支出。

从技术角度看，维护负担是什么样的？

AI 功能维护与传统维护在结构上有一个关键区别：模型行为是概率性的，因此回归测试必须评估输出质量和行为漂移，而不仅仅是代码是否仍然正确执行。一个在上个季度边缘案例上表现良好的 prompt，可能随着使用模式变化或底层模型被提供商更新而悄无声息地退化。

这意味着评估集需要不断扩充，集成和数据源需要对模式或格式变化进行主动监控，而且团队中需要有人明确对质量负责——而非仅仅对正常运行时间负责——只要功能还在上线运行。传统功能的所有权在上线稳定后往往会淡化。AI 功能的所有权不能，因为被拥有的东西本身在持续变化。

团队如何在构建前判断一个功能是否值得这些开销？

跨工程团队出现的一种模式是：在生成任何代码之前先对成本面进行评估，而非在上线后才发现问题。这也是为什么架构优先规划在 AI 辅助开发中变得越来越常见的原因——在写下一行代码之前，先产出需求文档、数据流图以及功能将触及的所有内容的明确列表。LangGraph 和 CrewAI 这类工具在 Agent 编排层面推动这一做法，强制要求明确界定 Agent 可以调用什么以及何时调用。8080.ai 等平台在应用层面应用了类似的原则，将系统需求文档和架构图作为团队在构建继续之前审阅的批准步骤——在还便宜变更范围的时候就暴露出功能的检索和数据依赖，而非等到上线并承载真实使用成本之后。

在投入工程时间之前值得提出的根本问题是一个窄化的问题：这个功能解决的问题是否足够频繁、足够有价值，值得用一种随使用量而非保持固定成本的成本结构来支撑？如果一个更简单的确定性规则能解决同样的问题，它通常是更好的选择——规则不需要评估管道，不会漂移，且每次调用不携带推理成本。

那些通过初始门槛但停止产出价值的功能会怎样？

这是大多数路线图跳过的部分：当一个功能的使用量或信任度随时间侵蚀时的应对计划。弱信号——已上线的 AI 功能数量、模型调用次数、处理的总 token 数——衡量的是活动，而非价值。强信号——任务完成率、接受输出与编辑输出的比率、每次成功结果的成本，以及该功能是否真正减少了支持工单而非产生新的工单——衡量的是该功能是否仍然值得其成本。

一个成熟的 AI 功能生命周期包含一条与上线计划同样刻意规划的退役路径：最低采用阈值、每次成功结果的最大可接受成本，以及一个明确的所有者，负责对用户已悄然停止信任的功能做出整合或下线的决定。

工程视角的要点

AI 没有让功能的运行成本更低，而是让功能的启动成本更低。这个区别比听起来更重要，因为上述整个成本结构只有在功能上线之后才变得可见——到那时，构建的沉没成本已经支出了。在投入工程时间之前评估持续成本——模型、检索、产品、运营和风险——正在迅速成为区分路线图上有立足之地的 AI 功能与默默侵蚀一年利润、直到有人注意到之前无人察觉的功能的关键。