最近海外爆火的文章，分享给大家

原文：Ayman Nadeem，《Plan mode is dead》，Plan mode is dead | Ayman Nadeem

计划模式已死

2026年9月24日

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

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

我对这个想法深信不疑，甚至围绕它构建并发布了一整款桌面编程应用。Nuanced 的出发点是一个观察：AI 已经极大提高了代码生成的速度和数量，但支持这种新工作节奏所需的界面还没有跟上。

Nuanced 的规划方法失败了，但这也让我看清，更广泛意义上的计划模式已经没那么有用了。过去，计划模式有两个用途：(1) 给出足够精确的指令，让智能体可以执行；(2) 帮助人类理解自己正在构建什么。

我认为，随着模型变强，第 1 点正在迅速过时。第 2 点比以往任何时候都更重要，但计划模式并不是实现它的正确抽象，尤其当我们并行运行的智能体越来越多时。

我为什么构建 Nuanced

我当初有动力去做的产品，最终回答了一个我认为仍然相关、而且永远相关的问题：当机器改变软件系统的速度快于人类检查改动的速度时，人类如何维持一个连贯的软件系统心智模型？

模型可以在几分钟内写出数千行代码，这意味着你还没想清楚自己在构建什么、为什么构建，就已经背上了巨大的维护负担。这会让人难以推理系统行为，也难以调试那些过早被固化进代码里的错误假设。

虽然这样生成代码很轻松，会触发更强的多巴胺奖励，但它掩盖了那些令人不适却必要的工作：理解为什么构建某个东西很重要、它究竟是否重要，以及严格评估产品、设计和基础设施决策。我常常还没自觉地做出任何产品决策，就已经有了一个产品。如果我对架构说明得不够充分，智能体就会擅自填补这些空白，哪怕它划分抽象边界的方式之后会给我制造麻烦。这些关于预期行为和设计的误解，会在聊天界面之下、深藏在多个文件里扩散，很容易被漏掉。在这层表面之下摸索那些难以看清的问题，感觉不如一开始就把东西设计正确来得高效。

这种体验让我在精神上感到脱节，像行尸走肉，尤其当 Conductor 和 Codex 这类编程应用让人能并行运行更多智能体之后。我觉得自己无法真正专注，也无法像从前那样深入理解自己正在做的事情。这也让我更难验证生成结果是否正确。

没有一条清晰、可解释的轨迹，能展示用户提示 → 智能体决策 → 代码 → 产品行为之间的联系。这并不意味着我想回到逐行看代码或翻文件的老日子。实际上，我觉得用自然语言推理想法更容易、更高效。我想自信地在代码之上航行，而不必牺牲对系统运作方式的理解。

现有计划模式不够有协作感

我觉得，虽然计划模式已经存在，但真正能做好规划的正确抽象并不存在。当我在 Claude Code CLI、Conductor，以及后来发布的 Codex 之间轮换使用时，我发现自己一直在精心塑造和削减计划，却没有一个明确的地方来迭代它们。我会用聊天，然后把计划片段复制到新消息里修改（在 Codex 有标注功能之前）。这种剪切粘贴的工作流很笨拙，让我在推进一个想法时还要追踪当前计划，变得很费劲。

我想给计划一个归宿，把它们扎根于我的整体工作流，让它们从随着对话推进而消失在聊天记录里的临时文本块，变成一份活的、会呼吸的、持久存在的文档。我想把计划模式变成指导开发的一等原语，原因有几个：

• 我需要思考要做什么。


• 我需要确保自己描述得足够精确。


• 我需要理解已经做了什么。


• 我需要理解事情何时出错，以及为什么出错。

构建理想

我思考了自己理想中的工作流，并决定把它编码进一个产品，让它成为现实。Nuanced 让你可以创建线程，每个线程就是一段聊天对话。你可以把想构建的东西聊清楚，系统会浮现出需要你输入的模糊之处和决策，然后你们一起在实现开始前得到一份持久计划。接着，Nuanced 会实现你的计划，确保生成的代码符合你的要求。我想要一条端到端流水线，从意图开始，一路贯穿到实现、审查和验证。我更多把它看作人类心智（或者说我这种 ADHD 心智）的义肢，而不只是又一个编程应用；因为它既被设计来下达指令，也被设计来帮我随时掌握正在发生什么。

我为什么错了

与其说我对现有工具缺口或软件开发生命周期（SDLC）如何变化的判断错了，不如说我们的实现没有交付我们预期的解决方案。原因在于：

