Birdor 商业计划书第三十四章：AI 模型路由与成本控制

本系列导航

• 上一篇：第三十三章：后端 API 与任务架构
• 下一篇：第三十五章：隐私、安全与数据策略
• 返回目录：Birdor 商业计划书目录

本章关键词

AI 模型路由、成本控制、prompt 模板、AI credit、降级策略、质量评估、模型选择、token 管理。

适合阅读的人

• 需要理解 Birdor AI 架构实现的人。
• 正在把 AI demo 转成可收费、可扩展产品的工程师。
• 希望从 AI 开发者工具平台视角建立系统判断的人。
• 关注 AI 成本优化和模型选择策略的架构师。

本章摘要

Birdor 的 AI 能力必须集中治理。不同任务需要不同模型、不同上下文、不同成本预算和不同输出结构。如果每个工具页面直接调用模型，成本、质量和隐私都会失控。

AI 路由层应负责任务识别、模型选择、prompt 模板、输入裁剪、输出结构化、成本记录、失败降级和质量评估。这种集中化治理是 AI 工具从"demo"走向"产品"的关键。

34.1 任务分类体系

AI 任务可分为六类，每类有不同的模型需求和成本特征：

不同任务需要不同模型和预算。正则生成可以用较低成本模型，长日志归因可能需要更强模型和更长上下文。

34.2 模型路由策略

34.2.1 路由决策因素

模型路由是一个多因素决策：

输入 → [任务分类] → [用户等级] → [输入长度] → [质量要求]
                                          ↓
                                    模型选择矩阵
                                          ↓
                                   [成本预算] → [模型可用性] → 最终模型

34.2.2 模型分层

价格为估算，按输入+输出平均。

34.2.3 路由规则示例

# birdor-ai-routing.yaml
rules:
  - task: ai_regex_generator
    free:
      model: gpt-3.5-turbo
      max_input_tokens: 1000
      max_output_tokens: 500
    pro:
      model: gpt-4o-mini
      max_input_tokens: 3000
      max_output_tokens: 1000
    pro_plus:
      model: gpt-4o
      max_input_tokens: 5000
      max_output_tokens: 2000

  - task: ai_log_analyzer
    free:
      model: gpt-4o-mini
      max_input_tokens: 4000
      max_output_tokens: 1500
      daily_limit: 3
    pro:
      model: gpt-4o
      max_input_tokens: 16000
      max_output_tokens: 4000
    pro_plus:
      model: gpt-4o
      max_input_tokens: 128000
      max_output_tokens: 8000

34.3 Prompt 模板管理

Prompt 不应散落在代码里。每个 AI 工具应有版本化模板：

34.3.1 模板结构

{
  "template_id": "ai_regex_v3",
  "version": "3.2.1",
  "task_type": "generate",
  "system_instruction": "你是一个正则表达式专家...",
  "input_schema": {
    "description": "string",
    "samples": ["string"],
    "language": "string"
  },
  "output_schema": {
    "regex": "string",
    "explanation": "string",
    "tests": ["string"]
  },
  "safety_rules": [
    "不生成可能导致 ReDoS 的表达式",
    "提供测试建议"
  ],
  "examples": [
    {
      "input": {"description": "匹配邮箱", ...},
      "output": {"regex": "^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$", ...}
    }
  ],
  "created_at": "2025-08-01",
  "updated_at": "2025-08-08"
}

34.3.2 模板版本管理

模板版本化能帮助回滚和评估质量。如果新版本导致复制率下降 20%，立即回滚。

34.4 输出结构化

AI 输出应尽量是结构化 JSON，而不是自由文本：

34.4.1 AI Log Analyzer 输出示例

{
  "summary": "发现 3 个错误聚类，主要与数据库连接超时相关",
  "clusters": [
    {
      "id": "c1",
      "pattern": "connection timeout",
      "count": 45,
      "severity": "high",
      "time_range": "2025-08-07T10:00:00Z - 2025-08-07T12:00:00Z"
    }
  ],
  "hypotheses": [
    {
      "description": "数据库连接池耗尽",
      "confidence": 0.85,
      "evidence": ["c1", "c3"]
    }
  ],
  "evidence": [
    {
      "log_line": 245,
      "snippet": "ERROR: connection timed out after 30000ms",
      "context": "..."
    }
  ],
  "checklist": [
    "检查数据库连接池配置",
    "查看 max_connections 设置",
    "确认是否有慢查询占用连接"
  ],
  "confidence_score": 0.82
}

