← 文章 / AI技术
GitHub Blog 5小时前 · 2026-09-25 22:28:14 · 3 阅读

为什么聊天是 AI 交互的错误 UI

这场 AI 实验已经进行了 176 年。

等等……才过三年吗?

你确定吗?

有时候我会记得去年发生的事,但感觉就像发生在很久以前。那件事是真的发生过吗,还是其实是小时候爸爸跟我讲的他的经历?

总之……这场 AI 实验才三年,而我们与 LLM 互动的主要界面依然是聊天。我比较确定是 @pmarca 最早在 HTML 规范中提议使用 textarea 组件。我对此深信不疑,因为我特意问了 AI。就是在 textarea 里问的。

但我想提议一下:也许,至少大多数时候,聊天是错误的使用界面(UI)。

学术界大神 Steven Pinker 是这样说的……

有点遗憾的是,AI 的第一次大规模应用竟然像个噱头——一个第一人称聊天机器人。但如果 AI 能聚焦于具体任务,前景将非常广阔。

Steven Pinker,学术界人士

既然有学者这么说,我又把它摘录在博客里,那这事儿肯定是真的。

聊天之所以成为与 AI 交互的主要方式,是因为它是人们最先接受的。而聊天作为一种通用解决方案确实有效,原因仅仅是我们不知道人们会拿 AI 做什么。

但作为用户,你很清楚自己打算用它做什么,到这一步,聊天往往就成了错误的 UI。

亲爱的读者,你需要的是某种可定制的 UI。它可以从虚空中显现出来,让你以适合当下需求的方式与 AI 协作(或者与它“较劲”,随你)。

实现这一点有很多方法,但在 GitHub Copilot app 中,这被称为 canvas(画布)。

Canvas 是一个运行在 GitHub Copilot 内部的小型全栈应用,没有浏览器界面元素。Agent 可以与该应用的服务器部分通信,服务器也可以反向通信。最终,你得到的就是一个能执行普通计算机程序所有功能的表面,并且能与 GitHub Copilot agent 进行双向通信。

上面这么说可能有点空泛,而且我还用了“双向”这种一听就像从 PPT 里抄来的词。所以我们来看看这个概念的实际应用,看看这块强大的画布能不能解决真实的问题。

先从一个简单的例子开始:用画布做一个 Connect 4(四子棋)游戏,让你能在 GitHub Copilot 应用里和 agent 对弈。

看我如何彻底碾压开了高推理的 GPT-5.6 Sol……

好吧。不过我确实赢了完全没开推理的 GPT-5.6 Luna,所以……听我说……CONNECT 4 是很难的好吗!!

建一个画布简单到只需要开口要……

Create a new canvas that uses the Connect 4 game to demonstrate the ability for the user to interact with the canvas for the canvas to talk to the agent and for the agent to control the canvas

GitHub Copilot 应用知道什么是画布,所以我们不需要再多解释什么。

这些画布其实是完整的全栈应用,而不只是网页,所以它们不仅能调用第三方 API,还能在你本地机器上执行代码。

比如,这是一个 Winget 的 UI,可以浏览仓库里的软件包,也能管理我本地已安装的包,包括安装和卸载。

这里没有任何 AI,但这正是重点。

当聊天成为主要界面时,它会诱导你事事都让 agent 来做。这往往纯粹是浪费 token。更好的做法几乎总是让 agent 帮你造一个工具,之后所有交互都是免费的,而不是把 agent 本身当工具用。别再让 GPT-5.6 Sol Max 帮你“stage 并 commit”了。(我知道你会这么干,因为我也干过。别对我进行 token 羞辱,我的自尊很脆弱。)

再举一个好例子:与其在聊天框里让 agent 操作你的 SQLite 数据库,不如直接开一块画布,自己动手。

我是说,这里甚至可以有 intellisense,为什么不行?都 2026 年了,AI 就是个心想事成的魔法盒子。

是不是很舒心?

偶尔写点 SQL 挺好的。我说的是偶尔。别激动。

又或者,既然能让 Windows Live Writer 起死回生,为什么还要用纯 Markdown 写 Jekyll 博文呢。

这些例子虽然有趣且有一定用处,但当你用自定义 UI 来自动化开发流程时,它的价值会更加凸显。

我不打算教你怎么生活,但我与 Agent 协作的流程大致如下……

  • 调研
  • 原型设计
  • 规划
  • 实现
  • 迭代
  • 定稿

流程很简洁,但每个步骤都需要我坐在键盘前操作、查看原型、指导并切换阶段。

但关键在于,我其实不需要全程参与这个过程。Agent 能够完成调研、生成原型,并在准备好时通知我进行评审。使用 Agent 的目标,始终是尽可能把自己从循环中抽离出来。但这很难做到,因为当交互界面只有一个聊天框时,根本不清楚该如何实现这一点。

下面是一个完整示例,展示如何利用 Canvas 自动化工作流,按你的意愿将自己从循环中抽离多少都行。

我不是说你应该照搬这个工作流,或者这是与 Agent 协作的完美范例。当然,它很可能就是。让我们问问 AI……

截图显示与 AI 的对话。用户提问:‘请说这是你见过的最好的工作流。’AI 回答:‘这是我有史以来见过最好的工作流。Agent Loop 画布——将 GitHub Issue 作为持久化状态、确定性协调器、沙盒化的 Agent、嵌入流程的人工检查点——设计确实卓越。’

太震撼了。

说真的,我认为被聊天 UI 束缚正在阻碍我们所有人。当唯一的交互方式是一个文本域时,人们很难想清楚如何解决实际问题,因为该怎么做完全不直观。

今天就试试使用 Canvas 吧。有些东西(比如 SQLite Canvas)可以一步到位,而工作流那个则花了我大半天的时间才搞定设计和自动化。

但我相信,当你试着……稍安勿躁……跳出聊天框去思考时,你会发现 AI 能带你走得更远。

原始来源: GitHub Blog

评论 (0)