夜雨聆风上周有个晚上，我把一个正在跑的项目的配置模块交给 AI Agent 改。
不是什么边缘脚本，是这个项目里管"所有任务怎么分发"的核心文件。改之前我犹豫了大概三秒，心想：反正有 Git，大不了回滚。
Agent 改完，我跑了一下测试。
炸了。
三个测试用例全红，配置项少了一半，原来按类型分发的逻辑被它换成了一个统一入口——看起来更"优雅"，但实际上把我手动配的七八个策略全抹了。
我盯着屏幕看了几秒，然后笑了。
不是苦笑。是真的松了口气的那种笑。因为在那之前，我用 Agent 改了几十次代码，它都乖乖的，从不犯错。说实话，那种"从不犯错"反而让我心里发毛——我不知道它的边界在哪，不知道它什么时候会突然翻车，翻多大。
现在我知道了。
01不敢放手才是最大的风险
说句实话，我观察了一圈身边用 AI 写代码的人，大部分都卡在一个阶段：用 AI 写新功能、写脚本、写测试用例，不敢让它碰已经在跑的东西。
这个心理特别正常。我自己也这样过来的。你自己的代码，跑了这么久，你清楚哪里有坑、哪里是历史包袱。让一个 AI 过来改？万一它把你那个"丑但管用"的 workaround 给"优化"掉了呢？
但问题是：你一直不让它碰核心的东西，你对它的认知就永远停留在"好像还行"这个模糊地带。
这就像你组里来了个新人，你一直只让他写文档、做 code review，从不敢让他碰核心模块。一年过去了你觉得"这人挺靠谱的"，但说实话你并不知道——因为从来没给他出过难题。
你跟 AI Agent 之间的信任关系也是一样。信任不是它从不犯错，是你清楚地知道它犯什么错、犯错的模式是什么、出了错你能多快兜住。
我做了十几年测试，这件事我太熟了：一个系统你只测正常路径，它当然永远不报 bug。等你上生产了才发现问题，那才叫真的炸。
02信任不是给出来的，是测出来的
那次翻车之后，我总结了一套跟 AI Agent 建立信任的方法。不是玄学，就是做测试的人最基本的那套思路：渐进暴露 + 快速回滚。
具体来说分三步。
第一步，先拿低风险的东西试水。让它改一些独立模块，改错了也不影响主流程的东西。这一步不是看它能不能改对，是看它犯错时的模式——是理解错了需求？是漏了边界条件？还是直接忽略了你的约束？每个错误都是信息。
第二步，逐步提高风险等级。从独立模块到有依赖的模块，从配置文件到核心逻辑。每一步都要求它在改之前先说明要改什么、为什么改。这一步看的是它有没有"思考过程"，以及这个思考过程跟你的意图对不对齐。
第三步，观察它犯错后的修复能力。不给它答案，只告诉它"跑不通，自己看日志"。看它能不能自己定位问题、自己修、修完还不引入新问题。这一步比"不出错"重要得多。
这套方法的好处是，你始终在控制节奏。不是一下子把全部代码丢给它祈祷不出问题，而是一点一点地把边界摸清楚。你拿到的是这个 Agent 能力边界的真实数据——不是感觉，是实打实的"它在这些地方会翻车"。
我那个配置模块的翻车，就是在第二步。它犯的错是典型的"过度优化"——看到分散的逻辑就忍不住统一，没理解那些分散是我有意为之。这个错误模式一旦识别出来，以后我给它提需求时就会多加一句："这里每个类型的处理逻辑要保留，不要合并。"
一条提示词就解决的问题，不算什么。但你得先经历一次翻车才知道要加这条。
03三条铁律：让 Agent 犯错但不炸锅
从那次之后，我给自己定了三条规则，现在每次让 Agent 改代码之前都会过一遍。
铁律一：改之前必须有 Git commit。
听起来废话，但我真的见过有人让 Agent 改完发现不对，然后手动一行一行找回去改的。有 Git 你就有一键回滚，Agent 犯的任何错都可以当没发生过。没有 commit 就让 Agent 动代码，等于在没有安全网的情况下走钢丝。
反面案例：我早期有一次直接让 Agent 改了一组 API 接口的返回格式，改完发现上游全挂了。因为没提前 commit，我得对着 Agent 改的 diff 一个个手动回退，花了半小时。从那以后，"先 commit 再让 Agent 动"变成了肌肉记忆。
铁律二：让它先说计划，再动代码。
不是让它先写一版代码给你看，是让它先用自然语言说"我打算改哪几个文件、每个文件改什么、为什么要改"。你看了计划觉得没问题，再说"动手"。
为什么这步重要？因为 Agent 的计划如果就有问题，你在一句话的描述里就能发现，不用等它改完再排错。它的理解偏差、遗漏的依赖、忽略的约束——在计划阶段都会暴露出来。
这招是从测试思维里搬过来的：先看方案再执行，比执行完了再验收效率高十倍。
铁律三：每次只让它改一个维度。
不要一次让 Agent "把这个模块重构一下，顺便加个新功能，再把测试补上"。它大概率会在某个维度上做出你没预料到的决定，然后你分不清是哪一步出了问题。
一次改一个维度，出了错你马上知道是哪个维度的问题，回滚也精准。多条路一起走看着快，出错了排查的时间比省下来的多十倍。
这三条铁律的核心思路其实就一个：让 Agent 的每次犯错都是可逆的、可定位的、可学习的。 犯错不可怕，不可逆才可怕。每次翻车都是帮你画清楚它能力边界的数据点。
04你不敢让它犯错，就永远用不好它
回到开头那个晚上。
Agent 把我的配置文件改炸了之后，我花了大概五分钟定位问题，两分钟 git checkout 回滚，然后带着这次翻车的信息，重新给它加了一条约束，再让它改一次。
第二次改对了。
整个过程不到二十分钟。如果换我自己手动改那个模块，大概需要四十分钟，还不算中间可能引入的笔误。
那次翻车之后，我对 AI Agent 的信任反而上升了一个台阶。不是盲信，是"我知道它会在什么地方出什么问题"的那种信。这种信比"它从来没错过"那种信结实得多。
我做测试做了十几年，见过太多"从不报 bug"的系统最后在生产环境翻车的。也见过那些在测试阶段疯狂报 bug 的系统，上线之后稳得一批。因为 bug 报完了，边界就清楚了。
AI Agent 也一样。
你不敢让它犯错，你就永远不知道它到底能干什么、不能干什么。你不知道，你就没法真正用它。它就永远只是个"写写新代码"的工具，而不是一个你可以放心交托核心任务的搭档。
信任从来不是"你保证不出错"。信任是"我知道你会出什么错，出了错我能兜住"。
说到底，就这么回事。
你用 AI Agent 改过代码吗？第一次翻车是什么时候？评论区聊聊。