过去规划模式承担两大作用：给智能体提供精准指令，帮人类搭建系统心智模型。随着大模型能力跃升，前者价值快速衰减；但人类理解系统的需求从未减弱，只是静态规划文档并非正确载体。

作者在实践中发现，强行拆分「规划模式 / 构建模式」，采用 “先写完整规范文档，再编码” 的瀑布式流程，割裂了开发思考的连续性。规划与编码本是交织迭代的循环；AI 生成的长篇 spec 可读性差，还会增加认知负担。

新范式不再产出独立规划文档，而是转为「理解→行动→检视→澄清→调整→再行动」闭环。文章最后点出核心难题：大规模并行智能体同时修改系统时，如何筛选关键信息，只把最高价值内容交付给人，帮助开发者持续维护对软件的心智模型，仍是 AI 智能体产品待解决的长期命题。

AI 智能体产品设计 10 条推论

1. 区分「规划思考过程」和「规划文档产物」，不要把思考固化成一份静态文档作为强制前置产出。
2. 模型能力越强，对人工显式 spec 的依赖越低，产品设计不能假设用户愿意写长篇前置方案。
3. AI 生成的大段结构化文本可读性差，不要把长文档当作人机协作的主要交互载体。
4. 开发是交织迭代过程，避免强线性、瀑布式工作流，不要强制用户提前完成全部思考再动手。
5. 不要设计需要用户手动切换的独立模式（规划 / 构建），模式判定应由 AI 基于上下文自动完成，减少认知负荷。
6. 智能体产品核心价值不再只是生成结果，而是维持人类对复杂系统的心智模型。
7. 人机协作闭环优先采用：理解→行动→检视→澄清→调整循环，规划内化在循环内部，不必单独外化。
8. 大规模并行智能体场景，核心不是把全部信息丢给人，而是筛选人类干预收益最高的最小信息集。
9. 产品需要可追溯链路：提示词→智能体决策→产出→系统行为，方便人定位错误假设。
10. 界面设计目标：让人可以俯瞰系统逻辑，而不是强制阅读全部代码或长篇文档。

10 个关键问题 Q&A

Q1：标题 “Plan mode is dead” 是什么意思？ A1：指强制生成静态规划文档的模式失效，不是规划思考本身死掉；规划仍重要，只是不该以独立前置文档形式存在。

Q2：作者当初为什么开发 Nuanced？ A2：AI 写代码速度极快，但人跟不上系统变更，希望通过持久化规划文档，帮助开发者维持软件系统的心智模型。

Q3：传统规划模式有哪两个核心作用？ A3：①为智能体提供精确指令；②帮助人类理解待构建系统。前者随模型变强快速失效，后者依然关键。

Q4：Nuanced 最核心的设计误区是什么？ A4：混淆了「规划这个思考行为」和「规划文档这个产物」，强制用户先生成完整 spec 再编码。

Q5：为什么 AI 生成的规范文档不好用？ A5：篇幅冗长、行文是 AI 风格，信息多但清晰度不提升；即便做摘要工具，只会叠加更多文本与复杂度。

Q6：旧的 Agent 工作流和新循环有什么差别？ A6：旧：规划→审批→执行，线性瀑布；新：理解→行动→检视→澄清→调整→再行动，思考与执行交织。

Q7：为什么独立的规划 / 构建双模式设计体验差？ A7：增加用户元决策负担，用户需要自己判断任务是否需要规划并手动切换模式，提升认知负荷。

Q8：模型变强对 AI 编码产品带来什么冲击？ A8：模型可自主理解代码库、补全假设，不再需要人类预先写详尽指令，降低前置 spec 价值。

Q9：大规模多智能体场景，最大未解决难题是什么？ A9：上百个智能体并行修改系统时，如何筛选关键变更，只推送高价值信息，帮助人维持系统心智模型。

Q10：AI 代码智能体产品未来的核心设计目标是什么？ A10：构建人机协作循环，保留规划思考；不需要静态规划文档，但要保证人类始终能看懂系统逻辑，掌握全局。

附录 静态规划模式已死

原文作者：Ayman Nadeem｜发布时间：2026-09-24

今年早些时候，我曾坚信：规划将会成为借助 AI 开发软件最重要的一环。 这个想法在我脑海里根深蒂固，为此我甚至开发并上线了一整套桌面代码编辑器应用。推出 https://www.nuanced.dev/ 的初衷源于这样一个观察：AI 已经极大提升了代码生成的速度与产出量，但适配这种全新工作节奏的交互界面，却迟迟没有跟上。

Nuanced 这套规划方案最终失败了。而这次失败也让我意识到：广义上的规划模式，价值已经大不如前。过去，规划模式承担两大作用：

1. 为智能体提供足够精确的指令；
2. 帮助开发者理解自己正在构建的系统。

我认为，随着模型能力持续变强，第 1 点正在快速失效。第 2 点的重要性却比以往任何时候都更高，但规划模式并不是实现这个目标的正确抽象方式，尤其是当我们并行运行大量智能体的时候。

