AI公司应自建计量系统而非外包计费链路

Andrew Bihl 2026年11月4日 5 分享 我曾与多家科技公司的计费工程师交流，听到的故事往往是这样的： 我在平台团队，负责身份认证和功能开关之类的事情，不久前计费也交到了我们手上。我们接手的是一个多年前由产品团队匆忙拼凑起来的系统，当时他们第一次想尝试按用量计费。之后它就一路膨胀。计费里不断冒出错误，当企业客户要求我们证明某张发票正确时，可能要花好几天。我听说 GTM 还想往上面加更多定价杠杆，而我们光是维持现状就已经疲于奔命。我甚至不太清楚会计那边是怎么运作的——我们只是每月把数据导出给他们。 计费这件事出了名地比看上去更大、更难，而且代价高昂：计费错误、收入漏损、审计失败，甚至错过 IPO 窗口。 问题在于，“计费”其实揉合了好几项不同的工作。采集用量事件、套用价格、开具发票、处理抵扣、确认收入，这些都是不同的工作，有着不同的要求、约束和挑战。 AI 正在把这些难题提前。按 token 和计算时长收费的公司需要计量用量、更新余额、执行消费限额。企业客户带来的是议定费率、承诺抵扣和合同变更。团队在还没有专职计费专业知识的时候就遇到了这种复杂性，这使得“自建还是采购”的决策成为一个早期架构选择，影响深远。 对 AI 公司，我的建议是拆分：自己掌握用量计量、定价逻辑和客户余额；发票开具和收入确认使用专业软件；再通过协调商业协议的统一表示把两者连接起来。 上面的简化图展示了如何把问题空间拆成若干区域。下面我逐一说明。 计量，即上图中的红框，聚焦于基础设施和计算。你采集产品如何被使用的数据，对这些信息进行转换（通常还有聚合），并为事件确定适用的价格。 漏掉事件会导致少计费。重复处理会导致多计费。这一层必须同时应对你的事件量和定价模型的逻辑。 客户余额严格来说不属于计量。但如果你的产品需要展示实时余额或执行消费限额，两者就会紧密耦合。每个用量事件都必须足够快地完成采集、定价并反映到余额中，产品才能据此行动。这条路径上任何环节的延迟，都会让产品基于过时的信息运作。 这种共享的延迟要求，使实时余额管理与计量归到了一起。 发票开具（蓝框）是发送发票、扣款和办理退款的层级。这是一个极其敏感的层级，往往涉及多个部门的利益相关方。财务和会计负责确保向客户开出的账单正确、准确，而客户经理、销售人员或支持代表则拥有向客户发放抵扣和退款的工具权限。 会计（绿框）涉及看似晦涩的要求：持续捕获、解释、计算并记录你各项协议的财务故事。在许多公司，收入会计既是会计部门最专业的工作，也是最敏感的审计领域。 依据 ASC 606 正确确认收入，依赖大量数据和上下文。合同（无论是隐性还是显性）、合同的所有变更、后续事件、用量数据和账单，都是产出收入故事的必要输入，这使得它成为技术栈中很难做对的一层。许多团队采用的是一种混合做法：由计费供应商给出会计分录取证的粗糙初稿，再用一套单独的电子表格调整来重新解读和重新分摊这份初稿，使其成为合规的会计处理。 合同是业务及其协议的模型，包含法律条款和费率卡配置。计费的每一层都依赖合同的部分或全部内容，因此要看清如何以及在哪里拆分问题空间并不容易。 传统计费厂商声称覆盖上图的所有部分。把事件发给我们，在我们的应用里建模你的定价，剩下的我们全包。 但对于中端市场和企业级业务，他们通常很快就会发现： 他们必须在前端运行自己的采集和聚合基础设施，把事件压缩到厂商能够处理的更小体量。 他们必须在并行系统中管理企业协议或订阅计费。 合同层难以应对逐合同的差异性和合同变更。 会计是事后才想到的。你的会计部门仍然依赖电子表格（或又一个软件工具）来做收入确认，因为系统导出的基础会计分录满足不了会计要求。 理论上，他们为你做了一切。但他们并不是样样都精通。 端到端系统的不同部分，可能会在不同的时间点被你“用超”。事件量可能迫使你自建聚合基础设施，而厂商的定价工具对你仍然可用。合同的差异性可能超出其协议模型的设计能力，或者会计要求可能变得比其会计分录导出所能支持的更严格。 困难在于替换掉你已经用超的那部分。你的定价规则、用量数据和发票开具流程都依赖一个单体系统，所以替换一个组件可能需要改动整个技术栈。你最终只能围绕一个你仍然需要它做其他工作的厂商打补丁。随着时间推移，这些补丁会让你更难脱身。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）