freeroad · AI 解读站

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

我对这个想法的信念如此之强，以至于我围绕它构建并发布了一整个桌面编码应用。Nuanced 的动机源于一个观察：AI 已经极大地提升了代码生成的速度和数量，但支持这种新工作节奏所需的界面还没有跟上。

Nuanced 的规划方案失败了，但这也让我意识到，更广泛地说，规划模式已经不如过去那么有用了。以往，规划模式主要承担两个作用：（1）为智能体提供足够精确的指令；（2）帮助人理解自己正在构建什么。

我认为，随着模型能力增强，第（1）个作用正迅速失去必要性。第（2）个作用比以往任何时候都重要，但用“规划模式”来承载它并不合适，尤其是在我们同时运行的智能体越来越多的情况下。

我为什么构建 Nuanced

我想做的这个产品，归根结底是为了回答一个问题。我认为这个问题现在仍然重要，而且会一直重要：当机器修改软件系统的速度快到人来不及逐一检查时，人要如何在头脑中维持对整个系统连贯、完整的理解？

模型几分钟就能写出几千行代码。这意味着，你甚至还没想清楚自己要做什么、为什么要做，就已经背上了沉重的维护负担。那些尚未经过充分推敲的错误假设，过早地被固化进代码，导致你很难理清系统行为，也很难排查这些假设带来的问题。

如此轻松地生成代码，确实能带来更强的多巴胺奖励，却也掩盖了那些令人不舒服、但必须完成的思考：做这件事为什么重要，它究竟有没有意义，以及如何严谨地评估产品、设计和基础设施方面的决策。我常常还没主动做出任何产品决策，一个产品就已经摆在面前了。如果我没有把架构描述得足够清楚，智能体就会自行填补空白，即便它划分抽象边界的方式会在日后给我带来麻烦。这些对预期行为和设计意图的误解，会在聊天界面看不到的深处，扩散到多个文件中，很容易被忽略。要在表面之下四处打捞这些难以看清的问题，感觉还不如一开始就把设计做对来得高效。

这种体验让我觉得，自己的思维和手头的工作脱了节，整个人像在机械地应付。尤其当 Conductor、Codex 这样的编程应用允许同时运行更多智能体之后，这种感觉更明显了。我很难真正集中注意力，也很难像过去那样，深入理解自己正在做的事情。这也让我更难验证生成的结果到底对不对。

我们缺少一条清晰、易于理解的追溯链路，来呈现“用户提示 → 智能体决策 → 代码 → 产品行为”之间的联系。但这并不意味着，我想回到过去那种逐行看代码、逐个看文件的工作方式。恰恰相反，我觉得用自然语言推敲想法更轻松，也更高效。我希望自己能安心地在代码之上的层面工作，同时仍然清楚系统是如何运转的。

现有的规划模式缺少协作感

我觉得，虽然已有规划模式，却没有一种合适的交互形式，能真正支持人把规划做好。我先后使用 Claude Code CLI、Conductor，最后在 Codex 发布后转向了它。在这个过程中，我总是在精雕细琢、反复打磨计划，却找不到一个明确的地方来持续修改它们。当时，我只能通过聊天完成这些工作，再把计划的部分内容复制到新消息里进行修改——那还是 Codex 推出批注功能之前。这种复制粘贴的工作方式很笨拙，让人很难一边深入推敲想法，一边掌握计划的最新状态。

我想给计划一个固定的归宿，让它融入整个工作流程。它不该是一团转瞬即逝的文字，随着对话推进就消失在历史消息里，而应该是一份可以持续更新、长期保留的活文档。我希望让规划模式成为开发流程中具有核心地位的基础环节，原因有几个：

我需要思考要做什么。
我需要确保我把它描述得足够精确。
我需要理解已经做了什么。
我需要知道什么时候出了问题，以及为什么会出问题。

把理想中的工作方式变成产品

我仔细想了想自己理想中的工作流程，决定把它做成一个产品。在 Nuanced 中，你可以创建多个会话，每个会话都是一段聊天。你先通过讨论梳理自己想做什么，系统会指出含糊之处，以及需要你参与的决策；在开始实现之前，你们会一起形成一份持续保存的计划。接着，Nuanced 会执行这份计划，确保生成的代码符合你的要求。我想要的是一套端到端的流程，从意图出发，一直贯穿实现、审查和验证。与其说我把它看作又一款编程应用，不如说，我把它看作人类大脑——或者说我这个 ADHD 大脑——的辅助装置。它既要帮助传达指令，也要帮助我随时掌握正在发生的事情。

我为什么错了

与其说我对现有工具的不足，或对软件开发生命周期变化的判断有误，不如说，我们做出来的产品没有带来预期中的解决效果。原因在于：

我把规划过程和计划文档混为一谈。
模型变得非常强大。
没人想读 AI 生成的文字。
我们把规划和开发拆开了，打断了原本连贯的工作过程。

