AI 写代码越来越快，我们还知道自己在做什么吗？

我对此深信不疑，甚至围绕这个想法做了一款桌面端编程应用，并把它发布了出来。这款应用叫 Nuanced^[1]。它的出发点是：AI 生成代码的速度和数量已经大幅提升，但支持这种工作节奏的界面还没有跟上。

Nuanced 在规划上的尝试失败了。但这次经历也让我意识到：更普遍地说，计划模式（Plan mode）已经没有过去那么有用了。

过去，计划模式主要解决两个问题：

1. 把指令写得足够精确，让智能体照着执行。

2. 帮助人理解自己正在构建什么。

随着模型能力提高，第一个作用正在迅速减弱。第二个作用却比以往更加重要。只是我现在认为，计划模式并不是解决它的合适方式，尤其是在我们同时运行越来越多智能体的时候。

我为什么做 Nuanced？

当时真正推动我做这款产品的，是一个至今仍然重要的问题：

当机器修改软件系统的速度，已经快到人来不及检查时，人怎样才能持续、清楚地理解这个系统？

模型几分钟就能写出几千行代码。可你甚至还没想清楚要做什么、为什么要做，就已经背上了一大笔维护成本。这让我们很难推敲系统会如何运作，也很难发现那些过早被写进代码的错误假设。

生成代码太容易了，确实会让人感到兴奋。但这种快感也会掩盖一些不那么轻松、却更重要的工作：弄清楚一件东西为什么值得做、是否值得做，以及认真评估产品、设计和基础设施方面的选择。

我常常发现，自己还没真正做出产品决策，产品就已经有了。如果我没有把架构说清楚，智能体就会自行补上空白。它划分抽象边界的方式，可能要到后来才给我制造麻烦。

对预期行为和设计的误解，会沿着多个文件一路扩散，藏在聊天记录看不到的深处，很容易被忽略。事后再到这些地方寻找问题，感觉还不如一开始就把设计想清楚来得高效。

这种工作方式让我觉得自己与正在做的东西脱了节，像在机械地往前走。尤其是 Conductor、Codex 这样的编程应用让我们可以同时运行更多智能体之后，我更难像以前那样专注，也更难深入理解手头的工作。验证生成结果是否正确，也随之变得更困难。

当时缺少一条清晰、易于理解的线索，把用户提示词 → 智能体决策 → 代码 → 产品行为连接起来。

这并不意味着我想回到过去，逐行看代码、逐个翻文件。实际上，我觉得用自然语言讨论想法更容易，也更高效。我想把视角放在代码之上，同时仍然清楚地知道系统是怎样运作的。

现有的计划模式，不够像协作

计划模式已经存在，但我觉得，我们还没有找到一种真正适合规划的交互方式。

我先后使用过 Claude Code 命令行、Conductor，以及推出后的 Codex。我会非常仔细地打磨计划，却始终没有一个方便反复修改计划的地方。通常，我只能在聊天中讨论，再把计划的某些部分复制到新消息里继续修改——那时 Codex 还没有批注功能。

这样不断复制、粘贴很笨重。讨论一个想法的同时，还要弄清楚哪一版才是当前计划，也很费劲。

我希望计划在整个工作流程中有一个固定的位置。它不该只是聊天记录里转瞬即逝的一大段文字，而应该成为一份可以持续更新的文档。我想让计划模式成为指导开发的基础功能，因为我需要：

• 想清楚接下来做什么。

• 确保自己的描述足够准确。

• 理解已经完成了什么。

• 出问题时，知道问题发生在何处、为什么发生。

把理想流程做成产品

我设想了一套理想的工作流程，并把它做进了 Nuanced。

在 Nuanced 中，你可以开启一个个对话线程，讨论自己想构建什么。系统会指出含糊之处，以及需要你做决定的问题。你们一起在动手实现前形成一份持续保存的计划。随后，Nuanced 根据这份计划实现功能，并确保生成的代码符合你的要求。

我想要的是一条完整的流程：从意图出发，一直延伸到实现、审查和验证。

对我来说，它更像是人类思维的一种辅助装置——或者说，辅助我这个 ADHD 患者思考的装置——而不只是另一款编程应用。它既要帮助我给出指令，也要帮助我随时弄清楚正在发生什么。

我错在哪里？

我并不认为自己对现有工具缺口和软件开发流程变化的判断全错了。问题在于，我们的实现没有带来预想中的解决方案。

原因主要有四个：

• 我把“规划过程”和“一份计划”混为一谈。

• 模型变得很强了。

