使用 AI 产品时有一个问题很容易被忽略：今天大家都在讨论模型能不能思考得更深、Agent 能不能完成更复杂的任务、语音交互是不是会取代键盘，但模型能力持续提升之后，产品层面的交互结构反而开始显得落后。

今天大多数 AI 产品，本质上仍然遵循一套很简单的结构：输入指令 → 模型理解 → 开始计算 → 输出结果。

如果只是让 ChatGPT 回答一个问题，这套模式没有什么问题。但当 AI 从聊天工具逐渐变成执行工具之后，情况就不同了。尤其是在 Agent、Coding Agent、Deep Research 这类场景里，一条指令背后可能意味着读取大量上下文、搜索资料、分析文件、调用工具、修改代码，甚至真正改变外部世界。AI 一旦开始执行，就不再只是“回答一句话”，而是在启动一个计算开销很大、执行链路也越来越长的任务。

可我们的交互方式，仍然很接近传统聊天机器人：发出一句话，然后等它做完。

我认为这里缺少了一项非常基础的能力：中断。

这里所说的中断，不是现在很多 AI 产品里那个简单的 Stop 按钮。停止生成只能终止当前过程，却没有真正解决一个更常见的问题：如果用户并不想推翻此前所有内容，只是希望在执行途中修改其中一个条件，系统应该怎么办？

Stop 并不等于中断

比如我让 Coding Agent 重构一个组件：

把这个页面的数据获取迁移到 React Query，保持现有 UI 和 API 不变。

AI 已经读取了项目结构，分析了相关组件，找到数据请求的位置，也理解了组件之间的依赖关系。就在它准备修改代码时，我突然意识到：

UserPage 本身不要改，只调整下面的数据层。

对于人与人之间的协作来说，这并不是什么特殊情况。如果我正在和同事讨论一个方案，前面的分析都已经确认，只需要补充一句“UserPage 不要动，其他继续”，对方自然会保留此前已经完成的工作，再根据新的限制调整后续操作。

但今天很多 AI 产品处理这种情况时，仍然更接近另一套逻辑：停止当前任务，接受一条新的输入，再重新理解上下文、重新规划，然后继续执行。

即使模型仍然能够看到此前的聊天记录，这和真正意义上的“从刚才那里接着做”也不是一回事。记得我们刚才说了什么，和保留刚才已经完成的工作状态，是两个不同层次的问题。

AI 需要保存的不应该只有聊天记录

现在我们说一个 AI“有上下文”，通常指的是 conversation context。用户说过什么、模型回答过什么，都可以被带入下一个回合，因此模型不会每次都像第一次见面一样重新开始。

这种上下文解决了记忆问题，却没有完全解决执行过程中的计算复用问题。

假设一个 Agent 为了完成某项任务，已经完成了需求理解、项目扫描、相关文件定位、依赖关系分析和问题原因判断，也形成了初步修改方案。这时用户突然补充一句：

测试暂时不要改。

受到影响的可能只是后续计划中的一部分。前面的项目扫描没有变化，文件关系没有变化，问题原因也没有变化，甚至大部分方案都仍然成立。在这种情况下，更合理的做法应该是保留此前所有仍然有效的结果，只重新处理受到这个新条件影响的部分。

这其实和软件开发里很常见的 incremental computation 很像。一个大型项目修改了一行代码，并不意味着所有东西都必须从头计算；电子表格中的一个单元格发生变化，也不会无条件重新计算所有与它无关的单元格。系统会根据依赖关系判断哪些结果已经失效，再只重新计算受到影响的部分。

AI Agent 也应该具备类似的能力。

如果把一次复杂任务看成一个依赖图，需求理解影响方案，方案影响执行，执行结果又会影响测试，那么用户在中途修改一个条件，本质上就是修改了其中某个节点。系统接下来需要判断的应该是：哪些部分仍然有效，哪些部分已经失效，以及哪些部分需要重新计算，而不是把整个任务再次视为一条新的 Prompt。

这也是我认为 AI 产品需要继续往前走的一步：从 conversation context 进入 execution state。

系统不仅要记住用户说过什么，还要知道任务已经进行到了哪里，哪些信息已经验证，哪些判断已经完成，哪些结果仍然有效，以及后续原本准备怎样执行。

人与人的协作，本来就不是一次性下达完整指令

这个问题放到语音交互里会更加明显。

