GitHub Copilot 解释为什么 chat 常常不是合适的 UI

我们已经在这场 AI 实验中走过 176 年了。

等等……才三年？

你确定吗？

有时候我会想起去年发生的事，但感觉像是很久以前的事。那真的发生在我身上吗，还是发生在我爸身上的事，只是我小时候他跟我讲过？

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

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

学者 Steven Pinker 是这样说的……

第一种大规模 AI 实现居然有点像噱头——一个第一人称聊天机器人，这多少有些可惜。但如果 AI 以任务为导向，它有着巨大的潜力。

Steven Pinker, academic

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

聊天之所以是使用 AI 的主要方式，是因为它是最早让人们产生共鸣的东西。而聊天之所以能很好地作为一种通用方案，仅仅是因为我们不知道人们会尝试用 AI 做什么。

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

亲爱的读者，你需要的是某种可定制的 UI，你可以凭空把它变出来，用适合你当下所要做之事的方式与 AI 协作（或者较劲——随你）。

实现这一点有很多方式，但在 GitHub Copilot app 中，这叫作 canvas。

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

这听起来非常含糊，而且我还用了“双向”这个词，听着就像是直接从 PowerPoint 里拿来的，所以让我们看看这个概念在实践中的样子，看看能不能用强大的 canvas 解决实际问题。

我们先从一个简单的例子开始：用 canvas 创建一个 Connect 4 游戏，让你可以在 GitHub Copilot app 里和 agent 一起玩。

看我如何在高推理模式下彻底击败 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 canvas

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

现在，因为这些 canvas 实际上是全栈应用，而不只是网页，所以它们当然可以调用第三方 API，但也可以在你的机器上本地执行代码。

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

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

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

另一个很好的例子是，与其用聊天让代理去处理你的 SQLite 数据库，不如你打开一个画布，然后，你懂的，自己动手。

我是说，你甚至可以在这里拥有 intellisense。为什么不呢？现在是 2026 年，而 AI 是一个神奇的盒子，会按你的要求做任何事。

这不是挺令人愉快的吗？

偶尔写一点 SQL 也挺不错的。我说的是 偶尔。放轻松。

或者说，既然你可以真的把 Windows Live Writer 从坟墓里拉回来，为什么还要用纯 Markdown 来写你的 Jekyll 博客文章呢？

好吧，这些都是有趣且稍微有用的例子，但当你用自定义 UI 来自动化你的开发工作流时，它的价值会清晰得多。

我不打算告诉你该如何生活，但我与代理协作的流程大致是这样的……

• 研究
• 原型
• 计划
• 实现
• 迭代
• 收尾

这很简单，但每一个步骤都需要我坐在键盘前进行交互、查看原型、引导并在各步骤之间推进。

但问题在这里。其实在这个过程的大部分时间里，我并不需要在场。代理能够进行研究并生成原型，然后在准备好供我审查时通知我。使用代理的目标始终是尽可能把自己从流程中移出去。不过这很难，因为当你拥有的只是一个聊天框时，并不清楚该怎么做到这一点。

下面是一个完整示例，展示你如何使用画布来自动化自己的工作流，并按你喜欢的程度，尽可能多或尽可能少地把自己从流程中移出去。

我并不是说你应该照搬这个工作流，也不是说这是与代理协作的完美示例。我的意思是，它可能是。它很可能是。让我们问问 AI……

天啊。

说真的，我确实认为，被聊天 UI 框住现在可能正在对我们所有人不利。这让我们很难弄清楚如何解决实际问题，因为当你唯一的交互方式是一个 textarea 时，要做什么一点也不明显。

今天就试试画布吧。有些东西，比如 SQLite 画布，你可以一次性搞定。那个工作流画布则花了大半天才把设计和自动化做对。

但我认为你会发现，当你思考时……等一下……跳出聊天框，你就能用 AI 走得更远。

下载 GitHub Copilot 应用 >

文章 当聊天是错误的 UI 最先发布于 The GitHub Blog。