thinking-fermi-estimation

费米估算

概述

费米估算以物理学家恩里科·费米命名，是一种针对无法直接测量的数量进行合理估算的艺术。将问题拆解为可估算的因素，再将它们相乘，往往能得到出人意料地准确的数量级结果。

核心原则： 将未知量拆解为已知（或可估算）的部分。即使是粗略估算，误差也会相互抵消，从而得出合理准确的结果。

触发卡片

当你需要一个无法测量或查询的数字，且数量级估算已足够时：

1. 拆解： 数量 = 因素₁ × 因素₂ × ... × 因素ₙ（按组成部分、按速率 × 时间，或按总体 × 比例拆解）。
2. 估算每个因素： 使用范围而非单点值；估算数量级时使用几何平均数；四舍五入到一位有效数字。
3. 相乘并检查合理性： 数量级是否合理？误差 10 倍会改变决策吗？
4. 报告： “约 X，误差在 3–5 倍以内”——绝不虚报精度。

如果数字可以查询（COUNT(*)、查看定价页面、进行性能分析），就直接查询——明明存在真实值，却凭空估算，结果会糟糕得多。

适用场景

• 容量规划（“我们需要多少存储空间？”）
• 成本估算（“这套基础设施需要多少成本？”）
• 市场规模估算（“有多少潜在用户？”）
• 可行性评估（“这真的可行吗？”）
• 合理性检查（“这个数字合理吗？”）
• 面试问题（“芝加哥有多少钢琴调音师？”）
• 快速确定优先级（“这值得继续推进吗？”）

决策流程：

Need a number you don't have? → Can you measure OR look it up cheaply? → yes → DO THAT (don't Fermi it)
                                                                       ↘ no → Will an order-of-magnitude answer suffice? → yes → FERMI ESTIMATE
                                                                                                                          ↘ no → you need real data, go get it

不适用场景

• 数字很容易查询或测量。 不要用费米估算来估算可以通过 COUNT(*) 查询的表大小、可以通过性能分析测量的延迟、可以用 ls 查看文件大小、定价页面上的价格，或任何只需一次查询或搜索就能获得的事实。明明有真实值，却凭空估算，结果会糟糕得多——这会增加误差并造成虚假的信心。直接查询。
• 你需要精确值，而非数量级。 费米估算只能得出“约 4 TB，误差在 3–5 倍以内”。如果决策取决于 3.8 还是 4.2，估算无法胜任——请获取真实数字。
• 因素之间存在相关性，或者你要凭空编造基准率。 如果拆解过程只是层层猜测，毫无依据，那么结果不过是表演。要么找到一个真实的依据，要么明确说明整个结果只是粗略猜测。
• 在合理范围内，决策都不会改变。 如果“介于 1 GB 到 1 TB 之间”不会影响你的行动，就跳过估算，直接行动。

费米估算流程

第 1 步：明确要估算的内容

明确界定要估算的数量：

Vague: "How big is the market?"
Precise: "How many SaaS companies with 50-500 employees in the US
         would pay $1000/month for our product?"

第 2 步：拆解为可估算的因素

将问题拆分为可估算的部分：

Storage needs for user data:
= (Number of users)
  × (Data per user per day)
  × (Days of retention)
  × (Overhead factor)

拆解策略：

策略	示例
按组成部分拆解	总量 = 各部分之和
按速率 × 时间拆解	总量 = 速率 × 时长
按总体 × 比例拆解	目标值 = 基数 × 百分比
按类比 × 调整量拆解	新值 ≈ 相似值 × 比率

第 3 步：估算每个因素

针对每个因素，根据以下依据进行估算：

来源	示例
已知数据	“我们的日活跃用户数为 10,000”
行业基准	“SaaS 平均流失率为 5%”
物理限制	“一个人每天大约能做出 50 个决定”
逻辑边界	“至少为 1，最多为 100 万”
个人经验	“我见过每秒处理 1000 个请求的系统”

估算时：

