Plan mode is dead“计划模式”已死

Earlier this year, I believed planning was going to become the most important part of building software with AI.今年早些时候，我曾认为“规划”将成为利用人工智能构建软件过程中最重要的环节。

My belief in this idea was so strong that I built and launched an entire desktop coding app around it. Nuanced was motivated by the observation that AI had radically increased the speed and volume of code generation, but interfaces required to support this new pace of working hadn’t caught up yet.我对这一理念深信不疑，甚至围绕它构建并发布了一款完整的桌面代码编写应用。Nuanced 的开发初衷源于这样一个观察：人工智能虽然极大地提高了代码生成的速度和规模，但支持这种新工作节奏的界面却尚未跟上步伐。

Nuanced’s approach to planning failed, but it also revealed to me how plan modes more broadly aren’t as useful anymore. Historically, plan modes served two purposes: (1) they specified instructions that were sufficiently precise enough for an agent, and (2) they helped humans understand what they were building.Nuanced 在规划方法上的失败，也让我意识到从更广泛的层面来看，“计划模式”已不再那么有用。从历史上看，计划模式有两个作用：(1) 为智能体提供足够精确的指令；(2) 帮助人类理解他们正在构建的内容。

I think #1 is rapidly becoming obsolete as models get better. I think #2 matters more than ever, but plan modes are the wrong abstraction for it, especially as the number of parallel agents we run increases.我认为随着模型能力的提升，第 (1) 点正迅速变得过时。我认为第 (2) 点比以往任何时候都重要，但计划模式并非实现这一目标的正确抽象方式，尤其是在我们运行的并行智能体数量不断增加的情况下。

Why I built Nuanced我为何构建 Nuanced

The product I was motivated to build ultimately answered a question I think is still relevant, and will always be relevant, which is: how do humans maintain a coherent mental model of a software system while machines are changing it faster than humans can inspect the changes?我所构建的产品最终回答了一个我认为至今仍具现实意义，且永远不会过时的问题：当机器改变软件系统的速度快到人类无法一一检查这些变更时，人类该如何维持对该系统的连贯心理模型？

Models could write thousands of lines of code in minutes, meaning you’d inherit a massive maintenance burden before even thinking through what you were building or why. This made it difficult to reason about behavior and debug incorrect assumptions that had prematurely been hardened into code.模型可以在几分钟内编写数千行代码，这意味着在还没来得及思考构建内容或缘由之前，你就已经背负了巨大的维护负担。这使得人们很难对行为进行推理，也很难调试那些过早被固化为代码的错误假设。

While the ease of generating code this way triggered a greater dopamine reward, it obfuscated the uncomfortable work of understanding why building something mattered, whether it mattered at all, and rigorously evaluating product, design, and infrastructure decisions. I would often have a product before consciously making any product decisions. If I under-specified the architecture, the agent would take the liberty of filling those gaps, even if the way it carved abstraction boundaries created problems for me later on. These misunderstandings about intended behavior and design would propagate through several files far beneath the surface of chat, and could be easily missed. Fishing around for problems inscrutable under this surface felt less efficient than having designed something correctly to begin with.虽然这种生成代码的便捷性带来了更强的多巴胺奖励，但它掩盖了理解“为什么要构建某物”、“它是否有意义”以及严谨评估产品、设计和基础设施决策这些令人不适的工作。我经常在还没有做出任何产品决策时，就已经拥有了一个产品。如果我没有对架构进行充分说明，智能体就会自作主张地填补这些空白，即便它所划分的抽象边界在日后给我带来了麻烦。这些关于预期行为和设计的误解会蔓延到聊天界面之下的多个文件中，且极易被忽略。在这些表象之下搜寻难以察觉的问题，远不如从一开始就正确设计来得高效。

There was something about this experience that made me feel mentally disconnected and zombie-like, especially as coding apps like Conductor and Codex enabled the ability to run more agents in parallel. I felt I couldn’t really focus and access the same depth or understanding about what I was working on as I was able to in beforetimes. This also made it more difficult for me to verify whether generated results were correct.这种体验让我感到精神上的脱节，仿佛行尸走肉，尤其是当 Conductor 和 Codex 这类编码应用支持并行运行更多智能体时。我感觉自己无法像过去那样专注于工作，也无法达到同样的深度或理解力。这也让我更难验证生成的代码结果是否正确。

