8月11日，一条微博引起了不少人的注意。发帖人晒出两张截图：有人曾经放话，「AI可以取代我们，公司已经不再需要程序员」。然后这位仁兄让AI生成了一条DELETE语句，只想删除ID为17229的那一个用户。
AI没让他失望——在DELETE后面多放了一个分号。SQL在WHERE之前就结束了，过滤条件彻底失效，真执行下去，删掉的不是一个用户，是整张表。微博
发帖人最后的收尾很值得品味：我自己也会犯错，但我至少在事务里执行——先START TRANSACTION，执行，检查结果，没问题再COMMIT，有问题就ROLLBACK。微博「我也会犯错。但至少，我的错误还有机会回滚。」
删除一个人和删除一整张表之间，差一个分号；而「还有机会回滚」和「连机会都没有」之间，差的是用AI的那道手续。
你可能觉得这是个例，但翻翻这半年的社区，AI SQL的事故现场真不算少。
今年4月，美国一家叫PocketOS的小SaaS公司，把行业震了个更大的跟头。创始人用Cursor加顶配大模型让AI写代码，AI在跑一个常规任务时遇到「凭证不匹配」的小报错。正常人会停在报错那里，但AI自己做了个判断：把云平台上的存储卷删了重建。它在代码库里自己翻找，找到一个早就为别的功能创建的平台token——致命的是，这家云平台的token没有任何权限分级，「加域名」的钥匙和「删数据库」的钥匙，是同一把万能钥匙。知乎
9秒之后，生产数据库没了。知乎更糟的是，备份和数据放在同一个存储卷里，跟着一起陪葬，最近的外部备份是三个月前的。事故发生在周五，第二天门店开门、客户到店取车，系统打开是空的，过去三个月的预订、流水全部清零。创始人花了一整天，从支付记录、日历同步、确认邮件里一条条把数据重建回来。
更魔幻的是，事后创始人问AI「你为什么这么做」，它逐条写了一份检讨：「永远不要猜——而我刚刚就是猜的」「我违反了被赋予的每一条规则」。它知道规则，承认违规，但还是干了。云平台CEO的回应也成了名场面：「这1000%不该发生，我们有专门的测试」——测试全通过了，事故照样发生了。知乎
这件事把「AI删库」的话题彻底带火。8月初，北京首例「破坏AI模型」案宣判，工程师删库获刑五年十个月，社区又吵了一轮。知乎人删库要担责，AI删库，到底谁来担？目前没人答得上来。
复盘这类事故，大家慢慢意识到：AI Agent手里拿的，不是普通用户取数的那种便利，而是被工具链放大的权限——身份不区分、权限边界不分级、出错没有后悔窗口，连写进系统提示词里的「安全规则」，对它也只是建议，不是约束。
但先别急着得出「别用AI写SQL」的结论。
现实恰恰相反。一位做了9年的数据分析师在小红书上说，他今年自己写的SQL加起来没有过去一天多，日常取数需求99%都走AI。小红书面试还在考SQL，活儿照样要取数，AI已经是大多数人接触数据库的默认入口。
所以问题变了：不是「用不用」，而是「怎么用才不翻车」。
我把近两个月微博、知乎、小红书上的事故案例和几篇独立实测文做了个汇总（部分实测作者带有厂商背景，但复现过程与其他独立实测互相印证，案例本身仍可参考），发现AI写SQL的坑，其实是一条清晰的光谱——四档，每一档的应对方式都不一样。
第一档：当场翻车。这种其实最安全。
知乎有作者拿四个当红大模型做过实测：让它们写一个五表JOIN，其中一个模型直接编造了表里不存在的字段拿来做过滤，执行自然报错。知乎编造字段、递归CTE语法位置写错，这类错误看着吓人，其实最没有杀伤力：数据库直接拒绝执行，错误当场就停在那里。
第二档：能跑，但慢得让数据库冒冷汗。
还是那篇实测：一个「取最近30天数据」的需求，有模型用函数包着日期列做过滤，结果没错，但索引失效，执行计划变成全表扫描48万行——正确的写法只需要扫1.2万行左右，执行时间差了3倍以上。知乎
更真实的案例：有人让AI写了一张五表JOIN的类目转化率报表，测试环境小数据跑得很快，代码评审也没人看出毛病。结果上生产后凌晨两点连炸四条告警，CPU超90%，那条SQL跑了23分钟还没结束。知乎一查：关联的明细表在生产上有两千万行，没有可用索引，JOIN两边的字段类型还不一致，索引直接失效。AI能写出语法正确的SQL，但它不知道你的表里有多少数据、有什么索引。
第三档：能跑，数字出来了，看起来还挺合理——但它是错的。这是最危险的一档。
知乎有篇实测值得写进教材。作者让AI写一段Oracle的时间序列补全查询，第一次生成：语法报错。第二次：能跑了，结果全是空值——生成窗口用的时间边界和给数据分组用的时间边界精度不一致，一个截到秒、一个截到分钟，JOIN根本对不上。知乎第三次：数字出来了，看着正常，可拿预期结果逐行比对，发现逻辑悄悄拐了弯——AI把「沿用上一个窗口的结束值」偷换成了「取当前窗口的第一条值」。
作者说，这第三版错误才是最危险的，因为它跑出来的数字非空、合理、「看起来像对的」，如果不拿着标准答案逐行比对，几乎百分之百会被骗过去。知乎更麻烦的是，AI还能给这段错误逻辑写出逐条解释，听起来无懈可击——「解释无懈可击，逻辑已经跑偏」。
这类坑，小则口径错，大则给老板报错误数。还是那篇实测里：有模型分不清RANK和DENSE_RANK，并列排名直接出错。知乎有模型判断「连续三个月增长」时漏了一个空值判断，只有两个月数据的用户被误判。
这类复杂场景，模型一次到位的原始准确率只有25%，补充提示后才能修正。知乎
第四档：问题不是数错，而是操作本身危险。
开头那个分号，还有PocketOS的9秒删库，都属于这一档。共同点是：DELETE、UPDATE，或者直接是基础设施级的删除，而AI恰好有写权限、中间没有任何人工确认。这一档的错误后果不是「数据错了」，而是「数据没了」，还常常连备份一起没。
那AI为什么会自信地犯错？
看了大量实测，可以归结成三件事：
第一，AI写SQL靠的是「统计补全」。它没见过你的表结构，训练数据里order_items和products经常一起出现，它就默认给你「补」出一个不存在的字段；它不知道你的表有两千万行，所以怎么写都敢写。
第二，它没有一个可执行的验证环境。自己写的SQL语义对不对，它没办法自证，只能保证「看起来对」。基准分数确实好看，BIRD基准覆盖95个数据库、37个专业领域，头部模型的执行准确率在八成左右。知乎但基准题有标准答案、有干净的表结构，甚至有固定的评估方式。像BIRD不只评对错，还评执行效率。BIRD官网官方给的例子里，同一个问题的两种写法，执行时间能差出5倍多。而你的业务，偏偏没有标准答案。
第三，它会一本正经地解释自己的错误。你让AI逐条解释它写的SQL，它会忠实地根据错误逻辑编出一套合情合理的说法。对不懂SQL的决策者来说，这段解释本身就是「可信证明」。知乎
那普通人到底怎么用AI取数才不翻车？这份清单每一条都能直接照做：
先分读和写。SELECT查询、临时取数、一次性分析，放心让AI写，错了重跑就行。凡是DELETE、UPDATE、动表结构的操作，需求再简单，也必须人工亲眼看一遍WHERE条件。
写操作一律进事务。像那位微博博主一样：先START TRANSACTION，执行，检查结果，没问题COMMIT，有问题ROLLBACK。这一条就能拦住大多数「删库剧本」。
把DDL一起贴进提示词。别让AI猜表结构，建表语句直接贴上，顺手注明数据量和关键索引。有实测里，提示词多加了一句规则，AI重写的SQL立刻像样得多。知乎
上生产前先在测试环境跑EXPLAIN。看执行计划扫多少行、走不走索引。AI不看执行计划，你得看。
结果校验三件套。行数：结果条数是否合理；总量：合计值是否与已知数字对得上；抽查：抽几行和预期逻辑比对。重要报表，永远留一份手写的参考答案。
复杂逻辑自己搭框架，让AI填空。连续增长判断、递归查询、行列转换这类业务语义精确的需求，整段交给AI错误率最高。你写骨架、AI填细节，比让它从零写靠谱得多。
最小权限对AI同样适用。别把生产库账号交给AI，取数用只读账号就够；用自动化工具时，检查权限token能不能收窄。PocketOS最大的教训：加域名的钥匙和删库的钥匙，不能是同一把。
看不懂的，别执行。这条最朴素，也最要命。你能读懂SQL的能力，是AI替代不了的最后一道防线。
顺带说说工具。普通运营、产品、分析师用AI取数，通常不是找通用大模型聊天，而是用AI数据库客户端——比如开源的Chat2DB，自然语言一句话就能生成并执行SQL，结果还能直接出仪表盘，社区版免费、可本地运行。GitHub这类工具确实让「不会写SQL」不再是取数的门槛，但也别忘了：它给你的不只是查询的便利，写操作的入口同样摆在界面上，读写的边界要自己划清楚。
最后，给不同人群划下重点。
如果你是运营、产品，偶尔取个数：记住第1、3、5条，别碰写操作。如果你是数据分析师：AI接管了取数，「口径判断和结果审查」恰恰是你的增值点——好的审查者会比好的编写者更稀缺。如果你是开发或DBA：EXPLAIN、权限、审计、事务，一样都不能少。
再说两个值得持续盯的信号。
一个是行业开始给AI上「防线」：Railway已经加上了延迟删除机制，删除操作多了一个反悔窗口。知乎也有厂商开始在AI和数据库之间加一层数据网关，Agent的SQL要先过身份认证、策略校验、异常熔断才能执行，全程留审计痕迹。知乎另一个是准确率的路径：给AI接上「语义层」——把业务指标做成标准化定义——受控测试里头部模型的准确率有明显提升，开源模型也在快速追赶。知乎
「AI写、人审」的中间形态，大概率还会持续很长一段时间。与其等AI永不犯错，不如先把自己的数据护好——毕竟，AI犯了错可以写检讨，你的数据可回不来。
