模型之间如何组合

Category

industry / models 子树。节点定位：组合关系的核心是主次不是加法——识别主导模型、常见组合场景、分阶段建设与可直接复用的判断模板。

Definition

真实项目几乎从来不是单一模型。一个产品可能局内是强实时对战，局外是长周期成长，还叠加支付和平台约束；另一个产品可能底层是持续在线世界，但部分玩法又是房间化实例。理解这一点很重要，因为架构最常见的失败，不是复杂度不够，而是复杂度没有主次。

这一页要解决的问题不是“项目会不会同时属于多个模型”，而是：同时命中多个模型时，谁决定主链路，谁只构成次级约束。

Problem

真实项目几乎都是多模型组合（局内强实时 + 局外长成长 + 支付平台），最常见的失败不是复杂度不够而是没有主次：每个子系统按自己的主导矛盾建，边界与阶段失配，互相拖累。

组合关系的核心不是加法，而是主次

判断组合模型时，最危险的做法有两种：

• 只给项目贴一个标签，忽略其他模型迟早会反咬主链路。
• 看到项目很复杂，就把所有模型都按最高标准一起建设。

前者会漏关键约束，后者会把系统做成过重的全能架构。更现实的做法是先分清三件事：

• 哪个模型决定玩家最先感知的核心体验。
• 哪个模型决定最贵、最难回滚的故障。
• 哪个模型只是长期会持续施压，但暂时不该主导第一阶段成本。

怎样识别主导模型

判断主导模型时，最有效的是看下面三个维度。

1. 玩家最先因为什么流失

如果玩家首先因为不同步、误判、输入延迟流失，主导模型更接近强实时；如果首先因为开不了局、掉线回不去、结算异常流失，主导模型更接近房间型；如果首先因为活动节奏、养成积累和资源分配失衡流失，主导模型更接近长周期成长型。

玩家最先感知的问题，通常就是最不该被外围系统绑架的问题。

2. 最贵的故障发生在哪里

技术上最该优先防的，是发生后代价最高、恢复最困难的故障。

• 一次判定争议很贵，主导模型更靠近强实时。
• 一次场景迁移或世界状态损坏很贵，主导模型更靠近持续在线世界。
• 一次资产错发、活动事故或回档很贵，主导模型更靠近长周期成长。
• 一次漏单、重复发货或风控失效很贵，主导模型更靠近平台与经济。

3. 团队大部分研发时间花在哪里

这是最诚实的一项指标。如果大部分时间花在同步、战斗、技能与回放上，主导模型往往是强实时；如果主要花在活动、配置、资产链和补偿修复上，主导模型往往是长周期成长；如果主要花在分区、迁移、跨服和运维编排上，主导模型往往是持续在线世界。

常见组合场景

房间对战 + 长线成长

这类组合很常见。通常做法是：

• 局内按房间型或强实时型组织，先把开局、重连、托管、结算做稳。
• 局外成长系统单独承接长期资产和活动。
• 不让成长系统直接绑死房间生命周期。

如果先把成长中台做得极重，却没把房间主链路做稳，玩家通常不会给系统第二次机会。

强实时战斗 + 高频对象与重表现

MOBA、动作对抗、部分射击和 ARPG 很容易命中这个组合。这里不能只谈同步，也不能只谈端上优化，因为：

• 同步、裁决和回放决定公平性。
• 对象预算、资源预算和表现预算决定系统能否随着内容增长继续活下去。

这类项目通常需要承认两条主线同时成立，但仍然要区分主导体验与次级约束。

持续在线世界 + 长周期成长

这是 MMO、SLG 和大世界在线项目常见的组合。它们往往两个都重，但依然要分先后：

• 如果迁移、分区、跨服、合服和运维编排更危险，世界模型优先。
• 如果活动、赛季、资产和商业化链路更容易出事故，成长模型优先。

关键不是选一个抛弃另一个，而是决定第一阶段主链路先围绕谁稳定下来。

平台型 + 任意玩法型

只要项目高度依赖渠道、支付、广告、社交裂变或 UGC 生态，平台模型就会作为主级或次级模型叠加进来。最大的错误，是把它理解成“最后接 SDK 就行”的收尾工作。

组合模型下怎样划边界

模型一旦组合，边界就必须更硬。比较稳的做法通常是：

• 主导模型决定主链路和核心服务组织方式。
• 次级模型通过数据契约、状态边界和扩展接口进入系统。
• 不同模型之间尽量通过明确交互，而不是互相侵入。

这意味着：

• 房间或战斗进程不应直接承担长期资产修改。
• 长期资产系统不应直接依赖局内临时内存状态。
• 支付与平台链路不应侵入实时战斗推进路径。
• 纯表现对象不应默认进入最昂贵的权威同步路径。

组合越复杂，越不能靠“先混着做，后面再拆”。

分阶段建设比一步到位更现实

组合型项目尤其需要控制第一阶段复杂度。比较现实的顺序通常是：

1. 先围绕主导模型把最贵的主链路做稳。
2. 再补上次级模型里最容易反噬主链路的部分。
3. 最后才为远期场景建设平台化和通用化能力。

这样做的目的，不是偷工减料，而是避免在产品方向尚未稳定时，先把系统复杂度做满。

一个可直接复用的判断模板

遇到组合型项目时，可以要求团队用一句完整的话说清楚：

主导模型是 X，因为核心体验和最贵故障主要落在 A、B、C；次级模型是 Y 和 Z，因为它们会持续约束 D、E、F；所以第一阶段先做 G、H、I，不提前为 J、K、L 付最高成本。

这句话如果说不出来，通常说明模型组合关系还没理清。

常见误区

• 把多个模型简单相加，做成一个谁都不够强的全能架构。
• 主导模型判断错误，把大量成本砸在不是主链路的系统上。
• 只承认主导模型，完全忽视次级模型迟早会反噬主链路。
• 阶段划分不清，一开始就为所有远期能力支付最高复杂度。

模型组合的意义，不是证明项目“很复杂”，而是帮助团队在复杂度里分清先后顺序和边界责任。

Used By

混合品类项目的架构评审；分阶段建设路线制定。

Related

关系链：组合 → 主导模型识别 → 组合场景 → 边界划分 → 分阶段。上游：models/02–07（六模型）。下游：production/retro/02（模式对照）、genres/06（专题使用法）。

Reference

本页为工程经验归纳。