本系列导航
- 上一篇：第二十三章：Pro 订阅与定价体系
- 下一篇：第二十五章：团队版与企业版
- 返回目录：Birdor 商业计划书目录
本章关键词
API 计费、用量计费、API token、rate limit、AI API、批处理、团队额度、Birdor。
适合阅读的人
- 正在设计 Birdor API 商业化的人。
- 需要区分 Pro 订阅和 API 计费的人。
- 关心 AI API 成本控制和开发者体验的人。
本章摘要
API 是 Birdor 从网页工具走向开发者基础设施的关键。网页工具服务手动任务，API 服务自动化任务。API 计费必须清晰、可预测、可控制，否则开发者不会把它接入自己的系统。
Birdor API 可以从免费额度开始，按调用次数、处理数据量、任务类型和 AI 成本分层计费。确定性工具 API 成本低，适合较大免费额度；AI API 成本高，需要 credit、限额和任务队列。
24.1 API 计费目标
API 计费有四个目标：
- 覆盖服务器、带宽和 AI 成本。
- 让高频自动化用户贡献收入。
- 防止滥用和异常流量。
- 保持价格透明，方便开发者控制预算。
API 用户通常比网页用户更稳定，因为他们把 Birdor 接入了流程。计费设计要重视长期关系。
24.2 免费额度
免费 API 额度很重要。它让开发者可以试用：
- 每月一定调用次数。
- 低速率限制。
- 只支持确定性工具。
- 不支持高成本 AI 或大文件。
免费额度不应太低，否则无法体验；也不能太高，否则会被滥用。早期可以根据成本逐步调整。
24.3 计费维度
Birdor API 可以按以下维度计费：
| 维度 | 适用场景 |
|---|---|
| 调用次数 | JSON validate、Base64、Timestamp |
| 数据量 | CSV、文件转换、日志分析 |
| AI credit | AI Regex、AI Log、AI Config |
| 批处理任务 | 多文件、多记录 |
| 并发和速率 | 高吞吐用户 |
| 团队共享额度 | Team/Enterprise |
不同 API 不应强行使用同一计费单位。确定性轻量工具按调用次数，AI 工具按 credit 更合理。
24.4 API 套餐结构
可以分为：
- Free API：试用和轻量调用。
- Pro API：个人开发者自动化。
- Team API：共享额度、团队 token、成员管理。
- Enterprise API：高额度、SLA、数据策略、专属支持。
早期可以先做 Free + Pro，等 API 使用增长后再拆 Team 和 Enterprise。
24.5 成本控制
API 成本控制包括：
- rate limit。
- payload size limit。
- timeout。
- queue limit。
- AI credit。
- 异常检测。
- 日志和用量监控。
没有成本控制的 API 很危险，尤其是 AI API。Birdor 必须从第一天记录调用量、错误率、平均处理时间和成本。
24.6 开发者体验
计费不能牺牲体验。开发者需要：
- 清楚的额度。
- 即时用量面板。
- 超额提醒。
- 结构化错误码。
- 价格文档。
- 示例代码。
当用户超额时，错误应该清楚说明 quota_exceeded，而不是模糊失败。
24.7 与 Pro 的关系
个人 Pro 可以包含基础 API 额度，但高频 API 用户应进入 API 套餐。否则个人 Pro 会被自动化调用消耗过多资源。
简单规则是：Pro 服务个人效率，API 计费服务自动化规模，Team 服务组织协作。
24.8 本章结论
Birdor API 计费应从免费额度和少量确定性 API 开始，逐步扩展到 AI credit、批处理和团队共享额度。核心是透明、可控、稳定，让开发者敢把 Birdor 接入自己的系统。
24.9 API 账单页面
API 用户需要一个清晰账单页面，展示：
- 当前套餐。
- 本月调用次数。
- 剩余额度。
- 错误率。
- 主要 endpoint 用量。
- AI credit 消耗。
- 超额费用预估。
- token 列表。
这个页面既是账单，也是信任工具。开发者能看到用量，才敢把 API 放进自动化流程。
24.10 超额策略
超额策略要谨慎。可以提供几种选择：
- 达到额度后停止调用。
- 达到额度后降速。
- 达到额度后按量计费。
- 接近额度时邮件提醒。
默认策略不应让用户意外产生高额账单。开发者 SaaS 的计费信任非常重要。
24.11 API 成本复盘
每个 API 上线后要定期复盘单位成本。确定性 API 成本通常低，但 AI API 成本可能波动。Birdor 应按 endpoint 记录平均输入长度、处理时间、模型成本和错误重试。没有成本数据，就无法设计健康价格。
24.12 API 产品指标
API 指标应独立于网页指标。核心包括 token 创建数、首次调用成功率、7 日留存调用、错误率、quota exceeded 次数、平均响应时间、单位调用成本和付费转化。首次调用成功率尤其重要，如果开发者按文档无法快速跑通，后续调用和付费都不会发生。
Birdor 还应记录不同 endpoint 的使用结构。JSON validate 可能调用量大但价值低，AI Log API 调用量小但价值高。不同 endpoint 应有不同商业判断。
24.13 API 文档和内容联动
API 计费必须和文档联动。每个可收费 API 都需要示例场景：如何在 CI 中校验 JSON、如何在内部后台批量转换 CSV、如何调用 AI Log Analyzer 生成报告。这些场景内容既是 SEO，也是转化材料。
没有场景说明的 API 很难卖。开发者需要看到它能放进哪里，而不是只看 endpoint。
24.14 API 的长期壁垒
API 一旦进入用户流程，迁移成本会高于网页工具。用户会写脚本、配置 token、接入 CI、依赖返回格式。Birdor 必须珍惜这种信任，保持版本兼容和稳定错误码。短期频繁破坏 API，会严重伤害长期商业价值。
24.15 API 版本策略
Birdor API 应从一开始使用版本号，例如 /v1/json/format。即使早期 API 很少，也要建立版本意识。后续如果修改请求字段、响应结构或错误码，应通过新版本或兼容字段处理，而不是直接破坏旧调用。
版本策略是开发者信任的一部分。网页工具可以快速改 UI，API 不能随意改协议。
24.16 API 验收清单
每个 API 上线前检查：
- 是否有稳定 schema。
- 是否有清楚错误码。
- 是否有 curl 示例。
- 是否有至少一种 SDK 示例。
- 是否有速率限制。
- 是否有用量统计。
- 是否有隐私说明。
- 是否有版本号。
缺少这些能力时，API 仍然只是内部接口，不适合公开计费。
24.17 本章最终判断
Birdor API 的商业价值来自稳定和可预期。用户越敢依赖 API，Birdor 的收入越稳定。API 计费不是简单收费表，而是一整套开发者信任系统。
24.18 后续动作
下一步应选 2-3 个确定性 API 做原型，例如 JSON validate、Base64 decode、Timestamp convert。先完成 endpoint、token、错误码、文档、调用统计和免费额度。等这些基础稳定后，再考虑 AI API。这样可以避免一开始就被高成本和不确定输出拖住。
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。