复杂任务跳过规划，55% 的回滚率

Plan 模式提供只读探索。不修改文件。你映射依赖、评估方案、设计解决方案，然后才动手。接着切到直接执行去实现。

决定不是”要不要规划？“而是”这个任务有不确定性吗？“有就用 plan 模式。解决方案已知的就直接执行。

数据

一个团队跟踪了 100 个任务的两种模式：

复杂任务不规划超过一半失败。简单任务不必要的规划浪费双倍时间换 3% 的成功率提升。模式必须匹配任务复杂度。

什么时候用 Plan 模式

存在多种有效方案。 “给 API 层加缓存”有三种选项——Redis、内存、文件——每种对数据库和会话层有不同影响。Plan 模式在提交前探索每种选项的影响。

代码库不熟悉。 新团队成员被要求实现一个跨模块特性，从没见过这代码。Plan 模式在改动前映射结构、边界和规范。

需要架构决策。 把单体重构为 3 个微服务，跨 45+ 文件有复杂相互依赖。一个开发者跳过规划用直接执行，改了 12 个文件花 30 分钟后发现方案和会话管理系统冲突。全部回滚。Plan 模式在任何改动之前就能发现那个冲突。

多文件有相互依赖。 变更在代码库中级联的需要知道什么连着什么的地图。

什么时候跳过 Plan 模式

解决方案已知。 堆栈跟踪指向第 42 行，修复显而易见。直接执行。

范围清晰且小。 修错别字、更新常量、添加已知测试用例。不需要探索。

单文件且改动明确。 没有依赖要映射，没有方案要评估。

标准不是文件数、不是预估时间、不是开发者资历。是任务复杂度和不确定性。不熟悉代码中的 1 文件改动可能需要 plan 模式。已知模式的 20 文件改动可能不需要。

Plan → Explore → Direct 工作流

大代码库（500+ 文件）中，即使 plan 模式也可能用探索输出填满上下文。组合工作流解决这个问题：

1. Plan 模式 — 建立只读安全上下文
2. Explore 子代理 — 在隔离上下文中做冗长的代码库发现，只返回摘要到主会话
3. 直接执行 — 用保留给编辑的主上下文实现改动

Explore 子代理对大规模探索至关重要。没有它，读几百个文件会填满主上下文，不留空间给设计或实现阶段。子代理的摘要保护了上下文预算。

/compact 是有损的替代——它压缩对话但可能丢弃设计需要的探索发现。Explore 子代理是无损的：完整结果存在于子代理的上下文中，摘要提供主会话需要的。

注意：plan 模式是只读的。它不能实现改动。工作流必须切到直接执行做实现阶段。子代理也没有无限上下文——它们的价值是隔离和摘要，不是更大容量。

“总是规划”反模式

团队负责人提议每个任务都用 plan 模式。这是错的。简单任务上 plan 模式浪费时间——解决方案已知时探索的价值为零。数据显示简单任务有 2 倍开销且质量没有提升（100% vs 97%）。

反向反模式——从不规划——更糟。架构重构上直接执行导致 55% 的回滚率。但”总是规划”过度纠正了，给 35% 不需要规划的任务增加了开销。

满足双重约束

团队需要质量（不回滚）和速度（快速完成）。组合方案：

• 复杂/不确定的任务： Plan 模式调查，然后直接执行实现。质量优先防止回滚。
• 简单/已知的任务： 立即直接执行。速度优先避免不必要的开销。

通过在各自提供价值的地方应用每种模式来满足两个约束。

一句话总结： 不知道答案时用 plan 模式；知道时用直接执行——模式匹配任务不确定性可以同时防止 55% 的回滚率和 2 倍的开销。