这页的用途

Category

design / problem-domains 子树。节点定位：问题域速查的使用说明——什么时候翻、对照哪些维度、与主线和类型专题的分工、归型顺序。

Definition

这一页说明这组问题域附录该怎么用、和哪些内容分工。前面几篇分别归纳了一类项目的关键判断，这一篇回答更实际的问题：什么时候翻这组附录，翻到之后怎么对照，对照完又该回到哪里去。

一句话画像：这组附录是横向速查表，不是架构答案。它把主线推导出的结论按问题域压成一页一页的对照，适合在理解成因之后，用最快的速度定位“这类项目的钱和险大概在哪里”。

Problem

速查页被当架构答案抄是唯一的误用：它压缩的是判断结论不是推导过程。正确路径是先归型（六问）、再对照速查、最后回到主线篇目看推导。

这组附录回答什么问题

按问题域聚类回答的是一类很具体的提问：几个候选方向摆在一起，哪一个更贴合这个项目的主导矛盾。

• 它给的是同类项目的共性判断：这类项目通常把复杂度压在哪个环节，特有风险通常从哪里长出来。
• 它给的是比较的尺度：状态共享方式、时间推进方式、资产复杂度、运营强度，四个维度固定下来，比较才不会各说各话。
• 它给的是常见坑的清单：这些坑在同类项目里反复出现，评审时逐条对照，往往能提前拦下一部分。
• 它给的是归型语言：房间型、对战型、世界型、成长型、平台型，让团队讨论“我们像哪一类”时有共同的词。
• 它给的是提问的起点：每篇结尾的概括句就是为对照之后准备的，指出该带着哪些问题回主线。

它不回答“为什么”，因果推导留给主线；它也不回答“具体怎么做”，参数与实现细节留给各工程篇目。

对照时看哪几个维度

各篇速查内容反复出现的比较维度有四个，评审时逐项过一遍，往往比自由讨论更有效。

• 状态共享：关键状态在哪里闭合，跨了多少边界，谁有最终解释权。
• 时间推进：按帧、按事件还是按事务推进，对时间误差的容忍度是毫秒级还是天级。
• 资产复杂度：资产种类、发放入口、经济闭环的数量，决定了审计与对账的负担。
• 运营强度：活动、补偿、版本、回档的频率，决定了配置链路与数据链路要扛多少变更。

维度固定下来之后，两个项目的比较才是同尺度的，否则讨论容易滑回“我们不一样”的感受之争。

与主线篇目的分工

主线按因果展开，一个问题从成因推导到方案与代价；这组附录按横向聚类展开，把不同项目的结论压在速查表里。两种组织方式服务的时刻不同。

• 第一次学习某个机制，或者为具体系统做设计时，通常走主线，因为方案要用得对，得先理解它为什么长成这样。
• 方案评审、项目盘点、技术分享时，通常翻这组附录，因为这些场合要的是快速对照，不是完整推导。
• 复盘线上事故时，两边往往配合使用：先用附录定位“这像哪一类项目的历史坑”，再回主线找对应机制的推导与细节。
• 新人建立直觉时，附录往往更友好，先知道“这类项目难在哪”，再进主线理解“为什么难”，学习曲线更平。

用附录替代主线，结论会失去解释力；用主线替代附录，讨论会失去效率。常见做法是把附录当成主线结论的索引，而不是主线的摘要替代品。

归型语言与主线六个问题模型的对应也值得交代。五个问题域里，房间型、对战型、世界型、成长型与主线同名模型一一呼应，平台型对应经济与平台模型。唯一收拢的是主线的高频对象与重表现模型：它关心的对象吞吐与表现密度，在真实项目里很少单独主导架构，通常附着在世界型的密集对象场景或对战型的大规模同屏场景里；而它另一半的热点读写压力，与经济与平台的交易安全在项目里往往一起治理，于是归型时并入平台型，不单设一型。模型允许交叉，是分析工具；问题域是归类标签，要求能指导排期。两边对不上时，通常以模型分析为准重新归型。

与游戏类型附录的分工

书里另有一组姊妹附录，按游戏类型聚类（附录 A1 游戏类型专题），和这一组是两套镜头：一组按品类说话，一组按问题域说话，看的是同一批项目。

• 品类视角更贴近团队日常沟通，适合和策划、制作人、发行对齐，回答“这是个什么游戏”。
• 问题域视角更贴近架构判断，适合在技术方案里使用，回答“主导矛盾属于哪一类，约束从哪里来”。
• 两个标签经常不一致：一个看起来像休闲品类的产品，可能因为玩家之间高频交易，实际落在经济平台型的问题域里。
• 品类附录擅长建立直觉、组织跨职能讨论；问题域附录擅长确定架构基调、圈定风险面。
• 常见做法是先用品类标签组织讨论，再用问题域判断确定架构方向，两者对不上时，以问题域为准。

