AI 编程最容易让人上头的地方，是它改得很快。你本来只想修一个按钮，Cursor、Claude Code 或 Codex 读完项目后顺手发现样式可以优化、组件可以抽象、旧逻辑可以重构，最后任务从“改一处”变成“动一片”。
这不是工具不能用，而是缺少需求变更控制。人类开发里有范围管理，AI 编程也一样需要。越是让 AI 直接读仓库、改文件、跑命令，越要把“这次做什么、暂时不做什么、发现新问题怎么处理”写清楚。
如果你已经看过 AI编程工具专题 里的任务说明、版本管理和验收清单，这篇可以当作中间一环：任务执行过程中需求变了，怎么不让项目失控。相关的真实项目方法，也可以继续对照 老达AI实践专题。
为什么 AI 编程更容易范围蔓延
传统开发里，需求变更通常由人提出。但 AI 编程里，变化可能来自三个方向。
- 人临时加需求：看到 AI 改得快，就顺手说“再帮我把这个也优化一下”。
- AI 主动扩展：它发现相邻代码有问题，开始重构无关模块。
- 验证暴露新问题：跑测试或打开页面后发现旧逻辑本来就有隐患。
这三类变化都很常见，但处理方式不能一样。临时加需求不一定要当场做，AI 主动扩展需要先停下来确认，验证暴露的问题则要判断是否阻塞本次交付。
如果不分清，最后就会出现一个典型结果：本来 30 分钟能完成的小任务，变成半天的大改；本来能清楚验收的改动，变成谁也说不清影响范围的混合提交。
先给任务设定“冻结范围”
需求变更控制的第一步，是在任务开始前写出冻结范围。冻结范围不是说永远不能改，而是说本轮默认不改，除非先解释原因并得到确认。
例如你要让 AI 修复文章页 SEO meta 检查脚本，可以这样写：
本次只修改发布后检查脚本和必要的解析逻辑，不改 WordPress 主题、不改发布脚本、不新增依赖。若发现主题输出结构异常，先记录为后续任务，不要直接修改。
这段话会让 AI 明白：目标是检查脚本，不是全站 SEO 重构。类似规则也适合写进 AI编程任务说明模板，让每一次任务都从边界开始。
把变更分成四档
执行过程中一旦出现新需求，不要只问“做不做”。更好的是先分级。
- A 档：阻塞本次目标。不处理就无法完成当前任务，应该纳入本轮。
- B 档：影响验收质量。会影响结果稳定性，但可以小范围处理。
- C 档：相邻优化。有价值，但不阻塞本次目标，建议进入后续任务。
- D 档：想法和探索。先记录，不在当前分支或当前会话里做。
举个例子：你让 AI 修复登录按钮点击无响应。它发现按钮组件缺少 loading 状态，这属于 B 档；它又发现整套表单组件可以重构，这多半是 C 档；它建议顺手重做登录页视觉风格，那就是 D 档。
分级的价值，是让你和 AI 都从“想到就做”切换成“按交付目标取舍”。这和 AI编程先规划再写代码 的思路一致：先定范围，再执行。
追加需求要变成新任务，不要塞进原任务
很多 AI 编程失控，都是因为追加需求没有单独成任务。你在同一轮里不断说“再改一下”“顺便优化一下”“这个也帮我处理”，AI 会继续沿着当前上下文改下去，但 Git diff、测试范围和验收标准会越来越乱。
我建议用一个简单规则：只要追加需求改变了目标、文件范围或验收标准，就新建任务。
新增变更记录：
- 原任务：修复文章页特色图 alt 检查不准确。
- 新发现：部分旧文章没有设置特色图。
- 判断：不阻塞本次脚本修复，属于 C 档相邻优化。
- 处理：记录为后续任务“批量补旧文章特色图 alt”，本轮不改。这样做不是降低效率，而是保护效率。当前任务能按原目标交付，后续任务也有清晰入口。
让 AI 每次扩范围前先说明代价
如果 AI 认为必须扩大范围，不要直接让它开改。先让它回答四个问题：
- 为什么当前范围内无法解决？
- 需要新增修改哪些文件或流程？
- 扩大范围后需要增加哪些测试或检查？
- 如果不扩大范围，本次交付会留下什么风险？
这一步能过滤掉很多“看起来顺手”的改动。真正必要的扩展，经得起解释；只是 AI 自己想优化的部分，通常会在这四个问题里露出边界不清。
如果涉及共享组件、权限、安全或数据结构，更要谨慎。可以参考 AI编程安全审查怎么做，先把风险说清楚，再决定是否纳入本轮。
每次变更都要更新验收标准
需求变了，验收标准也必须变。很多人只让 AI 改代码，却忘了同步修改验收清单，最后检查的还是旧目标。
例如原任务是“给表单增加手机号校验”，后来追加了“提交失败后保留用户输入”。那验收标准就要从“手机号格式错误时提示”扩展为：
- 手机号为空、格式错误、格式正确时提示符合预期。
- 提交失败后，已填写字段不会被清空。
- 重复提交时按钮有禁用或 loading 状态。
- 旧的提交成功流程仍然可用。
这部分可以和 AI编程验收清单 配合使用。变更控制负责决定做什么，验收清单负责证明确实做到了。
用 Git 提交把变更隔开
只要项目用 Git，需求变更就应该尽量和提交边界对应。一个提交解决一个明确目标，追加需求单独提交，实验性改动不要混在主线里。
个人项目也可以遵守这个习惯，因为它能降低回滚成本。你发现新增需求方向错了，只需要撤回那一个提交，而不是在一堆混合改动里手工拆文件。
如果你还没有建立这个习惯，可以先看 AI编程版本管理怎么做。AI 改代码越快，版本边界越重要。
可以直接复用的变更控制提示词
下面这段适合放在 Cursor、Claude Code 或 Codex 的任务中段，尤其适合你感觉任务开始扩大的时候。
请暂停扩展修改，按需求变更控制方式评估当前新增事项：它属于 A 阻塞目标、B 影响验收、C 相邻优化，还是 D 想法探索？请说明是否必须纳入本轮、会影响哪些文件和测试、如果延后处理有什么风险。未经确认不要修改新范围。
如果你要把它写进项目长期规则，可以再加一句：
当任务范围、文件范围或验收标准发生变化时，先更新变更记录和验收清单，再继续执行。
老达点评
AI 编程真正的风险，不是它改得不够快，而是它改得太快时，人没有把方向盘握住。需求变更控制就是这个方向盘。
对个人开发者、站长和小团队来说，不需要上复杂的项目管理系统。你只要做到四件事：任务开始写冻结范围，执行中给变更分级，追加需求另开任务，交付前更新验收标准。做到这四点，Cursor、Claude Code、Codex 就会更像可靠的项目助手，而不是把每个小问题都扩成大工程的代码生成器。