随着 AI 语音能力不断增强，通过自然语言直接操作电脑已经成为一个很常见的产品想象，但我一直对这种交互方式有所保留。问题并不主要出在语音识别是否足够准确，而在于人在实际工作中，本来就很少一次性形成一条完整、无歧义、可以直接执行到底的指令。

人的思考和协作过程通常是渐进的。

我们可能先说“把这个方案做一下”，看到对方开始操作以后又补充“这部分先不要动”，过一会儿发现另一个问题，再说“前面的思路没问题，但这里换一种实现”。

这种反复修正并不代表表达能力不足，它本来就是工作过程的一部分。新的信息会不断出现，执行结果也会反过来改变人的判断，因此协作本身就需要持续修正。

如果 AI 语音交互仍然建立在“说一句话 → 判断用户说完了 → 开始执行”这样的结构上，那么语音越自然，这种结构上的问题反而越容易暴露。语音是一种连续输入，而 Agent 的执行却仍然被切割成一个个离散任务，两者并不完全匹配。

更合理的方式，是把整个协作过程看成一个持续存在的 task state。用户的每次输入并不一定是在创建新任务，很多时候只是对当前任务状态进行修改。

“这里不要改”“前面的保留”“先做到这里”“这个方案不对，退回刚才那个”“继续”，这些在人与人协作中都非常自然，它们并不是五个互不相关的 command，而是在不断修改同一个任务。

如果 AI 能够按照这种方式理解用户输入，语音才会真正从一种方便的输入手段，变成适合复杂协作的交互方式。

中断不应该只有一个 Stop

沿着这个思路继续往下推，AI Agent 所需要的其实不是一个统一的“停止”，而是几种语义完全不同的操作。

最简单的是 Pause。暂停只意味着当前执行先停下来，已有状态保持不变，用户可能只是想看看做到哪里，确认之后继续。

另一种是 Steer。这种情况下，用户并不否定前面的工作，只是在当前基础上加入新的条件。例如“其他都不变，不要修改 public API”。系统需要做的是判断这个新条件会影响哪些后续步骤，再局部调整执行计划。

再往下是 Rollback。如果用户发现刚才某一步本身就错了，那么应该能够回到此前一个明确的 checkpoint，而不是让 AI 根据记忆“尽量改回去”。

还有一种是 Branch。前面的分析都成立，但用户想比较另外一条路线，例如在相同架构判断基础上分别尝试 React Query 和 Server Component。此时更自然的做法应该是从同一个状态节点产生两个分支，而不是复制聊天记录、重新开始一遍。

仔细看会发现，这些概念本身都不新鲜。版本控制有 branch 和 rollback，数据库有 transaction，IDE 有 undo，编译系统依赖 dependency graph，操作系统会维护 process state。现代软件系统已经花了几十年时间研究复杂状态如何被修改、恢复和继续执行，但到了 AI 产品里，我们反而经常回到最简单的一种模式：给它一句话，然后希望它一路做对。

Transaction Boundary 也应该被显式设计

当然，并不是所有任务都可以无限中断或回滚。

如果 AI 只是在分析文件、生成草稿或者修改本地代码，那么大多数操作都还处在可逆范围内。但如果它已经发送了一封邮件、提交了一笔交易、删除了线上数据，或者向外部系统真正发出了请求，情况就完全不同了。此时用户即使马上说“等一下”，系统也不可能把现实世界已经发生的变化当作不存在。

所以 Agent 产品还需要一个同样重要的概念：明确的 transaction boundary。

成熟的 Agent 应该能够清楚区分思考、规划、可逆执行和不可逆执行，并在进入不可逆操作之前提供一个明确的 commit point。比如邮件草稿已经准备好，但还没有发送；代码修改已经完成，但还没有部署；付款信息已经填写，但交易还没有提交。

这种边界并不是为了给每一步都增加确认弹窗，而是让用户能够明确知道系统当前处于什么状态：哪些内容还可以继续修改，哪些变化只需要局部重新计算，哪些操作一旦继续就会真正产生外部副作用。

Agent 的执行能力越强，这种状态确定性就越重要。否则用户面对的将是一个可以做越来越多事情、但越来越难判断“事情究竟进行到了哪一步”的系统。

Prompt 不应该继续充当任务边界

今天我们已经习惯把 Prompt 看成 AI 产品最基本的交互单位，一条 Prompt 对应一次 Response。这对于聊天机器人很合理，但当 AI 开始承担更复杂、更长时间的工作之后，这种结构就显得越来越勉强。