• 使用范围，而非单点估算：“10,000 到 50,000”
• 估算数量级时优先使用几何平均数：√(10,000 × 50,000) = 22,360
• 四舍五入到一位有效数字：约 20,000

第 4 步：合并各个因素

将各个因素相乘（或相加）：

Storage = 50,000 users × 10 KB/user/day × 365 days × 1.5 overhead
        = 50,000 × 10,000 × 365 × 1.5 bytes
        = 274 billion bytes
        ≈ 270 GB/year

第 5 步：检查合理性

验证结果是否合理：

• 数量级是否合理？
• 物理上是否可能？
• 是否与任何已知数据点相符？
• 误差 10 倍会改变决策吗？
• 是否有任何因素实际上可以查询？ 如果有，请用真实值替换估算值——每替换一个实测因素，误差范围就会缩小。

第 6 步：说明置信度和影响

Estimate: ~270 GB/year
Confidence: Within 3-5x (80-1,500 GB)
Implication: Standard database tier sufficient; no special infrastructure needed

费米估算模板

# Fermi Estimate: [Question]

## Question (Precise)
[Exactly what we're estimating]

## Decomposition
[Quantity] = [Factor 1] × [Factor 2] × ... × [Factor N]

## Factor Estimates

### Factor 1: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

### Factor 2: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

[Continue for all factors...]

## Calculation
[Show the math]

## Result
- Point estimate: [Value]
- Range: [Low] to [High] (representing Xx uncertainty)

## Sanity Check
- Physical plausibility: [Check]
- Comparison to known data: [Check]
- Order of magnitude reasonable: [Check]

## Implications
[What does this estimate mean for the decision?]

示例 1：数据存储需求

问题： 我们的新功能在第 1 年需要多少存储空间？

## Decomposition
Storage = Users × Events/User/Day × Event Size × Days × Replication

## Factor Estimates

### Users (DAU)
- Estimate: 100,000 (current) growing to 200,000 (end of year)
- Average over year: ~150,000
- Confidence: High (we have current data)

### Events per User per Day
- Estimate: 50 events (based on current feature usage patterns)
- Confidence: Medium (new feature might differ)

### Event Size
- Estimate: 500 bytes (JSON with typical payload)
- Confidence: High (we can measure similar events)

### Days in Year
- Estimate: 365
- Confidence: Certain

### Replication Factor
- Estimate: 3x (standard for durability)
- Confidence: High (architectural requirement)

## Calculation
Storage = 150,000 × 50 × 500 × 365 × 3
        = 150,000 × 50 × 500 × 365 × 3
        = 4.1 × 10^12 bytes
        = 4.1 TB

## Result
- Point estimate: ~4 TB
- Range: 1 TB (pessimistic assumptions) to 15 TB (growth beats expectations)

## Sanity Check
- 4 TB for 150K users = ~27 MB/user/year = reasonable
- Similar feature at other company uses "several TB" = consistent
- Standard database can handle 4 TB = feasible

## Implications
- Standard managed database tier sufficient
- No need for sharding or special storage architecture in Year 1
- Budget ~$500/month for storage costs

示例 2：API 速率容量

问题： 我们的 API 能应对黑色星期五的流量吗？

## Decomposition
Required RPS = Peak Daily Users × Requests/User/Session × Sessions/Day × Peak Multiplier / Seconds in Peak Hour

## Factor Estimates

### Peak Daily Users
- Estimate: 500,000 (3x normal 170K)
- Source: Last year's Black Friday
- Confidence: Medium

### Requests per Session
- Estimate: 30 API calls (measured)
- Confidence: High

### Sessions per Day
- Estimate: 2 (mobile + desktop)
- Confidence: Medium

### Peak Multiplier
- Estimate: 5x (traffic concentrated in 4-hour window, spiky within that)
- Confidence: Medium

### Seconds in Peak Hour
- Estimate: 3,600
- Confidence: Certain

## Calculation
Required RPS = (500,000 × 30 × 2 × 5) / 3,600
             = 150,000,000 / 3,600
             = 41,667 RPS
             ≈ 40,000 RPS peak

## Result
- Point estimate: 40,000 RPS
- Range: 15,000 to 100,000 RPS

## Sanity Check
- Current capacity: 10,000 RPS
- Gap: 4x capacity needed
- Similar scale companies report 20-50K RPS on peak days = consistent

## Implications
- Need 4x capacity increase
- Auto-scaling must handle 40K+ RPS
- Load test to 60K RPS (1.5x safety margin)

示例 3：市场规模

问题： 我们的开发者工具有多少潜在客户？

## Decomposition
TAM = Software Companies × Avg Developers × Adoption Rate × Price Tolerance

## Factor Estimates

### Software Companies (US)
- Estimate: ~500,000 (SBA data: tech companies)
- Confidence: Medium

### With 10+ Developers (our target)
- Estimate: 10% = 50,000 companies
- Confidence: Low (rough estimate)

### Developers per Target Company
- Estimate: 30 average
- Confidence: Medium

### Adoption Rate (would consider)
- Estimate: 20% (dev tools are crowded)
- Confidence: Low

### Price Point
- Estimate: $50/developer/month
- Confidence: Medium (based on similar tools)

## Calculation
Addressable Users = 50,000 × 30 × 20% = 300,000 developers
Revenue = 300,000 × $50 × 12 = $180M/year TAM

## Result
- TAM: ~$180M/year
- Realistic serviceable market: 5-10% = $10-20M/year

## Sanity Check
- Similar dev tools (Datadog, etc.) have $100M+ revenue = plausible ceiling
- 300K potential users in a niche = reasonable

## Implications
- Market size justifies investment if we can capture 5%+
- Need differentiation in crowded space

常见分解模式

容量规划

Needed = Users × Usage/User × Factor/Usage × Growth × Safety

成本估算

Cost = Resources × Unit Cost × Duration × Overhead

时间估算

Time = Tasks × Time/Task × (1 + Risk Factor)

市场规模估算

Market = Population × Segment% × Adoption% × Price × Frequency

改进估算的技巧

使用多种方法

用不同方法估算同一件事：

Website traffic estimate:
Method 1: Bottom-up from user base
Method 2: Top-down from market share
Method 3: Analogy to similar company

If methods agree within 3x, confidence increases
If they diverge wildly, investigate assumptions

先确定范围

从上限和下限开始：

"Definitely more than 1,000, definitely less than 10 million"
"So somewhere in 10,000-1,000,000 range"
"Let me narrow from there..."

注意相关误差

如果各因素之间存在相关性，误差就不会相互抵消：

BAD: Users × Revenue/User (both depend on same growth assumption)
BETTER: Estimate revenue directly, or use independent factors

保留一位有效数字

不要追求虚假的精确度：

Calculation: 47,832,519 bytes
Report: ~50 MB (not "47.8 MB")

验证清单

• 精确陈述问题
• 分解为 3-6 个可估算的因素
• 每个因素都有推理依据或来源
• 各因素相对独立
• 展示并检查计算过程
• 根据实际情况检验结果是否合理
• 说明不确定性范围
• 明确说明对决策的影响

关键问题

• “我能把这个问题拆分成更小、可估算的部分吗？”
• “我已经掌握哪些信息可以限制估算范围？”
• “上限是多少？下限是多少？”
• “这个数字合理吗？”
• “如果误差达到 10 倍，会改变我的决策吗？”
• “我能用另一种方法估算，以便交叉核验吗？”

费米的智慧

有人问芝加哥有多少钢琴调音师时，费米没有查资料，而是根据人口、家庭数量、钢琴数量、调音频率和调音师的工作能力进行估算。据说，他的估算结果与实际数字相差不到 20%。

其中的启示是：你知道的比自己想象的更多。拆解、估算、合并。误差往往会相互抵消，最终结果会出乎意料地接近真相。

“在知道答案之前，绝不要进行计算。”——约翰·惠勒（费米的同事）

含义：先估算，了解预期答案，再通过计算进行验证。