GitHub Copilot 为什么说聊天框是错的 UI
When chat is the wrong UI
AI 导读
GitHub Copilot 提出用 canvas 替代聊天框作为与 AI 协作的主要界面:canvas 是运行在 GitHub Copilot 应用内的全栈小应用,可与 agent 双向通信,也能调用第三方 API 或在本地执行代码。
正文· AI 翻译
我们进行这项 AI 实验已经 176 年了。
等等……才三年?
你确定吗?
有时候我会想起去年发生的事,但感觉已经过去很久了。那真的发生在我身上吗,还是发生在我爸身上、他只是在我小时候告诉过我?
总之……我们进行这项 AI 实验已经三年了,而我们与 LLM 的主要交互界面仍然是聊天。我很确定是 @pmarca 最早主张在 HTML 规范中加入 textarea 组件。我很确定这个事实,因为我在一个 textarea 里问过 AI。
但我想向你提出,也许,只是也许,聊天是错误的 UI。好吧,至少大多数时候是这样。
学者 Steven Pinker 是这样说的……
有点遗憾的是,AI 的首次大规模实现有点像个噱头——一个第一人称聊天机器人。但如果 AI 是面向任务的,那就有巨大的前景。
Steven Pinker, academic
如果一位学者说了这话,然后我把它作为引语写进博客文章里,那你就知道这是真的了。
聊天是与 AI 协作的主要方式,因为它是人们最先上手的东西。聊天作为一种通用解决方案效果非常好,原因很简单:我们不知道人们会尝试用 AI 做什么。
但作为用户,你知道自己要拿它做什么,而到了那个时候,聊天往往就是错误的 UI。
亲爱的读者,你需要的是某种可定制的 UI,你可以凭空把它变出来,以适合你当下要做的事情的方式与 AI 协作(或者跟它打架——随你便)。
实现这一点的方法有很多,但在 GitHub Copilot 应用中,这被称为 canvas。
canvas 是一个小型全栈应用,运行在 GitHub Copilot 应用内部,没有浏览器界面。智能体可以与这个应用的服务器部分通信,服务器也可以回传。所以你最终得到的是一个能做普通计算机程序能做的任何事情的界面,而且还能与 GitHub Copilot 智能体进行双向通信。
这听起来非常含糊其辞,而且我用了“双向”这个词,听起来就像直接从 PowerPoint 里搬出来的,所以让我们在实践中看看这个概念,看看我们能否用强大的 canvas 解决实际问题。
我们先从一个简单的例子开始:用 canvas 创建一个 Connect 4 游戏,让你可以在 GitHub Copilot 应用内与智能体对战。
看我如何彻底碾压高推理模式下的 GPT-5.6 Sol……
好吧。但我确实击败了无推理模式的 GPT-5.6 Luna,所以……听着……CONNECT 4 是个很难的游戏!!
构建一个 canvas 就像开口要一样简单……
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 canvasGitHub Copilot 应用知道 canvas 是什么,所以我们不需要再多做解释。
现在,因为这些 canvas 实际上是全栈应用,而不仅仅是网页,它们可以调用第三方 API,没错,但它们也可以在你的机器上本地执行代码。
例如,这是一个 Winget 的 UI,可以在注册表中浏览软件包,还可以管理我的本地软件包,包括安装和卸载。
这里没有 AI,但这正是重点。
当聊天成为主要界面时,它会鼓励你用智能体去做所有事情。这往往纯粹是在浪费 token。几乎总是更好的做法是让智能体构建一个工具,让未来所有交互都免费,而不是把智能体本身当作工具。别再让 GPT-5.6 Sol Max 去“暂存并提交”了。(我知道你会这么干。因为我也干过。别拿 token 羞辱我,我的自尊心很脆弱。)
另一个很好的例子是:与其用聊天让智能体对你的 SQLite 数据库做各种操作,不如打开一块画布,然后,你懂的,自己动手做。
我是说,你甚至可以在这里用上智能提示。为什么不呢?都 2026 年了,AI 就是个魔法盒子,你想让它干什么它就干什么。
是不是挺惬意的?
偶尔写点 SQL 也不错。我说的是偶尔。放轻松。
或者,既然你能把 Windows Live Writer 从坟墓里挖出来,为什么还要用纯 Markdown 写你的 Jekyll 博客文章呢?
好吧,这些都是有趣且略有用的例子,但当你用自定义 UI 来自动化开发工作流时,它的价值就清楚得多了。
我不打算教你怎么生活,但我与智能体协作的流程大致是这样的……
- 调研
- 原型
- 规划
- 实现
- 迭代
- 收尾
这很简单,但每一步都需要我坐在键盘前进行交互、查看原型、引导并推进到下一步。
但问题在于,这个流程的大部分环节我其实并不需要在场。智能体有能力做调研、生成原型,然后在我可以评审时通知我。使用智能体的目标始终是尽可能把自己从循环中抽离出去。但这很难,因为当你只有一个聊天框时,你并不清楚该怎么做。
下面是一个完整示例,展示如何用画布来自动化你自己的流程,让你想抽离多少就抽离多少。
我不是说你应该照搬这个流程,也不是说这就是与智能体协作的完美范例。我是说,它也许就是。它很可能就是。我们问问 AI 吧……

天哪。
说正经的,我确实认为,如今被聊天 UI 框住可能对我们所有人都不利。这让我们很难想清楚如何解决真正的问题,因为当你唯一的交互方式是一个文本输入框时,该怎么做完全不明显。
今天就试试画布吧。有些东西,比如 SQLite 画布,你可以一次搞定。工作流那个花了大半天才把设计和自动化调对。
但我想你会发现,当你……等等……跳出聊天框思考时,你能用 AI 走得更远。
文章 当聊天是错误的 UI 首发于 The GitHub Blog。