你多半见过那种场面：让AI帮你跑一个要改二十几个文件的重构，它每改一个文件就停下来问你要不要继续。前两次你还认真看一眼，到第七次就变成机械地按回车。最有意思的是，按下一次回车的时候，你其实已经不太清楚自己在批准什么了。工具方显然也意识到这个矛盾，于是给了两条极端的路线，又补了一条中间的。
一条是默认。默认权限是刻意保守的：每一次写文件、每一条bash命令，都要你点头。它安全，但代价是没法把大任务丢上去走开，因为中途会不断弹确认。另一条是跳过所有权限检查，官方对它的措辞很直接——跳过权限可能导致危险和破坏性的后果，除了隔离环境之外不建议使用。两个极端之间，就是后来补上的自动模式。这两条路线之所以都不理想，是因为它们处理的是同一件事的两个极端：确认权要么全给你，要么完全不要。而真实需求往往卡在中间——小事别烦我，大事必须问我。
自动模式的定位可以一句话讲完：由它替你做权限决定，但每一个动作执行之前，有另一套安全机制在看着。所以它不是把确认关掉，而是把做确认的人从你换成一个专门干这件事的分类器。今年七月的更新里，这个模式已经从研究预览转为面向所有用户开放，说明它已经过了内部试用的阶段。
自动不等于不问，只是问的人换了
这个分类器具体拦什么，官方给了一份清单：生产环境的部署和迁移；强制推送，或者把下载来的代码直接管道送进shell；把敏感数据发到外部端点；不可逆地删除会话开始之前就已经存在的文件。这四类有一个共同点——它们都不是难，而是错了没法回头。工具真正在防的是这种不可逆，而不是能力边界。注意这四类的共同前提是不可逆，而不是危险。有些动作看起来吓人，比如重写一大片代码，但只要在版本控制里、随时能退回去，它就不在拦截范围里。判断标准是有没有回头路，不是看起来可不可怕。
被放行的也很好猜：项目内部的本地编辑、按锁文件安装依赖、只读性质的请求、推送到你自己的分支。这套划分的思路可以概括成一句话：改的是你自己的东西、影响范围在这个项目里、还能撤回来，那就让你快一点；一旦越过这个边界、开始碰到外部世界或者历史数据，就拦下来让你自己看。
但这里有一条必须说清楚的限制，官方自己也点明了：分类器看的是意图，不是正确性。原话的意思是，你让它重构认证逻辑，它写出了一套坏掉的认证，分类器会放它过去，因为坏不等于危险。这句话值得反复读——你以为那道关卡在替你审代码，其实它审的只是这次动作想干什么，完全不负责干活的结果对不对。这一点直接决定了你对它的期待。如果你把它当成写完的代码有人替我审，多半会失望；如果你把它当成它动手之前有人替我看一眼方向对不对，那它的表现其实是合格的。
意图过了关，正确性没人管
正确性那一半得你自己补回来，官方推荐的搭配是再配一个结束时的钩子去跑测试。这样分工就清楚了：自动模式在动作执行之前检查意图，钩子在整个任务结束之后验证代码到底跑不跑得起来。一个管别闯祸，一个管别写错，两件事合起来才算闭环，缺了后面那个，就变成只防危险不防错误。再补一句实操细节：钩子是跑在任务结束那一刻的，所以它验证的是整体结果，不是每一步。如果你想要每一步都验，那就得把任务切小，让每一次结束都短到钩子来得及跑完，否则钩子本身也会变成瓶颈。
官方也提了代价：自动模式可能会让工具调用的开销、费用和延迟都增加一点，因为每次动作前多了一道审查。考虑到它省下的是你反复按确认的时间，这笔账多数情况下还是划算的，但它不是零成本——如果你的任务本来就很小、本来也只需要批准两三次，那这道审查就是纯粹的额外支出，不如继续用默认模式。
还有两个方向它都可能出错。一个方向是漏：当你的意图说得含糊，或者它对你的环境了解不够、没意识到某个动作会带来额外风险时，分类器可能放行本来该拦的东西。另一个方向是误伤：它偶尔也会挡住无害的操作。官方明确说这套护栏还在演进。翻译过来就是，别把它当成有保证的边界，它更像一个比全不问和全都问都更合理一点的默认值。还有一个场景要主动避开：别把它当成可以撒手的借口。即便开了自动模式，官方仍然建议在隔离环境里使用。真实项目里它最有价值的用法，是把那些反复出现的低风险操作交出去，把注意力省下来放在真正需要判断的地方。
所以对自动模式，比较稳的用法是：拿它去跑那些错了能撤回的活，比如本地重构、批量改名、整理测试；把那些不可逆的动作，比如动生产环境、删数据、碰发布流程，继续留在需要你亲自点头的位置上。至于顺序，先让它跑一次带测试钩子的任务，看它在哪一步放行、在哪一步停下，你大概就能摸清它认得什么、不认得什么。工具替你按下确认的前提，是你还知道不确认的时候该看哪里。最后提醒一句，模式是可以随时切的。你不用一开始就选定一种路线跑到底——遇到批量改文件切到接受编辑，遇到要动线上配置切回手动，这本来就是它设计里最实用的一点。
A5创业网 版权所有