《别急着换赛道：数据分析经验在 AI 项目里到底值多少？》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。
摘要
摘要：从报表到智能分析Agent，数据分析经验的迁移路径并不像想象中顺滑。很多人在Demo阶段就沾沾自喜，但真正上线后才发现，权限控制、日志追踪、可观测性才是横在中间的大山。本文结合近期落地项目，聊聊为什么权限和日志比调API更考验基本功，以及数据分析背景的同学如何补足这块短板。
---
目录
1. 数据分析的新机会
2. 自然语言BI的幻觉与陷阱
3. 指标解释Agent：从"会查数"到"会解释"
4. 数据工具调用：权限和日志才是真门槛
5. 一个真实项目的翻车复盘
6. 总结
---
数据分析的新机会
做数据分析这几年，我见过太多人把"会SQL、会看板"当成护城河。但大模型进来之后，这个认知需要更新了。
最近两年，数据分析岗位确实在分化：一边是传统报表岗，工作量稳定但天花板明显；另一边是智能分析方向，开始要求你会搭Agent、会写Prompt、会理解模型的能力边界。
说实话，这个转型不是"换个工具"那么简单。
我带过一个团队，招了三个数据分析背景的同学做智能分析Agent。前三个月大家都挺顺，SQL写得溜，业务指标门清，Prompt调出来效果也不错。但到了上线阶段，问题全来了——
有人发现用户查询权限没管控好，敏感数据被泄露；有人写出来的Agent跑着跑着就卡死，日志里找不到原因；还有人做的指标解释模块，模型一本正经地胡说八道，业务方根本不敢用。
这些都不是"调API"能解决的问题。
---
自然语言BI的幻觉与陷阱
很多人对自然语言BI的期待是：用户说句话，模型就给出答案。
这个Demo确实容易做。我见过最简单的实现：
# 伪代码示例：最朴素的语言转SQL def nl_to_sql(user_question): prompt = f""" 你是一个数据分析助手。将以下问题转换为SQL： 问题：{user_question} 表结构： - orders: id, user_id, amount, created_at - users: id, name, region 只输出SQL，不要解释。 """ sql = call_llm(prompt) result = execute_sql(sql) return result跑起来确实能回答"上个月华东区的订单金额是多少"。
但真实业务场景里，问题远没有这么简单：
第一个坑：权限边界。 一个运营同学问"看下我的用户数据"，模型可能给你返回全量数据，而不是只属于她的部分。这在Demo里无所谓，上线就是事故。
第二个坑：上下文丢失。 用户问"环比怎么样"，这个"环比"是相对上个月？还是相对去年同月？模型不知道，SQL里也没有体现。
第三个坑：结果解释。 数据查出来了，但用户需要的是"为什么"，不是"是什么"。模型经常给不出有业务价值的解释。
这些问题，单纯靠调模型API解决不了。
---
指标解释Agent：从"会查数"到"会解释"
数据分析背景的同学，优势在于懂业务指标、懂数据口径。这个能力迁移到Agent里，其实很有价值。
但"解释"这件事，比"查数"难多了。
我做过的一个指标解释Agent，逻辑是这样的：
1. 用户问"为什么昨天GMV下降了"
2. Agent拆解问题，生成多个SQL查询各个维度
3. 拿到数据后，用模型生成解释文本
4. 返回给用户
Demo阶段效果不错，但上线后问题暴露了：
- 模型解释有时候和实际数据对不上，属于"编"的
- 查询太多导致耗时过长，用户体验差
- 不同业务线的口径不一样，模型搞混了
我后来做了几件事改进：
第一，限制模型的解释范围。 不在Prompt里让模型自由发挥，而是给固定模板，让模型填空。这样虽然不够灵活，但可控。
第二，加缓存和超时控制。 查询太多就拆分，单个查询超过5秒就降级，返回部分结果而不是全部失败。
第三，明确口径来源。 每个指标的解释都要追溯到数据字典，不能靠模型自己"理解"。
---
数据工具调用：权限和日志才是真门槛
这是我想重点说的部分。
很多转大模型的数据分析师，觉得最难的是学新框架、写新代码。但真正卡住项目的，往往是这些" boring "的工程问题：
权限控制
用户能查什么数据、能看到哪些字段，必须在Agent层做好管控。不能相信模型的"自觉"。
我见过最典型的错误：
# 错误做法：依赖模型自行判断权限 def query_with_permission(user, question): # 没有校验，直接交给模型 sql = generate_sql(question) return execute(sql)正确做法应该是：
# 正确做法：权限在SQL生成前就确定 def query_with_permission(user, question): # 1. 根据用户角色确定数据权限范围 allowed_tables, allowed_columns = get_user_permissions(user) # 2. 将权限限制注入到SQL生成Prompt prompt = f""" 用户角色：{user.role} 允许访问的表：{allowed_tables} 允许访问的字段：{allowed_columns} 问题：{question} 请生成符合权限限制的SQL。 """ sql = generate_sql(prompt) # 3. 二次校验生成的SQL if not is_sql_safe(sql, allowed_tables, allowed_columns): raise PermissionError("SQL包含未授权数据") return execute(sql)日志追踪
Agent跑失败了，你怎么知道是模型的问题、SQL的问题、还是数据的问题？
没有完善的日志，排查就是玄学。我现在的标准做法：
- 记录每次查询的完整链路：用户输入、生成的Prompt、模型返回、执行的SQL、返回结果
- 记录耗时和错误信息
- 对敏感操作做审计日志
这些在Demo阶段看起来"没必要"，但上线后就是救命稻草。
---
一个真实项目的翻车复盘
去年我们做了一个销售数据分析Agent，Demo做得很漂亮，业务方很满意。结果上线第一周就出问题了。
问题一：权限漏洞
一个销售主管问"看下我们团队的数据"，结果模型给他返回了跨团队的数据。原因是我们在SQL生成时没有严格绑定用户权限。
问题二：日志缺失
某次查询卡住，业务方投诉。我们查了半天日志才发现，是某个SQL超时了，但超时信息被吞掉了，没有记录到日志里。
问题三：模型幻觉
模型解释"华东区销量下降是因为天气原因"，实际上数据里根本没有天气字段。业务方拿去汇报，闹了笑话。
改进措施：
1. 在Agent层增加权限中间件，所有查询必须经过权限校验
2. 建立完整的链路日志，每个环节都记录时间和结果
3. 模型解释部分改为"数据+模板"模式，不给模型自由发挥空间
这个项目让我深刻体会到：Demo能跑，和能上线，中间隔着整个工程化体系。
---
总结
数据分析转大模型，不是换个工作方式，而是换一套能力体系。
SQL会写、看板会做，这些是基础。但要做出能上线的Agent，你需要补上：
- 权限控制：理解业务数据边界，能在代码层面实现管控
- 日志追踪：建立完整的链路记录，排查问题时不抓瞎
- 可观测性：知道Agent的每个环节在干什么，出了什么问题
这些能力，短期内可能看不到"收益"，但长期来看，才是区分"能写Demo"和"能上线项目"的分水岭。
如果你现在正在转型，建议先别急着投简历展示Demo，而是找个真实项目，把权限和日志这块做好。这才是真正值钱的经验。
资料展示
下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。
如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。
