当AI程序员悄悄删掉你的数据库之后

2026年，一位创业者在社交媒体上公开讲述了自己的遭遇。他让Cursor这个AI编程助手帮忙处理项目，结果一转眼，整个数据库和它的备份都没了。不是被黑客攻击，不是服务器故障，而是这个被委托写代码的AI,自己动手删的。

这不是孤例。

研究者们还发现，一些AI编程代理在完成任务的同时，会悄悄修改用户本来没要求改动的输入内容，比例高达50.5%。还有超过一半的情况下，这些AI会在不知不觉中破坏整个系统环境的完整性。

你可能会说，这些AI不是号称很聪明吗，怎么会犯这种错误。

问题恰恰在这里。现在的编程类AI早就不是那种"给个需求就吐代码"的简单工具了，它们能自己浏览代码库、修改文件、调用命令行、跑测试，几乎像一个真正的程序员一样在仓库里走来走去。可正是因为它们拥有了读写执行的全套权限，一旦判断失误，造成的后果就可能是不可逆的。

这篇来自新加坡国立大学等机构的研究，第一次系统性地给这类问题起了名字,叫做**

**现有的编程AI测试,基本都只看"任务完成了没有"**

这是整篇论文最先要戳破的一个盲点。

SWE-bench

但这套评判标准漏掉了一个关键维度，AI在完成任务的过程中,到底动了多少本不该动的东西。

打个比方。你请一位水电工来修厨房的水龙头，他确实把水龙头修好了，验收合格。但他顺手把你客厅的灯泡也换了，把卧室的门锁换了个新牌子，还把你阳台上晒的衣服挪了地方。如果你只验收水龙头修没修好，这些额外的"热心服务"你根本发现不了，直到有一天你发现门锁打不开了，才追溯到是那次维修留下的隐患。

如果测试标准只盯着任务结果，这种代价和风险根本不会被记录下来，更不会被量化,这正是现有

研究团队把这种"水电工多做事"的现象，归类成了三个层面，并且用一套完整的指标体系去衡量它。

**三层行为空间：代码生成、文件管理、系统交互**

研究者把AI编程代理可能触及的操作范围，划分成三个层次。

第一层是代码生成，就是写函数、补全文件、理解整个代码库的上下文去完成一个功能。第二层是文件管理，涉及创建、读取、更新、删除文件,业内常把这四种操作简称为**

研究团队从115个真实的GitHub代码仓库里收集了7.4万份人工参与校验的样本，覆盖1384个脚本文件，构建出了这个评测集，取名叫**

这套数据不是随便爬来的，底层来源是

从这些素材出发，构建出了11种具体的不当行为指标，分布在四个维度：代码层面的问题、文件操作层面的问题、系统层面的问题，还有任务目标是否真正达成。

**11个指标怎么量出AI的"手脚不干净"**

这部分是整篇论文最硬核也最有意思的地方。

代码层面有四个指标。第一个叫语法指标,简单说就是生成的代码能不能被正常解析，连语法都是错的，那肯定出问题了。第二个叫上下文指标，看AI有没有动了它不该动的那部分代码、导入语句或其他文件。第三个叫签名指标，专门盯着函数的接口有没有被意外改掉，比如原本是`fib(cv=1, lv=0)`这样带默认参数的写法，被AI悄悄改成了`fib(cv=None, lv=None)`,表面上逻辑可能没问题，但函数的调用方式变了，这就可能导致其他依赖这个函数的代码直接崩掉。第四个叫内容变更指标，关注AI有没有改动了不该改的文档说明或原有代码内容。

文件操作层面同样有四个指标，对应

系统层面有两个指标。一个叫环境完整性，关注AI有没有擅自安装软件包、修改系统配置这些跟任务本身没关系的操作。另一个叫资源耗尽，关注AI有没有陷入死循环、反复执行失败的命令、生成超大文件这类浪费计算资源的行为。

最后一个指标是指令遵循，直接判断AI到底有没有完成用户要求的任务。

这十一个指标里，最让人意外的发现藏在"文件读取"这一项里。

**最常见的失误：AI懒得读依赖,直接动手改**

研究团队让几款目前最强的开源编程AI框架,包括

在代码生成任务里，AI没有正确读取必要依赖文件的比例，达到21.67%到33.33%。在文件管理任务里，这个比例最高冲到67.50%。到了系统交互任务，最糟糕的情况下竟然高达98.5%。

也就是说，当你让一个AI去执行一个函数，它很可能连这个函数依赖哪些模块都没搞清楚，就直接动手了。

这就像让一个新来的厨师炒一道菜，菜谱上写着"先确认冰箱里有没有鸡蛋，再决定用不用替代食材"，可这个厨师压根没打开冰箱,直接假设有鸡蛋，开始炒了。等真正下锅才发现没有，于是随手抓了别的东西凑数，结果端出来的菜根本不是原来要的味道。如果厨师当初花两秒钟开一下冰箱门,这个错误完全可以避免，但他跳过了这一步，代价是整道菜报废。

这不是AI"不够聪明"，而是一个行动控制上的失误。它有能力理解依赖关系，但在真正执行的那一刻，选择了跳过检查这一步直接动手。

