Plan Mode才成标配，就有人宣布它「已死」

来源：市场资讯

（来源：机器之心）

机器之心编辑部

这两天，Hacker News 上一个题为《Plan mode is dead》的帖子火了。

它的作者是亲手把「计划」做成产品、又亲自复盘这条路为何走不通的人：Ayman Nadeem，她是 YC 孵化的小型 AI 编程公司 Nuanced 的创始人兼 CEO。

今年早些时候，Nadeem 坚信，计划会成为 AI 编程最重要的环节。于是，她围绕这一判断打造了一款桌面编程应用，希望帮助开发者在代码生成速度大幅提升之后，重新掌握软件构建过程。

几个月后，她改变了看法。

这篇文章真正触及的，是 AI 编程工具里一条正在松动的产品假设：写代码前，人要先把需求、架构和执行步骤整理成一份完整计划，再交给 Agent。

以下为博客原文编译（第一人称）。文中出现 Planning 时翻译为规划，Plan 翻译为计划。

今年早些时候，我相信规划会成为用 AI 构建软件时最重要的环节。

我对这个判断深信不疑，甚至围绕它打造并发布了一整套桌面编程应用。Nuanced 的出发点是：AI 已经大幅提升了代码生成的速度和数量，可支撑这种新工作节奏的界面还没有跟上。

Nuanced 在规划上的方案失败了，但这段经历也让我看到，计划模式整体上已经没有过去那么有用了。

过去，计划模式主要承担两项工作：为 Agent 提供足够精确的指令；帮助人类理解自己正在构建什么。随着模型能力提升，第一项工作正在迅速变得过时。第二项工作比以往更重要，可计划模式并不适合承担这个任务，尤其是在并行运行的 Agent 数量不断增加之后。

我为什么做 Nuanced

就会自行补足空白。它划分抽象边界的方式，可能会在之后给我带来问题。对于预期行为和设计目标的误解，会沿着多个文件向深处传播，隐藏在聊天界面之下，很容易被遗漏。

在这种表层之下摸索那些难以理解的问题，感觉还不如一开始就把设计做好高效。

这段经历让我在精神上与工作脱节，甚至有些像行尸走肉。Conductor、Codex 等编码应用让并行运行多个 Agent 变得更加容易，这种感觉也随之变得明显。

我觉得自己很难像过去那样集中注意力，也很难深入理解正在做的事情。要判断生成结果是否正确，也变得更加困难。

当时没有一条清晰、可解释的轨迹，能够呈现「用户提示词 → Agent 决策 → 代码 → 产品行为」之间的联系。

这并不意味着我想回到过去，重新逐行查看代码或文件。事实上，我觉得用自然语言思考想法更容易，也更高效。我希望自己能够站在代码之上工作，同时继续理解系统是如何运行的。

现有计划模式缺乏协作感

我逐渐意识到，虽然计划模式已经存在，但适合良好规划的抽象方式仍然不存在。

我先后使用了 Claude Code CLI、Conductor，后来又使用了 Codex。期间，我总是在反复塑造、删改计划，却没有一个明确的地方可以持续迭代。

在 Codex 的批注功能出现之前，我通常只能通过聊天推进这件事，再把计划中的部分内容复制到新的消息里修改。这样的复制粘贴流程很笨拙，也让围绕一个想法展开工作、同时掌握当前计划变得十分困难。

我希望给计划一个固定的归属，把它放进整体工作流中，让它从随着对话推进而逐渐淹没在历史记录里的临时文字，变成一份持续存在、可以不断更新的文档。

我希望把计划模式变成指导开发的一等能力，因为我需要：

• 思考接下来要做什么；

• 确保自己的描述足够准确；

• 理解已经完成了什么；

• 在出现问题时，理解问题发生的时间和原因。

打造理想工作流

我思考了自己理想中的工作方式，决定把它编码成一款产品。

