上周的产品周会。
老板问我："上周新功能的数据怎么样？"
我说："数据同学还在排期，预计明天能出..."
老板皱眉："这么简单的数据，你自己不能看吗？"
会议室一片沉默。
旁边的技术总监看了我一眼，没说话。
那一刻，我想找个地缝钻进去。
会后，我找数据同学催数据。
他说："你的需求排在第5个，最快后天。要不你自己写个SQL查一下？"
我："呃...我不太会SQL..."
他："那我尽快吧。"
转身走了。
那天晚上，我在想：
做了5年产品经理，不会SQL真的说不过去了。
但学SQL要多久？我看了一眼教程，密密麻麻的语法...
算了，还是等数据同学吧。
直到3个月前，我发现用AI可以完全不学SQL，直接取数。
现在：
效果：
上周做新功能数据分析：
我一个字的SQL都没写。
今天分享我的完整方法，以及8个高频场景的Prompt库。
一、不会SQL的产品经理，到底有多被动？
先说个扎心的事实。
被动1：开会拿不出数据，显得不专业
真实场景：
产品评审会上，技术leader问："这个功能的使用率多少？"
你："我等会找数据同学取..."
技术leader："现在就需要，决定要不要继续做。"
你："那...我去催一下..."
气氛尴尬。
技术leader心里想的是：
"一个产品经理，连自己负责的功能数据都不掌握？"
虽然他没说出来，但你能感觉到。
不会取数，在大厂就是这么吃亏。
被动2：依赖数据同学，被排期卡脖子
更扎心的是：
数据同学每天要支持3-5个产品经理。
你的需求永远排在后面。
因为你不会SQL，他知道你离不开他。
我见过最夸张的：
一个简单的留存数据，数据同学说要3天。
为什么？
"前面还有4个需求，你的优先级不高。"
你只能等。
等着的时候，老板又催了：
"数据呢？我明天要汇报。"
你："数据同学说明天能出..."
老板："明天？那今天呢？"
你哑口无言。
被动3：看不懂SQL，无法判断数据准确性
更要命的是：
数据同学给你的数据，你根本看不懂取数逻辑。
他说："留存率是25%。"
你："怎么算的？"
他："我写了个SQL，统计了次日登录的用户..."
你："可以看看SQL吗？"
他发你一段代码：
SELECT
COUNT(DISTINCTCASEWHEN t2.login_time ISNOT NULLTHEN t1.user_id END) /
COUNT(DISTINCT t1.user_id) *100AS retention_rate
FROM user_table t1
LEFTJOIN user_table t2
ON t1.user_id = t2.user_id
ANDDATE(t2.login_time) =DATE(t1.register_time) +INTERVAL1DAY
WHEREDATE(t1.register_time) ='2024-07-01';
你盯着屏幕看了30秒。
完全看不懂。
只能说："好的，谢谢。"
心里想的是："这数据对不对？我也不知道..."
这才是最被动的地方。
二、产品经理真的需要学SQL吗？
说实话，我在腾讯见过很多P8、P9的产品总监。
他们中的大部分，不会写SQL。
但数据能力都很强。
真相1：重要的不是SQL语法，是数据思维
我问过我前leader（腾讯P9）：
"你会写SQL吗？"
他说："不会，但我知道该看什么数据。"
他给我举了个例子：
场景：新功能上线，要做数据分析。
大部分产品经理会这么做：
- 4. 产品经理："呃...就是使用率、活跃度这些..."
- 5. 数据同学："使用率怎么定义？按天还是按周？..."
高阶产品经理会这么做：
- 1. 明确业务问题："这个功能能提升用户留存吗？"
差距在哪？
不是SQL语法。
是"知道该看什么数据来解决业务问题"的能力。
这才是数据思维。
真相2：SQL只是工具，AI可以替代
以前，数据思维和SQL技能是绑定的。
你想验证假设，必须自己写SQL。
所以大家说："产品经理要学SQL。"
但现在不一样了。
AI可以把你的业务问题，直接翻译成SQL。
你只需要：
SQL从必需品，变成了可选项。
就像：
以前你要会五笔才能快速打字。
现在，语音输入也能很快。
工具变了，目标没变。
真相3：AI时代，产品经理的新能力模型
我整理了一张对比表：
AI时代的产品经理，核心能力是：
SQL语法，不再是必需品。
三、我的AI取数方法：3步出报告
现在分享我的完整方法。
Step 1：用5W法明确业务问题（3分钟）
很多产品经理取数失败的原因：
不是不会SQL，而是业务问题没想清楚。
数据同学问你："要什么数据？"
你说："用户活跃度。"
他问："怎么定义活跃？日活还是周活？"
你："呃...日活吧。"
他问："统计哪个时间段？"
你："最近一周？"
他问："要细分维度吗？比如按渠道、按版本？"
你："呃...好像要..."
来回沟通3-4轮，浪费时间。
正确做法：用5W法。
在取数前，先回答5个问题：
1. Why - 为什么要这个数据？
2. What - 具体要什么数据？
3. Who - 针对哪些用户？
4. When - 看什么时间段？
5. Where - 数据从哪来？
举例：
业务场景： 新功能上线1周，老板要看效果
5W分析：
Why（为什么）：
- 判断新功能是否提升了用户留存
- 决定是否继续投入资源优化
What（要什么）：
- 核心指标：次日留存率
- 对比维度：使用新功能 vs 未使用
Who（哪些人）：
- 全量新注册用户
- 时间范围：上线后1周内注册的用户
When（什么时间）：
- 统计周期：过去7天
- 对比基准：上线前1周的留存率
Where（数据来源）：
- user_register 表（注册时间）
- user_login 表（登录记录）
- feature_usage 表（功能使用记录）
5W想清楚，取数效率提升10倍。
Step 2：让AI翻译成SQL（2分钟）
想清楚业务问题后，直接让AI翻译成SQL。
AI Prompt模板：
我需要分析一个业务问题，请帮我生成SQL查询。
【业务背景】
[用5W法整理的内容]
【数据表结构】
表1：user_register
- user_id: 用户ID
- register_time: 注册时间
- channel: 注册渠道
表2：user_login
- user_id: 用户ID
- login_time: 登录时间
表3：feature_usage
- user_id: 用户ID
- feature_id: 功能ID
- use_time: 使用时间
【需要的数据】
1. 使用过新功能（feature_id=101）的用户，次日留存率
2. 未使用新功能的用户，次日留存率
3. 两组用户的留存率对比
【输出要求】
- 生成完整的SQL查询语句
- 加上注释说明每步的逻辑
- 如果有多种实现方式，选性能最优的
AI会给你：
你只需要：
完全不需要懂SQL语法。
Step 3：AI生成分析报告（5分钟）
拿到数据后，让AI生成分析报告。
AI Prompt模板：
基于以下数据，生成一份数据分析报告。
【查询结果】
[粘贴数据库返回的结果]
【业务背景】
[5W法整理的内容]
【报告要求】
1. 数据解读：这些数字说明了什么？
2. 对比分析：不同组之间的差异
3. 业务结论：功能效果如何？
4. 行动建议：接下来该做什么？
【输出格式】
- 用产品经理的语言，不要太技术化
- 突出核心结论，3-5条
- 每条结论都要有数据支撑
AI会生成：
【数据分析报告】新功能留存效果分析
一、核心结论
1. 使用新功能的用户，次日留存率35%，比未使用用户高10个百分点
2. 效果在iOS端更明显（提升15%），Android端提升较小（5%）
3. 付费用户使用率更高（60%），但留存提升不明显
二、数据明细
- 使用新功能用户：12,500人，次日留存率35%
- 未使用用户：25,000人，次日留存率25%
- 整体留存率提升：从25%提升到28.3%
三、行动建议
1. 继续优化新功能，重点提升Android端体验
2. 增加功能引导，提升使用率（当前只有33%）
3. 关注付费用户反馈，可能存在体验问题
直接复制，就能给老板汇报。
时间对比
关键是：你一句SQL都不用写。
四、实战：8个高频场景的Prompt库
现在给你8个最常用的取数场景，直接复制Prompt就能用。
场景1：用户留存分析
业务场景： 看新注册用户的留存情况
Prompt：
我需要分析用户留存率，请生成SQL。
【业务需求】
统计最近30天新注册用户的次日/7日/30日留存率
【数据表】
- user_table（user_id, register_time）
- login_table（user_id, login_time）
【计算逻辑】
次日留存 = 注册次日有登录的用户数 / 注册用户总数
7日留存 = 注册后7天内有登录的用户数 / 注册用户总数
【输出】
- 生成SQL查询
- 按注册日期分组
- 输出：日期、注册人数、次日留存率、7日留存率
用法： 复制后，把表名改成你的数据库表名，直接执行
场景2：功能使用率分析
业务场景： 看新功能有多少人在用
Prompt：
分析某个功能的使用情况。
【业务需求】
统计功能X上线后，每天有多少用户使用，使用率是多少
【数据表】
- event_table（user_id, event_name, event_time）
- user_table（user_id, register_time, last_login）
【计算逻辑】
使用率 = 使用功能X的用户数 / 当日活跃用户数
【输出】
- 按天统计
- 输出：日期、活跃用户数、使用用户数、使用率、环比增长
场景3：转化漏斗分析
业务场景： 看用户在哪一步流失最多
Prompt：
分析用户从A到B的转化漏斗。
【业务需求】
统计用户从"进入页面"→"点击按钮"→"完成支付"每一步的转化率
【数据表】
- event_table（user_id, event_name, event_time）
【漏斗步骤】
步骤1：page_view（浏览页面）
步骤2：button_click（点击按钮）
步骤3：payment_success（完成支付）
【输出】
- 每步的用户数
- 每步的转化率
- 流失最严重的环节
场景4：用户分群对比
业务场景： 对比不同用户群的表现
Prompt：
对比不同用户群的核心指标。
【业务需求】
对比付费用户 vs 免费用户的活跃度和留存率
【数据表】
- user_table（user_id, user_type, register_time）
- login_table（user_id, login_time）
【对比维度】
- 日均登录次数
- 周活跃天数
- 次日留存率
- 7日留存率
【输出】
- 分别统计两类用户的指标
- 计算差异百分比
- 指出显著差异的指标
场景5：异常数据诊断
业务场景： 数据突然异常，找原因
Prompt：
诊断数据异常的原因。
【业务问题】
昨天的DAU突然下降30%，需要找到原因
【数据表】
- login_table（user_id, login_time, channel, device_type, version）
【诊断维度】
- 按渠道拆分：哪个渠道下降最多？
- 按设备拆分：iOS还是Android？
- 按版本拆分：是否某个版本有问题？
- 时间分布：是否某个时间段异常？
【输出】
- 生成多个诊断查询
- 快速定位问题维度
场景6：AB测试结果分析
业务场景： 对比AB测试的效果
Prompt：
分析AB测试的效果。
【实验设置】
- 实验组：新版首页
- 对照组：旧版首页
- 核心指标：点击率、转化率、留存率
【数据表】
- ab_test_table（user_id, group_name）
- event_table（user_id, event_name, event_time）
【分析要求】
- 对比两组的核心指标
- 计算差异和显著性
- 给出是否推全量的建议
【输出】
- 两组的数据对比
- 差异百分比
- 置信度评估（如样本量是否足够）
场景7：增长归因分析
业务场景： 用户增长是哪些渠道贡献的
Prompt：
分析用户增长的来源。
【业务需求】
最近1个月，新增用户主要来自哪些渠道？各渠道质量如何？
【数据表】
- user_table（user_id, register_time, channel）
- login_table（user_id, login_time）
【分析维度】
- 按渠道统计新增用户数
- 各渠道的次日留存率
- 各渠道的7日活跃率
- ROI：优质用户占比
【输出】
- 渠道排名（按新增量和质量）
- 识别高价值渠道
- 给出渠道投放建议
场景8：自动化数据报表
业务场景： 每天/每周要看的固定报表
Prompt：
生成一份日常数据报表的SQL。
【报表需求】
每日运营数据报表，包含：
- DAU/WAU/MAU
- 新增用户数
- 付费用户数和金额
- 核心功能使用率
- 关键转化率
【数据表】
[列出相关表]
【输出格式】
- 生成可复用的SQL模板
- 只需修改日期参数就能执行
- 建议设置自动化定时任务
五、实战案例：我如何10分钟做了让老板叫好的分析
分享一个真实案例。
背景：
上周五下午4点，老板突然找我：
"新功能上线3天了，数据怎么样？明天早会要汇报。"
我心里一紧：完了，数据还没取...
传统做法：
- • 数据同学："我现在有个紧急需求，最快明天下午..."
我的AI做法（10分钟搞定）：
第1步：5W法明确需求（2分钟）
Why：判断新功能对留存的影响
What：使用率、留存率对比
Who：过去3天新增的用户
When：过去3天数据
Where：user_table, event_table
第2步：让AI生成SQL（3分钟）
我把需求发给AI，它给了我3段SQL：
我复制SQL，在数据库执行，拿到结果。
第3步：AI生成分析报告（5分钟）
我把数据发给AI，让它生成报告。
AI输出：
【新功能数据分析】
核心结论：
1. 使用率32%，符合预期（目标30%）
2. 使用用户留存率提升12个百分点（38% vs 26%）
3. iOS端效果更好，提升15个百分点
数据明细：
- 3天新增用户：15,000人
- 使用新功能：4,800人（32%）
- 使用用户次日留存：38%
- 未使用用户次日留存：26%
行动建议：
1. 功能效果显著，建议加大推广
2. Android端体验需优化（提升仅8%）
3. 增加引导，提升使用率到40%+
我复制到PPT，加了个图表，发给老板。
第二天早会：
老板看完说："这个分析很到位，数据维度都考虑到了。"
旁边的运营总监问："这是数据同学做的吗？"
老板："产品自己做的。"
那一刻，我知道这个方法对了。
关键点复盘
为什么10分钟就能做完？
最重要的是：
整个过程，我一句SQL都没写。
但数据分析的质量，不比数据同学差。
六、3个关键建议
做了3个月AI取数，我总结了3条经验。
建议1：数据思维比SQL语法更重要
很多产品经理纠结要不要学SQL。
我的答案：不用学，但要懂数据思维。
什么是数据思维？
场景：新功能上线，要做数据分析。
新手产品经理（没有数据思维）：
高阶产品经理（有数据思维）：
数据思维的核心：
SQL只是获取数据的工具。
AI可以替代SQL，但替代不了数据思维。
建议2：建立自己的Prompt库
刚开始用AI取数，你会发现：
每次都要重新描述需求，很累。
解决方法：建立自己的Prompt库。
我的做法：
效果：
取数时间从10分钟压缩到3分钟。
建议：
先用我这篇文章的8个Prompt开始。
用多了，根据自己的业务场景，不断补充。
3个月后，你会有一套完整的Prompt库。
建议3：学会验证数据准确性
用AI取数，最大的风险是：
你不知道数据对不对。
传统方式：
AI方式：
我的方法：3个验证技巧
技巧1：看数据是否符合常识
举例：
AI告诉你："昨天DAU是500万。"
你要想：
- • 上周DAU是多少？（如果是100万，突然变500万，肯定不对）
- • 总用户量是多少？（如果总用户才200万，DAU怎么可能500万？）
常识是第一道检验线。
技巧2：用简单查询验证复杂查询
举例：
AI生成了一个复杂的留存率查询。
你不确定对不对。
可以这样验证：
- 2. 再查"今天登录的昨天新增用户数"（简单查询）
如果差距很大，说明SQL有问题。
技巧3：让AI解释SQL逻辑
如果你还是不放心。
可以让AI解释SQL：
请用产品经理能懂的语言，解释这段SQL的逻辑。
每一步在做什么？
为什么这么做？
有没有可能遗漏的场景？
AI会给你一段人话版的解释。
你看完，就能判断逻辑对不对。
我的经验：
用这3个方法，AI生成的SQL准确率95%+。
剩下5%的问题，也能快速发现。
最后说几句
做了5年产品经理，我越来越觉得：
不会SQL不丢人，依赖别人才丢人。
以前，不会SQL，你只能等数据同学。
现在，AI可以帮你。
从"不会SQL"到"会用AI取数"，只需要10分钟学习成本。
但带来的改变是：
更重要的是：
你有了主动权。
想看什么数据，随时能看。
想验证什么假设，马上能验证。
这才是产品经理该有的状态。
想获得完整的AI取数Prompt库（含30+场景模板），关注公众号"Kris产品成长之路"，回复：
取数模板
我发你完整版，包括：
你在工作中最常需要取什么数据？遇到过哪些取数的尴尬场景？评论区聊聊。
下一篇聊《不会画原型的产品经理，如何用AI 5分钟生成专业交互稿》。我会分享如何用AI让原型设计效率提升10倍，即使你不会用Axure。
觉得有帮助，分享给你身边也在为SQL发愁的产品经理朋友，一起用AI提升数据能力。
彩蛋：我的AI取数工作流
很多朋友问我具体怎么操作，这里直接放出我的完整工作流：
工具准备
- 1. AI工具： Claude / ChatGPT / 豆包（都可以）
- 2. 数据库工具： DBeaver / Navicat / 公司内部平台
日常工作流
场景1：临时取数（10分钟）
1. 明确需求（用5W法，2分钟）
2. 打开Prompt库，找对应模板
3. 复制模板，填入具体参数
4. AI生成SQL（1分钟）
5. 数据库执行（1分钟）
6. AI生成分析报告（5分钟）
7. 复制到工作文档
场景2：定期报表（5分钟）
1. 已有SQL模板（上次AI生成的）
2. 只需修改日期参数
3. 执行查询（1分钟）
4. AI生成报告（4分钟）
5. 发送给相关人
场景3：复杂分析（30分钟）
1. 拆解成3-5个子问题（10分钟）
2. 每个子问题用AI生成SQL（10分钟）
3. 汇总所有数据
4. AI生成综合分析报告（10分钟）
5. 加上自己的业务判断
效率对比
3个月累计节省：约80小时。
这80小时，我用来：
时间省下来，用在更有价值的事情上。
这才是AI的真正价值。
粤ICP备14082021号
免费POC，
零成本试错