规划过程 ≠ 计划文档

我们首先认识到的是，自己把规划过程和计划文档混为一谈了。两者其实不是一回事。我原本认为，在动手实现之前，留出充分思考的空间很有价值。我也认为，随着项目推进，把这些思考保存在一份篇幅较长、结构完整的文档中，同样很有价值。但出乎意料的是，早期用户对这份规格文档几乎没什么兴趣。

模型变得非常强大

随着模型越来越善于借助上下文和记忆理解大型代码库，它们在探索代码仓库、作出合理假设方面也表现得越来越好。为了让它们给出经过充分考虑的结果，我们已经不再需要事事明确交代。

我最初没想过，模型能力的提升，会与“为人类思考设计更好的界面”形成竞争。但在很多方面，事实确实如此。因为模型每多一个能够独立、可靠地作出的决策，就少一个需要摆到人面前的决策。

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

规格文档包含了更多信息，却没有让事情变得更清楚，因为我们的文档实在太长了。它们记录了重要决策，也包含大量看似有用的上下文，但问题是：这些内容都是 AI 生成的。AI 文字的行文节奏，以及过度结构化的表达方式，让人很难读进去。我读着读着，就不自觉地走神了。

发现这个问题后，我们没有取消规格文档，而是做了一个“规格导览”（Spec Tour）功能来解决它。我们想，与其要求用户消化整份文档，不如由导览带着他们看重点。但这只是又叠加了一层复杂性，让屏幕上多出更多争抢注意力的文字。如果我们还得为规格文档生成一个精简版，它才变得可用，那当初保留完整文档的意义又是什么？

我们割裂了本该连贯的过程

我们的工作流程太过线性，太强调按部就班。大致是这样的：

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

真实的思考并不是这样发生的。把这些环节分开，显得生硬而刻意。通常，你会先理解问题的一部分，动手试一试，第一轮生成的结果又会让你发现新的东西，进而改变想法，再试另一种做法。每一步都会带出新的问题。规划和开发本来就是交织进行、自然演进的，而规划模式限制了这一过程，尤其是我们在 Nuanced 中设计的那种模式。我们的界面迫使用户过早地宣布“想完了”，才能开始开发。一旦进入实现阶段，再回到之前的聊天中继续推敲，就像是在工作流程里倒退。这条瀑布没有逆流而上的路。

看看现在 Codex 的工作方式，就会发现，规划与执行之间的边界正在消失，两者逐渐融为一体。早期，编程智能体确实受益于由人来推动的这套流程：

计划 → 批准 → 执行

那时，方向走错的代价要高得多。但随着智能体越来越善于理解系统，它们自主行动和测试自身工作的能力也在提升。它们也能在检查结果之后，及时调整做法。于是，另一种循环成为可能：

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

这个循环里，仍然包含大量的规划活动，但这些活动不一定非要以一份名为“计划”的文档呈现。我想，我犯下的最大错误，是把计划做成了一份必须产出的文档，而没有去设计一个能帮助人更好理解系统的过程。

把规划和开发分成两种模式很别扭

Nuanced 有规划模式和开发模式，用户可以从任意一种开始。规划模式一定会生成规格文档，而开发模式不会强制用户生成文档，适合那些不值得专门写一份规格文档的小任务。但这两种模式的划分很别扭，用户得先判断一个关于工作方式的问题：这项任务是否值得先做规划？如果值得，还得记住用按钮或快捷键开启规划模式。我觉得，AI 已经掌握了相关上下文，这类判断本该由它代劳。还要记住当前该处于哪种模式，只会增加认知负担。

意识到这一点时，我觉得自己就像那张“中等智力者”梗图里的中间人物：原来，简单的聊天界面就已经很好了——需要时再规划，而不是默认凡事都先规划。

我们仍未解决理解的问题

想清楚要做什么、为什么值得做，以及评估各项决策，仍然很重要。人需要在头脑中形成对当前状况连贯、完整的理解，但我不认为，大量 AI 生成的文字是实现这一点的合适界面。在聊天中逐步推敲决策，感觉更直观；但随着系统不断变化，如何让人的理解同步更新，仍然是一个尚未解决的问题。

当智能体从五个增加到几百个时，这个问题会更加棘手。要跟上进展，不可能靠读完每一段对话，再逐一要求智能体解释每一次代码改动。智能体需要找出尽可能少、却最值得人投入注意力的关键点，并提供足够的上下文，让人的关注真正发挥作用。

当数百个能力越来越强的智能体同时修改一个系统时，我们仍然不知道，该如何帮助人始终把握全局。但我认为，更深层的问题——人如何理解系统、如何在复杂的信息层级中找到方向，以及如何使用强大的工具——会长期存在。界面会随着背后的技术不断变化，但让复杂事物变得可以理解的需求，不会改变。

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

作者：Ayman Nadeem