Nuanced 允许用户创建多个线程，每个线程都是一段聊天对话。用户可以在其中讨论想要构建的东西，系统会指出其中的歧义，以及需要用户做决定的事项。双方共同推进，最终在实现开始前形成一份持久化计划。

之后，Nuanced 会按照计划执行，确保生成的代码符合用户要求。

我想建立一条从意图开始，一直延伸到实现、审查和验证的完整流程。

在我看来，Nuanced 更像是人类心智的义肢，也可以说是我这个 ADHD 大脑的义肢。它承担指导工作，也帮助我持续掌握项目正在发生什么。

我错在哪里

我对现有工具缺口和软件开发生命周期变化的判断，大体没有错。真正没有达到预期的，是我们的实现方式。

原因有几个：我把规划和计划混为一谈；模型变得足够强大；没人愿意阅读 AI 生成的文字；我们用一种打断工作连续性的方式，把规划和构建分开了。

规划（Planning） ≠ 计划（Plan）

我们最先发现，自己把规划和计划混为了一谈。两者其实并不是同一件事。

我原本认为，在实现之前留出充分思考的空间很有价值。我也认为，随着项目推进，把这些思考保存在一份大型结构化文档中会很有价值。

但早期用户对这类规格文档的兴趣，出乎意料地低。

模型变得足够强大

随着模型借助上下文和记忆理解大型代码库的能力增强，它们越来越擅长探索代码仓库，并自行做出合理判断。

人类需要明确告诉模型「请产出一个经过充分思考的结果」，这种需求已经减少了。

我原本没有想到，模型能力会和 “为人类思考设计更好的界面” 形成竞争关系。模型每可靠地自行做出一个决定，就少有一个决定需要单独提出来交给人处理。

AI 生成的文字读起来很痛苦

那份规格文档包含了更多信息，却没有带来同等程度的清晰度。

原因之一，是我们的规格文档太长了。它们记录了重要决策，也包含了许多看起来有用的背景信息。问题在于，这些文字是 AI 生成的。

AI 生成文字的节奏和过度结构化的写法，会让阅读变得非常困难。我经常读着读着就走神了。

发现这个问题后，我们没有立即放弃规格文档，而是做了一个 Spec Tour，希望带着用户浏览文档中的重点。

结果，这只是又增加了一层复杂度。屏幕上出现了更多文字，也有更多内容要求我分散注意力。

如果必须再生成一份更短的规格摘要，才能让原来的规格文档变得可用，那么完整文档存在的意义又是什么？

我们把一个本应连续的过程拆开了

我们的工作流过于线性，也过于强调顺序。大致流程是：

聊天 → 通过回答问题消除歧义 → 生成规格文档 → 审查规格文档 → 修改规格文档 → 批准 → 实现 → 审查代码

真实的思考不会这样进行。把这些环节彼此分开，也显得人为和生硬。

通常情况下，你会先理解问题的一部分，再尝试做点什么。第一次生成会带来新的认识，让你改变原来的想法，尝试另一种方案。每一步都会暴露新的问题。

规划和构建往往彼此交织，也会自然展开。计划模式很难容纳这种方式，尤其是 Nuanced 当时的设计。

我们的界面要求用户过早地「结束思考」，这样才能开始构建。实现一旦开始，再回到之前基于聊天的推理过程，就像在工作流中倒退。那条瀑布流无法逆行。

观察 Codex 目前的工作方式，你会发现规划和执行之间的边界正在消失，二者逐渐合为一体。

早期，编码 Agent 更适合这样的流程：

规划 → 批准 → 执行

那时，走错方向的代价高得多。

随着 Agent 更擅长理解系统，它们也越来越能自主行动、测试自己的工作，并在检查结果后调整方案。这使另一种循环成为可能：

理解 → 行动 → 检查 → 澄清 → 调整 → 再次行动

这个循环中依然包含大量规划，只是规划不一定要呈现为一份名为「计划」的文档。