我为什么开发 Nuanced

当初驱动我做这款产品的核心问题，至今依然成立，并且会一直重要：

在机器修改代码的速度远超人类审阅速度时，人类该如何维持对软件系统连贯的心智模型？

模型可以在几分钟内写出上千行代码。这意味着，你还没想清楚要构建什么、为什么要构建，就已经背上了沉重的维护包袱。这会让你很难理清程序行为，也难以排查那些过早固化到代码里的错误假设。

这种一键生成代码的体验，确实能带来更强的即时满足感，却掩盖了那些更艰难的思考工作：想清楚做这件事的意义、判断这件事到底值不值得做，严谨评估产品、设计与基础设施层面的各项决策。很多时候，产品都已经成型了，我却还没有主动做出任何产品层面的决策。 如果架构定义不够明确，智能体会自行填补这些空白；而它划分抽象边界的方式，很可能在后续埋下隐患。这些关于预期行为、设计思路的理解偏差，会扩散到聊天界面之下的多个代码文件里，极易被忽略。等到后期到处排查隐藏问题，反而不如一开始就把系统设计到位。

这种开发体验，让我感觉思维脱节，如同行尸走肉。当 Conductor、Codex 这类代码工具支持并行运行更多智能体之后，这种感受愈发明显。我很难像过去一样深度专注、吃透项目全貌，也难以校验生成结果是否正确。

没有清晰可读的追踪链路，展示「用户提示词 → 智能体决策 → 代码 → 产品行为」之间的关联。但这不代表我想回到逐行阅读代码、翻看文件的旧时代。实际上，用自然语言梳理思路反而更简单高效。我希望站在更高维度审视系统，不用深陷代码细节，同时又不会丢失对系统运行原理的理解。

现有的规划模式，协作性严重不足

虽然已经存在各类规划模式，但真正适合做规划的抽象范式还没有出现。我先后试用过 Claude Code CLI、Conductor，直到 Codex 发布。那段时间，我需要反复打磨、删减规划文档，却找不到一个专门的地方迭代它。在 Codex 的注释功能上线前，我只能在对话里写方案，再复制片段到新消息中修改。这种复制粘贴的工作流十分笨重，很难一边推进想法，一边持续追踪当前规划。

我希望给规划一个专属载体，把它嵌入完整工作流。让规划不再是转瞬即逝、淹没在历史对话里的文本片段，而是一份持续更新、可留存的文档。我想把规划模式升级成开发流程里的一等原语，理由有四点：

1. 我需要思考下一步该做什么；
2. 我需要确保描述足够精准；
3. 我需要看懂已经完成的工作；
4. 我需要定位问题、理解出错的根源。

打造理想工作流

我设想了一套理想开发流程，并把它落地成产品。Nuanced 支持创建多条会话线程，每条线程对应一段对话。你可以描述想要构建的系统，系统会主动抛出存在歧义、需要你来决策的问题；人机共同完成一份持久化规划文档之后，才正式进入开发实现阶段。随后 Nuanced 会按照这份规划编码，保证生成代码符合你的需求。 我想要一条端到端链路：从最初的想法，一路贯穿实现、评审与验证。与其说它只是另一款代码工具，我更愿意把它看作人脑的辅助工具（尤其适配我本身注意力缺陷的思维特点）—— 它既负责下达指令，也帮我持续掌握项目全局。

我错在哪里

并不是我对现有工具短板、软件开发生命周期（SDLC）变化的判断有误，而是这套产品实现方案，没能交付预期的价值。原因有四点：

1. 混淆了「规划动作（planning）」和「规划文档（a plan）」
2. 大模型能力突飞猛进
3. 没人愿意阅读 AI 生成的长篇文本
4. 强行拆分规划与构建，打断了开发的连续性

规划 ≠ 规划文档

我们最先得到的教训：规划这个思考过程，和一份规划文档，根本不是一回事。我原本认为，在编码前充分思考，并把思考过程保存为一份结构化文档，随着项目迭代会非常有价值。但早期用户对这类规范文档的接受度极低。

模型能力变得极强

随着模型依托上下文与内存，越来越擅长读懂大型代码库，它们已经可以自主探索仓库、做出合理推断。需要人工显式写详细指令，才能拿到靠谱结果的场景越来越少。

我原本没有意识到，模型能力的提升，会和「面向人类思考优化交互界面」这件事形成竞争关系。模型能稳定自主做出的决策越多，需要抛给人类确认的决策就越少。

AI 生成文本读起来很折磨人

这份规范文档信息量大，但清晰度并没有同步提升。文档很长，记录了重要决策、大量看似有用的上下文，可问题在于：它是 AI 写出来的。AI 文本的行文节奏、过度结构化的风格，让人很难读下去，看着看着就走神。

