高风险改动如何分级评审

一次代码改动要不要“升级评审”，不该只看改了多少行。一个很小的默认参数，可能扩大数据访问范围；一段看似普通的重试逻辑，也可能改变核心状态。真正该分级的，是改动一旦出错后，影响会落在哪里、是否容易发现、能不能回退。

可以先把风险分成三个直观层次。低风险改动通常是展示层调整、局部文案或已有能力的简单调用，重点确认依赖没有膨胀、现有测试能够覆盖即可。中风险改动涉及业务分支、返回结构、异常处理或重复请求，评审时要把关键假设说清楚：数据不存在怎么办，权限变化怎么办，失败后再次操作会怎样。

高风险改动则不应只靠“代码看起来没问题”。只要触及权限、用户资料、数据写入、核心业务状态，或引入新的依赖与复杂决策逻辑，就应要求更完整的说明和场景验证。评审者需要沿着数据流追问：谁发起请求，以什么身份访问，读写了什么，最终返回了什么；同时确认注释、命名和实现没有互相矛盾。

AI 参与生成的代码尤其适合放进这套分级里。它可能快速补齐主流程，却把边界条件、既有组件和维护成本留在代码背后。标记 AI 大幅参与的改动不是贴标签，而是提醒团队多问一句：这段逻辑对应什么业务规则，为什么必须这样实现？

分级评审不是增加一道形式化关卡，而是把有限的人工注意力放到最难回滚、最难解释的地方。低风险改动保持流畅，高风险改动放慢一点，反而更能保护交付节奏。