数据分析经典开放性问题：xx业务的xx指标（北极星指标）对比上个月跌了20%，怎么分析？

先拆解维度，先问：这个跌幅是否正常？如果不正常，那大概率是数据源出问题了

比如，月度曲线，可能整体波动不大的曲线、整体向上的曲线，突然俯冲向下，除非业务不做了这种极端情况，多半是数据源出问题了

找数据团队排查清楚了，再进行下一步分析

作为一个分析师，如果问我现在 AI 离真正“接管数据工作”还有多远，我会觉得，最大的瓶颈已经不完全是智力了，它越来越像一个可信度工程的问题。

AI 能不能完成查询、计算、写入数据？很多时候已经能。
AI 能不能连续正确地完成 100 次？开始变得困难。
第 73 次做错的时候，它自己知不知道？更困难。

而当它不知道自己错了的时候，系统能不能发现异常、拦住错误，不让一个“看起来正确”的结果进入正式产出？

这可能才是最后一公里。

像 lock、validator、state machine、golden baseline 这些东西，看起来只是我为了修一个 Excel 自动化逐渐接触到的工程概念，但它们背后其实都在解决同一个问题：

怎么把一个“很聪明但可能犯错的 Agent”，装进一个能够约束它、验证它，并尽可能阻止错误结果被正式交付的系统里。

说得更具体一点。

当你告诉 AI：“检查本周数据是否完整，然后更新 Excel。”它需要先理解“完整”是什么意思，再决定应该怎么做。

于是可能出现：
第一次：发现只有 6 天 → 停止。
第二次：发现只有 6 天 → 认为“虽然不完整，但也够分析” → 继续。
第三次：发现缺了一天 → 自己想办法补了一下 → 继续。

真正麻烦的是，后两种情况不一定会报错。

Agent 可能非常流畅地读取数据 → 做出判断 → 写入 Excel → 生成周报 → 告诉你“任务完成”。

整个流程看起来完全正常，但它其实在中间替你做了一个它本来没有资格做的判断。

传统程序当然也会产生静默错误，但 Agent 又增加了一层新的风险：

它可能理解错了、判断错了，却依然非常顺利地把整个任务执行完。

所以后来我发现，给自动化不断增加的那些检查，本质上都是在给 Agent 划定一些它没有资格自行判断的边界：

6 天够不够？——你不用判断，必须 7 天。
重复运行能不能再写？——你不用判断，唯一键不允许。
前一步失败还能不能继续？——你不用判断，状态机不允许。
两个任务能不能同时写 Excel？——你不用判断，lock 不允许。

这些规则不是为了让 AI 变得更聪明，而是为了让一些关键问题根本不需要 AI 发挥聪明。

能验证的自动验证，不能验证的明确暴露，有疑问的停止交付，而不是让错误安静地流到最后。

6年数分，都是和公司同事一起做，分享下近一年做的几个有意思的分析项目抛砖引玉，有任何想法欢迎交流

睡了一小觉了中途惊醒，没再睡着，怀民亦未寝，记录一二
1.宇宙厂现在大多可以ab数据论证了，人也更螺丝钉化，数据分析和模型理解能力现在对单体要求也低了不少，仍在做corr分析，没怎么做casual impact
2.查内容冷启动badcase，一个半小时看了10条case，合作的算法3-2会直接问一线有什么总结的，一线大概2-1水平，我说他要是能做明白也就不需要和我开会了，找回了一些好久不做一线case分析的手感，定位了几大关键问题，指出了内容找人类算法的建议，圈定了早期人群的性别年龄地域目标比例，优化到我的直觉水位，评测先行。感受就是「魔鬼在细节」，实现没问题，但技术选型出了偏差，不仔细肯定发现不了
3.结构洞是新时代人才供需关系的核心

外国人的开源精神值得称道，实体书要出版，线上还会给你免费看
这本《Causal Inference: the Remix》是因果推断权威斯科特·坎宁安的新书，是对上一本因果推断必读书《Causal inference: The mixtape》的更新

说两点：1，商业分析师、数据分析师可以关注一下。因为这个榜单主要测试电子表格、文档任务的能力；2，这是连续步骤测试，排名高，说明稳定，但不一定最强。

刚把八年前做过的一份客户流失分析脱敏后，重新交给 AI 跑了一遍。

这次最让我警惕的，不是 AI 编了假数字。它引用的基础数字都是真的，却把“观察结束前没有再下单”写成了“最终流失”，又借错了分母，最后还算出一笔看起来很像那么回事的业务损失。

后来我把没有对照组、观察期不同、缺少客户历史和销售跟进这些边界明确写进任务。同一个模型马上收住了，只把结果称为条件样本里的后续未下单比例，不再直接写成因果。

这也让我想起当年做流失预警模型时犯过的错：我们先把“三个月没登录”写进流失标签，模型自然会认真回答“谁已经沉默”；可业务真正想知道的是“谁正在离开”。

很多时候，工具还没开始犯错，我们已经把一个需要验证的问题写成了答案。AI 后面做的，只是把这个答案补得越来越完整。

