让 agent “给这个遗留代码库加测试”，它开始给工具函数写测试——80% 的时间花在琐碎代码上，而没测试的支付模块无人问津。根因：它跳过了探索阶段，对先碰到的东西直接开干。
探索优先模式
- 地形勘察 — 代码库结构、模块边界、依赖图
- 识别优先级 — 高风险区域（使用最多、变更最频繁、最复杂、测试最少）
- 基于发现做计划 — 不是基于对代码样子的假设
- 执行并适应 — 执行过程中发现未文档化的依赖、隐式模式时调整
没有第 1-2 步，agent 没有优先级依据。它按遇到的顺序测试文件，通常是字母顺序或目录遍历顺序——都和代码重要性无关。
发现后修订计划
初始计划：重构模块 A → B → C → D → E。重构 A 的过程中，agent 发现 C 对 A 有紧密的未文档化依赖。单独重构 A 而不同时处理 C 会搞坏系统。
正确：修订计划。A 和 C 一起重构，然后继续 B → D → E。这就是动态分解的核心——计划适应发现。
错误：按原计划继续，“以后再修 C”。你已经知道它会坏。现在适应能防止那个故障。
瀑布反模式
“阶段 1：探索所有东西。阶段 2：创建完整计划。阶段 3：执行。阶段 2 后不允许改变。”
这假设在执行前能收集到完整知识——对开放任务来说是假的。遗留代码库在修改过程中才暴露真正的复杂度，不是在探索时。锁定的计划在执行开始那一刻就过时了。渐进式的探索-计划-执行循环更有效。
时间约束下的有界探索
探索所有东西太慢了。一个有 3 个模块、复杂度各异的代码库：
- 模块 A：3 个文件，简单，有文档 → 5 分钟完全探索
- 模块 B：15 个文件，复杂，无文档 → 45 分钟完全探索
- 模块 C：8 个文件，中等 → 20 分钟完全探索
- 总探索：70 分钟。重构预算：总共 120 分钟。只剩 50 分钟。
有界探索：模块 A 简略（3 分钟），模块 C 适度（10 分钟），模块 B 够识别优先级（20 分钟）。总计：约 33 分钟，留约 87 分钟给定向重构。随着重构揭示模块 B 的结构，增量式地重访探索。
探索时间按不确定性和复杂度分配，不是均匀分配。
时间受限的开放任务
30 分钟给一个不熟悉的代码库加测试。5/25 分配：
- 5 分钟：快速探索——根据结构、命名和复杂度信号识别 3 个最关键模块
- 25 分钟：聚焦在那些模块上写测试
简短的探索确保精力瞄准正确的代码。即使 5 分钟的探索也比”先碰到什么就测什么”的定位准确度大幅提升。
约束下的渐进深入
500 个文件，零现有测试，一个会话。不可能全部测试。
- 快速探索：勘察结构，识别关键路径
- 先给最高风险模块写测试
- 时间允许则扩展到中等风险
- 每写一个测试都能指导接下来测什么
如果在任何时候时间用完了，最关键的代码已经有了覆盖。这严格优于随机、字母顺序或均匀方法。
一句话总结： 不探索就直接开干，80% 的精力瞄准琐碎代码——先探索再定优先级，探索时间按复杂度分配，发现未文档化依赖时修订计划，时间受限时用快速探索（5 分钟）再聚焦执行（25 分钟）。