聊天框的幻觉：为什么我们一直在给 AI Agent 做错误的界面？

在目前的开发工具里，不管是 Cursor、Codex 还是 Claude Code，默认界面几乎全是一个窄窄的聊天窗口。我们在终端或编辑器里输入一行字，看着屏幕上的日志开始滚动，然后等待 AI 吐出修改方案，并询问我们是否满意。

这种输入-滚动-提问的对话机制，表面上将门槛降到了最低。但如果从人机协作的效率出发，这种模仿人类聊天软件的交互，正在限制 AI 发挥真正的潜力。

一、 第一性原理：AI 独立干活需要什么？

要理清界面的问题，我们需要先回到人机协同的最理想状态。

假设你手下有一个靠谱的下属。最省心的协作方式是：你交代完任务，他就自己去干活，高质量地解决问题。你不需要站在他背后盯着他打字，也不需要每隔几秒钟就回答他一个零碎的疑问。

要达到这种放手让 AI 自主干活的状态，系统必须满足三个前提：

1. 详尽的任务说明与验收标准：AI 必须知道你要做什么，以及怎么验证结果对错。
2. 辅助资料与非 Prompt 上下文：在复杂的任务里，AI 需要参考大量的背景资料（比如项目代码库、历史偏好、本地文档）。这些资料过于庞大，不可能塞进单行输入框，需要有其他的接入通道（如附件或本地工作区路径）。
3. 异步等待的心理预期：AI 要通读这些上下文，自己去写代码、跑编译、运行测试并反复调试，这需要几分钟甚至几十分钟。你必须允许它慢下来，建立一种发完任务就去干别的的异步预期。

二、 界面对用户预期的无形塑造

我们在调优模型时，总在讨论怎么写 prompt。但很多人忽略了，界面本身也在时刻给人类写 prompt，无形中塑造了我们使用产品的预期。

这里存在一个容易被忽略的逻辑漏洞：AI 本身是一段运行的代码，它根本看不见图形界面，它是如何被一个聊天框影响的？

事实是，界面通过暗示设计工具的程序员与使用工具的用户，从两端合力限制了 AI 的自主干活空间。

• 对用户的无形规训（输入端）：输入框的尺寸、流式输出的闪烁、永远亮着的发送键，这些交互细节在暗示人类：写短一点，我马上就会回你，你随时可以插话。这导致我们会本能地只输入一句模糊的简短指令（比如“改一下首页布局”）。输入质量低，并不是因为人懒，而是界面在诱导人变懒。AI 在信息饥饿的情况下，只能靠猜测去生成代码。
• 对设计者的思维锁定（开发端）：因为工具的设计师假定这是一个聊天软件，他们就会按照聊天软件的节奏来设计 Agent 的后端运行机制。为了迎合即时对话的快节奏，开发者会命令 Agent 在遇到任何细节分支时立刻停下来发问，频繁地向人类汇报进度，并以最低延迟吐出文字。这直接导致 AI 失去了在沙盒里默默编译、运行测试、自我验证的安静时间。它被程序强行塑造成了一个急躁的聊天伙伴。
• REPL 交互的延续（契约锁定）：哪怕是命令行里的 Claude Code，人机交互的本质依然是一问一答的交互循环。聊天框对用户心理预期的设定被原封不动地搬了过来，人类依然被绑在屏幕前，频繁地查看状态、打字纠偏，陷入微观管理的恶性循环。

这种从两端发起的心智规训，构成了聊天窗口的先天局限（见图 1）。一个界面是否属于 AI 原生，不看它接的是不是最新模型，而要看它默认诱导的人类行为，是否恰好能让 AI 发挥出最佳性能。

三、 逆向套利：那些把 AI 用得最好的人，都在假装写邮件

观察那些真正把 AI 用成超级放大器的工程师，会发现一个有趣的现象：他们在用聊天框时，都在努力对抗聊天框的默认暗示。

• 他们不会只发一句话，而是把几千字的需求、完整的代码文件、API 规范一次性塞进输入框。
• 他们会主动扔给 AI 一个本地路径，告诉它：“去把这个目录下的代码读一遍，跑通测试，想明白了再回答”。
• 他们点击发送后，会主动关掉窗口，转头去写文档或喝咖啡，强行切断对秒回的期待。

