游戏客户端新手引导：不要把玩家困在发光手指里

引导不是一串强制点击

很多游戏的新手引导第一版都很像：遮罩盖住界面，一个发光手指指向按钮，玩家点一下，下一步再指向另一个按钮。这样做能快速把流程串起来，但上线后最容易出问题。玩家可能跳过剧情、网络慢、资源没加载完、按钮被活动入口挤走、界面版本变化、切后台回来，都会让引导停在一个不存在的目标上。

新手引导的目标不是让玩家按完脚本，而是帮助玩家理解核心循环。客户端实现也应该围绕“可恢复、可跳过、可诊断”设计，而不是把每一步写死在 UI 回调里。一个引导系统如果只能在理想路径下工作，它会成为新玩家的第一道障碍。

引导状态要独立

引导系统不要把进度藏在界面里。它应该有独立的 GuideState，记录当前引导线、步骤 ID、已完成条件、等待目标、是否允许跳过、最近一次失败原因。UI 只是引导的目标之一，不是引导的主人。

flowchart TD
    A[玩家进入场景] --> B[读取 GuideState]
    B --> C{当前步骤条件满足?}
    C -->|否| D[等待事件或降级]
    C -->|是| E[定位目标 UI/场景对象]
    E --> F{目标存在?}
    F -->|否| G[记录失败并尝试恢复]
    F -->|是| H[展示遮罩/提示/手势]
    H --> I[玩家完成动作]
    I --> J[提交步骤完成]
    J --> K[进入下一步或结束]

这里最重要的是目标不存在的分支。真实项目里，目标不存在并不少见。活动配置关了入口，A/B 实验换了按钮，低端机资源还没加载完，或者玩家已经提前完成了动作。引导系统应该能等待、跳过、重定位或终止，而不是让遮罩卡死。

触发条件要可组合

一个引导步骤通常不该只靠“等级等于 2”触发。更可靠的是组合条件：玩家等级、主线任务、场景、界面、资源状态、服务端开关、是否已完成前置步骤。条件表达要数据化，策划能调整，客户端能校验。

条件也要有反向保护。比如玩家已经获得装备，就不应该再强制他去领取同一件装备；玩家已经打开过商城，就不需要重复教学入口；服务端活动关闭时，引导不能继续指向活动按钮。引导系统要尊重当前真实状态，而不是盲目执行历史脚本。

强制和弱引导要分层

不是所有教学都需要锁屏。核心操作、首次战斗、第一次装备可以强引导；次要功能、活动入口、进阶养成更适合弱提示。强引导太多，玩家会觉得游戏不信任他；弱提示太少，玩家又会迷路。

客户端可以提供几种引导形态：强制遮罩、局部高亮、浮动提示、任务追踪、一次性气泡、可关闭教程卡片。业务选择形态时，应按风险和复杂度决定。消耗货币的操作可以强确认，打开图鉴不必锁住全屏。

跳过不是失败

很多团队不愿意让玩家跳过新手引导，担心玩家不懂玩法。但如果引导做得过长，跳过反而是保护体验。关键是跳过后要有补救：教程入口、帮助说明、任务追踪、可重新播放的教学关卡。

跳过也要记录原因。玩家在哪一步跳过，是否因为停留太久、反复失败、还是主动点击，这些数据能反映引导质量。如果大量玩家在同一步跳过，说明这一步可能太啰嗦或目标不清。

恢复路径要重点测试

引导中切后台、断网、杀进程、热更新、界面重载，是必须测试的路径。恢复时客户端先读 GuideState，再检查当前场景和条件。如果玩家已经完成了步骤，就推进；如果条件不满足，就等待；如果引导线已经不适配当前版本，就安全结束并上报。

不要把引导恢复做成“重新从第一步开始”。新玩家被迫重复教学，挫败感会很强。每一步都应该能单独判断是否完成，而不是只依赖线性脚本。

和 UI、任务、服务端协作

引导系统经常跨多个模块。UI 提供可定位目标，任务系统提供阶段，服务端记录已完成标记，配置系统控制开关。每个模块都要有清晰接口。UI 元素最好有稳定 guideId，不要靠层级路径查找；任务状态要能查询；服务端保存关键完成点，避免换设备后重复强引导。

如果引导目标来自动态活动，配置发布时要做校验：目标页面是否存在，guideId 是否可定位，最低客户端版本是否支持。否则运营临时开一个入口，可能直接把新手引导带坏。

诊断工具很有价值

开发版应有引导面板，可以查看当前引导线、步骤、条件判断、目标定位结果和最近失败原因。QA 可以跳到任意步骤，也可以重置某条引导。没有这个工具，调新手引导会非常痛苦，只能反复建号。

线上日志也要记录步骤停留时间、失败原因、跳过和完成。新手流失通常发生得很早，引导数据能帮助团队判断是玩法不吸引人，还是客户端把玩家卡住了。

小结

新手引导系统的好坏，不在发光手指做得多漂亮，而在它是否尊重真实状态。可组合条件、独立状态、可恢复路径、可跳过策略和诊断工具，能让引导从一次性脚本变成稳定的客户端基础能力。

引导脚本要版本化

