经济与平台型游戏问题模型

Category

industry / models 子树。节点定位：经济与平台型问题模型——与外部世界做可信协作成为主链路，故障形态完全不同。

Definition

有些项目的核心难点并不在战斗本身，而在交易、渠道、支付、广告、社交裂变和外部平台生态。对这类产品来说，技术系统的第一压力来自“与外部世界做可信协作”。一旦这条链路成为增长核心，平台和经济能力就不再是外围集成，而是主链路的一部分。

这类模型最容易被轻视，因为它看上去像“接几个 SDK”“接个支付”。实际上，只要支付、订单、交易市场、广告变现、UGC 分发、平台审核、渠道差异这些能力进入核心业务，系统边界就已经被重塑了。

Problem

交易、渠道、支付、广告、社交裂变成为增长核心后，平台能力不再是外围集成而是主链路；故障形态从「体验坏了」变成「钱和账不可信」。渠道对账、支付状态机、风控合规从接入项升为设计核心。

为什么这类项目的故障形态完全不一样

和强实时项目不同，经济与平台型项目最贵的故障通常不是局内体验，而是：

• 漏单
• 重复发货
• 回调错单
• 奖励错发
• 对账不一致
• 风控失效
• 黑产套利
• 审核或平台规则踩线

这类故障一旦出现，影响的不只是体验，还可能直接触发财务、合规、渠道关系和运营事故。

这类模型真正的主链路是什么

对经济与平台型项目来说，常见主链路通常像这样：

1. 用户通过渠道、平台或外部入口进入产品。
2. 账号、登录、鉴权和身份映射建立上下文。
3. 支付、广告、交易、分享、社交裂变等行为驱动增长或收入。
4. 外部平台回调进入系统，触发订单状态流转和发货。
5. 审计、对账、补偿、风控和合规对整条链路做兜底。

也就是说，系统不只是对玩家负责，还要对平台、财务、风控和审计负责。

技术压力通常会先压在哪

1. 账号与身份

平台型项目很少只有一个“本地账号”。常见现实包括：

• 渠道账号
• 游客账号
• 内部账号
• 第三方登录身份
• 设备身份与风控标识

如果一开始没有把身份映射、绑定、迁移、找回和封禁链路设计清楚，后面几乎一定会出现难以收拾的历史包袱。

2. 订单状态机

所有支付、发货和补偿问题，最终都会回到订单状态机是否清楚。
一个成熟的订单系统至少要回答：

• 订单什么时候创建
• 支付成功以谁为准
• 回调失败如何重试
• 发货失败如何补偿
• 重复回调如何幂等处理
• 订单最终状态如何对账

如果只是“收到回调就发货”，那基本等于在等线上事故。

3. 审计与对账

只要真实货币、广告收益、交易市场或渠道分账进入系统，对账和审计就必须成为正式能力，而不是事后导日志查。
技术系统必须能回答：

• 某笔订单为什么成功
• 某次发货凭什么发生
• 某个玩家为什么多拿了一份奖励
• 某个渠道报表和内部报表为什么不一致

这些能力做不好，系统后面会被大量人工流程拖住。

4. SDK 适配与隔离

很多团队会把 SDK 接入当成工程边角料，实际上这一步决定了系统后面会不会被平台差异绑死。
比较稳妥的做法通常是：

• 用统一适配层隔离渠道和平台差异
• 不让业务逻辑直接依赖 SDK 细节
• 明确哪些能力是平台能力，哪些是内部统一能力

否则一个新渠道进来，整个客户端和服务端边界都可能被拖着走。

5. 风控与合规

当经济链路进入主线，风控和合规也会自然前置。包括但不限于：

• 黑产注册与刷量
• 退款与拒付
• 虚拟交易套利
• 礼包和兑换码滥用
• 广告作弊
• 平台审核和地区合规差异

这些问题如果等产品跑起来再补，代价通常很高。

什么时候这个模型会压过玩法问题

如果产品具备下面这些特征，经济与平台型问题通常会成为主导模型之一：

• 高度依赖渠道、平台或广告变现
• 支付、交易、社交裂变、创作者生态本身就是增长核心
• UGC 内容分发和审核是主路径的一部分
• 联运、SDK、平台规则对版本和功能有直接约束

这时，哪怕玩法本身不复杂，技术边界也不会简单。

常见的系统组织方式

这类项目较稳妥的方式通常是：

• 账号和身份层独立治理
• 支付与订单用统一状态机管理
• 发货和奖励走幂等链路
• 外部平台差异用适配层隔离
• 对账、审计、风控和补偿有清晰闭环

关键不在于用了多少个平台 SDK，而在于内部有没有一套稳定的抽象把它们兜住。

典型失败模式

把平台问题当成上线前收尾

这是最典型的错误。结果通常是：

• 账号模型反复推翻
• 各渠道逻辑散落在业务代码里
• 回调失败只能人工补发
• 对账要靠运营手工导表

只有接入，没有状态机

接了支付接口，却没有完整订单状态流转；接了广告，却没有收益审计；接了交易，却没有风控和补偿。这样的系统短期能跑，长期极脆。

SDK 直接侵入业务

客户端和服务端大量业务逻辑直接依赖某个渠道或平台接口，后面一换平台、加新渠道、改规则，整个系统都要跟着抖。

判断这类模型时，先问哪几个问题

• 没有渠道、支付、广告或平台社交，这个产品还能不能正常成立。
• 最贵的故障是不是漏单、错发、套利和风控失效。
• 外部平台规则是不是直接影响版本节奏和功能形态。
• 对账、审计和补偿是不是必须被正式系统化，而不是人工处理。

如果这些回答大多是“是”，那平台和经济就已经不是外围约束，而是架构主问题。

更接近最佳实践的结论

经济与平台型项目最稳妥的设计，不是“把 SDK 接完”，而是先把外部协作链路做成内部可控系统：

• 账号身份清楚
• 订单状态机清楚
• 发货链路幂等可追踪
• SDK 适配隔离干净
• 对账、补偿、风控和合规是正式能力

这类项目真正难的地方，不在接入动作本身，而在“外部世界不可靠，系统还能不能把结果收回来”。

常见误区

最常见的错误，是把平台问题理解成上线前接 SDK 的收尾工作。实际上，平台能力会反向塑造账号模型、版本节奏和商业化实现。如果这些能力没有被提前设计，后面会不断用临时补丁修系统边界。第二类误区，是只有接口接入，没有订单状态机、审计和补偿闭环。第三类误区，是把所有渠道差异直接散落进业务逻辑，最后任何平台调整都会引发系统级返工。

Used By

平台/交易型项目的架构评估；支付对账与风控链路设计。

Related

关系链：外部协作 → 主链路 → 压力点 → 组织方式 → 失败模式。上游：models/01。下游：industry/platforms（平台与 SDK）、database 树（账务一致性）。

Reference

本页为工程经验归纳。