这群套利者，实际上是在用写邮件的思路，去强行使用聊天框。

但这暴露出一个荒谬的现状：为了让先进的 AI 帮我们干好活，我们竟然要在聊天框里假装自己正在写一封封电子邮件。既然如此，我们为什么不直接给 AI 一个邮件接口？

四、 答案在管理制度里：为什么偏偏是邮件？

邮件在商业社会里流行了半个世纪，因为它天生就是为了异步协作设计的，刚好能和 AI 干活的三个前提对齐：

• 邮件正文：天生对应详细的任务说明和成功标准。因为发信的预期是“对方几小时后甚至明天才回复”，这会反过来迫使你在写信时深思熟虑，一次性写清意图。
• 邮件附件与代码库引用：天生对应非 Prompt 上下文。你不需要在对话里贴几千行代码，只需把参考文件和设计图拖入附件，或者附上 Git 仓库链接。对于运行在本地的个人 Agent，甚至可以直接写下本地工作区的绝对路径，作为授权它访问物理硬盘的凭证。
• 收件箱心智：天生对应异步等待。点击发送后，你会去干别的事。这给了 AI 宝贵的安静执行时间，让它能安心跑编译器、运行测试并自我修正。

这本质上是把人类组织里成熟的直属汇报关系平移到了数字世界：

布置任务（写任务书/发送邮件） ──> 过程留痕（Git Repo/Markdown） ──> 阻塞上报（只在超预算/触发安全边界时打断） ──> 成果验收（Review Markdown 报告）

在运行中，我们应当践行代码是耗材的思路：遇到非致命的选择分支，AI 应该自己做出假设并干到底，而不是停下来提问。AI 做错的算力成本极低，而打断人类思路、迫使人类切换上下文的精力成本却极高。

最近，市场上开始出现 Manus 的邮件任务入口、AgenticMail 等创业公司。这种趋同演化说明，邮件被重新发现，是因为它是目前唯一现成的、能承载这套异步管理流程的数字基础设施。

五、 认知惯性与商业指标的思维惯性

既然异步协作和高上下文输入更合理，为什么市面上的产品几乎全在做聊天框？

这里存在两个层面的瓶颈：

1. 聊天的认知惯性：因为叫“人工智能”，我们的第一反应是“和它对话”。我们容易把智能等同于交谈，因此聊天机器人成了最符合直觉的方案。邮件听起来太像古老的恐龙，被大多数开发者忽视了。
2. 商业指标的思维惯性：大厂设计 AI 产品的核心指标，通常延续了移动互联网时代的 DAU、用户活跃度和停留时长。但一个真正高效的 Agent 工具，其体验恰恰相反：人类在界面里的停留时间越短越好，发完任务就走。这种指标导向的冲突，限制了真正解脱人类注意力的异步生产力产品的诞生。当然，随着 Agent 实际干活的能力提升，这种陈旧的指标设定在未来终将被打破。

六、 终局落地的画卷：Post Office vs. Office Desk

在工程落地时，我们并不需要推倒重建，只需将信息流和控制平面进行拆分，划分成邮局与办公桌两个界面（见图 2）：

• 邮局（Post Office）- 邮件流：负责任务下达与交付报告。你把复杂的任务要求发送给 Agent 的专属邮箱，然后关掉邮箱。
• 办公桌（Office Desk）- 共享工作区：Agent 收到邮件后，默默在工作区创建分支开始运行代码和测试，过程全部在工作区的任务状态文件（如 task.md）中留痕。
• 验收工具（如 iOS 客户端）：抛弃聊天的形式，只管理任务状态：Working（静默干活）、Ready to Review（干完了，通知人来验收）、Archived（归档）。

当 Agent 数量膨胀到几十个时，连读报告都会成为负担。届时界面会朝向高管模式再上演一次进化——默认静默推进，只对预算超支、越权等异常情况进行路由上报。但现在，我们首先要做的，是把 AI 从聊天框的微观管理里解脱出来。