plan mode 已死

今年早些时候，我曾一度认为，规划将成为用 AI 构建软件最重要的环节。

我对这个想法深信不疑，甚至围绕它开发并上线了一款桌面编程应用。Nuanced 的出发点是一个观察：AI 让代码生成的速度和数量急剧提升，但支撑这种新工作节奏所需的界面还没跟上。

Nuanced 在规划上的尝试失败了，但也让我看清，更广泛意义上的 plan mode 已经没那么有用了。过去，plan mode 有两个作用：(1) 把指令写得足够精确，让 agent 能照着执行；(2) 帮人理解自己在构建什么。

我认为随着模型变强，第 1 点正在迅速过时。第 2 点则比以往任何时候都重要，但 plan mode 并不是承载它的正确抽象，尤其是在我们并行运行的 agent 数量不断增加的情况下。

我为什么做 Nuanced

我当初想做的产品，最终回答的是一个我认为至今仍然成立、而且会一直成立的问题：当机器改动软件系统的速度超过人类检查改动的速度时，人如何维持对系统连贯的心智模型？

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

这样生成代码固然轻松，多巴胺回报也更大，但它掩盖了那些真正让人不舒服的工作：想清楚为什么值得做某件事、这件事到底值不值得做，以及严格评估产品、设计和基础设施决策。我常常是在没有自觉做出任何产品决策的情况下，就已经有了一个产品。如果我对架构描述得不够具体，agent 就会自作主张填补这些空白，哪怕它划出的抽象边界日后会给我带来麻烦。这些关于预期行为和设计的误解会沿着聊天界面之下、深藏在多个文件中的路径扩散，很容易被忽略。在这种表面之下翻找难以理解的问题，效率还不如一开始就把东西设计对。

这段经历让我有种精神上的抽离感，像行尸走肉，尤其是在 Conductor 和 Codex 这类编码应用能并行跑更多 agent 之后。我发现自己很难真正专注，也无法像从前那样对正在做的东西有同等深度的理解。这也让我更难判断生成的结果是否正确。

用户 prompt → agent 决策 → 代码 → 产品行为，这条链路没有清晰可读的痕迹可循。但这并不意味着我想回到逐行读代码、逐个翻文件的老日子。我反而觉得用自然语言推演想法更轻松、更高效。我想在代码之上自信地航行，同时不必牺牲对系统如何运作的理解。

现有的 plan mode 协作性不够

我觉得 plan mode 虽然存在，但规划所需的那个正确抽象并不存在。从 Claude Code CLI 到 Conductor，再到 Codex 发布后转过去，我一路都在精心打磨、削减计划，却没有一个固定的地方来迭代它们。我的做法是在对话里改，再把计划片段复制到新消息里修订（那还是 Codex 有标注功能之前）。这种剪切粘贴的流程很笨拙，边推进想法边跟踪当前计划，做起来相当费劲。

我想给计划一个归宿，把它扎进我的整体工作流，让它从随对话推进而消失在历史记录里的临时文本块，变成一个活的、持续存在的文档。我想把 plan mode 变成指导开发的一等原语，原因有几个：

• 我得想清楚接下来做什么。
• 我得确保自己把它描述得足够精确。
• 我得弄明白已经做了什么。
• 我得弄明白哪里出了问题，以及为什么。

构建理想中的产品

我设想了自己理想的工作流，决定把它固化成一个产品。Nuanced 让你创建 thread，每个 thread 就是一段对话。你讲清楚自己想构建什么，系统会把其中的歧义和需要你拍板的决策摆出来，你们一起在动手实现之前敲定一份可持续演进的计划。然后 Nuanced 按计划实现，确保生成的代码符合你的要求。我想要一条端到端的流水线，从意图出发，一路走到实现、评审和验证。与其说它是又一个编程应用，不如说它是人脑（或者说我这个 ADHD 大脑）的义肢——它的设计目标既是指导我，也是帮我盯住事情的进展。

我错在哪里

倒不是说我对现有工具的缺口、对 SDLC 正在如何变化的判断有错，而是我们的实现没能交付预期的方案。原因如下：

• 我把 planning 和 plan 混为一谈
• 模型变得非常强
• 没人愿意读 AI 生成的文字
• 我们把 planning 和 building 分开的方式造成了干扰

Planning != Plan

