作者：vivo 互联网产品团队- Wang Yuxi
本文探索：不改排序，补上排序之后的"表达与决策"------把游戏理解透，让同类多款可比较、可解释、可追溯。做法是让大模型放开探索、用工程约束收住，使生成稳定进生产。目标不是替代排序，而是帮用户从"给结果"走向"帮决策"。
1分钟看图掌握核心要点👇
推荐系统擅长回答"推什么"，用户却卡在"怎么选"。
排序已经够准了，可用户还是不知道选哪个
做游戏分发时，有几类场景反复出现。最典型的一类，是用户打开页面，同时看到几款游戏：
排序已经把最可能被点的那款放在最前面，但用户没点，他在犹豫------这几个看着差不多，到底有啥区别？哪个适合我？该先玩哪个？
还有一类更隐蔽：很多用户是拿自己玩过的游戏当锚去找相似的。搜一款玩过的游戏，最后却点开了结果里的别款；或者进到这款游戏，专门去翻它的相关推荐。他要的其实不是这款，而是"像它、又有点不一样"的下一款------可到底差在哪、哪个更对路，同样得他自己看明白。
这两类用户的状态其实相反：前一类是被几个选项卡住、迟迟选不动；后一类恰恰是带着明确的锚在主动找下一款。但他们卡在同一个地方------都得先看懂这几款到底差在哪、哪个对自己的路，才愿意去尝试。排序解决的是"推什么"，它并不负责让用户看懂差异；而当候选池越收越窄，再优化排序的边际收益也越来越小。真正没被接住的那一步，不是"推得准不准"，是"看懂差异、把选择走完"。
而游戏这个场景，决策成本天然比内容、短视频高：刷短视频不喜欢划走就是，几乎零成本；下载一款游戏玩进去，却要搭进时间、可能付费、甚至在里面交朋友。投入越重，选错的代价越大，用户在点下去之前就越需要先看懂"这是不是我要的"。可解释性和表达，在游戏推荐里不是锦上添花，而是决策的一部分。
这篇文章想分享的，是我们围绕"帮用户走完最后一步"做的探索------确切说，是这条链路里游戏这一端的理解与表达（另一端是把用户读懂，本文不做展开）。
一、为什么是"游戏理解与表达"
把用户带到门口，剩下的就是让他看懂------而这件事，推荐系统长期是缺位的。它很擅长算"你大概率喜欢 A"，却不太回答"A 凭什么值得你喜欢""A 和旁边的 B 差在哪""你这种玩家该从哪个入门"。可解释性和表达，一直没被当成一个正经能力来建------它们维护成本高、短期不像优化排序那样能直接拉指标，优先级自然靠后。
大模型的出现，让这件性价比一直不高的事，第一次有了能落地的做法。所以我们想试一次：不重做推荐系统，而是在排序给完答案之后，补上"讲清楚"这一段。
而要把一款游戏讲清楚，前提是先真正理解它。如果连游戏本身都没被理解透，"为什么推它""它和那个差在哪"全是空话。所以这一系列探索真正的起点，不是表达，而是游戏理解。
二、已经有标签体系了，为什么还要再做一套
这是一开始就必须回答的问题。
游戏分发本来就有一套相当成熟的分类和标签体系------玩法机制、题材世界观、战斗模式、节奏强度，这些维度早就有人在维护。再做一套游戏理解，凭什么？
答案只有一个：新体系必须产出旧体系给不了的信息增量，否则就是为做而做。 这条是设计之初定的底线，也是判断每一个新维度该不该存在的唯一标准。
那旧体系缺什么？它很擅长回答"这是什么"，却回答不了"玩家为什么玩、为什么付费"。而后者，恰恰是帮用户做决定时最关键的信息。
以一款捕鱼游戏为例。旧的内容标签能告诉你的，大致是：
捕鱼类 · PVE（对环境）· 模拟 · 轻度松弛
准确，但对"该不该推给这个用户"几乎没有帮助。而我们想补的增量，是这两层------
游戏动机：玩家到底为什么玩、为什么付费
付费机制：它靠什么结构与体系承载用户付费
付费模式：概率付费
主要付费点：常规抽卡/转盘 · 体力购买
付费复杂度：中
到这一层，这款游戏就不再只是"一款捕鱼"，而是"一款靠快节奏爽感和解压留人、用概率抽奖驱动付费的轻度游戏"。这句话才是旧标签给不了、又真正能用于推荐决策的信息。这就是我们说的"增量"------不是把旧标签换个说法重打一遍，而是补上一整层旧体系结构性缺失的理解。
那这些"值得存在"的维度，是怎么定出来的
确认了要补动机和付费这两层，新问题随之而来：动机有那么多说法，哪些维度值得进 schema、哪些是噪声？
这里没有一上来就拍一套体系让模型去标，而是先用大模型最擅长的事------见得多、覆盖广------去探索，而不是执行。让多个模型从各种角度去拆游戏：玩家为什么持续玩、爽感从哪来、成长循环怎么转、付费被什么驱动。这一步要的不是标准答案，而是尽可能多的"惊喜"和"边界"。
它确实给了惊喜，也很快暴露了边界：同一款游戏会被标成"Roguelike""Rogue-lite""随机地下城"，意思相近却无法归一，标签一失控，游戏之间就没法比。这一步不是失败，它验证了一个判断：
自由生成是大模型的能力上限，稳定输出得靠约束。
于是分工很清楚------探索交给模型，收敛和立规矩由人来做。把探索里反复出现、真正能解释差异的维度挑出来，定成闭集 schema，再让模型在体系内做填空。挑维度的标准卡得很死：必须同时可解释、可比较、可复用、有决策价值。成长驱动、刷宝驱动、爽感刺激这类留下，世界观、美术风格这类砍掉------不是它们不存在，而是在"帮用户做选择"这件事上区分力太弱。
整个过程不是"先定体系、再让 AI 执行"，而是：
模型放开探索 → 撞出边界 → 验证哪些维度真有用 → 收敛成 schema → 规模化生产一句话概括：大模型负责发现空间，人负责收敛空间。 这样产出的体系，每一个维度都对得起"信息增量"这条底线。
最后补一层工程兜底：模型输出天生不稳，我们在 API 层加了 normalize------缺字段回落默认值、类型强制收敛、不在 schema 内的脏值过滤。对下游来说，模型的原始输出不算接口，normalize 之后的稳定 schema 才算接口。
三、再往深一层：大模型到底能把一款游戏理解到什么程度
标签解决的是"是什么"，但我更想探一探另一件事：大模型对一款游戏底层逻辑、也就是"本质"的理解，上限到底在哪？
所以这一节更像一次探索，而不是一个准备直接上线的功能。判断"够不够深"有个很朴素的标准：哪怕是一个并不重度玩游戏、原本对这款游戏不了解的人，读完也能清楚感受到"玩家在这个游戏里到底在做什么、获得了什么"------那这份理解大概就到位了。
拿《逆水寒》举例。只丢"MMO、开放世界、古风武侠"给你没用。而按一套固定的解读结构往下钻，它会一层层展开。最上面是一张几秒就能判断"要不要玩"的极速判断卡：
arduino
快速标签：沉浸武侠 · 社交身份 · 慢节奏风险 · 生活密度
⚡ 极速判断卡
类型直觉：重内容武侠 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"，而是开头那个特别具体的场景------用户站在几款游戏前面，不知道选哪个。
顺着这个问题往下，搭的是这么一条线：
游戏标签 → 单游戏深度理解 → 多游对比 → 推荐应用
这条路对不对、代价值不值、能不能长期维护，还得靠落地后的数据来回答，结论不敢下得太早。但至少,这次探索把一种可能摆上了台面：推荐系统不该只告诉用户看什么,它也可以帮用户想清楚------到底选什么。