收藏夹里躺着几篇「文科生零基础SQL入门」「61段SQL取数核心代码」，正准备开学，结果刷到这么一个问题：AI都能写SQL了，数据工程师会是第一批被替代的岗位吗？知乎类似的讨论最近密集出现，连B站都有人问：AI那么强，27届秋招还要学SQLBIPython么？哔哩哔哩
先别急着删收藏夹，也别急着全押AI。现在的AI，用大白话描述一句需求，几秒钟确实能交回一段可运行的查询语句。
但「能写出来」和「敢直接用」是两回事。这篇文章把最近的实测和讨论捋一遍：AI的真实水平在哪，哪些能力必须长在自己身上，哪些可以彻底外包给它。
AI写SQL，真实水平到底怎么样
一位做Text2SQL产品的开发者出了套认真的考卷：41道题，分日常查询、统计分析、高级分析、专家级四档，覆盖过滤、聚合、排名、用户分析、趋势分析六类场景，然后让AI正式考试。先说成绩：78分（32/41）。知乎
这个分数不算低，但更值得看的是对9道挂科题的复盘：没有一道是因为AI「写不出SQL」而失败的。知乎3道栽在LIMIT这类细节上，一句提示词就能修复；4道栽在语义歧义上；2道栽在概念理解偏差上。
这次实测给出的结论很关键：瓶颈不在SQL生成能力，而在需求理解。知乎
错起来有多隐蔽？举两个真题。题目要求统计「连续3个月」的活跃用户，AI理解成了「最近3个月里每个月都活跃」，差一个「连续」的语义理解，结果差了一倍（4999 vs 2466）。知乎
帕累托分析更是直接把方向搞反。「找出销售额占总额前20%的产品」，正确含义是贡献了80%销售额的那些头部产品，AI却理解成了「累计占比≤20%的产品」，结果从13个变成了2个。知乎这种「知道这个词但理解反了」的错误，说明它的知识是碎片化的。
另一个实测更硬核：有人让大模型写一段Oracle的时间窗口补全SQL，需求不复杂，手写也就十几分钟。结果：六轮对话、三次生成、两次人工纠错，才勉强把它拉到正确的轨道上。知乎
而且错误是一次比一次「吓人」：第一次语法不合规，跑都跑不起来——这反而是最无害的；第二次跑通了，结果全是NULL，因为时间边界一边按秒、一边截断到分钟，LEFT JOIN根本匹配不上；第三次数字出来了，看起来一切正常，逻辑却偷偷拐了弯——窗口取数值时取了当前窗口的第一条记录，而不是需求要求的前一窗口结束值。如果不拿着事先准备好的正确答案逐行比对，你几乎百分之百会被它骗过去。知乎
一句话总结：AI写SQL，语法错误是小问题，数据库会直接报错；真正危险的是逻辑错误——SQL能跑通，结果也「看起来合理」，但口径和你的需求之间存在偏差。知乎更麻烦的是，如果你让大模型为每一步生成自然语言描述，它会忠实地根据它自己写的错误SQL，编造出一串合情合理的解释。知乎
所以社区里有个说法得到了不少认同：人的角色从一个「SQL编写者」变成了「SQL审查员」。知乎
而且这个审查员并不好当：审查一段由机器生成的、冗长且高度拆分的SQL，脑力负担其实比亲自写更大。知乎
为什么还是得学
第一，责任不会转移。你把一段AI写的查询丢进数据库执行，其实是在用自己的专业信誉为它背书。结果对不对、口径准不准，最终责任在你，不在AI。你可以不写，但你得看得懂。知乎
第二，AI的错恰恰需要「看得懂」才能抓住。比如AI用了LEFT JOIN但你的场景需要INNER JOIN，比如过滤条件漏掉了某个状态值，比如聚合粒度和你期望的不一致。知乎这类问题不看SQL本身，光看结果根本发现不了。定位不了问题出在哪，你就只能反复重试、碰运气，效率比手写还低。
第三，也是那套78分考卷给出的最重要提示：AI错的9道题，全部错在「没理解需求」。也就是说，人机分工之后真正升值的，是把需求说清楚、把口径定义准确、把结果验证明白的能力——而这些能力的基础，恰恰是你对表结构、字段含义、数据粒度的理解。这些正是学SQL学到的东西。
该学到什么程度？一份清单
对大多数为了求职和日常取数学SQL的人（不是要当DBA），建议把学习内容分成三档。
第一档，必须学。这是你的判断力，AI替代不了：查询的执行顺序（FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY），搞懂这一条能避开一半的入门坑；JOIN的类型和适用场景；聚合粒度——你按什么分组，数字就是什么含义；窗口函数，至少搞懂row_number、rank、sum() over的用途；用CTE（WITH）把逻辑拆清楚，这也是看懂AI产出的基本功。你需要的是理解SQL的核心概念（JOIN的类型和适用场景、聚合的粒度控制、子查询与CTE的区别），而不是记住每一种语法的写法。知乎
第二档，看得懂就行。窗口函数的各种组合写法、正则表达式、递归CTE的语法细节、深层嵌套子查询的调优技巧——知道它是干什么的、大概怎么工作，AI写出来你能读明白即可，不用背。
第三档，交给AI。语法记忆、样板代码、各数据库的方言差异、长SQL的初稿，都可以丢给它。但记住：它交出来的每一段都要你验证。78%意味着每问5个问题就有1个可能不准，而企业客户的心理底线是90%+。知乎
学法也不一样了
老路子是看教程、刷题、卡住了问人。现在可以把AI当教练，而不是答案机：自己先写一段，让它逐行帮你review，看逻辑哪里有漏洞；让它按你的薄弱环节出题，比如「给我出三道关于多表JOIN的练习题，用电商场景」。知乎
最推荐的是用「审查AI作业」的心态练习：先让AI生成一版，你来挑毛病，再对照验证。这恰好是职场上最值钱的那个技能，从学习第一天就开始练，等于抄了捷径。
基础语法部分，一个知识点一张卡片就够。像下面这种SELECT、WHERE、INSERT、UPDATE的四象限图解，语法、要点、示例都在一页里，搞懂一个主题，再让AI围绕它出一组练习题，这个知识点就算过手了。
不同人，重点不一样
求职党（运营、产品、数据分析方向）：核心是取数逻辑和口径表达。注意，现阶段面试仍然考手写：union和join的区别、常用的窗口函数、rank与dense_rank和row_number的区别，这些高频题AI替不了你上场。小红书
在职取数党：重点是审查能力。建议给自己建一份业务术语表，把「活跃」「复购」「连续N月」这些词的标准口径固定下来——AI出错的最大来源就是语义歧义，口径提前锁死，能消掉一半的坑。
开发同学：任何SQL上线前必须跑EXPLAIN看执行计划。知乎不管这段SQL是AI写的还是你写的。
最后说点值得盯的
Text2SQL这个方向还在快速进化，已经有人在做「语义层」的方案——先把业务口径固化成规则，再让AI在规则内生成SQL，这条线值得持续关注。但对个人来说，现阶段的判断其实不变：语法可以交给AI，原理必须长在自己脑子里。2026年学SQL，不是为了写得比AI快，而是为了在AI写完之后，你能判断它对不对。
SQL在AI时代的定位变了：它从一项「必须熟练手写」的硬技能，变成了一项「必须深刻理解」的底层素养。知乎
