AI时代数分的真正价值

现在经常看到“数据分析、数据科学不行了，它会被 AI 替代”这样的结论。有的人很喜欢演示把一个 CSV 文件给到 AI，让它直接完成整套分析和报告生成流程，仿佛数据分析就是这么简单。

但真正在复杂业务环境，特别是互联网大厂里做过数分工作的人会知道，实际工作远不止于此。input 从哪里来？为什么选择这些维度和指标？分析要解决什么业务问题？最后的建议又怎么落地？

这些在 Demo 里被跳过的事情，恰恰很考验一个分析师的能力。

数分真正的价值，主要体现在以下几个方面

第一，定义好分析的框架，并且量化分析的维度与指标

学校里的数分项目，很多时候是从数据入手：先看看有哪些字段，再做探索，尝试让结论从数据中自然涌现。但在实际工作中，做数据分析需要带着业务假设进行演绎推理，而不是先把数据拆一遍，再去寻找解释。这个过程需要多和业务沟通，理解问题的背景、目前的策略，以及业务真正想解决什么。

比如，对于一款内容 App，业务提出一个需求：“如何提升 App 的留存？”

如果没有明确的假设，很容易先拆性别、年龄、地域，看看哪个人群留存低；没有发现，再看看渠道、入口、新老用户；还不行，就把几个维度组合起来看看。最后做了大量分析，却未必知道该调整什么。

而在和业务充分沟通后，可以围绕用户的内容消费过程建立分析框架：

内容分发： 目前的分发策略是否满足用户诉求，推荐内容与用户消费偏好是否一致？如果不匹配，就考虑调整分发策略。
内容供给： 用户想消费的内容站内没有，是否因此流失？如果是，就考虑内容引进。
功能使用： 用户是否在使用功能时遇到了障碍，比如找不到上次没看完的内容？如果是，就考虑功能优化。

这些假设需要用数据验证，也可能被数据推翻。但有了框架，后续分析就更明确，也更容易对应到具体的业务动作。充分沟通不仅能帮助解决问题，也能减少 DA 大量无方向的取数和探索工作。

框架明确后，还需要进一步量化，选择合适的分析对象、指标和时间周期：

分析对象：分析谁，和谁比较？ 根据假设选择人群，例如区分新老用户、不同内容偏好的用户，同时构造合理的参考系。假设 App 本月次留是 60%，单看这个数字无法判断高低；即使上个月是 40%，也要确认用户来源、统计口径等是否可比。
分析指标：用什么衡量业务概念？ 比如，如何体现用户“喜欢这类内容”？可以考虑点赞率、收藏率，也可以结合阅读完成度和消费时长。但分母用曝光人数还是阅读人数，含义并不相同，需要根据具体问题定义清楚。
时间周期：看多长时间，和哪个时期比较？ 对高频、体量大的内容 App，观察日常消费行为可以先取一个完整周，兼顾工作日和周末，并注意节假日、活动等影响。研究长期留存则需要更长的观察窗口，对比期也应尽量选择业务条件相近的时期。

这些选择，往往最能体现分析师的业务经验和量化能力。此外，还要结合分析目的多思考一步：发现消费某类内容的用户留存更高，究竟是内容促进了留存，还是本来就更活跃的用户更容易消费这类内容？

第二，真实业务中的表关联和取数逻辑

Demo 里的 CSV，Kaggle 项目里的表，已经整理好了字段、口径和数据粒度。但在真实业务中，用户信息、行为日志、内容信息、实验分组等数据往往散落在不同的表里，需要经过复杂的关联才能用于分析。

其中任何一个字段选错、关联条件写错，都可能影响最终结果。比如，用户表关联行为表后，一个用户对应多条行为记录，如果没有正确处理，就可能重复计算用户数。SQL 能跑通，数字也看起来正常，但逻辑已经错了。

做一个数据摸底任务时，需要判断人群如何定义、从哪个时间点开始统计，以及如何关联分组、曝光和后续行为。动辄涉及多张甚至十几张表，难点不仅是把代码写出来，还包括确认每一步取到的都是自己想要的数据。

数仓里也可能存在大量历史中间表。同样叫“活跃用户”，有的按启动 App 计算，有的要求发生有效消费；看起来相似的字段，实际含义可能差很多。这些差异需要结合文档、业务背景和历史经验去确认。

所以，把所有原始表丢给 AI，让它写 SQL，并不意味着取数问题就解决了。AI 可以提高写代码的效率，但分析师仍然需要 review 口径、关联逻辑和结果。只有自己理解数据，才能判断它有没有取对。

第三，协同各方，推动分析结果落地，拿到业务收益

完成一份分析报告、输出几条策略建议，通常还只是中间过程。

沿用前面的例子：假设发现用户找不到上次阅读的位置，建议优化“继续阅读”入口。接下来还要和产品讨论方案、与研发协调排期、补齐埋点，并设计实验验证效果。

不同团队可能有不同的优先级，研发资源也有限。如何把证据讲清楚、争取资源、处理分歧、推动上线，都很考验 DA 的综合能力。

上线后，也不能看到留存上涨就认定方案有效。还需要通过 A/B test，或在适用条件下使用因果推断方法，判断增长是否来自这次调整，并评估收益和其他指标的变化。

从发现问题到验证收益，这整段过程，才是分析工作的完整价值。

数分应该怎么在工作里利用 AI？

前面这些工作需要经验和判断，并不意味着分析师应该继续用原来的方式做所有事情。我觉得可以从两个层面入手。

最直接的，是用 AI 提升日常工作的效率

比如，在明确表结构和指标口径后，让 AI 草拟 SQL、辅助排查代码问题、生成数据处理和可视化脚本，以及整理分析报告。这些环节都有不少重复劳动，适合交给 AI 辅助完成，由分析师检查关键逻辑和结果。

更进一步，可以尝试把团队的一些业务环节 AI 化

让 Agent 参与一段相对完整的分析流程。

如果公司有自己的 Agent，可以通过 MCP 或 CLI 等方式连接各种内部平台，让 Agent 去拉取需求文档、聊天记录信息、数仓和实验平台里的数据。例如：

收集业务背景： 读取需求文档和相关聊天记录，整理分析目标、已有策略，以及需要确认的问题。
获取分析数据： 查找数仓中的相关表，根据约定的口径生成并执行查询，从实验平台获取实验配置和结果。
执行分析流程： 按照团队沉淀的方法完成数据校验、指标拆解和初步分析，再输出带有数据来源和待核实事项的分析初稿。

要让这套流程可靠，需要把团队的业务知识和分析方法沉淀下来。

一方面，可以把一些相对成熟的分析流程 SOP 化，再封装成 Agent 可以调用的 skill。比如异动分析、人群分层等。

另一方面，需要整理该业务方向常用的表、字段和指标定义。例如，一张表的粒度是什么，关联时用哪个键，哪些记录需要排除，留存和有效消费分别怎么计算，以及哪些历史表已经不建议使用。经过验证的 SQL，也可以作为参考样例一起沉淀。

这样，Agent 在取数和分析时就有了明确的依据，可以减少猜测字段含义、选错表和混用口径的问题。分析师 review 时发现的错误，也可以继续补充到文档和 skill 中，让后续的使用更可靠。

我认为，AI 会替代一部分重复性的取数、做表和报告整理工作，也会放大成熟分析师的能力。数分可以主动把自己的经验转化成 AI 能调用的知识和流程，把更多时间投入到业务理解、假设验证和策略落地上。

但基本功仍然不能省。只有自己知道该怎么分析，才能指导 AI、检查结果，并对最终结论负责。