全球 AI API 中转站技术落地研发计划
以 New API 快速二开为商业底座，以 LiteLLM Proxy 增强多模型路由，以 AI Coding 工程化提高研发效率，在 2 个月内交付可对外商用的 API 中转平台。
建设目标与交付边界
本项目第一阶段只做 API 中转站核心平台，不在 2 个月内追求完整 Agent 生态、算力租赁、白标私有化全部落地。目标是先形成“可注册、可充值、可调用、可计费、可运营、可风控”的商业闭环。
客户完成注册、充值、创建 API Key、调用模型、查询用量；平台完成扣费、成本统计、毛利查看和异常处理。
OpenAI-compatible API、流式响应、供应商路由、fallback、Token 统计、余额扣减、日志追踪、监控告警。
管理后台可配置模型、渠道、倍率、用户额度；代理商可邀请客户、查看消耗、统计佣金。
2 个月必须交付的能力
| 类别 | 必须交付 | 验收口径 |
|---|---|---|
| 用户侧 | 注册登录、API Key、余额、充值记录、调用日志、模型价格、接入文档 | 真实用户可自助完成 API 调用 |
| API 侧 | OpenAI-compatible endpoint、流式透传、模型映射、错误码统一 | 主流 SDK 修改 baseURL 和 key 即可接入 |
| 计费侧 | Token usage 归一化、模型倍率、余额扣减、消费流水、补账机制 | 账本误差低于 0.5%，每笔扣费可追溯 |
| 管理侧 | 用户、渠道、模型、价格、订单、充值、日志、风控、成本毛利 | 运营人员不依赖研发即可日常管理 |
| 代理侧 | 邀请码、客户归因、代理客户消耗、佣金统计、结算记录 | 可支撑首批 5-10 个代理试运营 |
| 运维侧 | 监控、告警、状态页、供应商健康、备份、发布回滚 | 故障可发现、可定位、可切换 |
全局产品路线图
路线图采用“中转站先行、Agent 拉消耗、自有算力提毛利、企业与白标做壁垒”的节奏。第一阶段必须克制，所有研发优先保证 API 中转主链路。
全局技术架构
架构原则：底座复用、核心账本自控、业务后台 AI 辅助开发、生产安全人工把关。第一阶段不做过度微服务化，采用模块化单体 + 独立网关 + 独立账本的方式快速交付。
架构落地原则
New API 承担中转商业底座，LiteLLM 承担多模型适配增强，减少重复造轮子。
余额、扣费、订单、佣金必须独立建模，不完全依赖开源项目原有逻辑。
v1.0 不过度微服务化，服务边界清晰即可；后续按压力拆分。
所有请求从第一天就要有 traceId、usage、cost、provider、userKey 记录。
平台规划与页面/后台能力
平台规划按使用角色拆分：用户、代理商、管理员、运维、开发者。AI Coding 主要承担页面、CRUD、报表和文档生产，核心资金安全链路由人工主导。
| 平台 | v1.0 必须完成 | AI 可承担比例 | 人工重点把关 |
|---|---|---|---|
| 用户控制台 | Key、余额、充值、日志、文档入口 | 70%-85% | 权限、余额展示、敏感字段隐藏 |
| 管理后台 | 用户、供应商、模型、倍率、订单、日志 | 60%-75% | 高危操作权限、审计日志、补账流程 |
| 代理后台 | 邀请、客户归因、佣金统计、结算记录 | 65%-80% | 佣金算法、归因边界、结算审批 |
| 文档站 | 快速开始、接口说明、SDK 示例、FAQ | 80%-90% | 接口准确性、价格口径、合规措辞 |
| 运维平台 | 状态页、健康检查、告警列表、成本预警 | 50%-65% | 告警阈值、事故流程、供应商切换 |
技术选型与开源底座二开策略
选型标准不是“哪个最酷”，而是“哪个能最快支持商业闭环，且后续不会把核心能力锁死”。结论是 New API 做主底座，LiteLLM Proxy 做增强层，自研账本/代理/成本/风控。
| 候选 | 定位 | 优势 | 短板 | 采用建议 |
|---|---|---|---|---|
| New API | 中转商业底座 | 模型渠道、用户额度、倍率、日志、兑换码等能力贴近中转站场景 | 企业治理、复杂路由、代理商商业体系仍需二开 | 主底座 |
| LiteLLM Proxy | 多模型网关增强 | OpenAI 兼容、多 Provider、Virtual Key、预算、限流、路由能力强 | 商业后台和代理分销能力不是重点 | 增强层 |
| One API | 轻量中转底座 | 成熟、轻、容易部署 | 后续商业化和治理能力不如 New API | 备选 |
| Portkey | 企业级 AI Gateway 对标 | 路由、缓存、fallback、观测、Guardrails 完整 | 如果直接商业化使用需评估成本和自控程度 | 对标/参考 |
| 纯自研 | 完全自控 | 长期灵活度最高 | 2 个月风险极高，流式、usage、渠道差异、账本都会拖慢 | 不建议 v1.0 |
推荐技术栈
New API + LiteLLM Proxy，先独立部署，再按流量和能力逐步打通。
Go 或 Python/FastAPI。若团队 Go 强，用 Go 做账本和高并发；若 AI 迭代快，用 FastAPI 做后台服务。
Next.js + React + Tailwind/Ant Design Pro，AI 生成页面效率高。
PostgreSQL 做主库，Redis 做限流/缓存，Loki/ClickHouse 后续承接日志分析。
二开边界
| 能力 | 处理方式 | 说明 |
|---|---|---|
| 模型转发、基础渠道、模型倍率 | 复用 New API | 只做必要适配和界面调整 |
| 多 Provider 适配、复杂 fallback、BYOK | 引入 LiteLLM Proxy | 第 1 个月只接关键模型，第 2 个月增强 |
| 余额、订单、扣费、补账 | 自研 | 资金链路必须可审计、可回放、可修复 |
| 代理商归因和佣金 | 自研 | 决定分销体系，不能完全寄托开源项目 |
| 成本毛利和供应商台账 | 自研 | 商业决策核心数据，必须和账本打通 |
| 后台 CRUD 和报表 | AI 主写 | 人工做 schema、权限、验收 |
核心系统数据流程与时序
API 中转站最关键的是“请求能转发”和“钱能算清楚”。下面两张图分别描述调用扣费数据流和支付充值时序。
API 调用与扣费数据流
充值与订单状态时序
核心模块拆解与前后置关系
研发拆解不能按页面随意开工，必须围绕主链路依赖。下面的模块关系决定 8 周排期。
| 模块 | 优先级 | 依赖 | 实现方式 | 负责人 | 验收标准 |
|---|---|---|---|---|---|
| 底座部署 New API | P0 | 服务器、数据库 | 开源部署 + 少量配置 | 后端 + DevOps | 可完成基础模型调用 |
| LiteLLM PoC | P0 | 供应商测试 Key | 独立部署验证 | 架构师 | 至少 3 个 Provider 可转发 |
| 用户与 API Key | P0 | 底座用户体系 | 复用 + 二开 | 后端 | Key 可创建、禁用、鉴权 |
| Provider/渠道管理 | P0 | New API 渠道能力 | 复用 + 成本字段二开 | 后端 | 可配置成本、余额、健康状态 |
| 计费账本 | P0-A | 用户、模型、订单 | 核心自研 | 架构师 + 高级后端 | 余额扣减、流水、补账准确 |
| 充值订单 | P0-A | 计费账本 | 自研 + AI 辅助 | 后端 | 订单状态机和幂等入账通过测试 |
| 用户控制台 | P0-B | 用户、Key、账本 API | AI 主写 | 前端 | 用户可自助完成主链路 |
| 管理后台增强 | P0-B | 模型、渠道、账本 | AI 主写 + 人工验收 | 前端 + 后端 | 运营可配置模型和订单 |
| 监控告警 | P0 | 网关日志、部署环境 | 开源组件 + 配置 | DevOps | 错误率、延迟、供应商故障可告警 |
| 代理商系统 | P1 | 用户、账本、订单 | 自研 + AI 页面 | 后端 + 前端 | 邀请归因、佣金统计可跑 |
| 成本毛利看板 | P1 | usage、供应商成本、订单 | AI 页面 + 自研聚合 | 后端 + 前端 | 按模型/供应商/用户查看毛利 |
| 状态页与文档 | P1 | 模型和监控 API | AI 主写 | 前端 + 产品 | 客户可按文档成功接入 |
AI Coding 工程化研发体系
AI 不是替代技术负责人，而是替代重复编码。越依赖 AI，越需要强架构、强测试、强评审、强门禁。
后台 CRUD、表单、列表、报表、文档、SDK 示例、测试样板、部署脚本初稿、Mock 数据。
账本、扣费、支付回调、佣金、密钥管理、权限、安全、路由策略、并发一致性。
前端页面、管理后台、成本看板、代理后台、状态页、接口测试、运维手册。
AI 开发流水线
AI 代码合并门禁
| 门禁 | 要求 | 失败处理 |
|---|---|---|
| 代码规范 | lint、format、类型检查通过 | 退回 AI 修复，禁止人工带病合并 |
| 单元测试 | 账本、订单、佣金、限流等核心逻辑必须有测试 | 没有测试不得合并 |
| 接口测试 | API 调用、充值、扣费、日志查询需自动化验证 | 失败必须定位到具体模块 |
| 安全扫描 | Gitleaks、依赖漏洞、敏感配置扫描 | 发现密钥或高危漏洞立刻阻断 |
| 人工评审 | 核心链路至少 1 名高级工程师 review | 高风险逻辑需要技术负责人复核 |
研发资源投入、人员安排与成本
AI 辅助模式下，不建议靠人海战术。团队要小而强：1 个强架构师，2-3 个能驾驭 AI 的后端/全栈，1 个前端，1 个 DevOps，1 个产品测试。
推荐 6 人核心团队
| 岗位 | 人数 | 核心职责 | AI 使用方式 | 月成本 RMB |
|---|---|---|---|---|
| 技术负责人/架构师 | 1 | 架构、选型、数据模型、核心代码评审、上线把关 | 拆任务、审代码、生成测试、辅助设计 | 35,000-50,000 |
| 后端工程师 | 2 | New API/LiteLLM 二开、账本、支付、代理、风控 | 生成接口样板、迁移脚本、单测、后台 API | 50,000-80,000 |
| 前端工程师 | 1 | 用户台、管理台、代理台、官网、状态页 | 生成页面、表单、图表、交互样板 | 18,000-30,000 |
| DevOps/SRE | 1 | 部署、监控、日志、备份、安全、CI/CD | 生成脚本、配置、告警规则初稿 | 25,000-40,000 |
| 产品/测试/交付 | 1 | PRD、验收用例、测试、文档、客户反馈 | 生成验收用例、文档、SOP、测试数据 | 18,000-30,000 |
| AI 工具与测试 API | - | Codex/Claude Code/Cursor、测试模型消耗 | 研发效率基础设施 | 5,000-20,000 |
| 云与监控成本 | - | 服务器、数据库、日志、CDN、安全 | 测试与生产环境 | 10,000-40,000 |
6 人，月成本约 16.1-29 万 RMB；2 个月约 32.2-58 万 RMB。
7-8 人，加 1 名前端/全栈和 1 名 QA，2 个月约 44-76 万 RMB。
10-12 人传统开发 2 个月成本更高，沟通和返工也更多；AI 模式预计节省 35%-55%。
用人硬要求
- 技术负责人必须懂后端架构、账本一致性、API 网关、部署安全和 AI Coding 管理。
- 后端工程师必须能读开源项目源码，不能只会从零写业务 CRUD。
- 前端工程师必须能驾驭 AI 生成页面，但要能修复状态管理、权限和接口对接问题。
- DevOps 必须第 1 周介入，不允许最后一周才部署。
- 产品/测试必须懂 API 业务链路，能写出可自动化的验收用例。
建设优先级与依赖关系
优先级以“能否对外商用”为核心判断。P0-A 为人工主导的高风险核心链路，P0-B 为 AI 可大量参与的交付链路。
P0-A 人工主导
- 账本扣费
- 支付回调
- Key 加密
- 权限隔离
- 并发一致性
P1-A 人工设计
- fallback 策略
- 供应商成本
- 异常冻结
- 风控规则
P2 后续增强
- 自研路由 DSL
- 多区域调度
- 企业私有化
P0-B AI 主写
- 用户台
- 管理台
- 订单页面
- 日志页面
P1 业务增强
- 代理后台
- 佣金看板
- 毛利看板
- 状态页
P2 生态
- Agent 平台
- 开发者市场
- 算力租赁
P0 基础设施
- 部署环境
- CI/CD
- 文档站
- SDK 示例
可延后
- 多语言全量
- 营销官网复杂动画
- 高级主题配置
不进 v1.0
- 完整白标系统
- 复杂投资人看板
- 重型 BI 仓库
关键前后置关系
| 前置任务 | 后置任务 | 原因 |
|---|---|---|
| 底座部署 + 首批供应商接入 | API 调用链路、用户控制台 | 没有真实调用，所有页面都是空壳 |
| 用户、模型、价格数据模型 | 账本、订单、毛利看板 | 计费必须先统一模型和价格口径 |
| 账本扣费 | 充值、代理佣金、成本毛利 | 所有商业数据都依赖账本流水 |
| 调用日志和 traceId | 监控、告警、状态页、客服排障 | 没有 trace 就不能定位客户问题 |
| 代理归因 | 佣金结算 | 先确定客户归属，才能计算佣金 |
| CI/CD 和测试环境 | AI 批量开发 | AI 产出必须依赖自动门禁兜底 |
8 周详细研发计划
每周都有明确产出和验收。第 4 周必须完成内测闭环，第 6 周必须公测，第 8 周形成可对外销售版本。
| 周次 | 核心目标 | 研发任务 | 并行任务 | 验收标准 |
|---|---|---|---|---|
| 第 1 周 | 技术底座与规范冻结 | New API 部署、LiteLLM PoC、PostgreSQL/Redis、CI/CD、核心数据模型、AI 开发规范 | 供应商测试 Key、品牌域名、产品原型、验收用例 | 至少 3 个模型可通过测试环境转发 |
| 第 2 周 | API 调用主链路 | 用户、API Key、模型列表、渠道管理、基础日志、流式响应验证 | AI 生成用户台/管理台初版、文档站骨架 | 用户 Key 可调用主流模型并记录日志 |
| 第 3 周 | 计费和订单主链路 | 账本、usage normalizer、模型倍率、余额扣减、订单状态机、人工充值 | AI 生成订单页面、流水页面、充值页面 | 充值后调用扣费，流水可追踪，余额准确 |
| 第 4 周 | 内测版本 | 用户控制台闭环、管理后台配置、API 文档、SDK 示例、第一批内测客户 | 客服 SOP、FAQ、价格表、种子客户导入 | 10-20 个内测用户可完成接入 |
| 第 5 周 | 代理和毛利体系 | 代理邀请、客户归因、佣金统计、成本字段、毛利看板、供应商健康检查 | 代理协议、代理素材、客服排障流程 | 至少 3 个代理可跑测试客户归因 |
| 第 6 周 | 稳定性与公测 | fallback、限流、告警、异常冻结、压测、安全扫描、公测发布 | 状态页、故障公告模板、监控日报 | 公测请求成功率 97%+，核心告警可用 |
| 第 7 周 | 商业化补齐 | 企业套餐、代理结算单、成本报表、管理台补齐、bug 修复 | 销售材料、案例沉淀、运维手册 | 可支持 30-50 个真实客户试运营 |
| 第 8 周 | 正式上线 v1.0 | 生产发布、回滚预案、备份演练、验收报告、二期 Agent 规划 | 代理招募、客户转化、客服值班 | 正式对外销售，形成日常运营机制 |
项目甘特图
甘特图展示 8 周交付节奏。技术底座、前端页面、供应商、运维、文档、代理体系必须并行推进。
资源到位时间规划
资源不到位是 2 个月计划最大的非技术风险。服务器、API 合作商、支付、法务协议必须前置，不允许等研发完成后再补。
| 时间 | 资金与预算 | 服务器/基础设施 | API 合作商 | 运营/法务资源 |
|---|---|---|---|---|
| D0-D3 | 确认 2 个月研发预算和 API 测试预算 | 域名、Cloudflare、Git 仓库、测试服务器、PostgreSQL、Redis | OpenAI、Anthropic、Google、OpenRouter 测试账号 | 产品负责人、技术负责人、项目群、日报模板 |
| 第 1 周 | 开通 AI Coding 工具、测试模型额度 | CI/CD、测试环境、日志基础设施 | Together、DeepInfra、Groq、SiliconFlow、Azure/GCP 评估 | 服务条款、隐私政策、AUP 初稿 |
| 第 2 周 | 首批供应商充值预算 | 生产环境雏形、备份策略、监控面板 | 确认首批 4-6 个生产供应商 | 价格表、套餐、代理政策初稿 |
| 第 3-4 周 | 支付通道保证金/手续费预算 | 生产数据库、对象存储、邮件服务 | 供应商成本台账、额度预警机制 | 代理协议、企业合同模板、客服 SOP |
| 第 5-6 周 | 公测补贴预算和异常消耗备用金 | 压测资源、安全扫描、状态页 | 备用供应商和 fallback 配置 | 种子客户、代理商名单、公测公告 |
| 第 7-8 周 | 正式运营预算和续费预算 | 生产扩容方案、值班机制、回滚预案 | 企业合同/更高额度谈判 | 销售材料、运维手册、验收报告 |
质量、安全与运维体系
API 中转站卖的是稳定性和信任，质量体系不能等上线后再补。尤其是 AI 生成代码，必须用自动化门禁和人工审查兜底。
单元测试覆盖账本、订单、分佣、限流；接口测试覆盖调用、充值、扣费、日志；Playwright 覆盖用户主链路。
API Key 加密、Secrets 管理、权限分层、审计日志、Gitleaks、依赖漏洞扫描、IP/设备异常检测。
Prometheus、Grafana、Loki、Sentry、状态页、告警机器人、备份恢复、发布回滚、事故复盘。
上线质量指标
| 指标 | 内测线 | 公测线 | 正式上线线 |
|---|---|---|---|
| API 请求成功率 | 95%+ | 97%+ | 98%+ |
| 账本扣费准确率 | 99% | 99.5% | 99.9% |
| 网关额外延迟 P95 | < 500ms | < 350ms | < 250ms |
| 关键告警覆盖 | 错误率、供应商失败 | 成本、余额、延迟 | 全链路、SLA、异常消费 |
| 数据备份 | 每日备份 | 每日备份 + 恢复演练 | 自动备份 + RPO/RTO 记录 |
风险预估与应对措施
风险控制重点围绕技术、成本、周期、供应链和 AI 代码质量。每项风险必须有触发信号和应对动作。
| 风险 | 触发信号 | 影响 | 应对措施 | Owner |
|---|---|---|---|---|
| 开源底座二开困难 | 第 1 周 PoC 无法跑通核心场景 | 周期延误 | 立即切换备选：New API/One API/LiteLLM 组合降级，核心账本独立 | 技术负责人 |
| 账本误差 | usage 与扣费不一致、并发扣费错乱 | 资金损失、信任崩塌 | 账本流水不可变、幂等扣费、补账任务、每日对账 | 高级后端 |
| AI 代码质量不稳 | bug 多、风格乱、测试缺失 | 返工增加 | 小任务、强模板、强 review、测试门禁、禁止 AI 直接改核心账本 | 架构师 |
| 上游断供或限流 | 供应商错误率升高、余额不足、接口失败 | 客户调用失败 | 多供应商、健康检查、自动 fallback、余额预警、备用供应商 | DevOps + 供应商运营 |
| 成本失控 | 高成本模型调用异常、低价包被套利 | 毛利变负 | 预算阈值、模型白名单、限购、成本实时告警、异常冻结 | 产品 + 后端 |
| 支付审核拖延 | 支付通道 2 周内未开通 | 无法自动收款 | 先支持人工入账和企业转账，支付自动化并行推进 | 项目负责人 |
| 周期膨胀 | P1/P2 需求挤占 P0 | 2 个月无法上线 | P0 冻结，需求委员会每周裁剪，P2 全部移入二期 | 项目负责人 |
| 安全泄露 | 密钥进入代码、日志泄露敏感信息 | 重大事故 | Secrets Vault、Gitleaks、日志脱敏、最小权限、审计 | DevOps |
最终验收标准与交付物
v1.0 上线不是“页面做完”，而是商业主链路和运维主链路都可闭环。
- 新用户可注册、充值、创建 API Key。
- 用户使用 OpenAI SDK 可成功调用至少 6 类模型。
- 调用后实时或准实时扣费，并生成消费流水。
- 余额不足、权限不足、限流、供应商失败有明确错误。
- 代理商可邀请客户并看到客户消耗和佣金。
- 管理端可配置供应商、模型、倍率和用户额度。
- 每笔请求有 traceId、provider、model、usage、cost。
- 核心供应商失败后可切换备用供应商。
- Prometheus/Grafana/Sentry/Loki 基础监控可用。
- 数据库备份、发布回滚、事故处理文档完成。
交付物清单
| 交付物 | 内容 | 责任人 |
|---|---|---|
| 生产系统 | API 中转平台、用户台、管理台、代理台、文档站、状态页 | 技术负责人 |
| 源代码与部署文档 | 代码仓库、README、部署脚本、环境变量说明、回滚流程 | DevOps |
| 接口文档 | OpenAI-compatible API、模型列表、错误码、SDK 示例 | 产品/测试 |
| 测试报告 | 单元测试、接口测试、压测、安全扫描、验收用例 | QA/产品 |
| 运维手册 | 监控、告警、备份、事故处理、供应商切换、账本补账 | DevOps |
| 运营手册 | 价格配置、充值审核、代理结算、客服排障、异常用户处理 | 运营负责人 |