计划模式已死

最近海外爆火的文章，分享给大家 原文：Ayman Nadeem，《Plan mode is dead》， Plan mode is dead | Ayman Nadeem 今年早些时候，我相信规划将成为使用人工智能构建软件的最重要部分。 我对这个想法的信念如此坚定，以至于我围绕它构建并启动了整个桌面编码应用程序。 细致入微 其动机是观察到人工智能从根本上提高了代码生成的速度和数量，但支持这种新的工作节奏所需的界面尚未跟上。 Nuanced 的计划方法失败了，但它也向我揭示了更广泛的计划模式如何不再有用。从历史上看，计划模式有两个目的：（1）它们为代理指定足够精确的指令，（2）它们帮助人类理解他们正在构建的内容。 我认为随着模型变得更好， #1 正在迅速过时。我认为#2 比以往任何时候都更重要，但计划模式对于它来说是错误的抽象，特别是随着我们运行的并行代理数量的增加。 为什么我构建 Nuanced 我想要构建的产品最终回答了一个我认为仍然相关且永远相关的问题，即：当机器改变软件系统的速度快于人类检查变化的速度时，人类如何保持软件系统的连贯心理模型？ 模型可以在几分钟内编写数千行代码，这意味着您在考虑要构建什么或为什么构建之前就承受了巨大的维护负担。这使得推理行为和调试过早固化为代码的错误假设变得困难。 虽然以这种方式生成代码的简便性引发了更大的多巴胺奖励，但它混淆了理解为什么构建某些东西很重要、它是否重要以及严格评估产品、设计和基础设施决策的令人不安的工作。在有意识地做出任何产品决策之前，我经常会先拥有一个产品。如果我对架构的指定不足，代理就会冒昧地填补这些空白，即使它划分抽象边界的方式后来给我带来了问题。这些对预期行为和设计的误解将通过聊天表面下的多个文件传播，并且很容易被忽略。与一开始就正确设计一些东西相比，在这个表面下寻找难以理解的问题感觉效率较低。 这次经历让我感觉精神上脱节，就像僵尸一样，特别是当 Conductor 和 Codex 等编码应用程序能够并行运行更多代理时。我觉得我无法像以前那样真正集中注意力并深入了解我正在做的事情。这也让我更难验证生成的结果是否正确。 没有清晰、可解释的痕迹显示用户提示→代理决策→代码→产品行为之间的联系。这并不意味着我想回到过去查看代码行或文件的日子。我实际上觉得用自然语言推理想法更容易、更有效。我想自信地在代码之上航行，而不必牺牲我对系统如何工作的理解。 现有的计划模式感觉协作性不够 我觉得虽然计划模式存在，但正确的规划抽象并不存在。当我轮流使用 Claude Code CLI、Conductor，最后是 Codex 推出时，我发现自己在精心制定和削减计划，却没有一个明确的地方来迭代它们。我会通过使用聊天来完成此操作，然后将计划的各个部分复制到新消息中以对其进行修改（在 Codex 的注释功能之前）。这种剪切和粘贴的工作流程感觉很笨拙，并且很难在跟踪当前计划的同时完成一个想法。 我想给我的计划一个家，将它们扎根于我的整体工作流程中，并将它们从随着对话的进展而消失在回卷中的短暂文本块，变成一个活生生的、会呼吸的、持久的文档。我想把计划模式变成一流的原始指导开发有几个原因： 我需要考虑该怎么做。 我需要确保我的描述足够准确。 我需要了解已经做了什么。 我需要了解何时出现问题以及原因。 筑梦 我思考了我梦想的工作流程，并决定通过将其编码到产品中来将其变为现实。细致入微让您可以启动线程，其中每个线程都是一个聊天对话。您将讨论您想要构建的内容，系统将显示需要您输入的歧义和决策，并且在实施开始之前，您将共同达成一个持久的计划。然后，Nuanced 将实施您的计划，确保生成的代码符合您的要求。我想要一个端到端的管道，从意图开始，一直进行到实施、审查和验证。我更多地将它视为人类思维（或我的多动症思维）的假肢，而不仅仅是另一个编码应用程序，因为它旨在指导尽可能多的内容，并帮助我密切关注正在发生的事情。 为什么我错了 与其说我对现有工具的差距或 SDLC 如何变化的想法不正确，不如说我们的实施没有提供我们期望的解决方案。这是因为： 我将计划与计划混为一谈 模型变得非常好 没有人愿意阅读人工智能生成的文本 我们以一种破坏性的方式将规划与建设分开 计划！=计划 我们了解到的第一件事是我们将计划与计划混为一谈。这些实际上不是同一件事。我的假设是，在实施某件事之前有足够的空间进行彻底的思考是很有价值的。我还认为，随着项目的发展，在大型结构化工件中保留这种思维是很有价值的。但令人惊讶的是，早期用户对该规格兴趣不大。 模型真的很好 随着模型通过上下文和内存更好地理解大型代码库，它们擅长探索存储库并做出合理的假设。明确指示他们得出深思熟虑的结果的需要已经减少了。 我最初并没有认为模型能力与为人类思维设计更好的界面存在竞争，但在很多方面，它确实是竞争。这是因为模型可以可靠地自行做出的每一项决策都减少了需要浮出水面的决策。 人工智能生成的文本读起来很痛苦 该规范包含了更多信息，但没有增加清晰度。这是因为我们的规格很长。它们捕获了重要的决策，并包含许多看似有用的背景信息，但问题是：它们是人工智能生成的。人工智能生成的文本的节奏和过于结构化的性质使其非常难以阅读。我的眼睛一直呆滞。 我们没有通过终止规范来应对这一发现，而是构建了一个规范之旅来解决这个问题。我们认为，Spec Tour 可以引导他们了解重要部分，而不是要求某人理解整个文档。但这只是增加了一层复杂性，屏幕上有更多文本需要注意。如果我们需要生成规范的较短表示形式以使规范可用，那么完整文档首先有什么意义？ 我们分割了一个需要感觉连续的流程 我们的工作流程过于线性和顺序。我们的流程看起来像这样： 聊天 → 通过回答问题消除歧义 → 生成规范 → 审查规范 → 修改规范 → 批准 → 实施 → 审查代码 真正的思考并不是这样发生的，这些部分之间的分离感觉是人为的和被迫的。通常你会理解问题的一部分，尝试一些东西，第一代会教你一些新的东西，这可能会让你改变主意并尝试其他东西。每一步都会暴露一个新问题。规划和建设是相互交织的，并且比规划模式允许的更有机地出现，尤其是我们如何在 Nuanced 中构建它。我们的界面迫使用户过早地“完成思考”，以便他们可以开始构建。一旦开始实施，返回到早期基于聊天的推理感觉就像在工作流程中倒退。瀑布已经没有回头路了。 当您了解 Codex 目前的运作方式时，您会发现计划和执行之间的界限正在消失，因为它们合而为一。早些时候，编码代理受益于人类执行以下操作的工作流程： 计划→批准→执行 那时，走错方向的成本要高得多。但随着代理更好地理解系统，他们也更擅长自主行动和测试自己的工作。他们还擅长在检查结果后修改他们的方法。这将启用不同的循环： 了解→行动→检查→澄清→调整→再次行动 该循环中仍然存在大量计划，但不一定需要以称为“计划”的文档的形式出现。我认为我犯的最大错误是将计划变成了一个工件，而不是设计一个提高人类理解的流程。 计划模式和构建模式是一种奇怪的分离 Nuanced 有计划模式和构建模式，用户可以从其中任何一种模式开始。计划模式总是产生一个规范，而构建模式不会强迫用户接受规范，并且可以用于不证明规范合理的较小任务。但这些模式之间的分离很尴尬，要求用户必须问自己一个任务是否值得计划的元问题，然后记住通过按钮或键盘快捷键激活计划模式（如果需要）。这感觉就像人工智能应该根据它已有的上下文为你做出区分，记住你需要处于哪种模式感觉就像它引入了更多的认知负荷。 这种认识让我感觉自己就像助产士模因，因为聊天界面的简单性（其中计划是根据需要而不是默认完成的）实际上非常好。 我们还没有解决理解问题 思考要构建什么、为什么重要以及评估决策仍然很重要。人们需要对正在发生的事情建立一个连贯的心理模型，但我不认为大量人工智能生成的文本是正确的界面。在聊天中做出决策感觉更直观，但随着系统的变化保持这种理解最新仍然是一个悬而未决的问题。 当代理从五个增加到数百个时，这个问题变得更加困难。跟上并不意味着阅读每一次对话并尝试对每次代码更改进行解释。智能体需要确定人类注意力可以产生最大影响的最少位置，并提供足够的背景信息以使注意力发挥作用。 我们仍然没有解决如何帮助人们保持方向，因为数百个能力越来越强的代理同时改变系统。但我认为更深层次的问题，即人类如何理解系统、浏览复杂的信息层次结构和使用强大的工具，是一个持久的问题。接口随着为其提供支持的技术而不断变化；使复杂性易于理解的需要却没有。 12 个帖子 - 10 位参与者 阅读完整话题

• 情报分类：硬件与数码
• 分类依据：内容涉及硬件、数码产品或通信卡
• 信息来源：服务器 / LINUX DO - 最新话题
• 发布时间：2026/9/28 16:58:53