已经知道怎么修，直接修

直接执行立即修改文件。没有探索阶段，没有只读模式，没有依赖映射。解决方案已知、范围清晰、目标文件已确定时，这是正确选择。

三个标准：已知解决方案、清晰范围、已确定文件。三个都满足时，plan 模式增加的开销价值为零。

教科书级直接执行场景

堆栈跟踪 → 单函数修复。 response_formatter.py 第 23 行 format_response() 的格式化 bug。堆栈跟踪精确定位了位置，错误很清楚。直接执行：修函数。

已知边缘情况 → null 检查。 JSON 字段缺失时 parse_record() 的 NullPointerException。函数、缺失的字段和修复（加 null 检查）全都已知。直接执行。

CI 测试失败 → 更新引用。 流水线失败”Expected 200, got 404”，因为路由从 /api/users 改名为 /api/v2/users 但测试没更新。通过 git blame 找到根因。直接执行：更新测试。

明确需求 → 单函数。 “加一个日期校验检查：拒绝超过 90 天前的日期”在 validate_intake_form() 中。算法清晰，单函数，单文件。直接执行。

不局限于单文件

直接执行不限于一个文件。一个 CLI bug 修复可能涉及：

• 修 cli.py 中的 parse_args()
• 更新同一文件的帮助文本
• 在 CHANGELOG.md 加一行

两个文件，但每处改动的解决方案都已知。不需要探索来搞清楚做什么。标准是解决方案确定性，不是文件数。

2 文件且解决方案已知 → 直接执行。1 文件但不熟悉的代码且方案不清 → plan 模式。

识别范围低估

一个开发者对一个”简单的”模板 bug 开始直接执行。会话数据讲述了真相：

这是经典的范围低估。任务在 5 个文件之间有隐藏的依赖，直接执行在正常工作流中发现不了。router.py 上的两次回滚说明开发者遇到了模块之间的意外连接。

Plan 模式会在任何改动之前通过只读探索揭示这些依赖。47 分钟的部分回滚直接执行本可以是 10 分钟探索加聚焦实现。

教训：如果你开始直接执行后发现范围比预期大，说明任务被错误分类了。一开始就该用 plan 模式。

一个会话中混合模式

两个 CI/CD 问题：

1. build.sh 中一个已知的拼写错误导致编译失败
2. deploy.yaml 中一个过时的容器镜像标签——不知道正确的替换

这是特征不同的不同任务。拼写错误有已知修复 → 直接执行。镜像标签需要调查 → plan 模式。

在各自适合的地方应用每种模式。不要把两个问题强塞进一种模式。拼写错误不该等 plan 模式的探索，镜像标签也不该在直接执行中乱猜。

简单修复被提议用 Plan 模式时

同事说：“咱们用 Plan 模式分析一下完整数据流再给 parse_record() 加这个 null 检查。”

Null 检查是一个已知函数中已知缺失字段的范围化修复。流水线的复杂度和修复的简单性无关——检查处理缺失字段，不管上游来源是什么。Plan 模式的探索增加开销但不改变实现。

这是”plan 模式过度使用”模式。复杂系统仍然可以有简单修复。把模式匹配到修复复杂度，不是系统复杂度。

直接执行的特征

会话日志中表明直接执行是正确选择的指标：

• 短时长（分钟级，不是几十分钟）
• 修改 1-2 个文件
• 清晰的错误消息或已知需求作为触发
• 没有回滚
• 时间线中没有发现阶段

如果日志显示 5+ 文件、回滚和 40+ 分钟用于一个本该”简单”的修复，模式选错了。

一句话总结： 已知解决方案、清晰范围、已确定文件——三者都满足时，直接开始修改；plan 模式对你已经理解的修复增加零价值。