关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集别让你的DBA在凌晨三点接到那通电话大家好我是某互联网公司数据平台团队的负责人负责数据治理和ETL体系建设。今天聊一个让我至今心有余悸的事故——我们的AI数据清洗助手因为吃了生产环境的脏数据反手生成了一段把核心业务表全表清空的SQL脚本。万幸的是我们在预发布环境拦截了没有酿成大祸。但复盘的过程让我出了一身冷汗。一、故事的起点让AI自学数据清洗规则去年年底我们上线了一个AI辅助数据清洗的工具。核心思路很简单——把生产环境的历史数据喂给大模型让它自动学习数据分布、识别异常模式、生成清洗脚本。这个想法在当时看起来非常合理。我们的数据湖里有几百张表每张表都有各种各样的脏数据——空值、格式错误、重复记录、业务逻辑异常。人工写清洗脚本每张表要花2-3天几百张表根本忙不过来。AI如果能学会怎么清洗效率提升将是巨大的。架构是这样的从生产环境抽取样本数据脱敏后喂给大模型分析数据分布和异常模式AI自动生成对应的清洗SQL脚本DBA审核后执行前两个月跑得挺好。AI确实能识别出不少人工容易漏掉的异常模式生成的脚本准确率也在稳步提升。团队上下都很兴奋觉得终于找到了数据治理的银弹。直到第三个月出了事。二、事故重现那条完美的SQL那天AI针对一张核心用户表生成了清洗脚本。脚本结构规整、注释完整、逻辑清晰——和之前几百条脚本看起来没有任何区别。但DBA老张在审核时多看了一眼发现了问题。AI生成的脚本里有一段DELETE语句是这样的DELETE FROM user_profileWHERE 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_profileWHERE 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里强制加入以下约束【硬性约束】不得臆想任何字段名所有字段必须从提供的表结构中选取任何DELETE/UPDATE操作必须附带明确的WHERE条件涉及多表关联的操作必须用注释说明关联逻辑的业务含义生成脚本后必须自检如果这个脚本执行错了最坏的后果是什么同时在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次不要这么做但全都无效。”看到这些案例我只有一个感受我们那次没出事纯粹是运气好。六、给同行的一些建议基于这次事故和复盘我有几点实在的建议永远不要让AI直接操作生产环境AI生成的代码必须在隔离环境中验证。 这不是对AI的不信任而是对生产环境的基本尊重。任何涉及生产数据的操作必须有人在回路里。给AI喂什么数据决定了它输出什么质量脏数据喂给AIAI只会生成更脏的脚本。 数据质量是AI生成代码质量的天花板。在让AI学习之前先把训练数据本身清洗干净——字段定义统一、数据分布正常、业务逻辑清晰。审核不是走流程是真正的安全阀我们前两个月就是吃了审核流于形式的亏。AI表现越好越要警惕——因为它的错误会藏得更深、更隐蔽。DBA老张事后说了一句话我记到现在AI最危险的地方不是它写得差是它写得太像那么回事了。 建立假设它有问题的文化在团队里建立一种文化任何AI生成的内容默认是有问题的。 审核的目的不是找有没有问题而是证明它没有问题。这个心态的转变比任何技术手段都重要。危险的不是AI是省掉的那一步我们复盘时发现每次出问题的脚本都跳过了某个关键步骤——没做字段验证、没在测试环境跑、没做数据量预估。AI不会主动跳过这些步骤是人选择跳过的。 危险的不是AI是我们自己为了省事而省略的那些环节。最后事故之后我们没有停用AI清洗工具——它确实能提效这是事实。但我们彻底改变了使用方式AI负责生成初稿人负责最终决策 。AI从决策者退回了辅助工具的位置而DBA重新拿回了审核的主动权。现在我们的流程是AI生成脚本 → 沙箱自动验证 → DBA逐行审核 → 测试环境执行 → 生产环境上线。每一步都有明确的负责人和checklist没有任何一步是可以跳过的。数据清洗的效率确实降了一些——从AI直接出脚本变成了AI出草稿、人审核、沙箱验证的多步流程。但安全比效率重要一万倍。最后送大家一句话是我在事故复盘文档里写的第一句“AI可以帮你写代码但不能替你承担责任。”本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。本文系作者基于真实事故的复盘总结文中数据已做脱敏处理。欢迎同行交流讨论。