我们学到的第一件事，就是自己把 planning 和 plan 混为一谈了。这两者其实不是一回事。我当时的假设是：在动手实现之前，有空间把事情彻底想清楚是有价值的；把这份思考保留成一份结构化的庞大文档，随着项目演进也会有价值。但早期用户对这份 spec 的兴趣低得出乎意料。

模型变得非常强

随着模型通过上下文和记忆理解大型代码库的能力越来越强，它们很擅长探索仓库并做出合理的假设。再要求它们明确地按指令产出深思熟虑的结果，这种需求已经萎缩了。

我原本没想过模型能力和「设计更好的界面来辅助人思考」这两件事会互相竞争，但很多时候它们确实在竞争。原因在于，模型自己能可靠做出的每一个决定，都是少了一个需要摆到用户面前的决策。

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

这份 spec 信息更多，清晰度却没有提高。因为我们的 spec 太长了。它们记录了重要的决策，也包含了很多看起来有用的上下文，但问题在于：它们是 AI 生成的。AI 生成的文本在节奏和过度结构化的方式上有某种东西，让人非常难读下去。我的眼睛一直发直。

发现这一点之后，我们没有直接砍掉 spec，而是做了个 Spec Tour 来解决。我们想，与其让人吸收整份文档，不如让 Spec Tour 带他们过一遍重要的部分。但这只是在上面又加了一层复杂度，屏幕上更多文字在争夺注意力。如果为了让 spec 可用，我们还得生成一份更短的版本，那这份完整文档一开始存在的意义是什么？

我们把一个本该连续的过程切开了

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

chat → 通过回答问题消歧 → 生成 spec → 审阅 spec → 修改 spec → 批准 → 实现 → 审阅代码

真正的思考不是这样发生的，这些环节之间的分隔显得人为而勉强。通常你会先理解问题的一部分，动手试一下，最初的生成结果让你学到新东西，这可能让你改变想法，再去试别的。每一步都会暴露出新的问题。规划和构建是交织在一起的，比 plan mode 允许的方式更有机地涌现出来，我们在 Nuanced 里的做法尤其如此。我们的界面逼着用户过早地「结束思考」，好让他们开始构建。一旦实现开始，再回到前面那种基于 chat 的推理，感觉就像在工作流里往回走。这座瀑布没有回头路。

看 Codex 现在的工作方式，规划与执行之间的界限正在消失，两者合为一体。早些年，编程 agent 受益于这样一套流程，由人来完成以下步骤：

规划 → 批准 → 执行

那时候，走错方向的代价要高得多。但随着 agent 越来越擅长理解系统，它们也越来越擅长自主行动、检验自己的成果。它们还善于在查看结果之后修正思路。于是有了另一种循环：

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

这个循环里仍然有大量规划在发生，但它不必以一份叫“计划”的文档的形式出现。我犯的最大错误，就是把计划做成了一件交付物，而不是设计一套让人类理解得更透彻的流程。

Plan mode 和 build mode 的划分很奇怪

Nuanced 有 plan mode 和 build mode，用户可以从任意一个开始。plan mode 总会产出一份 spec，而 build mode 不会强迫用户写 spec，可以用来处理那些不值得写 spec 的小任务。但这两个模式的划分很别扭：用户得先问自己一个元问题——这个任务值不值得规划——如果值得，还得记得通过按钮或快捷键启用 plan mode。这种区分本该由 AI 根据它已经掌握的上下文来替你判断，而记住自己该用哪个模式，只会增加认知负担。

想明白这一点后，我觉得自己就像那个 midwit meme：聊天界面里按需规划、而非默认规划，这种简单做法其实相当不错。

理解问题仍未解决

思考要构建什么、为什么重要、如何评估决策，这些依然重要。人需要对自己面对的系统建立连贯的心智模型，但我不认为大段 AI 生成的文本是合适的界面。在聊天里推演决策感觉更直观，但系统一变，如何让这份理解保持最新，仍是个未解的问题。

从五个 agent 扩展到几百个，这个问题只会更难。跟上进度不可能意味着读完每一段对话，再针对每处代码改动去追问解释。Agent 需要找出人类注意力能产生最大影响的那几个位置，并给出足够的上下文，让这份注意力真正有用。

当成百上千个能力越来越强的 agent 同时改动一个系统时，如何让人保持方向感，我们还没有答案。但我认为更深层的问题——人如何理解系统、如何在复杂的信息层级中穿行、如何使用强大的工具——是长期存在的。界面始终随支撑它的技术一起变化；让复杂性变得可理解的需求不会变。