什么是 Recovery Template 和 Default Order？
在 AI 编程工作流中，团队经常需要控制 agent 的回复顺序，尤其是在并行调用、多步回溯或状态恢复场景。Recovery template 是指当某次生成失败或需要重新生成时，系统按预先定义的模板只替换受影响部分，而保留其他上下文。Default order 则是严格按照请求发出的顺序依次生成回复，即使中途有失败也会等待或跳过，不改变未受影响部分的顺序。
简单说，recovery template 是“局部重试”，default order 是“整体排队”。
适用场景：什么时候选哪个？
Recovery Template 适合：代码审查和局部修复
当你的 AI agent 负责代码审查（code review）时，经常需要修改某一行或某一个函数，而不想影响其他已审核的代码。例如，团队用 AI 审查 PR，发现某个函数有 bug，你用 recovery template 让 agent 只重新生成那个函数的建议，而保留其他评论和上下文。这样既能快速修复，又不会让 agent 重新输出所有内容。
实操例子：
- 你用 AI 生成了 5 个针对 PR 的评论。其中第 3 条评论的修复建议有错误。
- 用 recovery template：将第 3 条评论替换为正确版本，其他 4 条不动。
- 用 default order：你需要从头重新执行整个审查，或者手动跳过，容易丢失工作。
Default Order 适合：一致性要求高的流程
当你的团队需要严格按固定顺序执行任务时，比如自动化 CI/CD 流水线、逐步部署脚本，或者多 agent 协同的严格流程，default order 能保证结果的可复现性。例如，AI 按顺序生成测试用例、然后运行、然后报告。如果其中一步失败，default order 会明确中断，方便你定位问题，而不会像 recovery template 那样“静默”隐藏局部错误。
真实场景：某团队在用 AI 生成全量迁移代码时，用了 recovery template 试图快速重试失败步骤，结果因为上下文不一致导致迁移后的代码出现隐式 bug。后来改用 default order，虽然慢，但每次失败都能追溯到准确步骤。
最容易踩的坑
误区 1：盲目追求速度而用 recovery template
有些团队为了让 AI 响应更快，所有场景都用 recovery template。但 recovery template 依赖于模板的准确性和上下文的完整性。如果模板定义不严谨（比如替换范围过大或过小），很容易出现“局部正确，整体错乱”的情况。例如，一个函数签名改了，但 recovery template 只替换函数体，导致签名不匹配。
误区 2：认为 default order 一定更稳定
Default order 按序执行，但一旦出现长时间等待或挂起，后续所有请求都会被阻塞。在并行处理大量小任务时，default order 可能变成瓶颈。
误区 3：忽略上下文一致性
两种策略都依赖 context。如果你在执行过程中修改了外部状态（比如数据库、环境变量），recovery 的模板无法感知这些变化，导致生成结果与预期不符。
具体对比决策表
| 对比维度 | Recovery Template | Default Order |
|---|---|---|
| 核心适用场景 | 局部重试、代码审查、修复 | 严格顺序、流水线、可复现性 |
| 执行速度 | 快（只重试局部） | 慢（按序执行） |
| 一致性与可追溯性 | 低（可能隐藏中间错误） | 高（每一步可观察） |
| 实现复杂度 | 高（需要设计模板和补丁策略） | 低（按序编排即可） |
| 失败影响范围 | 局部（可单独修复） | 全局（可能阻塞后续） |
失败时的备用方案
当 recovery template 因上下文不一致导致错误时，回退到 default order 重新执行整个流程。具体做法：记录请求的初始状态（包括所有输入和环境快照），然后按原顺序重新发送请求，不跳过任何步骤。这能确保结果可复现。
如果 default order 因长时间挂起而失败，可以采用 超时 + 重试模板，即对超时的单步设定 recovery template 只重试该步，但依然保持其他步骤顺序。
迁移检查清单
如果团队正在从 default order 切换到 recovery template（或反之），以下清单能帮你避免常见问题：
- 明确哪些步骤有严格的顺序依赖（必须用 default order）
- 定义 recovery template 的作用域（替换什么、保留什么）
- 确保上下文快照在重试前不变
- 设置日志记录每次重试的模板和实际替换内容
- 灰度测试：先用 recovery template 在低风险任务上（如代码格式化），再逐步扩大
下一步动作
理解这两种策略后，建议先在自己的 AI 工作流中画出一个“风险阶梯”，把任务按失败容忍度和顺序依赖分成两类，分别应用不同策略。然后从小范围试点开始，逐步优化。
暂无评论，快来发表你的见解吧