Birdor 商业计划书第三十一章：技术架构总览

本系列导航

• 上一篇：Birdor AI Log Analyzer PRD：日志归因、证据片段与排查报告
• 下一篇：第三十二章：前端工具页架构
• 返回目录：Birdor 商业计划书目录

本章关键词

技术架构、工具页、API、任务队列、AI 模型路由、账户计费、隐私安全、可观测性。

适合阅读的人

• 准备把 Birdor 从内容规划转成产品实现的人。
• 需要设计 AI 开发者工具平台技术架构的人。
• 想判断哪些能力应前端本地执行、哪些需要后端服务的人。

本章摘要

Birdor 的技术架构要服务三个目标：工具页足够快、AI 能力可控、API 和 Pro 可以长期扩展。它不能只是静态工具页面，也不能一开始做成过重企业平台。更合理的架构是：前端承载高频交互和本地确定性工具，后端承载账户、API、AI、任务队列、计费和审计。

整体架构可以分为七层：前端工具层、工具执行层、后端 API 层、异步任务层、AI 路由层、账户计费层、安全观测层。

31.1 架构原则

Birdor 架构应遵循：

• 本地优先：能在浏览器安全完成的基础工具优先本地执行。
• API First：核心工具能力可被网页、API、批处理复用。
• AI 分层：轻量解释和高成本分析分层处理。
• 隐私前置：敏感输入默认不保存，上传和 AI 调用必须明确。
• 渐进扩展：MVP 不做全量平台，但为 API、Pro、Team 预留结构。
• 可观测：每个工具、API、AI 调用都能被追踪和复盘。

这些原则能避免 Birdor 变成一堆不可维护的页面脚本。

31.2 分层架构

这些层并不要求第一天全部完整实现，但架构边界要清楚。

31.3 MVP 架构

MVP 可以较轻：

• 静态或服务端渲染工具页。
• 前端本地执行基础工具。
• 后端只处理 AI、账户、API token 和少量工具 API。
• 异步任务先不复杂化，只为 AI Log 预留。
• 计费先做 Pro 原型和 AI credit 统计。
• 观测先记录核心事件和错误。

MVP 的目标是验证工具和商业信号，不是一次完成企业级架构。

31.4 可复用工具核心

核心工具能力要可复用。例如 JSON format/validate 不应只写在页面组件里，而应抽成工具模块。网页工具、API、批处理、测试都可以调用同一能力。

这样做有几个好处：

• 结果一致。
• 测试方便。
• API 更容易开放。
• 后续 CLI/SDK 可复用。
• 错误码和错误提示更统一。

31.5 AI 架构

AI 能力需要独立路由：

• 根据任务选择模型。
• 管理 prompt 模板。
• 控制输入长度。
• 记录成本和 token。
• 返回结构化结果。
• 支持失败降级。

AI 不应散落在每个页面里。否则成本、质量和隐私都难控制。

31.6 本章结论

Birdor 的架构应从轻量工具站起步，但按平台方式设计边界。前端负责快和可用，后端负责账户、API、AI、计费和观测，工具核心需要可复用，AI 需要集中路由。下一章将展开前端工具页架构。

31.7 开发落地清单

第一阶段只需要完成四件事：统一工具页模板、可复用工具执行模块、最小 AI 调用服务、基础事件埋点。不要一开始把 Team、Enterprise、复杂队列和完整计费全部做完。

第二阶段再增加 API token、少量工具 API、AI credit 和任务队列。第三阶段根据真实使用增加 Team、审计和企业能力。

31.8 架构风险

最大风险是过早复杂化。Birdor 的优势是轻量，如果技术架构第一天就像大型企业平台，会拖慢验证速度。另一个风险是工具逻辑分散在页面中，导致后续 API 和批处理无法复用。

因此每个工具都要问：核心逻辑能否被网页、API 和测试复用？如果不能，就需要重构边界。

31.9 验收标准

• 新增工具页能复用统一模板。
• 基础工具能本地执行。
• AI 工具通过统一 AI 服务调用。
• 核心操作有埋点。
• 工具逻辑可被 API 复用。
• 敏感数据处理路径清楚。

延伸阅读

• AI 时代全球开发者工具平台目录
• Birdor AI Log Analyzer PRD：日志归因、证据片段与排查报告
• 第三十二章：前端工具页架构
• 第三十六章：可观测性与 SRE 计划
• 第三十五章：隐私、安全与数据策略