AI Agent首次搞崩我的代码，我却更放心了

前几天夜里，我交给AI Agent一个正在运行项目的核心配置文件去修改。

这并非边缘脚本，而是掌控“所有任务如何调度”的关键文件。动手前我迟疑了片刻，转念一想：反正有版本控制，不行就撤销。

Agent修改完毕，我随即执行了测试。

结果崩溃了。

三个测试全部失败，配置参数丢失过半，原本按类别分发的逻辑被替换为单一入口——表面更“简洁”，实则将我手动设置的七八条策略全部清空了。

我凝视屏幕片刻，随即笑了。

不是无奈的笑，而是如释重负的笑。在此之前，我用Agent修改过数十次代码，它始终表现完美，从未出错。说实话，那种“零失误”反而令我忐忑——我不了解它的能力边界，不知何时会突然失控，后果有多严重。

此刻我终于明白了。

说实话，我观察了周围使用AI编程的同事，大多停留在同一阶段：用AI编写新功能、脚本和测试用例，却不敢让它触碰已在运行的核心代码。

这种心态很正常，我也经历过。自己的代码运行已久，哪里藏有陷阱、哪里背负历史包袱都了然于胸。让AI来修改？万一它将那个“虽丑但有效”的临时方案“优化”掉了怎么办？

但问题是：若始终不让它接触核心模块，你对它的认知将永远停留在“似乎不错”的模糊地带。

这好比团队来了新人，你只安排他写文档、做代码审查，从不让他接触核心模块。一年后你认为“这人挺可靠”，但实际上你并不清楚——因为他从未面临过真正的挑战。

你与AI Agent的信任关系亦然。信任并非源于它永不犯错，而是源于你清晰知晓它会犯何种错误、错误模式是什么、出错后你能多快补救。

我从事测试十余年，对此深有体会：若只测试正常流程，系统自然永不报错。待上线后才发现问题，那才是真的灾难。

那次失误后，我总结了一套与AI Agent建立信任的方法。并非玄学，而是测试人员最基础的理念：逐步暴露+快速撤销。

具体分为三个阶段。

第一阶段，先用低风险内容试水。让它修改独立模块，即使出错也不影响主干流程。此阶段目的不是看它能否改对，而是观察其犯错模式——是误解需求？遗漏边界条件？还是无视约束？每个错误都是宝贵信息。

第二阶段，逐步提升风险等级。从独立模块到依赖模块，从配置文件到核心逻辑。每一步都要求它先阐述修改内容、原因及目的。此阶段考察其是否具备“思考过程”，以及该过程是否与你的意图一致。

第三阶段，观察其犯错后的修复能力。不提供答案，仅告知“运行失败，自行查看日志”。看它能否独立定位问题、修复且不引入新问题。此阶段比“零失误”更为重要。

这套方法的优势在于全程可控。并非一次性将所有代码交给它并祈祷不出问题，而是逐步摸清其能力边界。你获得的是Agent能力边界的真实数据——非主观感觉，而是确凿的“它在这些场景会失效”。

我那个配置模块的失误发生在第二阶段。它犯的错误是典型的“过度优化”——见到分散逻辑便想整合，未能理解那些分散是我的有意设计。识别此错误模式后，日后提需求时我会补充：“此处各类别处理逻辑需保留，勿合并。”

一条指令即可解决的问题，不算什么。但你必须先经历一次失败才会意识到需要添加此条。

自那以后，我为自己定下三条准则，如今每次让Agent修改代码前都会检查一遍。

准则一：修改前必须提交Git版本。

看似常识，但我确实见过有人让Agent改错后手动逐行回退。有版本控制就能一键撤销，Agent的任何错误都可视为未发生。未提交就让Agent动代码，等于在无保护网的情况下走钢丝。

反面案例：我早期曾直接让Agent修改一组API接口的返回格式，改完后发现上游系统全部崩溃。因未提前提交，我只能对着Agent的修改记录逐一手动回退，耗时半小时。自那以后，“先提交再让Agent动手”已成为肌肉记忆。

准则二：先让其陈述方案，再动手编码。

并非先让它写代码给你看，而是先用自然语言说明“计划修改哪些文件、每处修改内容、修改原因”。你审阅方案无误后，再下令“执行”。

此步为何关键？因若Agent的方案本身存在问题，你在其描述中即可发现，无需等待修改完成后再排查。其理解偏差、遗漏依赖、忽略约束——均会在方案阶段暴露。

此技巧借鉴自测试思维：先审方案再执行，比执行后再验收效率高出十倍。

准则三：每次只让它修改一个层面。

不要一次性让Agent“重构此模块，顺便添加新功能，再补充测试”。它很可能在某个层面做出你没预料到的决策，导致你无法判断问题根源。

一次只改一个层面，出错后立刻能定位问题所在，回滚也更精确。多线并行看似高效，但出错后的排查时间远超节省的时间。

这三条准则的核心思想只有一个：确保Agent的每次错误都是可逆的、可定位的、可学习的。犯错不可怕，不可逆才可怕。每次失败都是帮你明确其能力边界的数据点。

回到最初的那个夜晚。

Agent搞崩我的配置文件后，我耗时约五分钟定位问题，两分钟用git checkout回滚，随后带着这次失败的经验，新增一条约束，再让它重新修改。

第二次修改成功了。

整个过程耗时不到二十分钟。若由我手动修改该模块，约需四十分钟，还不包括可能引入的笔误。

那次失败之后，我对AI Agent的信任反而提升了一个层次。并非盲目相信，而是“我清楚它会在何处出现何种问题”的信任。这种信任比“它从未出错”的信任牢固得多。

我从事测试十余年，见过太多“零bug”的系统最终在生产环境崩溃。也见过那些在测试阶段bug频发的系统，上线后却异常稳定。因为bug暴露完毕，边界就清晰了。

AI Agent亦是如此。

若不敢让它犯错，你便永远无法知晓它的能力范围。不了解，就无法真正运用它。它将永远是“编写新代码”的工具，而非可托付核心任务的伙伴。

信任从不是“你承诺不出错”。信任是“我知晓你会犯何种错，出错后我能应对”。

归根结底，就是如此。

你曾用AI Agent修改过代码吗？第一次失败是何时？评论区交流一下。