作者 vivo 互联网产品团队- Wang Yuxi本文探索不改排序补上排序之后的“表达与决策”——把游戏理解透让同类多款可比较、可解释、可追溯。做法是让大模型放开探索、用工程约束收住使生成稳定进生产。目标不是替代排序而是帮用户从“给结果”走向“帮决策”。1分钟看图掌握核心要点推荐系统擅长回答“推什么”用户却卡在“怎么选”。排序已经够准了可用户还是不知道选哪个做游戏分发时有几类场景反复出现。最典型的一类是用户打开页面同时看到几款游戏排序已经把最可能被点的那款放在最前面但用户没点他在犹豫——这几个看着差不多到底有啥区别哪个适合我该先玩哪个还有一类更隐蔽很多用户是拿自己玩过的游戏当锚去找相似的。搜一款玩过的游戏最后却点开了结果里的别款或者进到这款游戏专门去翻它的相关推荐。他要的其实不是这款而是像它、又有点不一样的下一款——可到底差在哪、哪个更对路同样得他自己看明白。这两类用户的状态其实相反前一类是被几个选项卡住、迟迟选不动后一类恰恰是带着明确的锚在主动找下一款。但他们卡在同一个地方——都得先看懂这几款到底差在哪、哪个对自己的路才愿意去尝试。排序解决的是“推什么”它并不负责让用户看懂差异而当候选池越收越窄再优化排序的边际收益也越来越小。真正没被接住的那一步不是“推得准不准”是“看懂差异、把选择走完”。而游戏这个场景决策成本天然比内容、短视频高刷短视频不喜欢划走就是几乎零成本下载一款游戏玩进去却要搭进时间、可能付费、甚至在里面交朋友。投入越重选错的代价越大用户在点下去之前就越需要先看懂“这是不是我要的”。可解释性和表达在游戏推荐里不是锦上添花而是决策的一部分。这篇文章想分享的是我们围绕“帮用户走完最后一步”做的探索——确切说是这条链路里游戏这一端的理解与表达另一端是把用户读懂本文不做展开。一、为什么是“游戏理解与表达”把用户带到门口剩下的就是让他看懂——而这件事推荐系统长期是缺位的。它很擅长算“你大概率喜欢 A”却不太回答“A 凭什么值得你喜欢”“A 和旁边的 B 差在哪”“你这种玩家该从哪个入门”。可解释性和表达一直没被当成一个正经能力来建——它们维护成本高、短期不像优化排序那样能直接拉指标优先级自然靠后。大模型的出现让这件性价比一直不高的事第一次有了能落地的做法。所以我们想试一次不重做推荐系统而是在排序给完答案之后补上“讲清楚这一段。而要把一款游戏讲清楚前提是先真正理解它。如果连游戏本身都没被理解透“为什么推它”“它和那个差在哪”全是空话。所以这一系列探索真正的起点不是表达而是游戏理解。二、已经有标签体系了为什么还要再做一套这是一开始就必须回答的问题。游戏分发本来就有一套相当成熟的分类和标签体系——玩法机制、题材世界观、战斗模式、节奏强度这些维度早就有人在维护。再做一套游戏理解凭什么答案只有一个新体系必须产出旧体系给不了的信息增量否则就是为做而做。 这条是设计之初定的底线也是判断每一个新维度该不该存在的唯一标准。那旧体系缺什么它很擅长回答“这是什么”却回答不了“玩家为什么玩、为什么付费”。而后者恰恰是帮用户做决定时最关键的信息。以一款捕鱼游戏为例。旧的内容标签能告诉你的大致是捕鱼类 · PVE对环境· 模拟 · 轻度松弛准确但对“该不该推给这个用户”几乎没有帮助。而我们想补的增量是这两层——游戏动机玩家到底为什么玩、为什么付费付费机制它靠什么结构与体系承载用户付费付费模式概率付费主要付费点常规抽卡/转盘 · 体力购买付费复杂度中到这一层这款游戏就不再只是“一款捕鱼”而是“一款靠快节奏爽感和解压留人、用概率抽奖驱动付费的轻度游戏”。这句话才是旧标签给不了、又真正能用于推荐决策的信息。这就是我们说的增量——不是把旧标签换个说法重打一遍而是补上一整层旧体系结构性缺失的理解。那这些值得存在的维度是怎么定出来的确认了要补动机和付费这两层新问题随之而来动机有那么多说法哪些维度值得进 schema、哪些是噪声这里没有一上来就拍一套体系让模型去标而是先用大模型最擅长的事——见得多、覆盖广——去探索而不是执行。让多个模型从各种角度去拆游戏玩家为什么持续玩、爽感从哪来、成长循环怎么转、付费被什么驱动。这一步要的不是标准答案而是尽可能多的惊喜和边界。它确实给了惊喜也很快暴露了边界同一款游戏会被标成“Roguelike”“Rogue-lite”“随机地下城”意思相近却无法归一标签一失控游戏之间就没法比。这一步不是失败它验证了一个判断自由生成是大模型的能力上限稳定输出得靠约束。于是分工很清楚——探索交给模型收敛和立规矩由人来做。把探索里反复出现、真正能解释差异的维度挑出来定成闭集 schema再让模型在体系内做填空。挑维度的标准卡得很死必须同时可解释、可比较、可复用、有决策价值。成长驱动、刷宝驱动、爽感刺激这类留下世界观、美术风格这类砍掉——不是它们不存在而是在帮用户做选择这件事上区分力太弱。整个过程不是“先定体系、再让 AI 执行”而是模型放开探索 → 撞出边界 → 验证哪些维度真有用 → 收敛成 schema → 规模化生产一句话概括大模型负责发现空间人负责收敛空间。这样产出的体系每一个维度都对得起信息增量这条底线。最后补一层工程兜底模型输出天生不稳我们在 API 层加了 normalize——缺字段回落默认值、类型强制收敛、不在 schema 内的脏值过滤。对下游来说模型的原始输出不算接口normalize 之后的稳定 schema 才算接口。三、再往深一层大模型到底能把一款游戏理解到什么程度标签解决的是“是什么”但我更想探一探另一件事大模型对一款游戏底层逻辑、也就是“本质”的理解上限到底在哪所以这一节更像一次探索而不是一个准备直接上线的功能。判断“够不够深”有个很朴素的标准哪怕是一个并不重度玩游戏、原本对这款游戏不了解的人读完也能清楚感受到“玩家在这个游戏里到底在做什么、获得了什么”——那这份理解大概就到位了。拿《逆水寒》举例。只丢“MMO、开放世界、古风武侠”给你没用。而按一套固定的解读结构往下钻它会一层层展开。最上面是一张几秒就能判断“要不要玩”的极速判断卡快速标签沉浸武侠 · 社交身份 · 慢节奏风险 · 生活密度 ⚡ 极速判断卡 类型直觉重内容武侠 MMO更像线上江湖生活 爽点直觉沉浸 / 在场感 社交归属 生活密度 主要风险慢 / 重不爱社交会觉得琐碎 一句话定调想长期生活在武侠世界很可能适合只图即时战斗爽大概不是你的菜。往下结构会强制它逐层回答几个固定问题每一层都把模糊的“好玩”拆成可判断的东西它靠什么留人核心卖点武侠在场感被世界回应的存在感、生活密度不必一直赶进度的松弛日常、强社交与身份被看见、被记住、被需要。区别于同类的点在于它不是刷数值的壳社交也不是工具组队而是关系型的。玩家一天到底在干嘛三条链并行——副本战斗配技能走位打配合、身份生活钓鱼采集经营奇遇、社交维护组队帮会固定圈子分别对应“赢”“过日子”“我属于哪儿”。好不好玩取决于哪几件事体验开关社交密度、节奏容忍度、沉浸需求。每个开关拉满或拉低直接决定“谁爱死、谁流失”——社交型 / 慢节奏友好 / 沉浸党上头独狼 / 效率党 / 功利党则相反。这层“哪几个开关决定爱或走”也正是下一章多游对比里“哪几维该抢上卡片”的来处。后期在追什么长期驱动力社交关系 身份经营 内容推进。玩家再登录多半是为了维系关系和位置不是战力数字——这直接决定了它的留存逻辑和别的 MMO 不一样。最后落一句决策句最看重【武侠沉浸 社交归属 生活密度】大概率适合你受不了【慢节奏 强社交】那它大概率不对路。这里要说清两点。第一这份解读不是模型自由发挥出来的而是按一套预先设计好的分区结构逼出来的——固定它从哪些角度看、每个角度必须回答什么。理解能钻多深取决于喂给它的结构。第二这一节探的是“上限”——但上限不等于能直接用这么长、这么重用户要的是决策不是一篇游戏论文。从“模型能钻多深”到“用户用得上”中间隔着一个人的取舍——留什么、砍什么、压成什么形态。这一步不是模型自己能完成的它恰恰是下一节多游对比要解决的事模型负责钻得深、生成得多人负责判断哪种表达值得固化下来。四、多游对比从“一次能跑”到”稳定生产”游戏标签和深度理解都还停在单款游戏上。但用户很少孤立地看一款——他打开页面时心里往往已经有个熟悉的游戏当 benchmark或者面前同时摆着好几个看着很像的结果。这种时候帮得上忙的不是再多推一个而是把这几款之间的差异提炼出来让他据此做决定。还是开头那三款。它们的类型标签其实是分开的——Roguelike、RPG、弹幕射击——可再往下看玩法刷关、随机构筑、成长、装备、Build 高度重叠上手却是三种完全不同的手感。用户卡的正是这层错位类型看着被区分好了真正决定玩不玩得下去的体验差异却没人替他说清。最初做得很轻不搭 pipeline、不拆多步直接把三款丢给模型让它讲差异出来的结果就够用了。坑恰恰在这——如果只看这一次几乎会以为“丢给大模型就完事了”。顺着“做成一个正经系统”的惯性往复杂走拆多步、加 pipeline、分段 prompt结果反而退化了能让用户一眼看清差异的多维详情没了刚提炼出来的品类—核心维度也没进最终输出只剩卡片上几个标签加一句建议。教训比“输出不稳”更深一层复杂化本身会吃掉价值。加 pipeline 不是天然的进步——只有当它产出的东西不比直出版本少、还能稳定复现才算进步。发现这件事、再把丢掉的产出摁回去靠的不是模型是人盯着一条线哪些信息必须出现在最终结果里。所以真正要做的是反过来——先锁死“必须产出什么”再让结构保证它每次都产出、且跨品类对得齐。收敛出来的是同一份品类配置的三个部分core_dimensions 管比什么expression_schema 管怎么说预定义表达模板把描述格式钉死highlight_priority 管哪几维抢上卡片表面、其余退进详情按这个品类玩家最先想知道什么人工选过不是机械取前三。这份配置喂给 prompt驱动模型为每款产出一组字段core_expression一句话扫读入口如元气骑士的地牢射击·爽快闯关、fit_for适合谁以及真正承担看清差异的逐维度 dimension_values。前面那个坑错就错在一度只留了短表达、把详情扔了——短表达负责三秒锁定方向详情负责真正看清差异两层都得在。拿元气骑士这三款走一遍完整产出——说明数据是底层能力真实跑出来的但仍属验证阶段并非线上生产结果上线时会按具体场景找相似、换口味、新游探索……重新设计表达不会照这样全摊给用户。这套 pipeline 的意义就在于“该怎么比”这件原本只能靠人脑经验、每次结果还不一样的事变成了一张能 review、能交接、可复用的配置表。目前已配出数十个品类的草案新品类原则上加一行配置、不动代码——但这还在方案成形阶段没有全量定稿。它还特意保留了一个特性不依赖推荐上下文、可独立调用——一个捕鱼玩家未必在等你推新游他可能就是想搞清楚几款头部捕鱼差在哪。排序解决“推什么”对比解决“怎么选”。这一步才算真正去碰推荐的“最后一公里”。五、同一套理解还能再做什么多游对比之外这套游戏理解能力还能往别的场景延伸。底层是同一套理解换的只是上层表达。推荐解释——不只说推了什么还说“为什么是它”。传统推荐理由通常就两句“猜你喜欢”“大家都在玩”信息量基本为零。有了游戏理解推荐理由能落到用户真实感受到的体验上这款保留了你熟悉的刷宝成长体验同时有更完整的长期养成体系。或者直接挂在他玩过的游戏上喜欢《元气骑士》的爽快刷关《元气骑士前传》会给你更强的成长和装备追求。比起“大家都在玩”这种说法显然更贴用户的实际体感。再往前走一步当排序侧要排除某款游戏时这套理解层可以提供排除所依据的结构性理由——rejectList 记录的是“这款游戏的结构 / 规则在哪一维和当前场景的体验约束冲突”可回溯游戏某某 RPG排除原因成长高度依赖重复刷装循环与当前场景的体验约束冲突冲突维度成长系统 / 节奏强度要说清楚的是做排除决定的仍是排序侧理解层只提供“为什么冲突”的依据不回写、不参与排序本身——理解层是约束依据的提供方排序侧是消费方这和前面“只读不回写”是一致的。这样至少能带来两个东西推荐第一次有了可回溯的“负决策依据”以及一个诊断入口——某类游戏若被长期错杀能顺着 rejectList 反查是规则冲突还是表达出了问题。目前它只作为内部诊断字段具体怎么用——谁产出、排序侧怎么消费、要不要对用户透出——还要再探索。场景化引导——同一份理解换个场合换个说法。同一款游戏在不同入口该说的话不一样。底层调的都是同一套理解话术按场景走【找相似】喜欢《元气骑士》试试同样强调随机构筑与刷关爽感的《我的勇者》。【换个口味】最近一直在玩刷宝游戏换个更强调技能搭配与操作的动作 RPG 试试。【新游探索】你偏爱长期养成这款新上线作品可能正合口味。【热门推荐】最近热度持续走高的一款刷宝 RPG不少玩家拿它当《元气骑士前传》的替代。场景天差地别“找相似”强调共性、“换口味”强调差异但底下都是同一套游戏理解在支撑没有重复造轮子。这些表达场景也不只是设想。其中一部分——推荐解释、场景化引导——正在接入前端后续会陆续上线。这一层正从“能讲清楚”真正走向“用户能看到”。六、AI 的边界做这套东西始终守着一条线事实来自数据表达来自模型。模型干的是理解、归纳、总结、解释、表达不干的是凭空造事实、自己发明规则、替代排序。推荐系统照样负责“推什么”AI 补的只是“怎么说清楚”。这条线不是限制它而是为了出问题时能查得到——某个解读偏了能顺着结构定位到是哪一层而不是对着黑盒抓瞎。七、几条可复用的工程经验下面这几条更像个人的体会——是在这个项目里边学边做的经验谈不上什么方法论但每一条背后都踩过对应的坑。1. 探索和生产要用模型的两副面孔。最常见的浪费是把两副面孔混用——拿生产的严苛去做探索、或拿探索的自由度去做生产。先发散探索再收敛执行。2. 模型的原始输出不算接口。靠 prompt 求不来稳定起作用的是外面那层确定性结构闭集 schema normalize 兜住缺字段、错类型、脏值——这层 harness 才是非确定性生成进生产的前提。3. prompt 的结构决定理解的深度。喂给模型的结构就是它输出的上界——逆水寒那份解读能钻那么深不是模型更聪明而是 prompt 把回答路径切成了固定分区、每区强制回答一个具体问题。4. 把“比什么”“怎么说”“谁上卡片”解耦。三件事塞进一个 prompt 一把出跨品类必飘能拆开的关注点就分别约束——core_dimensions 管对齐比较维度expression_schema 管统一表达格式highlight_priority 管哪几维抢到卡片表面。5. 让能力不绑上下文才能复用。把 LLM 能力做成无状态、不绑死调用场景的插件它才能跨场景复用既服务“推荐后解释”也能直接回答“我就想搞清楚几款头部捕鱼差在哪”。八、一个产品视角的变化做完这一轮最大的感受是AI 没让产品设计变简单它把“系统结构”本身变成了产品的一部分。还有一层感受是关于角色的。推荐表达层过去难落地不是因为原推荐链路不重要而是理解、表达、验证和前端呈现这几件事很难由单一角色贯通——它们分属不同工种中间每一次交接都在衰减。而 AI 把这条链压短了AI 让 PM 能把判断、结构和 Demo 串成一条可验证的系统路径让表达层能力从想法变成系统。这也正是这件事能从一个人的探索起步的原因——判断要做什么、把它结构化、再跑出 Demo 去验证第一次可以由同一个人闭环。以前推荐系统里有两条清楚的分工线PM 和工程一条策略层和体验层一条。它们让协作边界清晰却也把“系统能力”和“用户体验”切成了两个互不打扰的世界。AI 进来之后这两条线一起开始糊——因为像 core_dimensions、expression_schema、rejectList 这些东西既是工程实现又直接决定用户看到什么、看不看得懂。它们是长在系统语义层里的产品设计。需求路径也跟着变了以前业务目标 → 功能设计 → 工程实现现在业务问题 → 能力探索 → 结构设计 → 原型验证 → 系统协同很多东西的复杂度从“实现阶段”前移到了“结构设计阶段”。这套探索最后长成的样子大致是一层挂在排序之上、只读不回写的能力层它没动排序一根线只是在排序给完答案之后接上了“讲清楚”这一段。九、写在最后项目起于单人探索经实用性与价值评估后正逐步进入正式生产。目前部分前端场景已开发、测试待上线部分在详设和迁移生产的过程中。事情的起点从来不是“要用 AI”而是开头那个特别具体的场景——用户站在几款游戏前面不知道选哪个。顺着这个问题往下搭的是这么一条线游戏标签 → 单游戏深度理解 → 多游对比 → 推荐应用这条路对不对、代价值不值、能不能长期维护还得靠落地后的数据来回答结论不敢下得太早。但至少,这次探索把一种可能摆上了台面推荐系统不该只告诉用户看什么,它也可以帮用户想清楚——到底选什么。