我最大的错误，是把计划做成了一个成果文档，却没有设计出一个能够提升人类理解力的过程。

计划模式与构建模式的分离很奇怪

Nuanced 同时提供计划模式和构建模式，用户可以任选其一开始。

计划模式总会生成一份规格文档。构建模式不会强迫用户先写规格文档，适合那些不值得专门制作规格文档的小任务。但这两种模式之间的分离很尴尬。

用户需要先问自己一个元问题：这个任务是否值得规划？如果值得，还要记得通过按钮或键盘快捷键启用计划模式。

这种区分应该由 AI 根据已有上下文替用户判断。让用户记住自己该处于哪种模式，只会增加认知负担。

意识到这一点后，我有种「midwit 梗图」的感觉：原来，一个简单的聊天界面，按需进行规划，而不是默认进入计划流程，体验可能已经相当不错。

我们仍未解决「理解」问题

思考要构建什么、为什么重要，以及评估各种决策，依然十分重要。人需要建立对系统正在发生什么的连贯理解，但我不认为一大段由 AI 生成的文字适合承担这个任务。在聊天中逐步推进决策，感觉更加直观。随着系统不断变化，如何让这种理解始终保持更新，仍然是一个悬而未决的问题。

当 Agent 数量从五个增加到几百个，这个问题会变得更加困难。

跟上变化，不能意味着阅读每一段对话，再为每一次代码变更单独要求解释。Agent 需要找到少数几个最值得人关注的位置，并提供足够的上下文，让人的注意力真正产生作用。

当数百个能力不断增强的 Agent 同时修改一个系统时，我们仍然没有解决如何帮助人保持方向感的问题。

但在我看来，更深层的问题始终存在：人类如何理解系统，如何穿行于复杂的信息层级，如何使用强大的工具。

界面会随着背后的技术一起变化，让复杂性变得可理解的需求不会消失。

网友热评

对于 Nadeem 的观点，支持、反对的人皆有。

一位自称参与 Claude Code 开发的人基本认同「Plan Mode 过去有用，但现在价值正在下降」的判断。他解释，Claude Code 的 Plan Mode 本质上一直只是一个提示机制，用来提醒模型「先规划，不要立刻写代码」，并没有真正改变模型可调用的工具。随着模型能力提升，他自己已经越来越少使用 Plan Mode：模型对任务意图的理解更好了，而在更复杂的任务中，规划也越来越呈现出交互式、迭代式的特点，很难在执行前一次性完成。

不过，他并不认为「理解代码变化」这个需求已经消失。对于核心系统中的复杂修改，他有时会让 Claude 额外生成说明文档、架构图甚至交互式 Demo，帮助自己和其他开发者理解改动及其备选方案，并把这些材料附在 PR 中，为后续协作和未来继续处理项目的 Claude 保留上下文。

这里帮大家回顾一下，2025年中，Claude Code率先把「规划」和「执行」做成明确的模式区分；此后Cursor、GitHub Copilot快速跟进。2026年初，OpenAI Codex和Google Gemini CLI也先后补齐 Plan Mode。到 2026 年 3 月，Plan Mode已经从 Claude Code 的一个交互设计，变成主流Coding Agent几乎都会提供的一种产品形态。

另一位开发者认为，Plan Mode 的价值仍然很明确，尤其是在大型代码库和复杂任务中。它至少能让开发者先理解 Agent 准备采取的策略，并有机会检查设计和架构。如果缺少这一步，开发者很容易逐渐失去对代码的理解，Code Review 也可能退化成简单的「打勾通过」，最终让代码库变得越来越臃肿、难以维护。他尤其担心，能力较弱的开发者虽然表面产出提高了，却没有真正建立起对系统的理解，团队也可能因此快速积累大量技术债务。

大家怎么看呢？

Hacker News 原贴地址：https://news.ycombinator.com/item?id=49840054

原文链接：https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/09/24/plan-mode-is-dead.html