数据+AI的落地实践

一、在数据上应用AI的特殊性

大模型是大语言模型，是概率模型，而数据工作，最终是要产出一个明确的数字和结论的，对幻觉的接受度为0。不像让AI写PRD、写代码、写文案、做视频，都可以接受一定程度的幻觉，这也OK，那也OK的。

但是分析查询不同，要100%的准确率！但凡有一个地方AI编造数据了，整个结论不可信。而你，是要最终为数据结论负责的人。

这是首要的约束条件。如何避免幻觉呢？在工作流上强制现实：必须让AI先写好SQL+让你审阅后，再进行后续的分析和解读。写好了SQL，此时运行结果已经确定了。这个过程必不可少，否则直接问AI，AI直接回答你，这过程中的幻觉不可接受。这是整个工作流的主要约束之一。

二、AI可以做什么？缺什么？

AI是擅长写代码的。写sql肯定比最厉害的分析师都厉害。同样的分析思路，AI完成代码只需要2分钟，人类可能需要1小时。
AI可以提供分析思路。往往能提出你没想到的思路，在你没有思路时，可以探讨、发散。
AI擅长数据可视化（本质还是代码能力）。在有了明确的结论后，要以适当的可视化展示出来，这部分工作对汇报对象价值较高，但是做数分、PM等产出者价值不高但耗时。恰好AI擅长。

综上，就是人和AI来取长补短了。其中最关键的，是怎么通过Agent协作、工作流的限制，让AI最终使用的是准确的业务口径。

AI接入数仓、埋点系统后，有了数仓表、埋点的元信息，此时AI有了很多的信息可以猜个八九不离十。但是此时，AI还是只能猜口径，具体的限制条件，需要业务精确给出。

以下是一些AI获取业务口径的方式：

元信息：Agent可以根据血缘关系、表的引用次数排名，字段是释义自己判断。根据埋点的量级自己判断。这种方式本身存在不确定性，而且让Agent搜索一个有可能有万以上字段的数仓实在非常重。
知识库：业务已经使用过的sql、看板。直接上这很好，已经验证过的东西喂给AI，不就是最好的口径吗？所以把大家用过的sql文件都喂给AI，随着sql越来越多，AI反而拿到的口径越矛盾和模糊。这种非结构化的文件，无法解决这个问题。
你来告知：每次查询告诉AI口径。这种情况你需要先知道，单纯用这个方式无法发挥AI的能力。相当于你知道口径，单纯让AI写sql了。

有效的方式是组合以上来源，最终形成一个量级较小但清晰、且能自动更新维护的文档。作为AI的口径唯一参考。

口径主要是两方面：在各种数仓表里查询时的限制条件、埋点限制条件。所以文档我设计了两份：业务口径.md 、 埋点口径.md （埋点单独一张表、有清晰的规则和边界，单独拿出来作为一部分），在加上AI的memory，越用越懂业务。同时两个Agent：数分+埋点PM。

以下是整个的方案：

角色定义、工作流、业务知识、规范等，均在项目的CLAUDE.md中定义：

在 claude/agents/下，分别创建数据分析师、埋点PM角色。

选择多 Agent 架构：每个角色一个独立的 Agent 定义文件，CLAUDE.md 只做轻量调度。因为都放在CLAUDE.md 里：

用户发起需求
数分Agent阅读需求、业务口径.md、埋点文档.md、MEMORY.md，判断口径是否满足。如果清晰，则开始编写sql。如果不清晰，则询问用户，由用户告知口径。或者调用埋点PM探查口径。
业务口径或者埋点文档有更新后，回写文档
口径清晰后，与用户对齐sql思路、聚合方案。
编写sql，完成后供用户审阅。
确认后提交执行
保存结果
输出分析解读

💡 默认角色是数据分析师。你只需要说需求，系统会自动判断是否需要拉埋点PM介入。

以上，数分或者产品，都可以多两个-1同学用了。