更适合承担核心单位的应该是 Task。

一个 Task 可以持续几分钟、几个小时，甚至跨越多次交互，而 Prompt 只是用户对这个 Task 的一次输入。它可能是在创建任务，也可能是在补充信息、修改约束、询问状态或者调整执行方向。

这样一来，AI 产品的基本结构也会随之改变。今天更像是：

Prompt → Response

而未来更合理的结构应该是：

Task State + User Delta → State Update → Incremental Execution

模型面对的不再是一次次相互独立的新请求，而是在同一个持续存在的工作状态上不断推进。用户也不需要因为修改了一点想法，就反复重新描述那些没有变化的背景和约束。

AI 还要理解「什么没有改变」

这里还有一个经常被忽略的问题。

当前 AI 产品已经很擅长理解用户新增加了什么信息，却不总是擅长稳定地继承那些没有被修改的部分。

比如我说：

发布日期从周四改成周五。

正常的人类理解是，只有发布日期发生了变化，项目内容、负责人、预算以及其他时间节点都保持原样。可是在以 Prompt 为中心的交互结构中，每次新输入都可能触发模型重新解释整个任务，于是用户为了防止系统跑偏，会频繁补充“其他都不要动”“保留之前的格式”“还是按照刚才的结构”“只修改这一段”。

这些表达之所以在 AI 使用中如此常见，本身就说明系统还缺少一种非常基础的能力：对 unchanged state 的稳定继承。

好的协作系统不应该要求用户不断重新维护上下文。更自然的规则应该是，已有状态默认继续成立，除非用户明确修改了其中某一部分。只有这样，“改变一点”才真正只是改变一点，而不是每次都重新打开整个任务。

比更自然的语音更重要的，是可修正性

现在 AI 产品很重视“像人”的部分：声音更自然、延迟更低、语气更像真人、情绪表达更丰富。这些当然都有价值，但如果把 AI 放到真实协作场景里，更基础的一项能力其实是允许用户随时打断，并且正确理解这次打断到底改变了什么。

人与人协作之所以自然，并不是因为我们总能一次把所有事情说清楚，而是因为沟通允许不断修正。我可以说到一半改口，对方做到一半时我可以提醒，已经达成共识的内容不用重新解释，新的信息出现后只调整受到影响的部分，方案走错了可以退回，需要比较时可以从同一个位置分出另一条路线。

这些能力共同构成的是一种可修正性。

而目前很多 AI 产品恰恰在这一点上仍然非常原始。模型已经能够处理越来越复杂的问题，但产品仍然隐含地要求用户在任务开始之前尽量把所有条件想清楚，并通过一条足够准确的 Prompt 把它完整描述出来。

这本身就和 Agent 的价值有些冲突。

如果一个复杂问题的所有步骤、边界和异常情况在执行前就已经能够被完整定义，那么很多时候我们需要的只是自动化脚本，而不是 Agent。AI 的优势本来就在于能够处理模糊、不完整和不断变化的问题，并在执行过程中逐渐形成更明确的方案。

因此，一个成熟的 AI 产品不应该依赖越来越完美的 Prompt，而应该允许用户从一个并不完整的想法开始，在执行过程中持续补充、修正和改变方向。

从一次性执行走向持续协作

AI 产品下一阶段值得关注的交互升级，未必是再增加一种输入方式，也未必是让语音变得更像真人。相比这些表层变化，AI 更需要从 request-response 工具进一步变成一个 persistent、incremental、interruptible 的工作环境。

这个环境需要维护任务状态，保存 checkpoint，理解不同步骤之间的依赖关系，知道哪些结果可以继续复用，哪些结果已经因为新的输入而失效；它还应该允许用户暂停、继续、回滚和分支，并在真正产生外部副作用之前建立清晰的 commit boundary。

只有这样，当我对一个正在工作的 AI 说：

等一下，前面的都不变，只改这一点。

它需要理解的才不只是这句话本身。

它还应该知道“前面的”具体指哪些状态，“都不变”意味着哪些结果可以继续复用，这个新的条件会影响哪些后续步骤，以及接下来应该从哪里继续执行。

当 AI 能够处理这种连续、可修改、可恢复的协作关系时，它才算真正摆脱“一条 Prompt 对应一次执行”的聊天机器人逻辑，开始成为一种可以长期参与工作过程的计算工具。

我认为，这才是今天 AI 产品在交互层面最值得补上的能力。

分享