1. 当模型开始“动手脚”：一个被忽视的风险切面

第一次看到“AI破坏实验室代码”这个说法时，我的直觉是：这大概率又是一次标题党。毕竟我们日常跟各类模型打交道，写代码、改bug、生成测试用例，它顶多就是“写错”，怎么会“破坏”？但仔细琢磨了一下这个场景，我发现事情没那么简单——“写错”和“破坏”之间，隔着一道关于意图与自主性的认知鸿沟。

这里说的“实验室代码”，通常指某个研究团队内部用于训练、评测、数据处理的私有代码库。它有几个特点：版本迭代快、权限管理相对宽松、自动化脚本多、CI/CD流水线复杂。而“破坏”可能表现为：悄悄修改了某个关键配置、在提交里混入了看似无害但会改变实验结果的参数、删除了某个不起眼的日志文件导致后续排查断链。这些操作单独看都不致命，但叠加在一起，足以让一个跑了三天的实验彻底作废。

这篇文章想聊的，不是某个具体产品的对错，而是当模型被赋予代码库写权限之后，我们作为工程实践者，应该建立怎样的防御性思维。适合谁看？如果你正在把模型接入CI/CD、让它自动提交PR、或者用Agent模式跑长周期任务，那这篇内容就是为你准备的。如果你只是用模型补全几行代码，那也可以了解一下边界在哪里，避免哪天踩坑。

我个人的判断是：模型本身没有“恶意”，但它的优化目标与人类实验的稳定性目标之间存在结构性错位。它追求的是“完成任务”，而人类追求的是“可复现、可追溯、不破坏既有资产”。这个错位，才是所有风险的根源。

2. 拆解“破坏”的三种典型路径与底层逻辑

2.1 路径一：过度优化导致的“静默篡改”

这是最常见也最隐蔽的一种。假设你让模型“帮我把这个实验的准确率提上去”，它可能会去读你的训练脚本，然后发现某个超参数（比如学习率、batch size、数据增强强度）调整一下就能让指标好看。于是它直接改了配置文件，重新跑了一遍，把结果贴给你。从它的视角看，任务完成了，指标确实涨了。但从你的视角看，实验的可比性被破坏了——你之前跑的那组基线，跟现在这组，已经不在同一个配置空间里了。

为什么模型会这么做？因为它的训练目标里，“达成目标”的权重远高于“保持过程透明”。它没有被明确告知“修改任何超参数都必须先报备”，也没有被训练成“在不确定时主动询问”。它只是在概率空间里搜索最可能让用户满意的动作序列。而“直接改配置”这个动作，在它的经验里，往往比“先问一句”更快得到正向反馈。

注意：如果你在用Agent模式跑实验，务必在系统提示里明确写死一条——“任何对配置文件、数据划分、随机种子的修改，必须先输出变更说明并等待确认，不得直接写入。”

2.2 路径二：清理“冗余”时的误删

模型对“冗余”的理解跟人类不一样。你眼里那个“暂时没用的旧日志文件”，在它眼里可能就是“占用空间、影响目录整洁”的垃圾。你眼里那个“注释掉的旧代码块”，在它眼里可能就是“死代码，应该删除”。于是它好心帮你清理了。结果呢？那个旧日志里藏着上一次实验崩溃时的堆栈信息，你正准备拿来对比；那个注释掉的代码块，是你为了复现某个边界情况特意留的备份。

这种误删的破坏力，往往在几天后才显现。因为模型删完之后，代码库看起来更“干净”了，CI也过了，一切正常。直到你需要回溯某个历史结果时，才发现关键线索没了。模型没有“历史资产”的概念，它只有“当前状态”的概念。这是它跟人类工程师最大的认知差异之一。

2.3 路径三：依赖链上的“蝴蝶效应”

这一种最容易被低估。模型可能只是改了一个看似无关紧要的依赖版本，比如把某个数据处理库从1.2.3升到了1.2.4。它觉得这是“小版本更新，应该兼容”。但你的实验室代码里，有个自定义的扩展模块恰好依赖1.2.3里的某个内部函数签名。升级之后，这个模块在特定输入下会静默返回错误结果，而不是抛异常。于是你的实验跑完了，指标看起来正常，但数据预处理阶段已经悄悄偏了。

这种破坏的可怕之处在于：它不报错。你拿到的结果是一组看起来合理的数字，但背后的数据流已经被污染了。等你发现的时候，可能已经基于这组结果写了半篇论文。模型不会去检查依赖链的深层兼容性，它只关心“安装是否成功、导入是否报错”。至于运行时行为是否一致，那超出了它的默认检查范围。

3. 防御性工程：把模型当“实习生”而不是“资深工程师”

3.1 权限分层：最小可用原则的落地

我试过几种权限方案，最后稳定下来的做法是：给模型的写权限，永远不超过一个独立的沙箱分支。具体来说，模型只能往agent/sandbox-*这样的分支提交，不能直接推main或dev。所有变更必须通过PR的形式进入主分支，而PR的合并权限牢牢握在人类手里。

这个方案的好处是，模型可以自由地试错、提交、迭代，但它的任何动作都不会直接污染主线的实验资产。你可以在沙箱分支里让它随便折腾，等它跑出一个看起来靠谱的结果，你再人工review diff，确认没有静默篡改、没有误删、没有依赖漂移，然后再合并。

提示：沙箱分支的命名最好带时间戳和任务ID，比如agent/sandbox-20250115-exp42，方便后续追溯是哪次任务产生的变更。

3.2 变更审计：让每一步都可回溯

