# 博弈逆向法：从功能反推需求、矛盾与格局

> 一套学习软件系统的方法论。核心假设：**一个功能的形态不是最优设计的产物，而是多方博弈在某个时点的均衡态**。系统当前的样子 = 初始约束 + 一连串外部冲击 + 每次冲击后各方的重新议价。
>
> 学习系统 = 把这个过程逆着放一遍。

---

## 0. 适用范围与失效边界

**适用**：有多个利益主体、且这些主体的收益相互影响的地方。用户、付费方、供给侧、平台、监管、竞品、滥用者、内部团队，都是 player。

**失效**：纯技术权衡（CAP、性能 vs 复杂度、内存 vs 吞吐）。这些是约束满足问题，没有对立的利益主体，硬套博弈框架会得出漂亮但错误的结论。识别方法——问"谁因此受损"，如果答案是"没人，只是物理限制"，换个框架。

**最大风险**：**事后叙事**。任何时间线，只要允许自由引入外部事件，都能编出通顺的因果故事。本方法论的一半篇幅都在处理这件事（见第 3 节）。

---

## 1. 核心提问集

对任何一个功能，依次问：

| # | 问题 | 指向 |
|---|------|------|
| 1 | 它**限制**了谁？ | 被压制的一方 |
| 2 | 它给了谁**权力**、撤走了谁的权力？ | 权力再分配 |
| 3 | 谁**买单**、谁**受益**？两者是同一个人吗？ | 付费方 vs 使用方错位 |
| 4 | **如果删掉它，谁会立刻开始占便宜？** | 最锋利的一问 |
| 5 | 它的**默认值**偏向谁？ | 谁赢了那场争论 |
| 6 | 它**不做**什么？刻意留下的空白是给谁的？ | 未言明的妥协 |
| 7 | 它是**对抗性**的吗（对手会适应）？ | 决定规则是否透明 |

第 4 问的用法：审批流、配额、冷却期、审计日志、限频——这类"让人不爽"的功能几乎必然对应一个真实存在的、正在占便宜的人。找到那个人，就找到了需求。

第 7 问的用法：非对抗场景下规则应当透明（文档写清楚）；一旦对手会适应，规则必须模糊——限频阈值不公开、灰度不解释、影子封禁不通知。**看到"故意不说清楚"的设计，基本可以断定存在对抗性 player。**

---

## 2. 常见的结构性矛盾（假设生成器）

拿到陌生系统时，先用这张表快速生成一批候选假设，再去验证。

- **增长 vs 风控**：注册/下单要短，但要拦住黑产。表现为渐进式验证、风险分级
- **使用者 vs 采购者**（B 端最典型）：买单的是老板，用的是员工 → 大量员工讨厌但必须有的管控、报表、审计功能
- **平台 vs 供给方**：抽成率、流量分配、排序权、是否允许绕过平台成交
- **体验 vs 变现**：付费墙的位置就是这条线的坐标
- **平台 vs 滥用者**：唯一真正对抗性的一类，决定了规则的不透明
- **新用户 vs 老用户**：迁移成本、兼容层、"经典模式"开关
- **内部团队之间**（康威定律）：并行的两套模型、命名混乱、职责重叠的接口
- **当下 vs 退出成本**：数据导出能力的强弱，反映了平台对锁定的态度

---

## 3. 证据分级与可证伪性

### 3.1 内部证据的可靠性排序

从高到低：

1. **当年吵架的现场** —— PR/issue 里的反对意见、RFC 下的争论、邮件列表、当时的社区讨论串
2. RFC / 设计文档 / ADR
3. commit message、代码注释里的 `// 因为 XX 才这么写`
4. release note / changelog
5. 官方博客
6. 媒体报道
7. **多年后的创始人访谈** —— 已被重新叙事，因果常被事后合理化，只能当线索不能当证据

> 原则：**优先找异议，而不是找结论**。反对者陈述的理由，通常比发布公告更准确地描述了当时的真实约束。

### 3.2 代码与产品中的"化石"

这些痕迹几乎必然是冲突留下的：

- **配置开关的密度** —— 开关越多说明当年争得越凶（"两边都要，谁也说服不了谁，那就做成可配置"）；**默认值暴露了谁赢了**
- **字段冗余** —— 同时存 `created_by` 和 `operator`，说明存在代人操作且发生过责任归属争议
- **白名单 / 硬编码例外** —— 大客户议价权的直接证据
- **不对称的信息设计** —— 如双盲评价（双方提交后才公开），是为消灭报复性评价的机制设计
- **命名与措辞的变更** —— 代码没动、只改了文案和默认值，往往是法务介入的签名
- **deprecated 但迟迟不删的接口** —— 存在无法得罪的依赖方

### 3.3 三个证伪手法

**① 前后顺序检验**
外部事件 → 内部变化之间应有符合组织反应速度的滞后（通常数周到数个季度）。
若内部改动**早于**外部事件：要么因果反了，要么两者有共同前因。此条淘汰假设最有效率。

**② 对照组检验**
同期未受该冲击的竞品做了同样的事吗？
- 做了 → 更可能是行业时尚或共同前因，不是这个冲击
- 受冲击程度不同的产品，出现了程度不同的反应 → 强证据

**③ 没叫的狗（幸存者偏差校正）**
只看 shipped 的功能会严重偏斜。真正高信息密度的是：
- 被否掉的 RFC / 被关掉的 PR
- 砍掉的功能、废弃的分支
- 长期开着没人做的 issue

