常见代码变更引发的协作风险
你曾修改了一个公共函数的返回值类型，本地测试正常通过，代码评审也顺利过关。然而三天后，另一个团队反馈线上出现报错——他们的模块调用了这个函数，却没有同步更新调用逻辑。
类似的情况并不少见：重构事件系统API时，逻辑层面毫无问题，但下游四个服务的调用方式全部失效，直到数据丢失一批才被察觉。
这类问题的共性是什么？变更本身没有问题，问题出现在变更与其他代码的依赖关系上。在Python、JavaScript这类弱类型语言中，编译阶段无法拦截此类错误，只能等到测试甚至生产环境才暴露。
传统的代码评审——包括早期的AI评审——仅限于审查本次提交的Diff。改动影响了哪些调用方、上下游是否适配，传统方法无法发现。
本次升级的核心能力
云效AI智能评审新增了跨文件感知能力。简单来说：AI评审不再局限于Diff中的代码，而是自动追踪改动所涉及的上下游调用关系，将未出现在变更列表中的受影响代码也纳入评审范围。
具体工作流程如下：当你提交代码变更时，AI首先识别你修改了哪些函数、类、变量，然后在整个代码库中检索这些符号被谁调用、被谁引用，将相关的代码片段和依赖文件拼接成完整上下文，最后基于全局视图进行评审。
三个典型应用场景
以下是三个真实案例，展示跨文件感知在实际评审中的价值。
场景一：接口参数顺序变更，调用方传参错误
开发者调整了一个Java接口的参数顺序，编译顺利通过，接口设计看起来也更规范。传统评审到此结束——Diff本身没有问题。但跨文件感知会继续追踪该接口的所有调用方，发现有一处调用仍然按原来的顺序传参，导致categoryId被当作channel传入。编译器不会报错，但运行时逻辑完全错误。
场景二：方法返回null而非空列表，调用方触发NPE
开发者将一个方法的返回值从空列表改为null，认为语义更清晰。传统评审认为改动合理。但跨文件感知检查了所有调用方的代码，发现有两处直接对返回值调用.size()和.forEach()，一旦返回null就会触发NullPointerException。在代码库庞大、调用方众多的场景下，人工评审几乎不可能逐个排查这类隐患。
场景三：方法新增异常，上游未捕获处理
开发者在一个方法中新增了业务校验逻辑并抛出异常。变更本身合情合理，传统评审不会提出异议。但该方法被多个上游服务调用，跨文件感知追踪后发现其中几个调用方没有处理新增的异常类型，一旦触发就会直接返回500错误或导致批量任务中断。调用方越分散，这类问题越容易遗漏。
实测效果
在跨文件代码影响专项测试集上验证，跨文件感知上线后，评审召回率从61%提升到80%，提高了19个百分点。这意味着之前近五分之一的跨文件风险问题会被遗漏，现在能被提前拦截。
该能力对以下场景尤其有效：弱类型语言（Python/JS）的方法签名变更，编译阶段无法拦截，AI在提交时即可检查；调用链复杂的公共函数修改，被多个团队调用的函数一旦变更，AI自动追踪所有调用方；以及返回值语义变更这类编译器不报错但调用方会崩溃的情形。
使用方式
即日起对所有云效Codeup用户限时免费开放。
跨文件感知通过沙箱配置开启。在代码库的评审配置中添加以下内容即可：
两个参数的含义：enable开启沙箱环境运行AI评审，可选true/false，默认false；enable_crossfile_analyze开启跨文件变更检测，可选true/false，默认false，需要enable为true时才生效。开启后，AI评审会自动识别跨文件的破坏性变更，如返回值语义变化、未处理异常、参数顺序调整等。
需要注意的是，开启跨文件分析后，评审的Token消耗和耗时将有所增加，因为AI需要读取和分析更多的关联代码。
