当聊天框成为错误的交互方式：AI画布登场

聊天框的局限性

对话式界面（chat UI）几乎成了当下AI工具的默认交互形态。从代码助手到写作工具，用户习惯了在一个输入框里敲下需求，然后等待模型返回一段文字。这种模式的优势显而易见——门槛低、上手快，符合人们与人交流的直觉。

但GitHub Blog在这篇《When chat is the wrong UI》中提出了一个值得开发者深思的问题：当任务需要比聊天框更具象、更可操作的东西时，纯对话式界面反而成了阻碍。原文一针见血地指出，开发者常常需要「something more tangible than a chat box」（比聊天框更实在的东西）。

聊天的线性特征决定了它擅长处理「一问一答」式的短交互，却难以承载需要反复编辑、结构化组织、并行对比的复杂工作流。当你想调整一段生成结果的某个局部，或者需要在多个方案之间来回权衡时，把所有意图都压缩进一行文字描述，本身就是一种信息损耗。

画布（Canvas）作为解法

原文给出的答案是「画布」（canvases）。相比线性滚动的聊天记录，画布提供的是一块可自由布局、可直接操作的工作空间。用户不再只是「描述」需求，而是可以直接在结果上进行操作——拖拽、圈选、局部修改、并列比较。

这种交互范式的转变，本质上是把AI从一个「只能通过文字沟通的黑盒」变成了一个「可以协同编辑的工作台」。对开发者而言，代码、图表、设计稿这类天然具备空间结构的产物，用画布来承载显然比塞进聊天气泡更合理。

画布的价值在于恢复了「所见即所得」的直接操作感。当生成物本身是可视化、结构化的内容时，让用户在对象上直接施加意图，远比让他反复用自然语言解释「把左上角那个改一下」来得高效。

「画布」范式并非AI时代的新发明，它的设计基因可以追溯到施乐PARC实验室在1970年代提出的「所见即所得」（WYSIWYG）理念，以及后来Figma、Miro等协作工具所验证的空间化操作逻辑。在AI产品中，较早将画布概念落地的是Notion AI和Figma的AI功能，而OpenAI于2024年推出的Canvas模式则让这一交互形态获得了更广泛的关注。其核心机制在于将生成结果从「消息气泡」提升为「可操作对象」——用户可以选中文本片段单独重写、对代码块执行局部调试、在同一工作区并列呈现多个版本。对于开发者工具而言，这与IDE（集成开发环境）长期以来的设计哲学高度契合：代码从来不是线性生产的，而是在文件树、编辑器、终端之间不断跳跃和迭代的。

对AI产品设计的启示

这篇文章的核心观点对整个AI产品设计领域都有借鉴意义：交互形态应当服务于任务本质，而非盲目追随对话式潮流。

聊天框之所以流行，很大程度上是因为大语言模型天然以文本为输入输出，对话是最自然的封装。但这并不意味着所有场景都适合对话。当任务涉及空间关系、局部编辑、多方案对比或持续迭代时，画布、表单、可视化编辑器等形态往往能提供更好的体验。

对于GitHub Copilot这类开发者工具而言，这种思考尤为重要。开发工作本身充满了非线性——在文件间跳转、对比不同实现、逐步重构。如果AI助手只能通过聊天框介入，就难以真正嵌入开发者的实际工作流。引入画布式交互，意味着AI能够更深地融入开发环境本身。

交互范式的未来走向

从更宏观的视角看，AI交互界面正在经历一次从「对话优先」到「场景优先」的重新校准。早期产品倾向于用一个万能聊天框覆盖所有需求，而随着应用场景细分，越来越多的产品开始为特定任务设计专门的交互形态。

画布只是其中一种探索方向。可以预见，未来的AI工具会更倾向于混合式交互——在需要开放式对话时保留聊天，在需要精确操作时切换到画布或结构化界面。关键不在于用哪种UI取代哪种，而在于让模型能力与恰当的交互形态相匹配。

这篇GitHub Blog的短文虽然篇幅不长，却点出了一个正在被行业逐渐重视的趋势：好的AI体验，不仅取决于模型有多强，也取决于它以何种形态与人协作。

「场景优先」的交互设计理念在人机交互（HCI）领域有一个对应的学术概念：情境感知界面（context-aware UI）。其主张是，界面形态本身应当根据用户当前任务的性质动态调整，而非提供一个固定的通用入口。这与当前AI产品设计的演化方向高度吻合——从Cursor在代码编辑器中内嵌AI、到v0用可预览组件取代纯文本输出、再到Replit Agent直接在运行环境中操作，都是「让AI界面贴合任务结构」的具体实践。值得注意的是，混合式交互也带来了新的设计挑战：何时从对话模式切换到画布模式、切换的触发机制是显式的还是自动的、两种模式之间的上下文如何同步，这些问题目前业界尚无定论，也是下一阶段AI产品竞争的重要维度。