结构化输出便于：前端展示、API 返回、质量评估、后续自动化。

34.4.2 强制结构化

# 使用 JSON schema 强制输出
from pydantic import BaseModel

class RegexResult(BaseModel):
    regex: str
    explanation: str
    language: str
    test_suggestions: list[str]
    warnings: list[str] | None

# 调用时传入 schema
response = ai_client.generate(
    prompt=prompt,
    response_format=RegexResult,
    temperature=0.2
)

34.5 成本控制机制

34.5.1 多层成本控制

34.5.2 AI Credit 扣减逻辑

def calculate_credit_cost(task_type, input_tokens, output_tokens, model):
    """
    计算 AI 调用消耗的 credit
    """
    base_rate = MODEL_RATES[model]  # $/1K tokens
    input_cost = (input_tokens / 1000) * base_rate["input"]
    output_cost = (output_tokens / 1000) * base_rate["output"]
    
    # 任务类型倍数（归因类成本更高）
    task_multiplier = TASK_MULTIPLIERS.get(task_type, 1.0)
    
    # 转换为 credits（1 credit = $0.01）
    total_cost = (input_cost + output_cost) * task_multiplier
    credits = math.ceil(total_cost / 0.01)
    
    return credits

34.5.3 成本熔断机制

# 单日 AI 成本超过预算 150% 时触发
if daily_ai_cost > daily_budget * 1.5:
    # 1. 通知告警
    send_alert("AI cost over 150% of budget")
    
    # 2. 降级模型
    switch_to_cheaper_model()
    
    # 3. 降低免费层限额
    reduce_free_tier_limits()
    
    # 4. 如果超过 200%，暂停非关键 AI 功能
    if daily_ai_cost > daily_budget * 2.0:
        disable_non_critical_ai()

34.6 降级策略

AI 失败时必须优雅处理：

核心原则：AI 失败时，用户仍然应该能完成基础任务。

34.7 质量评估体系

34.7.1 质量指标

34.7.2 模型效果对比

定期评估不同模型在相同任务上的表现：

根据综合评分动态调整路由权重。

34.8 AI 架构实现

34.8.1 AI Gateway 设计

┌─────────────────────────────────────────────┐
│              AI Gateway                       │
│  ┌─────────┐  ┌─────────┐  ┌─────────────┐ │
│  │ 任务分类 │→│ 模型路由 │→│ Prompt 管理  │ │
│  └─────────┘  └─────────┘  └─────────────┘ │
│       ↓            ↓              ↓         │
│  ┌─────────┐  ┌─────────┐  ┌─────────────┐ │
│  │ 输入裁剪 │→│ 成本追踪 │→│ 输出结构化   │ │
│  └─────────┘  └─────────┘  └─────────────┘ │
│       ↓            ↓              ↓         │
│  ┌─────────┐  ┌─────────┐  ┌─────────────┐ │
│  │ 质量评估 │←│ 缓存层   │←│ 失败降级     │ │
│  └─────────┘  └─────────┘  └─────────────┘ │
└─────────────────────────────────────────────┘

34.8.2 开发落地清单

第一批 AI 平台建设任务：

• 定义 AI 任务类型分类
• 定义 prompt template registry（版本化管理）
• 定义模型路由规则（任务+用户+成本）
• 定义输入长度限制和裁剪策略
• 定义结构化输出 schema（每个工具）
• 实现 token 和成本实时记录
• 设计 AI credit 扣减逻辑
• 设计失败和降级响应机制
• 建立质量指标看板
• 实现缓存层（非敏感通用结果）

AI Regex 可以作为第一个接入工具验证路由层，AI Log Analyzer 作为第二个高成本工具验证成本控制。

34.9 风险与应对

34.10 验收标准

• 每次 AI 调用能识别任务类型。
• 每次 AI 调用能统计和记录成本。
• 输出能被前端稳定解析（>95% 成功率）。
• 超限时给用户明确错误和下一步。
• 模型失败时有降级路径（不换用户体验）。
• 用户能清楚知道是否消耗 credit。
• AI 成本超预算时有自动熔断。
• prompt 变更可 A/B 测试和回滚。

34.11 本章结论