同一批项目在两套镜头下会得到两份不同的速查结论，这并不矛盾：品类结论回答玩家和同事的提问，问题域结论回答架构评审的提问，混用两份结论反而是最常见的误用来源。

品类不是架构结论，问题域也不是。它们各自提供的是一组先验，真正的形态仍要由具体项目的约束推导出来。

怎么给项目归型

归型是使用这组附录的第一步，也是最容易走偏的一步。常见做法是看行为与代价，而不是看宣传页上的类型标签。

• 看状态：状态以局为单位生灭，是房间型；以账号为单位沉淀，是成长型；以世界为单位常驻，是世界型。
• 看时间：毫秒级敏感是对战型，分钟与小时级是房间型，天与年级是成长型。
• 看钱的流向：资产在玩家与系统之间往来，是成长型；在玩家之间大量互转，是平台型。
• 看运营强度：活动、补偿、回档的频率超过玩法迭代时，运营链路就是主导矛盾。
• 看故障形态：历史上最疼的几次事故集中在哪里，往往比任何画像都更诚实地指出主导矛盾。

归型的结果应该是“主导矛盾是什么”，而不是“我们是某某游戏”。前者能推导约束，后者只能推导期待。

推荐的使用顺序

一个项目从接触到定案，这组附录比较自然的介入位置有三个。

• 立项盘点时，先用一句话画像给项目归型，确认主导矛盾落在哪一类，避免把世界型项目按房间型排期。
• 方案评审时，把同类项目的约束与坑逐条对照当前方案，重点看评审对象是否为特有风险准备了答案。
• 项目复盘时，用附录反问：这个项目遇到的大事故落在哪一类的哪个坑里，当初的归型判断错在哪里。
• 组队与招聘时，归型也能提示团队短板，成长型缺数据与审计经验、平台型缺风控与交易经验，都是常见的组合缺口。

多数项目不是单一类型。一个产品可以同时有房间战斗、长期养成和玩家交易，常见做法是按主导矛盾确定基调，再按次级问题域逐块对照，而不是勉强塞进一个标签。

对照的对象也不限于完整项目。一个公会系统、一套交易行、一个活动编排器，都可以单独拿出来归型，判断它更像哪一类的哪一块，再用对应篇目列出的约束与坑去校验设计。

这组附录不擅长什么

横向聚类的代价是失去推导，有些问题这组附录刻意不回答。

• 它不解释机制为什么这样设计，跳过主线直接套速查结论，方案往往流于表面。
• 它不给出参数、配额和实现细节，这些随项目规模和团队差异极大，速查表给不了。
• 它不处理跨类型的混合判断，混合项目的难点恰恰在类型交界处，速查表只能提示交界在哪里。
• 它不替代对具体项目的度量，容量、一致性和成本的结论最终来自本项目的数据，不是来自分类。
• 它不是验收标准，速查结论对上了不代表设计对了，只代表方向没有明显跑偏。

另一个常见误会，是把这组附录当成入门读物。它假设读者已经见过这些机制的推导，只带着问题回来对照；完全没接触过的读者，更适合先读主线再回来。

如果发现自己只引用了附录的结论而说不出原因，通常是一个信号：该回主线补推导了。

常见误用

• 把附录当检查清单逐条打勾，以为对照过就是设计过，实际上每一条结论都需要在当前项目里重新验证。
• 拿一句话画像给项目贴标签，然后用标签代替讨论，主导矛盾没确认，方案方向就整体跑偏。
• 用品类标签否定问题域判断，或者反过来，两个镜头争高下，忘了它们回答的是不同的提问。
• 只在出事后才翻附录，复盘变成对号入座，而不是把归型判断提前到立项与评审。
• 把五类问题域当成互斥选项，为了归型砍掉真实的次级矛盾，混合项目被硬裁成单一类型。

这组附录最适合做三件事：快速归型、组织对照、沉淀同类项目的经验。它最不适合做的一件事，是替代针对具体项目的推导与度量。

Used By

问题域速查的阅读路径指引。

Related

关系链：回答什么 → 对照维度 → 与主线分工 → 与类型专题分工 → 归型与顺序 → 不擅长什么。上游：problem-domains/01–05。下游：industry/models/01（六问分型）、industry/genres/06（类型专题用法）。

Reference

本页为工程经验归纳。