现在再看 AI 写的数据分析，我会先盯住几个不起眼的词：最终、因此、导致、损失、必须。

你在哪些报告里见过这种“数字都对，结论却偷偷跳了一步”？

ai时代数据分析的感受就是ai铺天盖地的把它自以为是的结论抛出给你，然后里头错了 30%，需要我不断找它错在哪里

其实完全没有节省我的工作量啊！

最近遇到一个让我非常困惑的职场问题：如果一个数据分析师已经满负荷工作了，怎么证明“需求延期不是效率低，而是需求真的超过了一个人的产能”？

我们是个新项目，目前只有我一个数据分析师。

我要同时支持产品、运营、市场和老板，负责产品埋点、日常取数、数据口径、数据问题排查，以及老板希望重点产出的专项分析。

最魔幻的是，我自己对“分析效率”的认知其实已经非常高了。

按照我以前工作的经验，一个比较完整的大型分析项目，全人力投入两周出一个报告很正常；复杂项目持续几周甚至一个月也并不奇怪。

但我现在很多专项分析，基本2～3天就已经交付了。

与此同时，每天还夹杂着大量这样的需求：

“帮我查一下这个数。”
“这个口径是什么？”
“为什么这个数据对不上？”
“这个功能能不能再拆一个维度？”
“这个埋点怎么设计？”
“这个字段存在哪里？”

听起来都是小事。

但真正做数据的人应该知道，一句“帮我查个数”的背后，可能是：

理解需求 → 搞清楚业务方到底想判断什么 → 找表 → 找字段 → 发现数据没存 → 找研发 → 找中台 → 对口径 → 排查历史逻辑 → 写SQL → 校验 → 最后交付。

尤其是在一个新业务、数据基础又不成熟的情况下，最耗时间的经常根本不是写SQL，而是先搞明白：这个数到底有没有？在哪里？口径是什么？以及——这个数到底能不能信？

而这些工作几乎都是隐形的。

甚至很多20分钟、30分钟的小需求，因为太碎了，我连排期都懒得记。

然后某一天，业务方跟老板反馈：“数据交付效率有点低。”我：？？？

这件事让我越来越困惑，因为我感觉它已经不是“再提高一点效率”能够解决的问题了。

一个人一周就是5个人日。

如果这5个人日里同时要求：

深度分析 + 产品分析 + 运营分析 + 市场分析 + 埋点 + 临时取数 + 口径梳理 + 数据治理 + 数据排查 + 需求沟通 + 各种会议……

那似乎已经不是效率问题了，这是一个数学问题。

更麻烦的是，“交付效率”这个指标天然只看得见：

业务什么时候提需求 → 数据什么时候交付。

却看不见一个需求在真正交付之前，可能已经消耗了几个小时甚至几天去理解问题、找数、核口径和排查数据。

所以特别想请教做数据分析、数据BP、产品分析、增长分析，以及带过数据团队的朋友：

1. 到底怎么客观证明一个分析师的效率有没有问题？

是记录每周人日？
统计需求数量和平均交付周期？
按照需求复杂度分级，再分别统计交付周期？
还是把所有工作和预计工时都放进排期，让“需求量”和“可用产能”直接可视化？

我不太想每天记录自己20分钟做了什么、30分钟做了什么，那感觉又增加了一层管理成本。

但如果完全不记录，这些碎片工作又会全部消失。

2. 当需求长期超过一个人的产能时，成熟团队到底是怎么解决的？

我现在是：固定周产能 + 需求分级 + 基础数据自助化 + 插单必须交换优先级。

比如一周只有5个人日，就先把5个人日排满。

如果周三突然来了一个需要1天的P0需求，当然可以做，但同时必须明确：那么原来哪一个1天的需求要延期？

而不是“这个也很急，所以插进来”，但其他所有事情的deadline都保持不变。

3. 一个分析师到底应该支持多少业务方？

按照我以前团队的经验，一个数据分析师大概稳定服务2.5～3个需求方。

而我现在同时面对产品、运营、市场、老板等多个方向，实际对接人数已经好几倍于过去的工作经验。

AI确实已经帮我提高了很多SQL和处理数据的效率，但我现在越来越明显地感觉到：

AI可以缩短“做”的时间，却很难消灭需求沟通、业务理解、口径确认、数据治理和上下文切换的成本。

所以我也很好奇，成熟的数据团队到底是按照什么方式配置分析师人力的。

最近这个问题最让我无奈的，其实不是工作很多。

而是：我已经通过不断提高自己的效率，把很多原本周级的事情压缩到了天级；但只要总需求持续大于产能，最终依然一定会有人觉得“为什么我的需求还没做”。

然后这个产能问题，又很容易被解释成：“数据分析师交付效率不够高。”

所以真的很想听听同行的经验：这种情况下，到底应该怎么证明问题出在产能而不是效率？

以及，一个只有1名分析师、同时服务多个业务团队的项目，应该建立什么样的需求机制，才能避免最后所有压力都落到“你为什么不能更快”上？

这个问题到底应该怎么破？

数据分析搞定了，基本和我自己分析差不多啦.....