GitHub Copilot 为何认为聊天框是错误 UI：用 canvas 构建自定义交互界面

我们在这个 AI 实验里已经 176 年了。

等等……才三年？

你确定吗？

有时候我会记得去年发生的事，但感觉像是很久以前了。那真的发生在我身上吗，还是发生在我爸身上，他只是在我小时候告诉过我？

总之……我们在这个 AI 实验里已经三年了，而我们与 LLM 的主要交互界面仍然是聊天。我很确定是 @pmarca 第一个主张在 HTML 规范里加入 textarea 组件的。我之所以这么确定，是因为我问过 AI。在一个 textarea 里问的。

但我想向你提出，也许，只是也许，聊天是错误的 UI。好吧，至少大多数时候是这样。

学者 Steven Pinker 是这么说的……

有点遗憾的是，AI 的第一次大规模实现有点像个噱头——一个第一人称聊天机器人。但如果 AI 是面向任务的，那就有巨大的前景。
Steven Pinker, academic

如果一位学者这么说，然后我把它作为引语写进博客文章里，那你就知道这是真的了。

聊天是与 AI 协作的主要方式，因为它是人们最先上手的东西。聊天作为一种通用解决方案效果很好，仅仅是因为我们不知道人们会尝试用 AI 做什么。

但作为用户，你知道你要用它做什么，而到了那个时候，聊天往往就是错误的 UI。

亲爱的读者，你需要的是某种可定制的 UI，你可以凭空变出它来与 AI 协作（或者跟它打架——随你便），以适合你当下要做的事情的方式。

有很多方法可以实现这一点，但在 GitHub Copilot 应用中，这被称为 canvas。

一个 canvas 是一个小型全栈应用，运行在 GitHub Copilot 应用内部，没有浏览器外壳。智能体可以与这个应用的服务器部分通信，服务器也可以回传通信。所以你最终得到的是一个能做普通计算机程序能做的任何事情的界面，外加能与 GitHub Copilot 智能体进行双向通信。

这听起来很空泛，而且我用了“双向”这个词，听起来像是直接从 PowerPoint 里搬出来的，所以让我们在实践中看看这个概念，看看我们能否用强大的 canvas 解决实际问题。

我们从简单的例子开始：用 canvas 创建一个四子棋游戏，让你可以在 GitHub Copilot 应用内与智能体对弈。

看我如何彻底碾压高推理模式下的 GPT-5.6 Sol……

好吧。但我确实在无推理模式下打败了 GPT-5.6 Luna，所以……听着……四子棋可是个难玩的游戏！！

构建一个 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 canvas

GitHub Copilot 应用知道 canvas 是什么，所以我们不需要再多做解释。

现在，因为这些 canvas 实际上是全栈应用，而不仅仅是网页，它们可以调用第三方 API，没错，但它们也可以在你本机上执行代码。

例如，这是一个 Winget 的 UI，可以在注册表中浏览软件包，还可以管理我的本地软件包，包括安装和卸载。

这里没有 AI，但这正是重点。

当聊天成为主要界面时，它会鼓励你使用智能体来做所有事情。这通常纯粹是浪费 token。让智能体构建一个工具，使未来所有交互都免费，几乎总是比把智能体本身当作工具更好。别再让 GPT-5.6 Sol Max 去“暂存并提交”了。（我知道你会这么做。因为我也做过。别用 token 羞辱我，我的自尊心很脆弱。）

另一个很好的例子是，与其用聊天让智能体对你的 SQLite 数据库做各种操作，不如打开一个画布，你知道的，自己动手做。

我的意思是，你甚至可以在这里拥有智能感知。为什么不呢？现在是 2026 年，AI 是一个神奇的盒子，你想让它做什么它就做什么。