用选区和 Diff 约束 Claude Code 的修改范围
“优化这个项目”之类的宽泛请求，会把目标选择、修改范围和验收标准都交给编码代理。结果即使能运行，也可能包含无关重构、公共接口变化或没有覆盖的行为回归。本文假设 Claude Code 已经连接 JetBrains IDE，只解决修改边界问题：怎样用当前选区、精确文件、禁止事项和 Diff 审查，把一个任务收敛成可解释、可验证、可拒绝的小改动。
把任务写成可检查的边界
一个适合交给编码代理的任务至少应回答四个问题：
- 目标：需要修复或增加什么可观察行为。
- 范围：允许读取和修改哪些文件或函数。
- 禁止事项：哪些接口、依赖和行为不能变化。
- 验证：用什么测试、静态检查或人工步骤判断完成。
例如，“修复空指针问题”仍然太宽，可以改成：
分析当前选区中的空值路径。只允许修改当前函数，不改变函数签名、调用方和异常类型。
先解释原因并列出最小修改计划，得到确认后再改。完成后展示 diff，并运行该模块已有测试。
约束不是提示词装饰，而是后续审查的检查表。
第一步：先解释选区，不修改
在 IDE 中选择目标函数或失败分支，先让 Claude Code复述代码行为：
只分析当前选区。说明输入、输出、外部依赖、异常分支和你认为的问题。
引用选区中的具体标识符作为依据。不要修改任何文件。
这一步同时验证上下文与理解。如果回答没有出现选区中的关键变量、条件或调用，就不要进入修改阶段。可以缩小选区、补充精确文件路径，或要求它重新基于代码说明判断依据。
“先解释”也能暴露需求歧义。例如，模型可能把 null 当作非法输入，而现有调用方其实用它表达“未配置”。这种分歧应在人类确认预期行为后解决，不能靠模型自行选择。
第二步：提供相邻证据，而不是整个仓库
修改通常需要少量上下文，例如调用方、现有测试和同类实现。只提供能影响决策的文件范围：
阅读目标函数、直接调用方和该模块现有测试。
说明当前行为由哪些测试覆盖，并列出准备修改的文件。
除非先解释必要性并获得确认，否则不得修改列出的范围之外的文件。
如果需要遵循项目风格，应指出具体样板文件，而不是只说“保持一致”。样板必须与目标处于相同框架和职责层次；控制器、领域逻辑和基础设施代码不能互相充当通用模板。
第三步：先审计划，再执行改动
计划不需要很长，但应说明：
- 根因是什么，证据位于哪里。
- 哪些文件会被修改。
- 为什么这些修改足以达到目标。
- 会运行哪些已有验证。
- 哪些风险仍需人工判断。
如果计划包含无关清理、依赖升级、接口重命名或大范围格式化，应在执行前移除。认证、支付、数据库迁移、部署权限和密钥处理等高风险路径，还需要更严格的人工审批和环境验证。
执行提示可以继续限定边界：
按已确认计划执行。不要进行顺手重构，不要新增依赖，不要改变公共接口。
遇到计划外问题时停止并报告，不要自行扩大范围。
第四步：按层审查 Diff
JetBrains 集成的安装与当前能力应以 Claude Code JetBrains 官方文档 为准。无论 Diff 在 IDE 还是终端中展示，都按相同顺序审查：
先看文件集合
修改文件是否与计划一致？出现配置、锁文件、生成文件或相邻模块时，必须说明为什么是完成任务所必需。
再看行为变化
逐块检查条件分支、返回值、异常、状态更新和外部调用。不要被变量重命名或格式变化掩盖真正的行为差异。
最后看边界之外
确认公共接口、依赖版本、权限范围、日志内容和敏感数据处理没有发生未计划变化。任何不必要的改动都应撤回，而不是留到后续 PR 再解释。
可以让 Claude Code 辅助自审：
审查当前 diff，只报告可能的 bug、行为回归、缺少测试和越过任务边界的修改。
每条结论引用具体文件和代码位置。不要提出纯风格建议，也不要声称未运行的验证已通过。
这份自审不能替代人的 Diff 阅读，但能帮助发现代理自己引入的不一致。
第五步：验证实际行为
Diff 合理只是静态判断，仍要执行仓库已有验证。优先顺序通常是：
- 与目标函数直接相关的测试。
- 所属模块的测试或静态检查。
- 受公共接口影响的更大范围验证。
不要在不知道项目工具链时让模型编造测试命令。应先从项目文档、构建配置和持续集成文件中找到已有命令，再由开发者确认运行环境。
交付说明要区分“已运行”和“未运行”：
目标：
修改文件：
行为变化：
已运行验证及结果：
未运行验证：
需要人工确认的风险：
测试失败时保留原始错误，判断它是本次回归、环境问题还是原有失败。不能把“命令执行过”写成“验证通过”。
发现越界时怎么处理
如果 Diff 已经超出范围，不要继续叠加修复提示。先拒绝或撤回未接受的改动，再把任务缩小到单个失败和单个验证目标。随后要求代理重新解释根因和最小文件集合。
常见越界信号包括：
- 为修一个分支而修改多个公共接口。
- 在没有要求时升级依赖或调整配置。
- 把缺少的测试替换成删除断言。
- 为通过静态检查而忽略错误或扩大豁免。
- 在没有证据时声称行为、性能或安全性得到改善。
结论与限制
约束 Claude Code 修改范围的核心流程是：用选区确认理解，用少量相邻证据建立上下文，先审计划，再按文件和行为审 Diff，最后运行仓库已有验证。这样可以把代理速度转化为可审查的工程变更，而不是不可解释的大型补丁。
选区和提示词只能降低越界概率，不能证明改动正确。最终接受仍取决于代码审查、测试结果以及对业务语义和高风险边界的人工判断。