为什么仪表盘不再够用（以及 AI 智能体转而解锁了什么）— GameAnalytics

在上一篇文章中，我描述了数据分析师的角色如何随时间变化，以及过去在分析师一天中占据过多时间的繁琐任务如今如何被自动化。这篇文章的重点是数据分析师工作的本质和实际范围，但并未深入探讨哪些工作可以自动化、如何在例行任务之外利用 AI，并赋予它真正的自主性，使其像同事一样工作（或者，如果你愿意，也可以说是实习生，或者仍希望保留足够的控制权）。

Olga Berezovsky 在《Data Analysis Journal》的展望2026一文中，简洁地概括了这一转变：

这项工作变成了为人类和 AI 的决策提供支持。成功以你能做出多少快速、具备因果性且可安全自动化的决策来衡量。

Benn Stancil 在其 Substack 上说得更直接：

“和一位科技行业的人喝上一杯，他们最终会告诉你他们对自己工作的感受：他们被困在一座白领盐矿里。他们一天中的大部分时间都在苦干那些琐碎的工作，这些工作即便不算屈才，也低于他们的潜力。他们被聘用是为了做影响更大的工作；更具战略性的工作；更有价值的工作。”

然后，具体谈到分析师时：

“分析师会说，他们想要寻找战略洞察，而不是再做又一个仪表盘。”

这就把我们带到了仪表盘，以及我今天真正想聊的东西。除了仪表盘（现在任何人都能用 AI 轻松拉出来）之外，分析师还有哪些工作是他们本该去做的？

仪表盘的问题

我偶然看到的一篇帖子中有一个敏锐的观察：

很多公司并不需要又一个 #dashboard，他们更需要学会读懂自己已经拥有的那些。 而且这个模式我见过很多次：没人明白业务想回答什么 > 于是被要求做“一个仪表盘” > 没人看 > 再要一个。 也正因如此，Data Scientist 的角色才如此重要：他不聚焦于工具，而是从提问开始：你要用这个做什么决策？ 如果对方给你的回答是“为了能看得见”……那你的问题就在这儿。

— Yesi Days 🤓 (@silvercorp) October 15, 2026

翻译：许多公司不需要再一个仪表盘；他们需要学会读懂已有的仪表盘。我多次见过这种模式：没人明白业务想要回答什么，有人要“一个仪表盘”，没人看它，又有人要另一个。这就是为什么数据科学家扮演如此重要的角色：他们不是从工具开始，而是先问你要用它做出什么决策。如果答案是“把它展示出来”，那就是你的问题。

这种模式并不新鲜，因为在过去近十年的大部分时间里，仪表盘增加的速度一直快于人们查看它们的速度。新鲜之处在于，其背后的条件终于开始改变。直到最近，仪表盘仍然是非分析人员查看数据的唯一方式；如果一位制作人想按获客渠道查看留存率，就得有人为他们搭建一个仪表盘。如果CFO想按同期群收入查看，又得有人再搭建一个。每一次新的请求都会催生又一个仪表盘，而它只会被查看一两次，随后便被悄然弃用。

在 AI 时代，这一瓶颈消失了，任何能够访问结构良好的数据模型、并且拥有一个不错的 AI 助手的人，都能在几分钟内生成自己想要的视图。这意味着数据团队的角色从构建仪表盘的人转变为决定什么值得度量、定义该如何度量，并掌管那套让其他所有人都能安全探索数据的系统的人。

这是一份有趣得多的工作。同时它也是一份难得多的工作。

仪表盘真的曾经奏效过吗？

这是一个大胆的问题——我知道。但自从数据团队存在以来，信任一直是潜藏在他们所产出的一切之下的隐性问题。利益相关者打开一张图表，看到一个数字，就必须决定是否要据此采取行动。没有人有时间去审查生成它的 SQL、重新推导指标定义，或追溯事件模式（event schema）上个季度是否发生过变化。于是，信任最终只能通过间接方式获得：图表看起来合理，仪表盘看起来做得不错，制作它的人口碑很好，而这些就必须足够了。

仪表盘从未真正解决这个问题，它们大多只是把问题移出了视线。熟悉仪表盘里一张干净的图表看起来就像一个答案，这让人很容易不再追问答案从何而来。Benn 在另一篇文章中一针见血地指出了这一点：

除非你理解一张图表是如何构建的，否则无法知道它是否“有效”；外部产物的有效性取决于其内部结构的有效性。源数据可靠吗？数学计算做对了吗？每个公式都正确编码了吗？我们无法“测试”一张图表，也无法根据其自身优劣来验证它是否正确。相反，我们只能通过替代指标来判断：它的结论听起来足够合理吗？它看起来是精心制作的吗？是谁制作的？然后我们必须选择是否信任它。

同样的问题也适用于 AI 生成的分析，而且可以说更为严重。仪表盘中的图表至少还处在某人刻意搭建的系统之内。而一个即时生成答案的 AI agent，除非有人把上下文内置进去，否则它完全不具备这些上下文。这就引出了数据团队如今真正要承担的工作。