这些是**输掉的一方**留下的痕迹。一个提案被否的理由，常比十篇发布博客更能说明当时的约束。

---

## 4. 外部冲击清单（联网搜索的检索方向）

按对软件形态的改造力排序。每一类都应带**具体时点**，用于与内部时间线对齐。

| 类别 | 特征 | 典型例 |
|------|------|--------|
| **监管** | 有明确生效日，最好对齐 | GDPR、反垄断判决、数据出境、行业牌照 |
| **平台方政策** | 单方面、不可谈判、影响整条生态 | Apple ATT (2021) 重构广告技术栈；App Store 抽成；Twitter / Reddit API 收费 (2023) 灭掉一代第三方客户端 |
| **上游许可证变更** | 下游会突然长出抽象层 | Redis / Elastic / HashiCorp → OpenTofu 等分叉 |
| **资本周期** | 从增长转盈利 | 加息后：免费额度收缩、提价、砍长尾功能 |
| **技术可得性突变** | 一批原本不成立的功能同时出现 | 某能力突然变便宜（如 LLM） |
| **安全事故** | 解释"突然变严格"的地方 | 数据泄露、供应链攻击、大规模滥用事件 |
| **竞品进入 / 退出** | 解释功能对齐与差异化 | 新 player 入场、免费替代品出现 |
| **人事与并购** | 模块风格突变 ≈ 某个人走了 | 核心维护者离职、被收购后战略换向 |

---

## 5. 执行流程

### Step 1 · 圈定范围
选一个具体功能或模块，不要一上来分析整个产品。

### Step 2 · 生成假设（廉价）
用第 1 节提问集 + 第 2 节矛盾表，快速列出 5–10 条候选解释。此阶段不求准，求覆盖面。

### Step 3 · 拉内部时间线
按时间排：changelog、release note、重大 commit、RFC、issue 讨论。标出**形态发生质变**的节点（不是小修补，是设计换向的那几次）。

### Step 4 · 拉外部时间线
针对每个质变节点，向前推 1–6 个月，用第 4 节清单搜索该窗口内发生了什么。

### Step 5 · 对齐与证伪
用 3.3 的三个手法逐条淘汰假设。淘汰不掉的留下，并标注置信度。

### Step 6 · 找"没叫的狗"
补查被砍掉的、被否掉的、被废弃的东西。这一步经常会推翻前面的结论。

### Step 7 · 识别地层
把留下的解释按轮次排列成"机制 → 反制 → 反反制"，见第 6 节。

### Step 8 · 输出与留白
明确写出：哪些是有证据的，哪些是推测，哪些**至今无法解释**。第三类必须保留，它是下次修正的入口。

---

## 6. 地层：多轮博弈的堆积

成熟系统的功能不是一次设计的结果，而是多轮攻防的**地层**。识别地层比识别单个功能重要。

典型序列：

```
无理由退货（解决买方信息劣势）
   ↓ 出现职业退货人
买家风险画像 / 退货次数限制（反制）
   ↓ 误伤正常用户，投诉与舆情
申诉通道 + 人工复核（反反制）
   ↓ 人工成本不可承受
分级自动化 + 高价值订单才进人工（成本再平衡）
```

三到四层功能，三到四轮攻防，跨越数年。若只看当前形态，会误以为这是一次性设计的"风控体系"。

**判据**：如果一个模块里的规则彼此打补丁、存在"例外的例外"，几乎必然是多轮堆积，不是一次设计。

---

## 7. 输出模板

```markdown
## 功能：<名称>

### 当前形态
（客观描述，不带解释）

### 涉及的 player
- 主张方：
- 被限制方：
- 买单方：
- 沉默的一方（不在界面上但有影响力）：

### 核心矛盾假设
1. <假设>｜置信度 高/中/低｜证据：
2. ...

### 时间线对齐
| 时间 | 内部变化 | 同期外部事件 | 滞后 | 判断 |
|------|---------|-------------|------|------|

### 对照组
| 竞品 | 同期是否有同样变化 | 说明什么 |

### 没叫的狗
- 被否掉的方案：
- 砍掉/废弃的功能：
- 它们说明的约束：

### 地层
第 1 层（时间/机制）→ 第 2 层（反制）→ 第 3 层（…）

### 已排除的假设
（写明为什么排除，避免下次重复推演）

### 尚无法解释的部分
（必须保留）
```

---

## 8. 自检清单

用完这套方法后，逐条检查：

- [ ] 我的解释是可证伪的吗？能说出"看到什么就说明我错了"吗
- [ ] 有没有把纯技术权衡硬套成利益冲突
- [ ] 时间顺序对得上吗（内部变化没有早于外部事件）
- [ ] 查过对照组吗
- [ ] 查过被砍掉/被否掉的东西吗
- [ ] 主要证据来自"当年的争论"还是"事后的总结"
- [ ] 有没有为了故事完整而强行填补空白
- [ ] 是否保留了"无法解释"的部分

---

## 9. 一句话总结

> 猜想廉价，验证才是功夫。
> 博弈框架的价值不在于给出答案，而在于**快速生成大量可检验的猜想**，然后靠时间线对齐、对照组和"没叫的狗"把它们中的大多数淘汰掉。
> 剩下的那几条，才是这个系统真正的历史。