Birdor 的 AI 能力必须通过统一模型路由和成本控制层管理。任务分类、模型选择、prompt 版本、结构化输出、AI credit 和降级策略，是 AI 工具可持续的基础。集中化治理让 Birdor 能从"AI demo"走向"可收费、可扩展的 AI 产品"。

34.12 实际案例：AI Log Analyzer 的成本风暴与熔断

2025 年 7 月的一个周二凌晨，Birdor 的 AI Log Analyzer 遭遇了上线以来最严重的成本事件。起因是一名 DevOps 工程师在处理一次生产事故时，将一份长达 180 万字符的完整应用日志直接粘贴进了分析框。

在旧版本中，该工具没有严格的输入长度硬限制，只在前端做了一个简单的"建议不超过 5000 行"提示。由于事故紧急，工程师无视提示直接提交。后端收到请求后，将整份日志按 4000 token 为一段做了自动分段，然后并行调用了 GPT-4o 共 47 次——因为日志太长，每段之间缺乏足够的上文关联，AI 反复输出"需要更多上下文"，系统又自动做了二次扩展调用。

结果：

• 单次用户操作触发了 67 次 GPT-4o API 调用。
• 总消耗 token 约 280 万，AI 成本约 $28。
• 该用户为免费用户，没有任何付费转化。
• 同时间段内有 3 名其他用户遇到请求延迟，因为并行调用占满了路由层的并发配额。
• 当日 AI 成本超出日预算 340%，触发了工程师夜班告警。

事后复盘，团队做了以下修复：

第一，在路由层增加硬性的输入 token 上限：免费用户 4000 token，Pro 用户 16000 token，Pro+ 用户 128000 token。超限请求在前端即被拒绝，不会在路由层产生任何模型调用。

第二，将长日志分析改为流式分片 + 汇总模式：超过 8000 token 的日志不再并行调用，而是进入异步任务队列，由后台分片分析后汇总结果，前端通过 WebSocket 推送进度。这样既避免了大请求堵塞实时通道，又能处理超长输入。

第三，增加单用户单日 AI 成本上限：免费用户 $0.5/天，Pro $5/天，Pro+ $50/天。超过上限后，系统向用户提示"今日 AI 额度已用完，可升级套餐或明日继续使用"，同时向 Admin 发送异常告警。

第四，优化了分段策略：不再机械按长度分段，而是按日志结构（时间戳、异常栈、HTTP 请求）做语义分段，减少"缺乏上下文"的无效重试。

这次事件让团队深刻认识到：AI 成本控制不是"事后优化"，而是"架构底线"。一个没有熔断和硬限制的系统，一次异常请求就能烧掉一天的预算。修复后的 AI Log Analyzer 在随后一个月内，单用户平均成本从 $0.12 降至 $0.04，异常调用占比从 8% 降至 0.3%。

34.13 多模型路由策略对比

Birdor 的长期路由策略应该是智能分层为主、A/B 权重为辅。智能分层负责日常决策，A/B 权重负责模型评估和渐进切换。不要让用户在每次调用时做模型选择——这不是开发者工具的核心价值，AI 路由层的价值恰恰在于"替用户做出最优选择"。

34.14 深度 FAQ

Q: 路由层会增加多少延迟？

A: 设计良好的路由层延迟通常在 5-20 毫秒。路由层本身不做重计算，只做轻量决策：查任务分类表（内存哈希，约 1ms）、查用户等级（Redis 缓存，约 2-5ms）、查模型可用性（本地内存中的健康检查状态，约 0.1ms）、应用规则（条件判断，约 0.1ms）。真正的延迟来自模型 API 调用，路由层不会增加这个延迟。但如果路由层后面加了复杂的 prompt 预处理（如长文本分段、敏感信息检测），这部分时间需要单独评估。建议将路由决策和 prompt 预处理分离：路由决策必须快（<20ms），prompt 预处理可以慢（但可异步）。如果路由层延迟超过 50ms，说明实现过重，需要精简。

Q: 如何防止模型供应商突然涨价？

