本系列导航
- 上一篇：第三十二章：前端工具页架构
- 下一篇：第三十四章：AI 模型路由与成本控制
- 返回目录：Birdor 商业计划书目录
本章关键词
后端 API、任务队列、API token、用量统计、批处理、错误码、异步任务、服务边界。
适合阅读的人
- 需要理解第三十三章：后端 API 与任务架构的人。
- 正在把 Birdor 商业计划书转成产品、内容、技术或运营动作的人。
- 希望从 AI 开发者工具平台视角建立系统判断的人。
本章摘要
Birdor 后端的职责是承载不能或不应在浏览器完成的能力：账户、API token、AI 调用、长任务、批处理、计费、用量统计和审计。基础工具尽量本地执行，后端服务高价值和自动化场景。
后端架构要从 MVP 起就区分同步 API 和异步任务。短任务用同步 API，长日志、批量文件和 AI 长分析使用任务队列。
33.1 后端服务边界
后端负责：
- 用户登录。
- API token。
- Pro/Team 权限。
- AI 调用。
- 工具 API。
- 用量统计。
- 任务队列。
- 结果存储。
- 账单事件。
- 审计日志。
后端不应该承担所有基础工具计算。JSON 格式化、Base64、Timestamp 等能本地完成的能力优先本地执行，同时抽象为可复用模块供 API 使用。
33.2 API 设计
API 应采用版本化路径：
/v1/json/format/v1/json/validate/v1/jwt/decode/v1/regex/generate/v1/log/analyze
响应应统一包含：
- request_id。
- result。
- error。
- usage。
- warnings。
错误码统一，例如 invalid_input、quota_exceeded、payload_too_large、unauthorized、model_unavailable。
33.3 同步与异步
同步适合：
- JSON format。
- Base64 decode。
- Timestamp convert。
- JWT decode。
异步适合：
- AI Log Analyzer。
- 大文件转换。
- 批量图片处理。
- 长文本 AI 分析。
异步任务需要 create、status、result、cancel 四类接口。
33.4 任务队列
任务队列应记录：
- task_id。
- user_id/workspace_id。
- task_type。
- status。
- input_ref。
- output_ref。
- error。
- created_at。
- finished_at。
队列可以先简单实现，后续再扩展重试、优先级和并发控制。
33.5 用量统计
所有 API 和 AI 调用都要记录用量：
- 调用次数。
- 输入大小。
- 输出大小。
- AI token。
- 成本估算。
- 错误率。
- 响应时间。
这些数据服务 Pro、API 计费和成本控制。
33.6 数据存储
存储分几类：
- 用户和账户。
- 工具历史。
- 模板。
- API token。
- 用量记录。
- 任务结果。
- 审计事件。
历史记录应由用户明确开启或保存，不能默认保存敏感输入。
33.7 本章结论
Birdor 后端应服务高价值能力：账户、API、AI、任务、计费和观测。同步 API 和异步任务要从一开始分清，错误码和用量统计要统一。下一章将展开 AI 模型路由和成本控制。
33.8 开发落地清单
第一批后端任务：
- 用户和会话基础。
- API token 创建、撤销、校验。
- 统一错误响应。
- JSON validate API 原型。
- AI Regex 调用服务。
- 用量记录表。
- 任务表预留。
不要第一天做完整 billing，但要记录足够用量数据，避免后续无法计费。
33.9 后端风险
风险包括 API 无版本、错误码不稳定、任务队列过早复杂、历史记录默认保存敏感输入、AI 调用无法统计成本。Birdor 后端必须从最小功能开始，但不能缺少可追踪性。
33.10 验收标准
- API 有版本号。
- 所有错误返回结构统一。
- API token 可撤销。
- 用量能按用户记录。
- 长任务有 task_id 设计。
- AI 调用能记录成本。
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。