API / 模型出海路线
把一项能力封装成接口，按调用量出售。
这是什么生意
你卖的是可编程的能力。产品本身没有界面，文档、可用性和计量准确性就是产品体验。一旦公开接口，兼容性就成了长期义务——这是与 SaaS 最大的不同。
常见收费模式
- 按调用次数计费
- 阶梯用量定价
- 额度包
- 企业版定制
用量计费的关键不是价格表，而是计量准确性、配额控制与超额处理。账单争议的成本远高于定价本身的优化空间。
适合什么样的开发者
比较适合
- 愿意长期维护接口兼容性
- 能接受客户是开发者、采购周期可能较长
可能不适合
- 希望快速迭代、频繁改变接口的人
- 无法承担稳定性承诺的业务
目标人群：有明确技术能力、能定义清楚接口边界的开发者。
从想法到收入：这条路上的六个节点
每个节点标明了必须做什么和可以推迟什么。同一套出海阶段，在不同模式下的重点并不一样。
-
确认真有开发者愿意为这项能力付费，而不是自己写。
必须做- 找到愿意试用的开发者
- 确认你的能力比他们自己实现更省事
可以推迟- 主体
- 计费体系
-
定义清楚接口边界与错误语义。
必须做- 确定输入输出格式
- 定义错误码与限流行为
可以推迟- 多区域部署
- 企业级 SLA
-
让开发者能在十分钟内完成第一次成功调用。
必须做- 可用的文档与示例
- 稳定的运行时
可以推迟- 多语言 SDK
-
企业客户的采购流程通常要求正式主体。
必须做- 确认目标客户类型是否需要合同与主体
可以推迟- 面向个人开发者的早期阶段
-
按量计费与预付费额度。
必须做- 准确记录每次调用
- 设定配额与超额策略
可以推迟- 后付费与账期
-
开发者只在需要时出现——所以要在他们搜索的地方有文档。
必须做- 把文档做成可被搜索到的内容
可以推迟- 集成目录收录
主要成本类别
这是这个模式会产生的成本类别，不是金额估算。具体数字取决于你的方案与用量。
成本发生在什么时候
这个模式的钱分三段花。上线前先付固定部分：域名、最小可用实例、文档站托管。随用量走的是计算时长与出口流量，其中日志与指标的存储最容易失控——每个请求记十几个标签、日志留 90 天，账单会先被这两项撑大。最后是支付费率与人工：小额充值常被费率里的固定费用吃掉，答疑与联调的时间没有上限。
常见误区
- 只按「调用次数」计量，但单次成本可能相差几十倍，重用量客户会亏、轻用量客户会被多收。更合理的做法是让计量单位贴近成本里最贵的变量。
- 先做价格表再打会计量。账单出错时人工核对与退款的成本，往往高于定价优化带来的收入。更合理的顺序是先把调用记成可追溯的明细，再谈档位。
- 免费额度不绑支付方式也不限速，会被脚本批量刷走。更合理的做法是按账号发额度而不是按 IP，默认限速并验证邮箱。
从零到第一笔收入
- 找 2～3 个真实开发者，确认他们宁可调你的接口，也不想自己写一遍。
- 只做一条主链路，把输入输出、错误码与限速写成一页文档，示例能直接跑通。
- 从第一天起把每次调用写入计量表，记下客户、时间、用量与当时单价。
- 开通预付费充值并设最小金额，额度用完即停，先跑通一笔真实付款。
- 把文档放到开发者会搜索的关键词下，并让第一个付费客户写下真实场景。
公司主体与收款
公司主体：API 客户多为企业，采购流程可能要求正式主体与合同。
全球收款：用量计费需要准确计量、配额与超额处理，账单争议处理成本较高。
以上为流程梳理，不构成法律、税务或支付建议。具体方案请以服务商官方说明为准，必要时咨询专业人士。
常见问题
我还没注册公司，能先开放 API 收预付费吗？
早期面向个人开发者通常可以先做，但各收款服务对主体与资料的要求不同，以官方页面为准。等出现要合同和发票的企业客户再补主体。
按调用次数计费，还是按 token／流量／时长计费？
看哪个变量最能解释你的成本。单次消耗相差数倍时，只按次数收会被重用量客户吃掉利润；也可以次数管预测、用量管封顶。
免费试用额度要不要绑支付方式？
不绑就得用别的方式限制：按账号发额度、验证邮箱后再发、默认限速。完全不设限的匿名额度会变成现金成本。
客户说账单对不上，我该怎么处理？
把每次调用明细做成客户可自助查询的页面，含时间、用量与单价，争议就从谈判变成核对。退款与超额规则提前写进文档。
获客渠道
- 开发者文档与示例
- 集成目录
- 开源 SDK