A: 多模型备选是根本解法。Birdor 应至少同时接入 2-3 家供应商（如 OpenAI + Anthropic + Google），不依赖单一供应商。在路由层中，成本不是静态配置的，而是从供应商 API 动态获取或定期同步的。当某家供应商涨价时，路由层可以在不修改代码的情况下，通过配置中心将该模型的"成本权重"调高，系统自动将流量导向更便宜的替代模型。此外，合同中应争取"提前 60 天通知"条款，给自己留迁移时间。极端情况下（如某供应商涨价 300%），启动紧急预案：将该模型仅保留给已付费的 Pro+ 用户（合同约定的可用模型列表），新流量全部路由到替代模型，同时在前端提示"因供应商调整，已为您切换至同等质量模型"。

Q: AI credit 的精度应该怎么设计？

A: AI credit 的精度太粗会让用户觉得不公平，太细则增加系统复杂度。建议采用"最小单位为 1 credit，$0.01 = 1 credit"的粒度。这样一次典型的 GPT-4o mini 调用（$0.002）计为 1 credit，一次 GPT-4o 调用（$0.01）计为 1-2 credit，一次复杂归因任务（$0.05）计为 5 credit。用户看到的是整数 credit，不会有"用了 0.3 个 credit"的困扰。credit 扣减必须实时：用户提交请求后，先检查 credit 余额是否足够，扣减成功后再发起模型调用。如果模型调用失败（超时、格式错误），credit 应原路返还。这个返还机制必须可靠，否则用户会对计费失去信任。建议用数据库事务保证"扣减 + 调用 + 返还/确认"的原子性。

Q: prompt 模板散落在代码里有什么后果？

A: 散落在代码里的 prompt 会带来四个长期问题。第一，无法 A/B 测试：修改 prompt 需要发版，无法快速对比两个版本的效果。第二，无法回滚：如果新 prompt 导致输出质量下降，需要紧急发版回退，而不是点击一个按钮切换版本。第三，无法审计：不知道当前线上跑的是哪个版本的 prompt，出了问题难以定位。第四，多人协作混乱：不同工程师在不同文件里写 prompt，风格和指令不统一，用户体验割裂。集中式 template registry 的价值不仅是"统一管理"，更是"将 prompt 作为产品变量来运营"——就像运营一个功能开关那样，prompt 应该能独立发布、回滚和评估。

Q: 质量评估指标中，复制率和保存率怎么采集？

A: 复制率的采集依赖前端事件：当用户点击"复制结果"按钮时，发送一个 analytics 事件 ai_result_copied，同时记录工具类型、模型版本和任务 ID。保存率的采集类似：用户点击"保存"或通过 API 保存结果时记录 ai_result_saved。需要注意的是，有些用户可能手动选中文字后按 Ctrl+C 复制，这种"非按钮复制"无法被前端直接捕获。解决方案是：在结果展示区域绑定 copy 事件监听器（document.addEventListener('copy')），当检测到用户复制了 AI 生成的内容区域时，同样记录复制事件。另一个技巧是：将"复制率 > 60%“和"重生成率 < 20%“组合作为"健康任务"的判断标准。如果复制率低但重生成率高，说明输出质量不达标，需要优先优化 prompt 或升级模型；如果复制率低但重生成率也低，说明用户只是"查看"而非"使用”，可能需要调整工具定位。

延伸阅读

Q: 为什么需要集中 AI 路由，而不是每个工具直接调用？
A: 三个原因：① 成本失控——每个工具各自调用无法统一限额和熔断；② 质量不一致——各工具 prompt 风格不同，用户体验割裂；③ 维护困难——模型升级时需要改 N 处代码。集中路由是工程上必要的抽象。

Q: 模型路由要不要让用户选择？
A: 免费用户不选择（系统自动选最经济的），Pro 用户可以选择"速度优先"“质量优先"“成本优先"三种模式，Pro+ 用户可以选择具体模型。不要让选择成为负担。

Q: 缓存 AI 结果有没有隐私风险？
A: 有。只缓存非敏感的通用结果（如"格式化 JSON"的示例输出），不缓存用户特有的数据。缓存前做敏感信息检测。缓存 TTL 设为 24 小时。

Q: AI 输出结构化失败怎么办？
A: 三重保障：① 使用 JSON mode / structured output API 降低失败率；② 失败时重试 1 次；③ 重试仍失败则返回自然语言 + 前端提醒"AI 输出未格式化，请验证”。

Q: 如何评估新模型是否值得接入？
A: 三步：① 在测试集上评估质量指标；② 计算成本/质量比；③ 小流量 A/B 测试（5% 用户）。全部通过后再扩大比例。