用途：在代码审查开始前，先判断这次变更属于小改动还是大改动，从而确定审查范围。核心原则是大改动需要更广的审查，小改动只需聚焦审查。
主要能力：提供小改动与大改动的判定指标。小改动通常为 1-3 个文件、孤立变更、无 API 变更、无新依赖、影响局部；大改动通常为 4 个以上文件、跨模块、公共接口变更、新增依赖、行为变更或架构影响。技能给出决策流程：先看改动文件是否超过 3 个，再看公共 API 是否变更，最后看是否存在行为变更，任一为是即判为大改动。
使用方式：先对变更分类；小改动只审查改动行、新测试和直接函数上下文。大改动需审查所有改动代码、所有调用改动代码的代码、被改动代码调用的代码、集成点与端到端流程。可借助 grep 定位影响面，例如：grep -r "import.from.'./changed-module'" src/ 和 grep -r "changedFunction" src/。审查前应记录范围说明，列出改动文件、审查重点、受影响代码与集成点，再按对应清单逐项核对。
适用场景：适用于以 issue 驱动开发或综合审查流程的步骤中，决定审查多少代码、检查哪些测试和集成点。
限制：资料未提供具体安装与调用命令、收费与价格、平台支持信息；不确定时默认按大改动处理。少行数也可能造成大影响，纯重构虽无行为变更仍需按大改动进行结构审查。