新手引导会随着界面和玩法变化不断调整。客户端需要知道当前玩家完成的是哪一版引导。否则旧玩家回流时，可能因为步骤 ID 改名被重新拉进旧教学；新玩家则可能拿到服务端旧配置，指向新版界面不存在的按钮。

引导配置应包含版本号和最低客户端版本。步骤 ID 一旦发布，尽量不要复用给不同含义。废弃步骤可以保留兼容处理，等确认没有旧状态后再删除。

引导和奖励不要强绑定

有些项目会在引导步骤里直接发奖励。这样做短期方便，长期风险很大：步骤重复执行可能重复发奖，跳过引导时奖励状态不清，服务端补偿也难处理。更好的做法是任务或成就系统负责奖励，引导只负责教学动作。

如果必须在引导中触发奖励，也要由服务端以幂等方式发放。客户端只提交完成事件，不直接改背包。

引导遮罩的技术细节

遮罩高亮目标时，要处理目标移动、列表滚动、屏幕适配和安全区域。目标 UI 如果在滚动列表里，系统要先滚动到可见，再定位。目标位置变化时，遮罩跟随更新，但不要每帧做昂贵布局查询。

遮罩还要处理输入穿透。只有高亮区域允许点击，其他区域拦截；如果目标消失，立即撤销遮罩或进入等待状态。不要让玩家点到遮罩下方的危险按钮。

引导文案也要本地化

引导文案通常比较短，但它直接影响理解。CJK、英文、德文长度差异很大，气泡位置要能适配。不要把文案写死在图片里，否则本地化和 A/B 调整都会很困难。

语音引导如果存在，还要处理跳过和字幕同步。玩家跳过时，语音要停止；切后台回来时，不要重复播放已完成语音。

数据复盘

引导不是上线后就不管。每个步骤的到达率、完成率、停留时间、失败率、跳过率都应该看。和新手留存、首局失败、功能开启率结合，才能判断引导是否真的有效。

如果某一步停留时间异常长，可能是文案不清、目标难找、网络等待或 bug。客户端日志要能区分这些情况，避免所有问题都被解释成“玩家不懂”。

引导和真实玩法的距离

新手引导常犯的错误，是教学环境和真实玩法差太远。教学里敌人不动、按钮被强制点亮、资源无限，玩家过完引导后进入真实战斗，发现完全不一样。客户端实现时要尽量复用真实系统，只在必要处加保护。

比如第一次释放技能，可以降低敌人伤害，但仍使用真实技能系统；第一次装备，可以引导打开背包，但装备结果仍走正常服务端确认。这样引导既稳定，又不会教玩家一套不存在的规则。

引导失败要有温和兜底

如果某一步连续失败，客户端不要无限重复。可以降低强制程度，改为任务提示；也可以跳过该步骤，后续在帮助系统里保留教程。玩家不应该因为一个引导目标定位失败而无法继续游戏。

失败兜底要上报。引导自动跳过不是正常成功，团队需要知道发生了多少次、在哪些设备和版本上发生。否则问题会被隐藏到数据里。

多账号和换设备

同一账号换设备时，引导进度应该跟账号走，至少关键完成点要同步。设备本地只保存临时步骤。否则玩家在手机完成引导，换平板又被强制教学，会很烦。

但操作布局教学可能和设备有关。手柄、触屏、键鼠的教学不同。账号完成了战斗基础教学，不代表完成了手柄按键教学。引导状态要支持按主题区分，而不是一个总开关。

小结之外

新手引导的工程目标，是让教学成为可维护系统，而不是版本里的临时脚本。它越早稳定，后面新增玩法教学就越轻松。

引导不要压住真实反馈

强引导遮罩常常会盖住 Toast、错误提示和网络状态。玩家点了目标按钮，但请求失败，错误提示被遮罩挡住，他只会觉得游戏没反应。引导层级要给系统错误和网络提示留出口。

引导期间如果发生断线、强更、封禁、资源缺失，系统提示必须高于引导。业务引导再重要，也不能压住系统状态。

引导编辑工具

如果项目引导很多，最好有编辑和预览工具。策划能选择目标 guideId、配置条件、查看遮罩位置，客户端能导出校验报告。没有工具时，引导配置会高度依赖工程师，迭代很慢。

工具不一定一开始很复杂，但至少要能检查目标是否存在、步骤是否可达、是否有循环和是否引用了不支持的界面。

最后看三条底线

新手引导要守住三条底线。第一，它不能卡死玩家，目标不存在、网络失败、切后台回来都要有恢复或跳过路径。第二，它不能教一套假规则，关键操作应尽量复用真实系统。第三，它的数据能被复盘，团队知道玩家在哪里停住、跳过和失败。

新手阶段是玩家和游戏建立信任的时间。引导系统稳定，玩家才会把注意力放到玩法上，而不是和界面搏斗。

维护成本来自脚本分叉

新手引导常常因为活动、渠道和 A/B 实验分叉。分叉不可避免，但要有规则。公共步骤复用，差异步骤用条件控制，不要复制整条引导线再改几步。复制越多，修 bug 时越容易漏。

引导配置也要能 diff。策划修改后，工程师和 QA 能看到新增、删除、条件变化和目标变化，而不是只拿到一大段 JSON。