我们没有直接砍掉文档，而是开发了「规范导览（Spec Tour）」功能来补救。我们想，不必让用户通读全文，由导览功能带用户浏览核心内容。但这只是额外增加了一层复杂度，屏幕上又多一堆文本需要阅读。 如果为了让文档可用，还得再生成精简摘要，那这份完整文档本身意义何在？

割裂了本应连续的过程

我们的工作流线性、顺序化过重： 对话 → 回答问题消除歧义 → 生成规范文档 → 评审文档 → 修改文档 → 审批通过 → 编码实现 → 代码评审

真实的思考并不是这样。很多时候，你只理解一部分问题，动手尝试；初次生成的结果会带给你新认知，进而推翻原有想法、重新尝试。每一步都会引出新问题。 规划与构建是交织在一起、有机推进的，而 Nuanced 的实现方式被规划模式束缚住了。界面强迫用户提前完成全部思考，才能开始编码。一旦进入实现阶段，想要回到前面对话里的推理过程，就像在工作流里强行回退，无法逆向回到上游环节，典型的瀑布流缺陷。

看看现在 Codex 的工作方式：规划和执行的边界正在消失，二者融合在一起。 早期代码智能体的工作模式是：规划 → 审批 → 执行。 那时候一旦方向出错，代价很高。但随着智能体更懂系统，它们自主执行、自测、基于结果调整方案的能力持续变强，于是诞生了新循环：

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

这个循环内部依然存在大量规划思考，但它不必固化成一份叫「规划文档」的文件。

我最大的失误，就是把规划变成一份静态产物，而不是设计一套帮助人类理解系统的思考流程。

规划模式与构建模式的生硬分割

Nuanced 区分了规划模式和构建模式，用户可以任选其一启动。规划模式一定会产出规范文档；构建模式不会强制生成文档，适合小任务。 但两种模式的划分非常别扭。用户需要额外思考一个元问题：这个任务是否值得走完整规划？如果需要，还要点击按钮或者快捷键切换模式。 这种区分本该由 AI 基于上下文自动判断，而不是交给用户记忆当前处于哪种模式，反而增加认知负担。

意识到这点后，我想起那个流行的「平庸之思」梗图：按需规划、默认直接对话的简单聊天界面，其实才是更优解。

理解系统这个难题，我们仍未解决

梳理构建目标、思考价值、评估决策依然至关重要。人类需要建立连贯的系统心智模型。但长篇 AI 文本，并不是承载这份理解的正确交互载体。 在对话中推演决策会更直观。但当系统持续迭代，如何保持这份理解实时更新，仍是一个悬而未决的问题。

当智能体数量从 5 个增长到上百个，这个难题会进一步放大。我们不可能阅读每一条对话，为每一处代码变更单独追问解释。智能体需要识别出人类干预收益最高的最小范围，并提供足够上下文，让人类的注意力发挥价值。

如何让人类在上百个高性能智能体同时修改系统时，还能把握系统全貌，这个问题我们还没有答案。但更深层的命题 —— 人类如何理解复杂系统、遍历庞大信息层级、驾驭强大工具 —— 是永恒的课题。交互界面会随底层技术不断迭代，但让复杂系统变得可理解，这个需求永远不会消失。

要点提炼

1. 作者 Ayman Nadeem 自研 Nuanced，初衷是解决 AI 快速写代码时，人类丢失系统心智模型的痛点；
2. 他曾经相信：显式规划文档（plan）是 AI 编码智能体的核心；最终结论：规划是思考过程，不是一份静态文档；
3. 两大旧目标的变迁：给 Agent 写精细指令（价值衰减，模型变强）；维持人类对系统的理解（依然最重要，但文档式规划不是好方案）；
4. 瀑布式「先写完整 spec，再编码」的流程违背真实开发，思考和编码是交织迭代；
5. AI 生成长文档可读性极差；模式切换还增加额外认知负荷；
6. 新范式：理解→行动→检视→澄清→调整循环，规划内化在循环里，不必外化成为独立文档；
7. 遗留核心挑战：大规模并行智能体场景下，如何把关键信息筛选出来，维持人类对系统的理解。

关键术语中英对照

关键词

核心概念

Plan mode （静态）规划模式

 planning 规划（思考过程）

 plan 规划文档（静态产物） 

Agent /coding agent 代码智能体 

Mental model 心智模型

 Spec /specification 规范文档

 Artifact 制品 

Interleaved thinking 交织式思考

产品 & 工作流关键词

Nuanced SDLC 软件开发生命周期 Waterfall 瀑布流 Human-AI collaboration 人机协作 Cognitive load 认知负荷 Persistent document 持久化文档 Trace 追踪链路 Context /memory 上下文与记忆

论点关键词

Plan mode is dead 规划模式已死 

Model capability 模型能力 

AI-generated text AI 生成文本 Parallel agents 并行智能体 Information filtering 信息筛选 

Understand → Act → Inspect → Clarify → Adjust 理解→行动→检视→澄清→调整循环