BMAD Method

BMAD 方法（商业模式与架构设计）

概述

BMAD 方法连接业务战略与技术架构，确保技术决策支持长期业务可持续发展，而不只是交付眼前的功能。

核心洞见： 你的架构就是以代码形式呈现的业务模式。

何时使用此技能

在以下情况使用 BMAD：

• 开始开发新产品或进行重大架构重设计
• 技术决策直接影响收入或成本
• 扩展挑战与业务模式限制相互交织
• 评估核心能力是自建还是购买
• 从 MVP 转向可持续增长
• 业务模式变更需要架构调整

核心能力

• 将业务模式映射为技术架构决策
• 识别收入模式对架构的影响
• 设计能够在规模扩大时保持成本可持续的方案
• 让技术投资与业务价值保持一致
• 评估基础设施成本与收入潜力
• 随业务增长规划架构演进

工作流

步骤 1：业务模式分析

了解收入引擎：

• 资金如何流动？（一次性、订阅、按用量计费、市场平台、广告）
• 单位经济效益如何？（CAC、LTV、毛利率、回本周期）
• 预期规模如何？（10 个用户？1 万个？1,000 万个？）
• 竞争护城河是什么？（网络效应、数据、技术、品牌）

关键问题：

• 这是 B2B 还是 B2C？
• 定价模式是什么？
• 哪些因素驱动成本？（基础设施、支持、销售、开发）
• 目标毛利率是多少？

---

步骤 2：架构对齐

将业务模式映射到架构：

订阅制 SaaS（B2B）：

• 多租户架构
• 随业务增长而付费的基础设施（起步成本低）
• 企业功能（SSO、RBAC、审计日志）
• 99.9% 以上的正常运行时间 SLA 要求
• 数据隔离与安全合规

按用量计费（API/平台）：

• 无服务器/计量式基础设施
• 速率限制与配额管理
• 详细的用量追踪与计费
• 开发者体验（文档、SDK）
• 可预测的单次请求成本

市场平台/网络：

• 支持双边交互（买家/卖家）
• 交易处理与托管
• 搜索、匹配和发现算法
• 信任与安全系统
• 基于佣金的成本结构

免费增值/消费者产品：

• 高效扩展至数百万用户
• 明确划分免费与付费功能
• 每位用户的边际成本低
• 优化转化漏斗
• 病毒式传播/增长机制

---

步骤 3：成本建模

基础设施成本分析：

计算单位经济效益：

• 每用户每月成本
• 每笔交易成本
• 每次 API 调用成本
• 基础设施开销与可变成本

示例（SaaS）：

Target: $20/user/month subscription

Acceptable costs:
- Infrastructure: <$2/user/month (10% COGS)
- Support: <$4/user/month (20%)
- Sales/Marketing: <$60 CAC (3-month payback)

Architecture decisions:
- Shared infrastructure (not dedicated per customer)
- Self-service onboarding (reduce sales cost)
- In-app support tools (reduce support tickets)
- Efficient database design (reduce storage costs)

---

步骤 4：可扩展性规划

针对不同增长阶段进行设计：

阶段 1：MVP（0-100 个用户）

• 目标： 验证产品与市场的契合度
• 架构： 简单的单体架构，使用托管服务
• 成本： 每月固定低成本（100-500 美元/月）
• 权衡： 优先考虑速度而非可扩展性

阶段 2：增长（100-1 万个用户）

• 目标： 验证单位经济效益可行
• 架构： 模块化单体，先纵向扩展
• 成本： 随用户数线性增长（0.50-5 美元/用户/月）
• 权衡： 优先优化利润率而非功能

阶段 3：规模化（1 万-100 万个用户）

• 目标： 高效扩展，无需重写
• 架构： 针对瓶颈使用微服务、缓存和 CDN
• 成本： 低于线性增长（0.10-1 美元/用户/月）
• 权衡： 在运维复杂性与效率之间权衡

阶段 4：企业级（100 万以上用户）

• 目标： 占据主导市场地位
• 架构： 多区域、自定义基础设施、专职团队
• 成本： 规模经济（低于 0.10 美元/用户/月）
• 权衡： 优先长期投资而非短期敏捷性

---

第 5 步：自建还是购买框架

评估核心能力与上下文：

适合自建的情况：

• 这是你的竞争优势
• 你需要特定的定制功能
• 经常性成本超过自建成本
• 团队内部具备相关专业能力
• 控制权或安全性至关重要

适合购买／使用 SaaS 的情况：

• 这是常见功能
• 上市时间至关重要
• 你缺乏相关专业能力
• 维护负担很重
• 成本可预测性很重要

示例：

能力	决策	理由
支付处理	购买（Stripe）	属于常见功能，合规要求繁重
核心算法	自建	形成竞争壁垒
邮件发送	购买（SendGrid）	属于常见基础设施
分析	购买（Mixpanel）	比自建更快
定制 AI 模型	自建	专为你的数据打造
身份验证基础设施	初期购买（Auth0）	规模扩大后再自建

---

第 6 步：记录业务约束

记录不可妥协的要求：

法规／合规：

• GDPR、HIPAA、SOC2、PCI-DSS
• 数据驻留要求
• 审计跟踪和数据保留政策

业务承诺：

• SLA 承诺（正常运行时间、响应时间）
• 数据可移植性保证
• 必须具备的安全认证
• 对客户做出的集成承诺

财务约束：

• 资金消耗率和资金可支撑时间
• 目标毛利率
• 已做出的定价承诺
• 投资方的预期

---

示例

示例 1：B2B SaaS 分析平台

商业模式：

• 每月订阅费 $99-$499
• 目标：1,000 个客户 = ARR $1.5M
• 目标毛利率：80%
• COGS 上限：每位客户每月 $3

