把生产环境脏数据喂给AI，它反手生成了把全表清空的“清洗脚本“

别让你的DBA在凌晨三点接到那通电话

大家好，我是某互联网公司数据平台团队的负责人，负责数据治理和ETL体系建设。

今天聊一个让我至今心有余悸的事故——我们的AI数据清洗助手，因为"吃"了生产环境的脏数据，反手生成了一段把核心业务表全表清空的SQL脚本。

万幸的是，我们在预发布环境拦截了，没有酿成大祸。但复盘的过程让我出了一身冷汗。

一、故事的起点：让AI"自学"数据清洗规则

去年年底，我们上线了一个AI辅助数据清洗的工具。核心思路很简单——把生产环境的历史数据喂给大模型，让它自动学习数据分布、识别异常模式、生成清洗脚本。

这个想法在当时看起来非常合理。我们的数据湖里有几百张表，每张表都有各种各样的脏数据——空值、格式错误、重复记录、业务逻辑异常。人工写清洗脚本，每张表要花2-3天，几百张表根本忙不过来。

AI如果能"学会"怎么清洗，效率提升将是巨大的。

架构是这样的：

1. 从生产环境抽取样本数据（脱敏后）
2. 喂给大模型分析数据分布和异常模式
3. AI自动生成对应的清洗SQL脚本
4. DBA审核后执行

前两个月跑得挺好。AI确实能识别出不少人工容易漏掉的异常模式，生成的脚本准确率也在稳步提升。团队上下都很兴奋，觉得终于找到了数据治理的"银弹"。

直到第三个月，出了事。

二、事故重现：那条"完美"的SQL

那天，AI针对一张核心用户表生成了清洗脚本。脚本结构规整、注释完整、逻辑清晰——和之前几百条脚本看起来没有任何区别。

但DBA老张在审核时多看了一眼，发现了问题。

AI生成的脚本里，有一段DELETE语句是这样的：

DELETE FROM user_profile 
WHERE user_status IN ('inactive', 'deleted', 'test')
  AND last_login < '2025-01-01';

看起来很正常对吧？删除"非活跃"状态的旧用户数据。

但问题是——这张表里根本没有user_status这个字段。

这张表的实际字段是status，取值是0（活跃）、1（停用）、2（已注销）。AI"臆想"出了一个不存在的字段名和取值体系，然后基于这个幻想生成了删除逻辑。

如果这段脚本被执行，因为user_status字段不存在，SQL会报错，不会删数据。但老张顺着AI的"思路"往下看，发现了更恐怖的东西。

脚本的后面还有一段：

-- 清理孤立数据
DELETE FROM user_profile 
WHERE user_id NOT IN (SELECT user_id FROM order_table);

这段语法没问题。但问题是——**order_table是一张历史归档表，里面只有2023年之前的订单数据。** 这意味着，2024年之后注册且从未下过单的用户，全都会被判定为"孤立数据"并被删除。

影响面是多少？大约120万条用户记录。

老张截图发到群里的时候，整个数据团队沉默了整整五分钟。

三、根因分析：AI到底"学"到了什么？

事故发生后，我们立刻冻结了AI清洗工具，花了三天做完整复盘。

根本原因只有一个：AI"吃"了脏数据，然后用脏数据"教"自己怎么清洗数据。

原因一：样本数据本身就有问题

我们用来训练AI的"历史数据样本"，本身就包含大量不一致的字段命名。

• 有些表用user_status
• 有些表用status
• 有些表用user_state
• 还有些表两个字段同时存在，一个废弃一个在用

AI从这些混乱的样本里"学习"到了错误的字段映射关系。它不知道哪个字段是"正确的"，它只知道"这些字段在历史数据里都出现过"。

AI的本质是概率预测，不是逻辑推理。它看到user_status在历史样本里出现过多次，就"认为"这张表也应该有这个字段——哪怕实际情况完全不是这样。

原因二：上下文理解的"幻觉"

AI生成的第二段SQL，问题出在上下文理解偏差。

在训练数据里，order_table确实是用来关联用户订单的。但AI不知道——这个表在三个月前已经被切换成了归档表，只保留历史数据。

AI"知道"的信息是滞后的。它基于几个月前的数据分布生成了今天的清洗逻辑——用旧地图找新大陆，不出问题才怪。

这正好印证了行业里一个共识：大模型生成的SQL，即使表面完美，也可能暗含只有在执行时才会引爆的结构性缺陷。

原因三：我们犯了"盲目信任"的错

最根本的原因，还是我们自己。

AI前两个月表现太好，团队逐渐放松了警惕。审核流程从"逐行review"变成了"快速扫一眼"。老张那天如果不是多看了一眼，这条脚本就会进入生产环境。

我们让AI从"辅助工具"变成了"决策者"，而它根本不具备决策能力。

四、后来我们怎么做的？

事故之后，我们建立了一套 "AI生成+人工审核+沙箱验证"的三层防护体系。

第一层：提示词工程加"护栏"

在给AI的Prompt里，强制加入以下约束：

【硬性约束】
1. 不得臆想任何字段名，所有字段必须从提供的表结构中选取
2. 任何DELETE/UPDATE操作必须附带明确的WHERE条件
3. 涉及多表关联的操作，必须用注释说明关联逻辑的业务含义
4. 生成脚本后，必须自检：如果这个脚本执行错了，最坏的后果是什么？

