界面正在塑造我们使用 AI 的方式

我们打开 AI，准备把一件难事交给它。输入框里先写下一句“帮我重做首页”，按下发送。它很快问回来，想要什么风格，要改哪些页面，移动端怎么处理，有没有参考网站，要不要先读代码。

这些问题都合理。麻烦在于，我们开始一条一条回答。刚答完配色，它又来问字体。刚解释完首页，它又来确认导航。屏幕不断滚动，人也留在屏幕前。原本想交出去的工作，最后变成了一场需要全程陪同的远程操作。

我越来越觉得，很多人遇到的 Agent 使用问题，模型只负一部分责任。那个窄窄的聊天框也在教我们怎么行动。

聊天框会把任务切碎

聊天框很适合问答。人说一句，对方回一句，回复来得越快，体验通常越好。输入框做得小，发送键一直亮着，回答逐字出现在屏幕上，这些设计都在催促人赶快说，等着看回应，然后继续说。

复杂工作需要另一种节奏。接手一项代码任务的人，至少要知道为什么改、改到哪里为止、哪些地方不能碰，还要知道怎样才算做完。相关代码、设计稿、历史讨论和测试命令也得有地方放。材料读完以后，他还需要一段完整时间去修改、运行、失败、再修改。

聊天框鼓励我们先发出一句不完整的话，缺失的内容留到后面再补。任务于是被切成许多轮对话。Agent 每走几步就回来问，人每隔一会儿就切回窗口看一眼。模型也许一直在工作，人的注意力却被这些小问题拆散了。

人们常把结果不好归到提示词上，然后学习角色设定、约束写法和各种提示技巧。这些技巧确实有用。同一个人换到邮件里，往往会自然写得更完整。他知道收件人不会立刻回复，就会提前交代背景，附上文件，写清期限，也会顺手说明自己希望收到什么结果。

写作能力没有突然提高。界面改变了他的预期。

现在已经有人在聊天框里故意采用邮件的写法。他们先写一份完整任务说明，给出仓库和文件路径，附上参考材料，列出不能改的范围，再写清验收办法。发完以后关掉窗口，让 Agent 自己读代码、改文件、跑测试。只有遇到需要人来决定的取舍，它才停下来询问。

这套用法多少有点别扭。我们买来一个可以执行任务的 Agent，却得先抵抗产品界面给出的暗示，提醒自己别像聊天那样只写半句话。

一份能交给 Agent 的任务说明，不需要研究复杂格式。它只要回答几个实际问题。

先讲清这次为什么要做。再告诉它最后要交付什么，哪些改动不在范围内。把代码、文档和参考资料指给它，写下可以执行的检查办法。遇到普通细节时，允许它依据仓库里的现有做法继续完成。只有答案会明显改变产品方向、引发安全风险，或者需要不可逆操作时，再回来问人。

这已经很像日常工作里的委派。主管不会要求同事每改一行都来汇报。他会先把目标和权限讲清楚，约好什么情况必须上报，最后看结果。Agent 若有独立工作区，能够读取材料、修改文件和执行测试，也应该按这样的节奏工作。

我希望看到的 Agent 界面，更像任务收件箱和工作台的组合。

任务收件箱负责接收说明、附件和验收条件。工作台负责保存执行状态、代码改动、测试结果和关键决定。人发出任务以后可以离开。Agent 安静工作，完成后把结果送回来。它若受到阻碍，也应该带着已经查到的材料和一个足够具体的问题回来，省得人重新进入整个上下文。

这样的产品不必隐藏过程。日志、文件改动和中间产物仍然可以查看，只是不再要求人一直看。状态也不用复杂。正在执行、等待决定、可以验收，通常已经够用。人的职责留在方向、取舍和最终验收上，持续盯守可以省掉。

这还会改变产品判断好坏的方式。聊天产品容易看重回复有多快、对话有多少轮、用户停留了多久。任务型 Agent 应该争取更少的打断、更短的人类操作时间，以及更高的一次性交付完成度。一个人发完任务就去做别的，过一阵回来验收，这恰好说明工具替他接住了工作。

等到一个人同时使用多个 Agent，聊天框的问题会更明显。十几个窗口轮流弹出问题，用户很快就会成为最忙的消息转发员。那时需要的是统一的任务列表和异常上报机制。普通选择由 Agent 按约定处理，预算超出、权限不足和意图不清时再通知人。

讨论一个想法、追问一句解释、共同梳理一个还没成形的问题，聊天很好用。任务刚开始时，人和 Agent 也可能需要几轮交流来确定方向。方向一旦明确，工作就该进入执行状态。聊天是其中一个环节，没必要承包整个过程。

我们已经花了很长时间学习怎样跟 AI 说话。接下来可以练习一次性交代完整：给足材料，约好边界和验收办法，然后允许自己离开屏幕。

评价这类界面时，可以看用户能否一次提交任务，离开页面，并且只在真正需要决定时回来。做到这些，聊天框才不再规定整项工作的节奏。

本文受到 Yage 的文章《聊天框的幻觉》启发。