跨文件自动修复为何仍需人工审查

AI 修 Bug 越来越像那么回事了，尤其面对那种几万行代码的存量项目，光靠补全已经不太够用。现在主流的思路分成两派：一派是“以写代码为中心”，人还在编辑器里开车，AI 在旁边递工具；另一派是“以完成任务为中心”，你把问题丢过去，它自己去翻代码、定方案、动手改，改完还跑测试验证。听起来后者挺省心，但真到了跨文件自动修复这一步，人工审查反而变得更关键了。

原因其实不复杂。存量项目里的 Bug 很少只藏在报错那一行，一个空值异常，背后可能是数据转换、缓存状态、异步请求顺序，甚至是很早以前留下的兼容分支。智能体要跨文件去追这条链，就得先判断该看哪些文件、哪些依赖关系可信、改完怎么验证。它把这些活儿都接过去了，但“接过去”不等于“接得住”。它可能为了尽快让测试通过，偷偷改掉了不该动的业务语义，或者把异常处理粗暴地吞掉——测试绿了，线上该炸还是炸。

所以现在大家更关注的不再是“谁更聪明”，而是“谁能把过程说清楚”。一个合格的跨文件修复，至少得能回答四个问题：它查了哪些地方、为什么这么判断、改动的影响范围到哪、凭什么证明修复有效。这四件事如果说不清楚，那它越“自主”，风险反而越大。毕竟智能体改动的文件越多，人工审查的难度就越高，你不可能像看单文件补全那样逐行扫一遍。

判断任务该交给谁，其实有个简单的标准：如果开发者已经知道改哪里、怎么改、怎么验收，那就用 Code-First，直接、可控、沟通成本低；如果只知道现象是什么，根因可能横跨好几个模块，那就适合启动 Agent-First，让它先做调查和计划，再进入修改阶段。但无论选哪种，审查改动范围、确认异常处理没被粗暴吞掉、检查测试是不是真的覆盖了故障场景，这几件事一步都不能省。

说到底，工具的分工越来越清晰：编辑器内的工具负责日常提速，智能体负责啃硬骨头。但对团队来说，最值得试用的不是“让 AI 一次修完一个 Bug”，而是观察它能不能把“查了什么、为什么、影响哪、怎么证明”这四件事讲明白。能讲明白的，才有资格当搭档；讲不明白的，再快也只是个让人提心吊胆的自动改稿机。