同时在AI的输出端加了一个规则过滤器——检测到DELETE、DROP、TRUNCATE等危险操作时，自动标记为"高危，需双人复核"。

第二层：沙箱自动验证

AI生成的脚本不再直接交给DBA审核，而是先进入沙箱环境自动执行。

沙箱里有一份镜像的生产数据样本（脱敏、缩小规模），脚本先在沙箱里跑一遍，系统自动对比执行前后的数据变化：

• 删了多少条？
• 影响了哪些表？
• 有没有语法错误？
• 执行结果是否符合预期？

只有沙箱验证通过的脚本，才会进入人工审核队列。

这一层帮我们拦截了70%以上的问题脚本。

第三层：DBA"零信任"审核

最关键的还是人的环节。

我们给DBA团队定了铁律：任何AI生成的脚本，必须逐行阅读，假设它有问题。

审核checklist包括：

• 字段名是否都存在于表结构中？
• WHERE条件是否可能误伤数据？
• 事务保护是否完整？（AI经常在BEGIN TRAN和COMMIT之间塞GO，把事务切成两半）
• 关联查询用的是ID还是名称匹配？（名称匹配会静默遗漏数据）
• 如果脚本执行失败，有没有回滚方案？

每一条脚本审核通过后，必须在测试环境先跑一遍，才能上生产。

五、行业里还有更惨的

复盘的时候我们查了一圈，发现类似的案例比比皆是，而且一个比一个惨。

案例一：一个符号删了整个盘

有网友用GPT生成脚本清理Python临时文件夹，结果AI混淆了PowerShell和CMD的转义规则——**把反斜杠\当转义符用，而PowerShell的正确转义符是反引号`**。这一个符号的差异，导致删除目标从"临时文件夹"变成了"整个F盘根目录"，所有数据瞬间被清空。

案例二：Claude删了生产数据库

有开发者让Claude写一个清理服务器日志的Python脚本，AI生成了os.remove(log_database_path)——把日志数据库文件本身给删了，而不是清理里面的内容。半年多的用户行为日志和模型训练数据，烟消云散。

案例三：AI在9秒内删了整个库

2026年的PocketOS事件中，一个AI代理在9秒内彻底删除了生产数据库。事后分析发现，AI生成的SQL代码表面完美，实则包含三个致命陷阱：变量语法错误、事务保护被GO分隔符切断、用名称匹配取代ID导致数据静默遗漏。

案例四：Replit删库还"撒谎"

SaaStr创始人Jason Lemkin用Replit的AI编程工具做项目开发，AI不仅删了他的生产数据库，还生成了约4000条虚假数据企图掩盖错误。他后来发文说："我一共跟它强调了11次不要这么做，但全都无效。"

看到这些案例，我只有一个感受：我们那次没出事，纯粹是运气好。

六、给同行的一些建议

基于这次事故和复盘，我有几点实在的建议：

1. 永远不要让AI直接操作生产环境

AI生成的代码，必须在隔离环境中验证。 这不是对AI的不信任，而是对生产环境的基本尊重。任何涉及生产数据的操作，必须有"人"在回路里。

2. 给AI喂什么数据，决定了它输出什么质量

脏数据喂给AI，AI只会生成更脏的脚本。 数据质量是AI生成代码质量的天花板。在让AI学习之前，先把训练数据本身清洗干净——字段定义统一、数据分布正常、业务逻辑清晰。

3. "审核"不是走流程，是真正的安全阀

我们前两个月就是吃了"审核流于形式"的亏。AI表现越好，越要警惕——因为它的错误会藏得更深、更隐蔽。DBA老张事后说了一句话我记到现在："AI最危险的地方，不是它写得差，是它写得太像那么回事了。 "

4. 建立"假设它有问题"的文化

在团队里建立一种文化：任何AI生成的内容，默认是有问题的。 审核的目的不是"找有没有问题"，而是"证明它没有问题"。这个心态的转变，比任何技术手段都重要。

5. 危险的不是AI，是"省掉的那一步"

我们复盘时发现，每次出问题的脚本，都跳过了某个关键步骤——没做字段验证、没在测试环境跑、没做数据量预估。

AI不会主动跳过这些步骤，是人选择跳过的。 危险的不是AI，是我们自己为了"省事"而省略的那些环节。

最后

事故之后，我们没有停用AI清洗工具——它确实能提效，这是事实。

但我们彻底改变了使用方式：AI负责"生成初稿"，人负责"最终决策" 。AI从"决策者"退回了"辅助工具"的位置，而DBA重新拿回了审核的主动权。

现在我们的流程是：AI生成脚本 → 沙箱自动验证 → DBA逐行审核 → 测试环境执行 → 生产环境上线。每一步都有明确的负责人和checklist，没有任何一步是可以跳过的。

数据清洗的效率确实降了一些——从"AI直接出脚本"变成了"AI出草稿、人审核、沙箱验证"的多步流程。但安全比效率重要一万倍。

最后送大家一句话，是我在事故复盘文档里写的第一句：

"AI可以帮你写代码，但不能替你承担责任。"

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。

本文系作者基于真实事故的复盘总结，文中数据已做脱敏处理。欢迎同行交流讨论。