There was no clear, interpretable trace showing the connection between user prompt → agent decision → code → product behavior. This didn’t mean I wanted to return to the olden days of looking at lines of code or at files. I actually felt that reasoning about ideas in natural language was easier and more efficient. I wanted to confidently sail above the code without having to sacrifice my understanding of how the system worked.没有任何清晰、可解读的轨迹能展示“用户提示 → 智能体决策 → 代码 → 产品行为”之间的联系。这并不意味着我想回到过去那种查看代码行或文件的旧时光。实际上，我发现用自然语言推理想法更容易、更高效。我希望能够自信地驾驭代码之上，而不必牺牲对系统运作方式的理解。

Existing plan modes didn’t feel collaborative enough现有的计划模式协作性不足

I felt that while plan modes existed, the right abstraction for planning well didn’t exist. As I rotated through the Claude Code CLI, to Conductor, and finally Codex when it launched, I found myself meticulously shaping and whittling plans without having a clear home to iterate on them. I would do this by using chat and then copying pieces of a plan into new messages to revise them (before Codex’s annotation features). This cut-and-paste workflow felt clunky and made it arduous to work through an idea while keeping track of the current plan.我觉得虽然计划模式确实存在，但实现良好规划的正确抽象方式却缺失了。当我轮流使用 Claude Code CLI、Conductor 以及后来的 Codex 时，我发现自己一直在细致地塑造和打磨计划，却找不到一个清晰的迭代场所。我不得不通过聊天进行操作，然后将计划片段复制到新消息中进行修订（在 Codex 的注释功能出现之前）。这种剪切粘贴的工作流感觉很笨拙，在跟进当前计划的同时推敲想法变得异常艰辛。

I wanted to give my plans a home, ground them in my overall workflow, and take them from being ephemeral blobs of text that disappeared into the backscroll as conversations progressed, into a living, breathing, persistent document. I wanted to turn plan mode into a first-class primitive guiding development for a few reasons:我希望为我的计划找一个归宿，将其植根于我的整体工作流中，让它们不再是随着对话进展而消失在滚动条后的瞬时文本片段，而是成为一份鲜活、持续存在的文档。我希望将计划模式转化为指导开发的一等公民要素，原因有几点：

• I needed to think about what to do.我需要思考要做什么。
• I needed to make sure I described it precisely enough.我需要确保描述足够精确。
• I needed to understand what had been done.我需要了解已经完成了什么。
• I needed to understand when things went wrong and why.我需要了解事情何时出错以及原因。

Building the dream构建梦想

I thought about my dream workflow, and decided to bring it to life by encoding it into a product. Nuanced let you spin up threads, where each thread was a chat conversation. You would talk through what you wanted to build, and the system would surface ambiguities and decisions that required your input, and together you would arrive at a persistent plan before implementation began. Then, Nuanced would implement your plan, making sure that the generated code adhered to your requirements. I wanted an end-to-end pipeline that started with intent, carried through all the way to implementation, review, and verification. I looked at it more as a prosthesis for the human mind (or my ADHD mind) more than simply just another coding app, in that it was designed to instruct as much as it was to help me keep tabs on what was going on.我思考了自己的理想工作流，并决定将其编码进产品中，使其成为现实。Nuanced 允许你创建线程，每个线程都是一场聊天对话。你会讨论想要构建的内容，系统会浮现出歧义和需要你输入的决策，你们共同在实现开始前达成一份持久的计划。随后，Nuanced 会执行你的计划，确保生成的代码符合你的要求。我想要一个从意图开始，贯穿实现、审查和验证的全流程管道。与其说它只是另一个编码应用，我更倾向于将其视为人类思维（或者我这种多动症大脑）的假体，因为它旨在指导我，同时也帮助我随时掌握进展。

Why I was wrong我为何错了

It’s not so much that my ideas regarding gaps in existing tools or how the SDLC was changing were incorrect, but that our implementation didn’t deliver the solution we expected it to. This is because:并不是说我对现有工具缺口或软件开发生命周期（SDLC）变化趋势的看法不正确，而是我们的实现方式没有提供我们预期的解决方案。原因如下：

• I conflated planning with a plan我混淆了“规划”与“计划”
• models got really good模型变得非常强大
• no one wants to read AI-generated text没人想读 AI 生成的文本
• we separated planning from building in a way that was disruptive我们将规划与构建以一种破坏性的方式分开了

Planning != Plan规划 != 计划