架构决策：

• 多租户数据库（共享 PostgreSQL）
• 无服务器数据处理（AWS Lambda）
• 托管基础设施（AWS RDS、S3、CloudFront）
• 不为每位客户配置专用资源（会严重损害利润率）

自建还是购买：

• 自建：核心分析引擎（差异化优势）
• 购买：身份验证（Auth0）、邮件（SendGrid）、支持（Intercom）

**结果：**每位客户每月 COGS 为 $2.50，利润率为 83%

---

示例 2：按用量计费的 API 平台

商业模式：

• 每次 API 调用收费 $0.01
• 目标：每月 10M 次调用 = MRR $100k
• 目标毛利率：70%
• COGS 上限：每次调用 $0.003

架构决策：

• 无服务器架构（AWS Lambda + API Gateway）
• 按使用量付费的基础设施（无闲置成本）
• 积极使用缓存（CloudFlare + Redis）
• 高效算法（每次调用的成本很重要）

自建还是购买：

• 自建：核心 API 逻辑（差异化优势）
• 购买：API 网关（AWS）、CDN（CloudFlare）、监控（Datadog）

**结果：**每次调用的 COGS 为 $0.0025，利润率为 75%

---

示例 3：面向消费者的市场平台

商业模式：

• 交易收取 10% 佣金
• 目标：每月 GMV $1M = 收入 $100k
• 目标毛利率：60%
• COGS 上限：每月 $40k

架构决策：

• 可扩展至数百万用户（无服务器架构 + CDN）
• 交易处理（Stripe Connect）
• 搜索与匹配（Algolia 或 Elasticsearch）
• 每位用户的边际成本较低（每位用户每月 < $0.01）

自建还是购买：

• 自建：匹配算法（差异化优势）
• 购买：支付（Stripe）、搜索（Algolia）、聊天（Stream）

**结果：**可扩展至 100k 用户，月成本低于 $35k

---

最佳实践

1. 从商业模式出发，而非技术栈

不要先选择 React/Node/AWS。先了解以下内容，再做选择：

• 收入模式
• 用户规模
• 单位经济效益
• 利润率目标

2. 按当前阶段再向前一步来设计

针对当前阶段构建，但不要让自己无法进入下一阶段。

**不佳：**硬编码为单租户，无法扩展
**良好：**从第 1 天起采用多租户架构（即使只有 10 位用户）

3. 衡量每位用户的基础设施成本

如果无法计算每位用户的成本，就无法预测盈利能力。

每月跟踪：

• AWS/GCP/Azure 支出
• 第三方 SaaS 成本
• 除以活跃用户数

4. 让架构投入与收入保持一致

如果某项功能无法带来收入或提高留存率，就推迟高成本的架构投入。

示例： 在验证 PMF 之前，不要构建多区域架构。

5. 规划架构调整节点

明确何时需要重构：

• 1,000 名用户 → 优化数据库查询
• 10,000 名用户 → 添加缓存层
• 100,000 名用户 → 针对瓶颈引入微服务
• 1M 名用户 → 多区域、自定义基础设施

---

常见陷阱

1. 为尚未达到的规模过度设计

只有 100 名用户时，却按 1M 名用户的规模构建系统，会浪费时间和资金。

反模式： 在 MVP 阶段采用微服务 + Kubernetes
更好的做法： 在 Railway/Heroku 上使用单体架构，之后再扩展

2. 未根据商业模式进行设计

B2B SaaS 不构建多租户架构，会导致规模扩大后利润率下降。

反模式： 为每位客户配备独立数据库
更好的做法： 从第 1 天起采用多租户架构

3. 忽视单位经济效益

不跟踪每位用户的成本，规模扩大后就会遇到意外。

反模式：“成本以后再说”
更好的做法： 构建产品前先对成本建模

4. 所有东西都自行构建

通用能力无需定制解决方案。

反模式： 自行构建自定义身份验证、支付和邮件功能
更好的做法： 购买 Stripe、Auth0、SendGrid 的服务；自行构建差异化功能

5. 技术投入与业务价值不一致

将资金花在无法带来业务价值的功能上。

反模式： 在验证 PMF 之前就完善 CI/CD
更好的做法： 快速交付，之后再优化

---

相关技能

• mvp-builder - 快速开发 MVP（BMAD 指导构建什么）
• product-strategist - 验证产品与市场的契合度（BMAD 让架构与之保持一致）
• deployment-advisor - 基础设施和 CI/CD（BMAD 设定成本目标）
• api-designer - API 设计（BMAD 决定定价模式）
• performance-optimizer - 在规模扩大后优化成本（BMAD 确定何时需要优化）

---

交付成果

使用 BMAD Method 时，需产出：

1. 商业模式画布

   • 收入来源、成本结构、价值主张
   • 单位经济效益（CAC、LTV、利润率）

2. 架构对齐文档

   • 架构如何支持商业模式
   • 每位用户的成本计算
   • 各增长阶段的可扩展性计划

3. 自建还是购买决策矩阵

   • 需要自建的核心能力
   • 可以购买的上下文能力
   • 成本效益分析

4. 架构路线图

   • 当前阶段的架构
   • 达到规模里程碑时计划进行的重构
   • 投入优先级

---

成功指标

满足以下条件，即表示你已成功应用 BMAD：

• 基础设施成本可预测，且处于目标利润率范围内
• 架构能够支持当前阶段，且不过度设计
• 已为下一个规模里程碑制定明确计划
• 自建还是购买的决策有业务价值依据
• 技术债务是经过策略性规划的，而非意外产生的
• 团队理解技术决策对业务的影响

---

请记住： 最好的架构，是能让你的商业模式可持续并实现盈利的架构。