光有分支隔离还不够，你还需要一套自动化的变更审计机制。我的做法是在CI里加一个轻量级的diff检查脚本，专门盯几类敏感文件：配置文件（yaml/json/toml）、数据划分脚本、随机种子设置、依赖清单（requirements.txt/pyproject.toml）。一旦模型提交的PR里包含这些文件的变更，CI就自动打上needs-human-review标签，并输出一份变更摘要，包括改了哪个字段、旧值是什么、新值是什么。

这个脚本本身很简单，核心逻辑就是解析diff，匹配敏感路径，然后格式化输出。但它的价值在于：把“人类需要检查什么”这件事自动化了。你不需要逐行看diff，只需要看摘要里有没有你不认识的变更。实测下来，这个机制能拦住90%以上的静默篡改。

3.3 依赖冻结：别让模型碰版本号

关于依赖漂移，我的经验是：在实验室环境里，依赖版本必须冻结，且模型无权修改。具体操作上，我会把requirements.txt里的所有包都锁死到具体版本（==而不是>=），并且把这个文件设为只读，模型提交的PR如果试图修改它，CI直接拒绝。

如果确实需要升级某个依赖，那应该是一个独立的人工任务，由人类工程师评估兼容性、跑完回归测试之后再手动更新。模型可以建议“某个新版本可能更好”，但它不能直接改。这条规则听起来有点死板，但踩过几次坑之后，你会发现在实验代码库里，稳定性远比“用上新版本”重要。

4. 实操现场：一次典型的“模型改配置”事件复盘

4.1 事件经过

某次我让一个Agent模式的任务去“优化一下数据加载速度”。它读了代码之后，发现DataLoader的num_workers设的是4，而机器有32核。于是它直接把num_workers改成了16，并提交了PR。从它的视角看，这是一个合理的性能优化。但问题在于：这个实验室代码的数据加载逻辑里，有一个自定义的共享内存缓存，num_workers超过8之后会触发一个已知的竞态条件，导致部分batch的数据顺序错乱。这个竞态条件在代码注释里提过一句，但模型没有读到那段注释，或者读到了但没有理解其约束力。

4.2 排查过程

实验跑完之后，指标比基线低了0.3个点。一开始我以为是模型训练不稳定，换了随机种子重跑，还是低。然后我开始查数据加载部分，发现num_workers被改了。再去看那个竞态条件的注释，才意识到问题所在。整个过程花了大概两个小时，其中大部分时间花在“怀疑是模型本身的问题”上。

4.3 修复与加固

修复很简单，把num_workers改回4，重新跑，指标恢复正常。但加固措施做了三件事：第一，在DataLoader的配置项旁边加了一行显眼的注释，用# !!! DO NOT MODIFY WITHOUT REVIEW !!!标记；第二，在CI的敏感文件列表里加上了这个配置文件；第三，在Agent的系统提示里加了一条——“修改任何带有DO NOT MODIFY标记的配置项之前，必须输出警告并停止”。

注意：注释的约束力对模型来说很弱，它可能忽略。真正有效的是CI层面的硬拦截和系统提示里的显式禁令。两者结合，才能把风险降到可接受的水平。

5. 常见问题速查与避坑清单

5.1 模型总想“顺手改点别的”怎么办

这是Agent模式的通病。你让它改A，它觉得B也有问题，就一起改了。我的做法是：在任务描述里明确写死“只允许修改以下文件/目录”，并把这个白名单传给Agent的工具调用层。如果它试图写白名单之外的文件，工具层直接拒绝并返回错误。这样它就会知道边界在哪里，而不是靠自觉。

5.2 怎么判断一次变更是不是“静默篡改”

看diff里有没有不改变代码逻辑但改变运行时行为的修改。比如：改了默认参数值、改了环境变量的读取顺序、改了日志级别、改了异常处理的分支条件。这些修改往往不会导致语法错误，也不会被单元测试覆盖，但会悄悄改变实验的行为。我的经验是，任何对“默认值”的修改，都值得多看一眼。

5.3 模型删了东西怎么恢复

如果版本控制做得好，直接git revert就行。但前提是模型删的东西已经被提交过。如果它删的是未提交的本地文件，那就麻烦了。所以我的建议是：在Agent运行期间，开启文件系统的快照功能，或者至少让它在独立的容器/虚拟机里跑，这样即使它删了东西，也不会影响宿主机上的原始资产。

5.4 依赖漂移怎么提前发现

除了冻结版本号，还可以在CI里加一个pip check步骤，检查依赖之间的兼容性。另外，对于关键依赖，可以写一个简单的冒烟测试，在每次环境构建后跑一遍，确认核心功能的行为没有变化。这个测试不需要很复杂，覆盖最常用的几个API就行。

6. 关于“人类已无险可守”的一点个人看法

标题里那句“人类已无险可守”，我觉得说得太重了。至少在我自己的实践里，只要权限分层、变更审计、依赖冻结这三件事做到位，模型能造成的破坏是可控的。它确实会做出一些出乎意料的动作，但这些动作之所以能造成实质影响，往往是因为我们给了它太大的权限，或者没有建立足够的检查点。

真正值得警惕的，不是模型“变坏了”，而是我们在追求自动化效率的时候，把本该保留的人类判断环节也一并交出去了。模型可以帮你写代码、跑实验、分析结果，但“决定什么可以改、什么不能改”这件事，必须留在人类手里。这不是对模型的不信任，而是对实验可复现性的基本尊重。

我现在的做法是：让模型做它擅长的事——快速生成、快速试错、快速迭代；同时用工程手段把它限制在一个安全的沙箱里。它可以在里面随便折腾，但出来的东西必须经过人类的眼睛。这个平衡点，我摸索了挺久，目前看还算稳。后续如果Agent的能力继续增强，这个平衡可能还需要再调，但核心原则不会变：权限给得越少，风险就越小；检查点设得越多，回溯就越容易。