The first thing we learned was that we had conflated planning with a plan. Those are actually not the same thing. My assumption was that having the space to think thoroughly about something before it was implemented was valuable. I also thought preserving that thinking in a large structured artifact would be valuable as the project evolved. But early users had surprisingly little appetite for that spec.我们学到的第一件事是，我们混淆了“规划”与“计划”。它们实际上并不是一回事。我的假设是，在实现之前有空间对某事进行深入思考是有价值的。我还认为，随着项目的演进，将这种思考保存在一个大型结构化制品中也很有价值。但早期用户对这种规格说明书的需求出奇地少。

Models got really good模型变得非常强大

As models got better at understanding large codebases through context and memory, they excelled at exploring a repository and making reasonable assumptions. The need to explicitly instruct them to produce a well-thought out result had shrunk.随着模型通过上下文和记忆在理解大型代码库方面变得越来越好，它们在探索存储库并做出合理假设方面表现出色。明确指示它们产生深思熟虑结果的需求已经减少了。

I hadn’t originally thought of model capability as being in competition with designing a better interface for human thinking, but in many ways, it was. This is because each decision the model could reliably make by itself was one fewer decision that needed to be surfaced.我最初并没有认为模型能力会与设计更好的界面以辅助人类思考形成竞争，但在许多方面，确实如此。这是因为模型能够可靠地自行做出的每一个决策，都是需要人工介入的决策的减少。

AI-generated text is painful to readAI 生成的文本读起来很痛苦

The spec contained more information without creating more clarity. This is because our specs were long. They captured important decisions and contained a lot of context that seemed useful but the problem was: they were AI-generated. There’s something about the pacing and overly structured nature of AI-generated text that makes it very difficult to read. My eyes kept glazing over.规格说明书包含了更多信息，却并未带来更多清晰度。这是因为我们的规格说明太长了。它们捕获了重要的决策并包含了许多看似有用的背景信息，但问题在于：它们是 AI 生成的。AI 生成文本的节奏和过于结构化的特性使得阅读变得非常困难。我的眼睛总是看着看着就失焦了。

Instead of reacting to this discovery by killing the spec, we built a Spec Tour to solve this. We thought that rather than asking someone to absorb the whole document, Spec Tour could walk them through the important parts. But that only bolted on an additional layer of complexity, more text on my screen demanding attention. If we needed to generate a shorter representation of the spec to make the spec usable, what was the point of the full document in the first place?为了应对这一发现，我们没有取消规格说明，而是构建了一个“规格导览”来解决这个问题。我们认为，与其要求用户消化整份文档，不如让导览带他们浏览重要部分。但这只是增加了一层额外的复杂性，屏幕上更多的文本要求我投入注意力。如果我们需要生成规格说明的缩减版才能使其可用，那么最初编写完整文档的意义何在？

We split up a process that needed to feel continuous我们拆分了一个本应连续的过程

Our workflow was too linear and sequential. Our process looked something like this:我们的工作流太线性、太顺序化了。我们的流程大致如下：

chat → disambiguate by answering questions → generate spec → review spec → revise spec → approve → implement → review code聊天 → 通过回答问题消除歧义 → 生成规格说明 → 审查规格说明 → 修改规格说明 → 批准 → 实现 → 审查代码

Real thinking doesn’t happen this way, and the separation between these parts felt artificial and forced. Usually you’ll understand a part of the problem, try something, the initial generation teaches you something new, which might make you change your mind about it and try something else. Each step exposes a new question. Planning and building are interleaved and emerge more organically than plan modes allow, especially how we built it in Nuanced. Our interface forced users to prematurely “finish thinking” so that they could start building. Once implementation began, returning to the earlier chat-based reasoning felt like moving backward in the workflow. There was no going back up the waterfall.真正的思考并非如此发生，这些部分之间的分离感既人工又生硬。通常你会理解问题的一部分，尝试一些操作，最初的生成结果会教给你新东西，这可能让你改变想法并尝试其他方案。每一步都会引出新的问题。规划与构建是交织在一起的，比计划模式所允许的更加有机地涌现，特别是在我们 Nuanced 的构建方式中。我们的界面强迫用户过早地“结束思考”以便开始构建。一旦实现开始，回到之前基于聊天的推理过程就感觉是在工作流中倒退。瀑布流没有回头路。