数据分析师及其他数据岗位如今应当做什么

一旦利益相关者能够自行生成视图，数据团队的价值就会向上转移。工作重心从执行转向判断、所有权和基础设施。

时间首先花在问题框定上。当制作人问“新的新手引导是否有效？”时，这实际上还不是一个数据问题。必须有人来决定“有效”指的是 D1 留存、教程完成率、首次会话时长、首次购买率，还是其中若干项的组合。AI 会回答它被给定的那个版本，但选出正确的版本是人的决定，而这会塑造后续的一切。

紧跟在指标框架之后的是：由谁负责界定这些指标到底是什么意思。随着游戏演进，定义会发生漂移，除非有人留心，否则没人会注意到。当新的游戏模式上线时，什么才算“活跃”玩家？当 PvP 上线时，“会话”的含义仍然一样吗？智能体不会捕捉到定义漂移。分析师会，而当他们也没捕捉到时，下一次看板更新就会建立在看似正确、实则不然的数字之上。

这种所有权延伸到数据模型本身。智能体需要一个定义明确的语义层，具备清晰的关系、规范的命名和有文档记录的业务逻辑，才能给出可靠的答案。基础越扎实，AI 在其之上所做的一切就越好。反过来也成立：智能体会自信地查询垃圾数据，并自信地给出垃圾答案，这使数据质量变得更有价值。

实验设计是另一个明显耗费大量时间的地方。如今，A/B 测试结果的解读已是基本要求，智能体可以处理其中大部分工作。真正的判断发生在更早的阶段：测试什么、何时测试、测试多久、排除哪些人群、结果在更大规模下是否依然成立。当分析师不再一次只跑一个测试，而是开始搭建实验基础设施，让制作人、设计师和 UA 经理能够安全地自行运行测试时，这种杠杆效应就会放大。

然后还有一类更新的工作，它在一年前还基本不存在：验证 AI 生成的内容。当任何人都能在几分钟内给出一个答案时，该相信哪些答案就成了关键所在。总得有人去发现那个连错了表的 join、那个定义略有偏差的队列，以及那个其实只是噪声的相关性。这就是新的质量保证层，而擅长这项工作的人正成为团队中最有价值的成员。

与此同时，还有一项职责：对会产生误导的请求提出反对。CMO 想看到按星期几划分的转化率。分析师的工作则是说：“这个样本量不足以支持这样的拆分，让我给你看一个能支持它的版本。”智能体让做什么就构建什么。分析师则从一开始就让企业避免问错问题。

最后，还有一层任何数据仓库都不包含的背景信息。App Store 的一项政策变了。竞争对手发布了一款产品，把你的受众注意力吸走了两周。一个看似季节性的规律其实并非季节性，而只是一次性的 Reddit 提及。智能体只能看到数据。分析师则会把他们在 Slack 上读到的、在全员大会上听到的、同事午饭时随口提到的东西带进来，而这些往往正是能解释那个数字的原因。

贯穿始终的一点是：上述所有工作都需要 AI 并不具备的判断力、背景信息或品味。机械性的那一层被自动化，反而让分析师能把一天的时间花在那些以人的经验为真正输入的工作上。过去的一周是 80% 执行、20% 判断。新的一周则把这个比例颠倒过来。

这种情况已经在哪些地方发生

如果你想看看这在实践中究竟是什么样子，目前最好的参考是 Simon Willison 最近在 Talking Postgres 播客上关于面向数据工程师的 AI 的对话。他详细列举了具体例子，说明当前这一代 AI 工具在真正获得数据库访问权限后能做什么，包括在几分钟内构建出一个带正则表达式的 150 行 SQL 查询（这个问题原本会花掉他一两个小时的工作量，因此根本不值得去问），以及循环运行智能体，让它们调查数据库、提出自己的查询，并把他们发现的结果构建成可视化。

西蒙对这一转变的表述，正是我会赞同的那一种：

AI 让我在主项目和副项目上都更有野心，因为通常你会想：做那件事要花我多长时间？那根本不值得。而这类任务所需的时间大大减少了。

这就是仪表盘从未给你的完整图景。仪表盘之所以存在，是因为人们问得足够频繁、值得为之构建图表的问题。所有那些不够频繁、不足以支撑一张图表的问题都得不到回答。拥有真实数据访问权限的 AI 智能体填补了这一空白。对游戏工作室而言，这就是差别所在：只回答能塞进每周复盘周期的问题，还是回答在 LiveOps 活动进行到一半、运营团队真正需要知道时冒出来的问题。

当然，让 AI 代理以这种方式访问你的游戏数据，本身就会引出一个显而易见的问题：如何安全地做到这一点？这属于另一个话题，我的同事、GameAnalytics 安全与合规负责人 Francesco Perrone刚刚就此撰写了文章。如果你正考虑将其中任何一项投入生产，接下来请阅读他的文章。