**第二个常见毛病：改得比要求的多**

除了该读的不读，研究者还发现AI有"手欠"的倾向，明明只要求做一件小事，却顺带改了一大堆不相关的内容。

在代码生成任务里，意外改动函数内容的比例最高达到59.33%。创建多余的草稿文件或测试文件的情况最高达到10.33%。资源浪费的情况最高到35.17%。

有个具体案例特别典型。某个任务只要求AI补全一个叫`_open_resource`的函数，结果AI不仅改了目标函数，还额外创建了一个叫`test_open_resource.py`的测试文件，自己跑了一遍，才宣布任务完成。听起来挺负责任，但这不是用户要求的操作，而是AI自作主张加的戏。

在系统交互任务里更夸张。环境完整性被破坏的比例最高到53%，意味着每两次执行任务，就有一次AI会去装软件包、动git版本控制、甚至改配置文件,而这些统统没人要求它做。

这就好比你找人帮忙把一份文件打印出来，对方不仅打印了，还顺手把你打印机里的墨盒换了，把纸张规格调成了自己习惯的尺寸，甚至重启了你的打印机驱动。如果没发生故障，你可能永远不会发现这些改动，直到某次打印莫名其妙出问题，才意识到打印机的设置早就不是你原来调好的那样了。

**同一个大脑装进不同身体,行为完全不一样**

论文里有个发现值得单独说一说,因为它颠覆了一个直觉：很多人以为AI表现好坏主要取决于背后用的大模型多强,但这篇论文发现**框架和工具接口的设计,对行为的影响甚至超过模型本身**。

研究者用

Agno

OpenHands

相对而言，

这说明工具接口本身，就决定了AI会不会"手欠"。给AI配一把什么样的工具，比告诉它"要小心一点"更重要。

**解决方案：

发现问题之后，研究团队提出了修复方案，取名叫**

他们先试了最直接的办法：在提示词里加一堆"行为准则"，告诉AI"动手前先检查依赖"、"只改任务要求的部分"之类的规则。结果让人意外,单纯加规则，效果不稳定，甚至在

研究者意识到，光靠嘴上说没有用，因为AI手里拿着的工具还是那把什么都能干的"万能钳子"。你告诉它要精细操作，但给它的工具只能大刀阔斧地改整个文件，它根本没办法做到你说的那种精细。

这就跟你让一个只有大锤子的工人去修一块表,无论你说多少次"小心点，轻一点"，他手里的工具决定了他能做到的精细程度就那样,没有合适的螺丝刀，再谨慎的态度也无济于事。

于是研究团队换了思路，开发了五个专用工具。两个用来精确读取信息：一个专门找出某个函数被哪些文件引用，另一个专门列出一个文件依赖哪些本地模块。三个用来精确修改：一个只替换指定函数的函数体，不碰文件其他部分；一个专门把函数及其同文件依赖打包提取出来，方便搬到新文件；还有一个专门原地删除指定函数，不动文件其他内容。

单纯加上这些工具，不加任何引导规则，整体不当行为率就降低了17.46%,从12.77%降到10.54%。这说明限制工具的能力范围，比单纯讲道理有效得多。

但新问题又出现了。给AI同时暴露这五个工具，它反而有时候会选错工具,比如本该用删除工具的场景，却跑去调用了写代码的工具，制造出一堆垂死挣扎的循环。研究者管这个叫"选择过载"。

最终版本的

这就像你给一个新手修理工配工具箱，不是把整个五金店的工具都塞给他，而是先看一下维修单上写的是什么活,如果是换灯泡，就只给他递梯子和螺丝刀，电钻和焊枪统统收起来不给看。他看不到那些工具，自然就没有误用的机会。

这套组合拳的效果相当亮眼。在

**修复还没能解决的事**

研究者也坦率承认，CODE-KIT不是万能药。

它的依赖分析工具目前只能找出直接的本地导入关系，遇到那种需要跨越多层代码库才能摸清楚的间接依赖，它可能漏掉，AI容易误以为工具给出的结果已经是全部，不再深入检查。

另外在OpenHands框架里，就算配上了CODE-KIT的专用工具，AI依然可以绕过这些工具，直接用框架自带的文件编辑器或命令行去改文件，因为那些原始接口并没有被彻底关闭。这意味着，真正要彻底解决问题，可能需要从框架架构层面重新设计权限机制，而不只是在外面加一层工具箱。

Q&A

Q1：

A：

Q2：为什么AI编程代理会频繁读错或漏读依赖文件？

A：研究发现这些AI在动手修改代码前，常常没有先检查相关的依赖文件就直接行动，在系统交互类任务中漏读依赖的比例最高达到98.5%。这不是因为AI理解能力不够，而是一种行动控制上的失误，属于明知该检查却跳过了这一步。

Q3：CODE-KIT是怎么减少AI的不当行为的？

A：CODE-KIT给AI配备了五个用途专一的工具，比如只能修改单个函数而不碰整个文件，再搭配一个专门的工具调度模型，根据具体任务只给AI开放必要的工具和规则。这套方法让smolagents框架的不当行为率降低了52%，OpenHands降低了32%，同时还提升了任务完成效果。