经验分享 | GameAlgo SDK游戏数据监控以及LLM AI接入游戏

最近我在 TapTap 制造里做了一款修仙题材的文字人生模拟游戏——《一念仙途》。

玩家先选一个开局身份，然后一年一年地做决定：是当散修四处游历，还是拜入宗门潜心修行；遇到秘境，是夺宝、结盟，还是避开杀劫。修为、道心和寿元会随着选择此消彼长，最后把这一世推向不同结局。

目前游戏内置了 186 个本地事件、十几万字的剧情数据。即使不调用大模型，玩家也能完整走完一世；开启 AI 命途后，每一年的遭遇则会根据身份、状态和此前选择现场推演，让不同周目更有独属于这一世的感觉。真正做下来我发现，难点根本不是“让 AI 写一段修仙文”，而是怎么把模型能力变成一套能持续运行、能控制成本、失败能返还，而且玩家愿意继续玩下去的游戏系统。

《一念仙途》的核心循环很简单：每一年给玩家一段遭遇和几个选择，选择改变属性，属性又会影响后续事件与结局。我没有把整款游戏全部押在 AI 上。本地命途负责稳定、完整的基础体验，AI 命途则负责制造那些连作者自己也无法提前写死的意外。两者不是互相替代，而是分别托住游戏的下限和上限：模型服务临时不可用时，游戏仍然能玩；玩家想要更强的未知感时，AI 再介入。

先说结论：不能像普通 Web 项目那样，随便填一个兼容接口地址，就默认任何模型都能接。

只有两个主流选择：千问 和火山引擎。 两家都是 TapTap 自带白名单，接入姿势基本一样。

LLM 调用必须放在服务端。 TapTap 制造是客户端/服务端架构，只有服务端能直连外部 HTTP。这意味着：API Key 永远不落客户端，玩家改不了、也偷不走。客户端把“玩家选了什么”发远程事件，服务端拼 prompt 调模型，再把结构化结果广播回来。

prompt 的输出必须是严格 JSON。 我让 AI 每次返回固定 schema 的剧情+抉择+数值变化，服务端解析。关键是容错：AI 偶尔会在 JSON 外面包一句“好的，以下是……”或者字段名漂移，我做了自动纠正重试，连续两次还解析失败才给玩家报错并退款。

人生模拟很容易玩到几十甚至上百个回合。如果每次都把前面所有原文重新塞回 Prompt，调用会越来越慢、越来越贵，模型也未必记得更好。

我的做法是只保留四类信息：

另外，每次请求都带唯一的 requestId，网络重试必须复用它。服务端还会持久化幂等记录，并以“玩家 + 存档 + 回合号 / 状态版本”做唯一校验。这样即使连点产生了两个不同请求，也只有符合当前状态的一个能进入结算，避免重复扣积分、重复发奖励，或者一口气推进两年。真正上线前还要补齐超时、限流、并发上限、每日额度和服务熔断。模型不可用时，可以提示稍后重试，或者切回本地事件兜底，不能让整个存档卡死在“正在推演命途”。

1. 本地命途（免费）不调用 LLM，没有 Key 也能完整玩完一世。它负责让玩家先理解玩法、喜欢上这套循环，同时也是模型服务异常时的保底。

2. AI 命途（玩家自带 Key）玩家使用平台当前明确支持的服务商 Key，模型费用由玩家自行承担。游戏方负责 Prompt、状态管理和结果校验。BYOK 需要把规则讲清楚：Key 是否只用于本次请求、是否保存、如何删除，以及报错与日志如何脱敏。不要一边要求玩家信任你，一边把完整 Key 写进调试日志。

3. 积分命途（游戏方代调用）不想研究 Key 的玩家，可以消耗积分，由服务端使用游戏方的 Key 完成调用。积分可以通过活动或激励广告获得，让玩家先体验几次 AI 命途。这一模式最怕被成本反杀，所以至少要有单局额度、单日额度、输出长度限制和异常账号限流。扣积分也建议采用“先冻结、成功后确认、失败后释放”的方式。需要注意的是：积分模式可以返还游戏内积分；BYOK 请求如果已经被模型服务商计费，游戏通常无法替玩家退回那笔外部费用。上线前也要复核 TapTap 与模型服务商的最新规则。

