AI 编码工具中计划模式的衰落

从线性规划到迭代执行的转变

传统的 AI 编码工具中的「计划模式」——即模型在编写任何代码之前生成一个结构化规格供人类审批——正变得过时。这一转变是由模型能力的显著提升以及一个根本性认识所驱动的:软件开发是一个发现性的迭代过程,而非线性步骤序列。

对许多开发者而言,聊天 → 规格 → 审查 → 实现 这种僵化的流程已被证明具有破坏性。现实世界中的工程实践通常遵循更自然的循环:理解 → 行动 → 检查 → 明确 → 调整 → 再次行动。在这个模型中,构建行为本身揭示了下一组问题,因此预先定义的「计划」是一种人为的约束,迫使用户过早地完成思考。

传统计划模式为何失败

几个技术和心理因素共同导致了显式计划文档的衰落:

1. 模型能力与界面设计的差距

随着模型在通过扩展上下文窗口和更好的记忆能力探索代码库并做出合理架构假设方面的能力提升,人类通过详细计划来显式引导模型的需求已大幅减少。模型能够可靠自主做出的每一个决策,都是无需在计划文档中呈现的决策。

2. 「AI 生成文本」的摩擦

阅读长篇 AI 生成的规格存在显著的认知负担。LLM 生成的文本往往结构过于严密且重复,容易导致「视而不见」,即人类审阅者因文本过于枯燥而忽略关键错误。当规格变得过长而无法有效使用时,该文档的价值便消失了。

3. 将规划与计划混淆

在 规划(对问题进行推理的认知过程)和 计划(该过程产生的静态文档)之间存在关键区别。虽然规划过程仍然至关重要,但生成的文档往往是一个低价值的产物,一旦开始实现,便迅速过时。

对规划的不同看法

尽管趋势倾向于迭代执行,但相当一部分开发者社区仍认为显式规划在特定场景下依然至关重要:

支持保留计划模式的观点

  • 风险缓解: 对于高风险的架构变更或高成本的计算任务,设置「暂停并确认」的检查点可防止代价高昂的错误。
  • 上下文收集: 一些开发者主要使用计划模式来迫使模型在开始编写代码前读取更多代码库内容,从而降低「幻觉式」实现的可能性。
  • 人类导向: 规划有助于人类保持对系统的心理模型,尤其是在多个代理并行修改时。
  • 复杂编排: 对于非常大型的功能,将主计划拆分为更小、可并行的子计划,可以提升模型的「视野」,避免上下文压缩问题。

支持迭代方法的观点

  • 更快的反馈循环: 在代理产生具体结果后进行纠正,通常比在文本文档中预测所有边缘情况更快。
  • 降低认知负荷: 消除「任务是否足够大以值得正式计划」这一元问题,可减少摩擦。
  • 基于执行的发现: 如一位社区成员所言:「执行就是答案」,因为只有在变更真正发生后,你才能知道编译器或远程系统会如何反应。

AI 辅助理解的未来

计划模式的消亡并不意味着规划的终结;相反,它标志着需要新的界面来支持人类理解,而无需依赖冗长的文本文档。持续的挑战在于:当机器改变系统的速度超过人类检查变更的速度时,人类如何维持对软件系统的连贯心理模型。

传统计划模式的新兴替代方案包括:

  • 交互式「质询」: 使用专门的提示(例如 Matt Pocock 的「grill-me」技能),强制 AI 在实现前向用户提出详尽的澄清问题。
  • 确定性可视化: 在 README 中生成数据模型或 RBAC 表的 SVG 图,提供比文本规格更易解析的、可验证的真相来源。
  • 代理审查: 使用第二个代理在主代理执行代码前,根据项目规则审查提议的方法。

Sources

相关

  • Dispatch
  • 项目
  • Dispatch
  • Dispatch
  • Dispatch