• 我把规划与一份计划混为一谈


• 模型变得非常强


• 没人想读 AI 生成的文本


• 我们以一种破坏性的方式把规划和构建分开

规划 != 计划

我们学到的第一件事是：我们把规划与一份计划混为一谈。二者其实不是一回事。我当时的假设是，在实现之前有空间彻底思考某件事是有价值的。我还以为，随着项目演进，把这种思考保存在一个大型结构化产物中也会很有价值。但早期用户对这种规格文档的兴趣低得惊人。

模型变得非常强

随着模型通过上下文和记忆更好地理解大型代码库，它们很擅长探索仓库并做出合理假设。明确指示它们产出一个深思熟虑结果的需求，已经缩小了。

我原本没把模型能力与“为人类思考设计更好的界面”看作彼此竞争，但在很多方面，它们确实在竞争。因为模型能可靠自行做出的每一个决策，都是少一个需要呈现给人的决策。

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

规格文档包含了更多信息，却没有带来更多清晰度。这是因为我们的规格很长。它们记录了重要决策，包含了很多看似有用的上下文，但问题在于：它们是 AI 生成的。AI 生成文本的节奏和过度结构化的特质，让它们非常难读。我的眼睛总是看着看着就发直。

发现这一点后，我们没有直接砍掉规格，而是做了一个 Spec Tour 来解决。我们以为，与其让人消化整份文档，不如让 Spec Tour 带他们浏览重要部分。但这只是又加上一层复杂性，让屏幕上更多文字争夺注意力。如果我们必须生成一份更短的规格表示，才能让规格可用，那完整文档一开始到底还有什么意义？

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

我们的工作流太线性、太按顺序了。我们的流程大致是这样：

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

真正的思考不是这样发生的，这些部分之间的分隔显得人为而勉强。通常你会先理解问题的一部分，尝试做点什么，最初的生成又会教给你新东西，这可能让你改变想法并尝试别的。每一步都会暴露一个新问题。规划和构建是交织在一起的，比计划模式所允许的更有机地涌现，尤其是我们在 Nuanced 里的做法。我们的界面迫使用户过早地“结束思考”，好开始构建。一旦实现开始，再回到之前基于聊天的推理，就像在工作流里倒退。你没法逆着瀑布往上走。

看看 Codex 目前的工作方式，规划和执行之间的边界正在消失，二者坍缩为一体。早期，编程智能体从人类这样的工作流中受益：

计划 → 批准 → 执行

那时候，走错方向的代价要高得多。但随着智能体更擅长理解系统，它们也更擅长自主行动并测试自己的工作。它们还擅长在检查结果后修正自己的方法。这催生了一种不同的循环：

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

这个循环里仍然发生着大量规划，但它不一定需要以一份叫“计划”的文档出现。我认为我犯的最大错误，是把计划变成了一种产物，而不是设计一个增进人类理解的过程。

计划模式和构建模式是一种奇怪的分离

Nuanced 有计划模式和构建模式，用户可以从任意一个开始。计划模式总会生成一份规格，而构建模式不会强迫用户进入规格，适合那些不值得写规格的较小任务。但两种模式之间的分离很别扭，用户得先问自己一个元问题：这个任务值不值得规划？如果值得，还得记住通过按钮或快捷键激活计划模式。这种感觉就像，这种区分本应由 AI 根据它已经掌握的上下文替你判断，而记住自己该用哪种模式，只会带来更多认知负担。

这个领悟让我觉得自己像那张“中等智慧”梗图：聊天界面按需规划、而非默认规划，这种简单其实相当不错。

我们仍未解决理解问题

思考要构建什么、为什么重要，以及评估决策，仍然很重要。人们需要建立对正在发生的事情的连贯心智模型，但我不认为一大团 AI 生成的文本是合适的界面。在聊天中推进决策感觉更直观，但随着系统变化让这种理解保持最新，仍是一个未解问题。

当你从五个智能体扩展到数百个时，这个问题会更难。跟上进度不可能意味着阅读每一段对话，并试图为每个代码改动提示一个解释。智能体需要找出人类注意力能产生最大影响的最少位置，并提供足够上下文，让这份注意力有用。

我们仍未解决：当数百个能力越来越强的智能体同时改变一个系统时，如何帮助人们保持方向感。但我认为更深层的问题——人类如何理解系统、穿越复杂的信息层级并使用强大工具——是一个持久的问题。界面会随着驱动它们的技术不断变化；而让复杂性变得可理解的需求不会变。