UI 方面，我一般先自己定信息层级和大致布局，再让 AI 批量生成几种视觉方向，例如水墨、古籍、青绿山水或暗色玄幻。选出最合适的一版后，再回到 TapTap 制造里复刻。第一版落地也不会直接定稿。我会把实机截图再交给 AI，看文字密度、按钮层级、留白和视觉重心是否合理，然后继续微调。文字剧情游戏的 UI，重点不是“够不够仙”，而是玩家能不能迅速看懂：

这是 AI 剧情游戏非常容易漏掉的一坑。

模型会生成各种人名、地名、功法名和生僻字。字体只保留常用字，包体确实小了，但模型一旦写出字符集之外的字，玩家看到的就是方框；反过来，把全量中文字体直接塞进首包，也会拖慢第一次进入。

我这个项目里的完整字体约 25.6MB。更稳妥的方案是做成两层：

埋点最好从第一天就做。我接入的是 GameAlgo SDK——TapTap 官方的游戏数据增长平台。它不只是统计“今天来了多少人”，而是能把核心概览、每日关键指标、留存、收入、命途进度和新用户流程串起来，帮助开发者看清玩家在哪里进入、在哪里流失、广告有没有被真正看完，以及一次改版到底有没有效果。

1. 看清玩家到底走到了哪一步对《一念仙途》这种文字人生模拟来说，传统的“第几关”可以换成更贴合玩法的命途节点，例如：进入游戏、完成第 1 年、完成第 3 年、完成第 5 年、完成第 10 年和完成第 20 年。

从这次的新用户命途漏斗里，我能直接看到：共有 442 人进入游戏，400 人完成第 1 年，379 人完成第 3 年，367 人完成第 5 年，344 人完成第 10 年，最后有 245 人完成第 20 年。也就是说，完成第 20 年的新用户占进入游戏人数的 55.43%。

这类漏斗的价值不是单纯报一个通关率，而是帮我定位问题：如果玩家在第一年之前大量离开，就优先检查加载速度、新手说明和第一次选择；如果第 10 年到第 20 年下降明显，就继续看中段事件是否重复、节奏是否拖沓，或者数值压力是否突然变大。

数据只能告诉我“问题可能发生在哪里”，不能直接替我下结论。找到掉点后，还要结合玩家反馈、版本差异和具体事件继续验证。

2. 广告不能只看收入，还要看玩家愿不愿意看接入广告相关事件后，可以按日期、用户类型、广告位和广告类型查看表现。除了收入，还应该把下面几层数据连起来：

这样才能分别看出广告的触发率、观看率、完播率和奖励到账率，而不是只盯着最后赚了多少钱。后台还可以对比不同广告位的收入贡献与曝光表现，例如《一念仙途》里的复活激励视频和积分兑换激励视频，哪一个更容易被接受、哪一个真正带来了后续游玩，都能分开观察。

我原本以为“支持作者”的广告位会有人愿意看，但在当时那批样本里，完播率是 0；反而放在“续命”节点的激励广告表现更好。一个可能的解释是：“支持作者”给玩家的收益比较抽象，而“续命”解决的是眼前的问题。

当然，两个广告位所处的玩家阶段并不相同，所以不能只凭一次对比就认定原因。看到异常数字时，还要检查事件有没有正确上报、广告是否成功填充、入口是否真实曝光，以及样本量是否足够；条件允许时，再用同入口随机分流验证。

GameAlgo 对开发者最有价值的地方，是把“我感觉这里有问题”变成可以验证的问题：

SDK 接上并不会自动理解你的游戏。开发者仍然要先定义好关键事件和属性，例如游戏版本、本地/AI 模式、开局身份、当前年份、事件类型与广告位，并尽量保持命名稳定。Key、完整请求头、完整 Prompt 和玩家隐私文本不要写进埋点。

还有一点很重要：数据通常不能倒着补。如果等上线后才开始记录，就看不到最早那批玩家到底在哪一步离开。因此 GameAlgo SDK 应该尽早接入，让设计、版本更新和商业化调整都有数据可以回看。接入之后我最大的感受是：数据不会直接替你做出一款好游戏，但它会告诉你，下一刀最值得改在哪里。