在业务研发中使用 AI Coding 时，一个常见问题是：AI 很容易“看起来完成了任务”，但实际改动范围过大，或者引入了与需求无关的代码变更。
请你回答：
在让 AI Coding Agent 修改业务代码前，你会如何约束它的改动范围？
可以重点讲：
这题只讨论：改动范围控制。不需要展开完整 AI Coding 流程。
通常而言，如果一个改动比较小的话，AI Coding Agent 改动的文件数目不多，就会直接操作。然后由我来Review.如果识别到比较大范围的修改，AII Coding Agent 都会先提供一个修改计划，等我 Review 完成以后再按照计划进行修改
你的回答方向是对的：用“改动规模”决定 AI Coding Agent 是直接执行，还是先出计划再执行，这是很实用的边界控制策略。
主要还可以补三点：
“小改动 / 大改动”的判断标准还不够明确
现在说“文件数目不多”是一个标准，但还可以补充：是否跨模块、是否改公共组件、是否涉及数据结构 / API / 权限 / 迁移等。
计划阶段可以更具体
不只是让 AI 给计划，还可以要求它列出：
Review 前的自动检查可以补上
除了人工 Review，还可以要求 AI 先自检：
我会把 AI Coding Agent 的改动范围控制分成两层：执行前约束范围，执行后验证是否越界。
首先，执行前会根据改动规模决定工作模式。
如果是小改动，比如只修一个局部 bug、改一个组件里的展示逻辑、补一个简单字段，我会允许 Agent 直接修改，但会明确告诉它只围绕当前问题改动，不做顺手重构，不改无关文件。
如果 Agent 判断需要改多个模块，或者涉及公共组件、接口定义、状态管理、权限逻辑、数据结构变化，我会要求它先输出修改计划，不能直接动代码。计划里需要说明：
我 Review 这个计划以后，再决定是否允许它执行。
其次，执行后我会检查它有没有越界。
我会重点看三个东西：
如果发现它做了无关重构、扩大了抽象、顺手修改命名或者调整架构，我会要求它回滚这些改动，只保留和需求直接相关的最小 diff。
所以核心原则是：小改动允许快速执行，大改动必须先计划；最终以 diff review 和自动化检查确认 Agent 没有超出授权范围。