Plan 模式已死
随着像 Claude 和 Codex 这样的 AI 编码助手不断进步，许多用户认为单独的“plan 模式”——即模型先概述步骤再修改代码——已经变得多余，因为更新的模型可以通过对话式指令被要求先规划、再行动。也有人强烈支持显式规划阶段，认为它是必要的安全护栏：它能暴露设计假设，让人类与 agent 将要做的改动保持一致，提供审计轨迹，并降低对 schema 或生产数据库等进行高风险修改的风险。无论哪种观点，大家普遍都认为，在复杂或高影响范围的工作中，规划本身仍然至关重要；真正的争论在于，它应当存在于一个专门模式里，还是作为更灵活的工作流的一部分，借助提示词、规格文件和多 agent 审查来完成。
Plan 模式的作用与价值
- 许多开发者仍然依赖 plan 模式，把它当作一个独立的“先暂停再行动”步骤：
- 强制模型先收集上下文，并在动代码之前概述改动。
- 让人类在昂贵或有风险的修改之前，预览架构决策、风险和取舍。
- 作为高影响范围工作（认证、支付、schema、生产数据库、复杂重构）的预演或“审计检查点”。
- 有些人用 plan 模式迭代加固规格：反复运行，直到问题都问完，然后再执行。
- 还有人把计划当作持久化产物（plan.md、spec 目录、AGENTS.md），可以版本化、被多个 agent 审阅，并在不同会话/模型之间复用。
认为 Plan 模式过时或被高估的观点
- 一些用户表示，新模型（例如最近的 Claude/Fable/Opus、某些 GPT/Gemini 配置）“直接就懂了”：
- 只要在普通模式下给出一句简单指令，比如“先规划，不要现在写代码”，对他们来说就能稳定工作。
- 很长的、自动生成的规划文字被认为难以审阅，也与人类实际构建理解的方式不太一致。
- 有人认为，最初的需求——防止“失控”agent——随着指令遵循能力提升已经不那么重要了。
- 也有人担心，内置的 plan 模式不过是 harness 提示词，而不是真正的沙箱或权限系统，而且可能在没有相称收益的情况下增加成本和延迟。
替代工作流与工具
- 常见替代方案包括：
- 用对话式规划，并明确要求“先不要修改”。
- 由 agent 维护专门的计划文档，实施时开启全新会话。
- 多 agent 设置：一个模型规划，其他模型实现，还有其他模型审查（有时通过诸如 plannotators、“grill me” skills 或 MCP servers 等单独工具）。
- 以规格或蓝图为驱动的工作流，由人类编写或严格整理规格，agent 补齐空缺。
控制、安全与质量方面的担忧
- 对意外修改的强烈焦虑，尤其是数据库和大型代码库；有些人希望有明确的只读或沙箱模式。
- 担心没有结构化规划的“vibe coding”会加速技术债，并削弱开发者对自己系统的理解。
- 反方观点：即使理解滞后，agent 之后仍然可以解释、画图并重构 AI 写出的代码，这会把重点从手工所有权转向验证和监督。
总体情绪
- 广泛共识是：规划 至关重要。
- 分歧在于，专门的“plan 模式”界面/机制是否仍然是实现这一点的最佳方式。