数据分析与清洗：用 Agent 做分析
系列入口：如何使用 Agent。M12 第 6 篇。
一、数据分析为什么适合 Agent 协作
真实的数据分析里，写查询和画图只占一小部分，大量时间消耗在：理解几十张表的含义和关联、反复试探数据长什么样、清洗各种脏数据、把业务问题翻译成正确的统计口径。这些环节信息密集、需要快速迭代，正是 Agent 的强项。
它能帮你读懂 schema、写和解释 SQL、对数据做探索性分析（EDA）、识别并处理异常值/缺失/重复、生成图表、并把结果叙述成结论。它把"从问题到洞察"的试错周期大幅缩短。但数据结论会直接影响决策，一旦口径错、聚合错，误导也很严重，因此数据任务必须坚持只读、抽样核对和统计审慎。
二、先对齐口径，再动手查
分析最常见的错误不在 SQL 语法，而在口径没对齐："活跃用户"怎么定义、时间按哪个时区、去重按什么键、包不包含测试数据。口径错了，后面再精确也是错的。
动手前，先和需求方（或让 Agent 协助你）明确：要回答的业务问题、关键指标的精确定义、时间范围和粒度。让 Agent 先读表结构、字段注释、样例数据，复述它对口径的理解并请你确认。把"问对问题、定对口径"作为第一步，能避免大量方向性返工。
三、只读访问 + 抽样探索
对生产数据，Agent 应使用只读凭证、默认在分析库/副本上查询，绝不允许它直接改生产（原则见连接数据库与安全护栏）。
探索阶段让它先抽样看数据分布（行数、空值率、取值范围、异常值），再写正式查询；复杂查询分步验证，先小样本确认逻辑、再全量跑。这种"先看后算"的节奏，能及早发现字段含义被误解、或数据本身比想象的脏。
四、数据清洗：让规则显式、可追溯
真实数据常有缺失、重复、格式不一、异常值、编码问题。让 Agent 协助清洗时，关键是把清洗规则讲清楚并保留原始数据：用什么填充缺失、按什么键去重、异常值是剔除还是校正、如何处理格式冲突。
让它生成可复跑的清洗脚本而非手工改表，并在清洗前后给出数据量和分布的对照，让你确认每一步改动合理。清洗永远在副本上进行、规则可审计，否则一旦误删或误改，原始证据就没了。
五、对统计结论保持警惕
AI（以及人）在数据结论上有几个典型陷阱，需要你把关：
错误聚合：该先去重再计数却直接 count、把可加指标做了平均、混淆粒度导致重复计算。相关当因果：两个指标一起变动就声称一个导致另一个。幸存者/样本偏差：只看了被筛选过的数据。小样本下过度解读。让它清楚写出每个数字是怎么算出来的、样本量多大、有无置信区间，并对"因果"措辞保持克制。数字可信的前提是计算过程可追溯、统计口径经得起推敲。
六、可视化与结论表达
让它根据问题类型选择合适图表、把关键发现叙述成"结论 + 证据 + 局限"。好的分析报告不只给数字，还说明：这个结论基于什么数据、有哪些前提、在什么范围内成立。对图表的坐标轴、口径、对比基准要核对，防止误导性可视化。
七、固化为可复跑、可审计的资产
一次性的对话分析难以复用和审计。把有价值的查询、清洗逻辑、图表生成固化成带注释的脚本或笔记本，让他人（和未来的你）能复跑、能检查、能在数据更新后重新得出结论。这与把经验沉淀为可复用资产的思想一致，也让分析结论经得起追溯。
八、一次口径错误如何被及时拦住
看一个具体的险例，理解"先对齐口径"为何如此重要。
某运营要"上个月的活跃用户数"，分析师让 Agent 直接查了登录日志、按出现过的用户计数，得到 42 万。幸而在发出前，他让 Agent 复述口径，发现两个问题：登录日志里包含大量内部测试账号，且"活跃"在公司指标体系里指"有过有效交易或关键操作"，而非仅仅登录。 重新对齐口径后——剔除测试账号、改用行为事件表、按用户 ID 去重——数字变成了 28 万，与历史趋势吻合。
如果直接把 42 万交出去，后续基于它做的预算和考核都会偏。这个险例的教训是：SQL 本身一个语法错误都没有，但答案依然是错的，错在口径。让 Agent 在动手前复述定义、并用历史数据做合理性校验，是成本极低、却能挡住大错的动作；而最终对"这个数字对不对"负责的，始终是分析师自己。
九、让分析可复现的几个习惯
数据结论要经得起复查，需要几个让过程可复现的习惯。
保留原始数据，所有清洗都在副本、用脚本完成，不手工改源表；记录每一步——用了哪些表、过滤条件、聚合口径、时间范围，写成带注释的查询；随机抽几条，手工核对脚本结果是否正确；给结论附上数据截止时间和刷新方式，因为数字会随数据更新而变化。
当别人质疑一个数字，你能立刻重跑脚本、逐步指给他看，这就是可信分析的标志。一次性的对话分析快但脆弱，可复现的分析慢一点却可审计、可传承。 把这些做顺，你的分析就从"某个结论"升级成了"一套别人能验证的方法"，这在团队协作和决策场景里价值要大得多。
十、用"下钻"代替一次到位的大查询
复杂分析容易在一个大 SQL 里出错且难定位，更稳的节奏是分层下钻、逐步确认。
先跑一个粗粒度的汇总确认大方向合理，再按关键维度（地区、渠道、时间）逐层下钻，每一层都和上一层对得上（各分组之和应等于总数）。让 Agent 协助维护这种"可对账"的下钻链——如果某一层数字加总对不上上层，立刻能发现口径或过滤出了问题。比起一次写出精巧大查询，分层下钻虽然多几步，却更易验证、更难藏错，也让你对结果的信心是逐层建立起来的。
十一、把分析结论和"建议动作"连起来
分析的终点不是数字，而是基于数字该采取什么动作，把两者连起来，分析才有落地价值。
给出结论时，顺带让 Agent 协助写清：这个发现意味着什么、建议谁做什么、预期影响是什么。比如不只说"某渠道流失率高"，而是"该渠道首周流失率显著高于其他，建议产品优先排查其引导流程"。但要区分**"数据支持的事实"与"你基于它的推断和建议"**，让读者能自己判断。好分析回答"so what"，且把事实与主张分层呈现，这样数字才能真正驱动决策，而不是停在报表上。
十二、警惕"结论先于数据"的偏差
人带着预设做分析时，容易只看见支持自己的数据、忽略反面，而 AI 也可能迎合你的倾向，这在数据工作中尤其要防。
刻意让 Agent 同时呈现支持与反对你预期的证据；对意外结果保持好奇而非急于解释掉；分析前先写下假设，避免事后"果然如此"。当数据否定了你的判断，以数据为准、修正认知。客观分析的核心是让证据决定结论，而不是让结论挑选证据。 保持这种坦诚，你的分析才不会沦为对既有立场的包装，也才能真正发现那些反直觉、却最有价值的洞察。
十三、给数字标好"可信区间"
并非所有数据都同等精确，把每个结论的可靠程度显式标出来，能帮助决策者恰当使用它。
样本充足、口径稳定的数字可以下较明确结论；样本小、数据有缺口或依赖假设的，应标注不确定性和可能范围，而非给一个貌似精确的点值。让 Agent 协助区分"硬数据"和"带假设的估算"。诚实地呈现不确定性，比虚假的精确更专业，也防止决策者把一个粗略估算当成板上钉钉的事实。当每个数字都带着它应得的可信标签，分析的整体可信度反而更高——成熟的数据沟通，从不讳言"我不完全确定"。
十四、让业务方参与"解读"环节
数据团队常常独自解读结果，但最懂业务背景的是业务方，让他们参与解读，结论会更可靠、也更易落地。
给出数据后，和业务方一起讨论"这在业务上意味着什么"，而不是单方面下结论；他们往往能提供数据之外的背景、解释异常背后的真实原因。让 Agent 协助准备好事实材料支撑这种对话。数据提供证据，业务提供语境，二者结合才有好判断。 这种协作也让基于数据的行动更易被接受和执行，避免"分析报告很好、却没人照着做"的脱节——分析的价值最终在共同解读和后续行动中实现。
十五、常见问题
Q：能让它直接连生产库跑吗？ 用只读账号连分析库/副本，避免大查询拖慢生产，且绝不允许写操作。
Q：它写的 SQL 我不懂怎么验？ 让它逐行解释逻辑、先在小样本上对结果，再用你能独立确认的口径抽查。
Q：结论和业务直觉冲突怎么办？ 这正是要深挖的信号：回查口径、数据质量和计算过程，而不是选一个自己想听的。
Q：数据很敏感怎么办？ 脱敏后再分析、走私有环境，遵循数据分级与出口管控。
九、检查清单
- 已对齐业务问题、指标口径、时间范围。
- Agent 只读访问分析库，先抽样 EDA 再全量。
- 清洗规则显式、在副本进行、有前后对照。
- 已检查聚合粒度，警惕相关当因果与小样本。
- 分析已固化为可复跑脚本，结论附局限。
总结
让 Agent 做数据分析，要把"安全"和"口径"放在"速度"前面：先对齐业务问题与指标定义、让它读懂 schema 并复述口径，用只读凭证在分析库先抽样探索、再正式查询，清洗时把规则显式化、在副本上操作并保留前后对照，同时对它的统计结论严格把关——检查聚合粒度与去重、不把相关当因果、看清样本偏差和样本量，最后把查询和清洗固化成可复跑、可审计的脚本；它能把从问题到图表的试错压缩到很短，但任何一个数字只有在计算过程可追溯、口径经得起推敲时，才配支撑真实决策。