When you look at how Codex currently works, the boundary between planning and execution is disappearing as they collapse into one. Earlier on, coding agents benefited from the workflow where humans would do the following:当你审视 Codex 目前的工作方式时，规划与执行之间的界限正在消失，因为它们正在合二为一。早期，编码智能体受益于人类执行以下操作的工作流：

plan → approve → execute计划 → 批准 → 执行

Back then, the cost of going in the wrong direction was significantly higher. But as agents got better at understanding systems, they also got better at acting autonomously and testing their own work. They’re also good at revising their approach after inspecting the result. This enables a different loop:那时候，方向错误的成本要高得多。但随着智能体在理解系统方面变得更好，它们在自主行动和测试自身工作方面也变得更强。它们也擅长在检查结果后修订方案。这实现了一个不同的循环：

understand → act → inspect → clarify → adjust → act again理解 → 行动 → 检查 → 澄清 → 调整 → 再次行动

There is still an enormous amount of planning happening inside that loop, but it doesn’t necessarily need to appear as a document called “the plan”. I think the biggest mistake I made was turning the plan into an artifact instead of designing a process for improved human understanding.在这个循环中仍然存在大量的规划，但它不一定非要以一份名为“计划”的文档形式出现。我认为我犯的最大错误是将计划变成了一个制品，而不是设计一个旨在提高人类理解力的过程。

Plan mode and build modes were a strange separation计划模式和构建模式是一种奇怪的分离

Nuanced had a plan mode and build mode, and users could start with either. Plan mode always produced a spec, while build mode wouldn’t force users into a spec and could be used for smaller tasks that didn’t justify a spec. But the separation between these modes was awkward and required the user to have to ask themselves the meta-question of whether a task deserved planning, and then remember to activate plan mode through a button or keyboard shortcut if it did. This felt like the kind of distinction AI should make for you based on context it already has, and remembering which mode you needed to be in felt like it introduced more cognitive load.Nuanced 拥有计划模式和构建模式，用户可以从任意一个开始。计划模式总是生成规格说明，而构建模式不会强制用户编写规格说明，可用于不需要规格说明的小型任务。但这些模式之间的分离很尴尬，要求用户必须自问“该任务是否值得规划”这一元问题，如果是，还要记得通过按钮或键盘快捷键激活计划模式。这感觉像是人工智能应该根据已有的上下文为你做出的区分，而记住你需要处于哪种模式似乎增加了认知负荷。

This realization made me feel like the midwit meme, in that the simplicity of a chat interface where planning was done as-needed rather than by default, was actually pretty great.这种领悟让我感觉自己就像那个“中智者”迷因，即那种根据需要而非默认进行规划的聊天界面，其简单性其实非常棒。

We still haven’t solved the understanding problem我们仍然没有解决理解问题

Thinking through what to build, why it matters, and evaluating decisions remains important. People need to build a coherent mental model of what’s going on, but I don’t think a large body of AI-generated text is the right interface for that. Working through decisions in chat feels more intuitive, but keeping that understanding up to date as the system changes is still an open problem.思考要构建什么、为什么重要以及评估决策仍然很重要。人们需要建立一个关于正在发生之事的连贯心理模型，但我不认为大量的 AI 生成文本是实现这一目标的正确界面。在聊天中推敲决策感觉更直观，但随着系统变更而保持这种理解的实时更新，仍然是一个悬而未决的问题。

That problem gets harder as you go from five agents to hundreds. Keeping up can’t mean reading every conversation and trying to prompt an explanation for each code change. Agents need to identify the fewest places where human attention can have the greatest impact and surface enough context to make that attention useful.随着智能体数量从五个增加到数百个，这个问题变得更加困难。跟上进度不能意味着阅读每一场对话并试图为每一处代码变更提示解释。智能体需要识别出人类关注点能产生最大影响的最少地方，并提供足够的上下文来使这种关注变得有用。

We still haven’t solved how to help people stay oriented as hundreds of increasingly capable agents change a system at once. But I think the deeper problem, which is how humans understand systems, navigate complex information hierarchies and use powerful tools, is an enduring one. Interfaces keep changing alongside with the technology that powers them; the need to make complexity comprehensible doesn’t.我们仍然没有解决如何帮助人们在数百个能力日益增强的智能体同时改变系统时保持方向感。但我认为更深层的问题——即人类如何理解系统、导航复杂的信息层级并使用强大的工具——是一个持久的问题。界面会随着驱动它们的技术而不断改变，但使复杂性变得可理解的需求却不会。