10 KiB
博弈逆向法：从功能反推需求、矛盾与格局
一套学习软件系统的方法论。核心假设：一个功能的形态不是最优设计的产物，而是多方博弈在某个时点的均衡态。系统当前的样子 = 初始约束 + 一连串外部冲击 + 每次冲击后各方的重新议价。
学习系统 = 把这个过程逆着放一遍。
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 内部证据的可靠性排序
从高到低：
- 当年吵架的现场 —— PR/issue 里的反对意见、RFC 下的争论、邮件列表、当时的社区讨论串
- RFC / 设计文档 / ADR
- commit message、代码注释里的
// 因为 XX 才这么写 - release note / changelog
- 官方博客
- 媒体报道
- 多年后的创始人访谈 —— 已被重新叙事，因果常被事后合理化，只能当线索不能当证据
原则：优先找异议，而不是找结论。反对者陈述的理由，通常比发布公告更准确地描述了当时的真实约束。
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. 输出模板
## 功能：<名称>
### 当前形态
（客观描述，不带解释）
### 涉及的 player
- 主张方：
- 被限制方：
- 买单方：
- 沉默的一方（不在界面上但有影响力）：
### 核心矛盾假设
1. <假设>｜置信度 高/中/低｜证据：
2. ...
### 时间线对齐
| 时间 | 内部变化 | 同期外部事件 | 滞后 | 判断 |
|------|---------|-------------|------|------|
### 对照组
| 竞品 | 同期是否有同样变化 | 说明什么 |
### 没叫的狗
- 被否掉的方案：
- 砍掉/废弃的功能：
- 它们说明的约束：
### 地层
第 1 层（时间/机制）→ 第 2 层（反制）→ 第 3 层（…）
### 已排除的假设
（写明为什么排除，避免下次重复推演）
### 尚无法解释的部分
（必须保留）
8. 自检清单
用完这套方法后，逐条检查：
- 我的解释是可证伪的吗？能说出"看到什么就说明我错了"吗
- 有没有把纯技术权衡硬套成利益冲突
- 时间顺序对得上吗（内部变化没有早于外部事件）
- 查过对照组吗
- 查过被砍掉/被否掉的东西吗
- 主要证据来自"当年的争论"还是"事后的总结"
- 有没有为了故事完整而强行填补空白
- 是否保留了"无法解释"的部分
9. 一句话总结
猜想廉价，验证才是功夫。 博弈框架的价值不在于给出答案，而在于快速生成大量可检验的猜想，然后靠时间线对齐、对照组和"没叫的狗"把它们中的大多数淘汰掉。 剩下的那几条，才是这个系统真正的历史。