• 没有人愿意读大段 AI 生成的文字。

• 我们把规划（planning）和构建（building）拆开，打断了原本应该连贯的过程。

规划过程，不等于一份计划

这是我学到的第一件事。

我原本认为，在实现之前留出空间，把一件事想透，是有价值的。我也认为，随着项目推进，把这些思考保存在一份结构化的大文档里同样有价值。

但早期用户对这份规格文档的兴趣，出乎意料地小。

模型变得很强了

模型越来越善于借助上下文和记忆理解大型代码库，也越来越能自己探索代码仓库、做出合理假设。

因此，人们需要明确告诉它“怎样才能做出经过充分考虑的结果”的情况变少了。

一开始，我没想过模型能力的提升，会和“为人类思考设计更好的界面”形成某种竞争。但在很多时候，确实如此：模型每能可靠地独立做出一个决定，就少了一个必须摆到人面前的决定。

AI 生成的长文很难读

我们的规格文档包含了更多信息，却没有让事情更清楚。

文档很长，记录了重要决策，也保留了许多看似有用的背景。但问题是，它由 AI 生成。AI 文字的节奏和过度结构化的表达，总让人很难读下去。我读着读着，注意力就涣散了。

发现这个问题后，我们没有取消规格文档，而是做了一个 Spec Tour，想带着用户浏览其中的重要部分，省去通读全文的负担。

结果，屏幕上又多了一层复杂性，又多了一些需要我注意的文字。如果一份规格文档必须先被压缩成更短的版本，才能派上用场，那保留完整文档的意义究竟是什么？

我们拆开了本应连贯的过程

我们的流程太线性，也太讲究先后顺序了。它大致是这样：

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

但真实的思考不是这样发生的。把这些环节硬拆开，会显得很不自然。

通常，你会先理解问题的一部分，动手试一试；初步生成的结果又让你看到新情况，于是你改变主意，尝试另一种做法。每走一步，都可能出现新的问题。规划与构建会相互穿插，自然地往前推进。至少，Nuanced 所采用的计划模式容纳不了这种过程。

我们的界面迫使用户过早地“想完”，才能开始做。一旦进入实现阶段，再回到之前的聊天中推敲，就像在流程中倒退。你没法顺着这道“瀑布”往回走。

看看今天的 Codex 就会发现，规划与执行之间的边界正在消失，两者逐渐融为一体。

早期，编程智能体更适合这样的工作方式：

规划 → 批准 → 执行

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

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

这个循环里仍然有大量规划。只是这些规划，不一定非要变成一份名叫“计划”的文档。

我犯的最大错误，可能就是把计划做成了一份产物，却没有设计一个能帮助人更好地理解系统的过程。

为什么要区分“计划模式”和“构建模式”？

Nuanced 有计划模式（plan mode）和构建模式（build mode），用户可以从任意一种模式开始。

计划模式总会生成规格文档。构建模式则不会强制生成文档，适合那些不值得专门写规格的小任务。

可两种模式之间的区分很别扭。用户得先问自己：“这件事值不值得规划？”如果值得，还得记得点击按钮或使用快捷键，切到计划模式。

这本该是 AI 根据已有上下文帮你判断的事。还要记住自己当前该处在哪种模式，只会增加思考负担。

想到这里，我感觉自己就像那张“中间人想得太复杂”的梗图里的人：原来，在普通聊天界面里按需规划，而不是默认启动一套规划流程，已经相当好用了。

“理解系统”这个问题，仍然没有解决

想清楚要构建什么、为什么值得做，并认真评估每个决定，依然重要。

人需要对系统形成一套连贯的认识。但我不认为，一大篇 AI 生成的文字是合适的界面。在聊天中逐步讨论决策更自然；可当系统持续变化时，怎样让人的理解也及时跟上，仍是一个没有解决的问题。

当同时运行的智能体从 5 个增加到几百个，问题会更加棘手。人不可能读完每一段对话，再逐项追问每次代码修改的缘由。

智能体需要找出最值得人投入注意力的少数地方，并提供足够的背景，让人的介入真正有用。

我们仍然不知道，当数百个能力越来越强的智能体同时修改一个系统时，该怎样帮助人始终弄清楚自己身在何处。

但我认为，更深一层的问题始终存在：人怎样理解系统、在复杂的信息层级中找到方向，并使用强大的工具？支撑界面的技术在变，界面也会跟着变；让复杂事物变得可理解的需求，不会消失。

本文基于博客 Plan mode is dead^[2] 整理而成，配图来自原文。