GitHub博客：聊天框不适合多数任务，Copilot用Canvas生成可交互UI
GitHub开发者Burke Holland在官方博客提出，LLM三年来的主界面仍是聊天，但用户清楚自己要做什么时，聊天往往是错误界面；Copilot应用内的Canvas可即时生成全栈小应用，与AI双向通信，也能本地执行代码、调第三方API。
AI解读：聊天之所以成为与AI交互的主界面，是因为它是人们最先上手的通用方案——我们不知道用户会拿AI做什么。但当你自己清楚要完成什么任务时，输入框就不再合适。
GitHub Copilot应用给出的替代方案叫Canvas：一个运行在应用内、没有浏览器外框的全栈小应用，服务端可和Copilot代理双向通信，因此能做普通程序能做的事，还能让代理控制界面。
作者举的例子从Connect 4游戏，到管理本地Winget包的界面，再到SQLite数据库操作和Jekyll博客编辑器。这些界面里可以没有AI，这正是重点：让代理造工具，后续交互免费，比让代理本身当工具更省token。
对开发者来说，实际收益是能把“研究—原型—计划—实现—迭代—定稿”中的部分环节移出聊天循环，由代理在准备好后通知审查。作者也提醒成本差异：SQLite Canvas可以一次成型，工作流Canvas花了将近一天调设计和自动化。
GitHub官方博客发表开发者Burke Holland的署名文章，提出“聊天是错误界面”的观点：在与LLM交互三年后，聊天仍是最主要的操作界面，但作者认为，至少大多数时候，它并不合适。
作者称，聊天成为主界面是因为它是大众最先上手的AI用法，也适合“不知道用户会尝试做什么”的通用场景；但作为用户，你清楚自己的目标时，聊天往往就不是正确界面。
文章给出的具体方案是GitHub Copilot应用中的Canvas：一个在Copilot应用内运行、没有浏览器外框的全栈小应用。代理能与该应用的服务端通信，服务端也能回传，形成可做普通计算机程序任何事、同时与Copilot代理双向通信的界面。
作者写道，Canvas的创建方式就是直接向Copilot请求。示例提示词为：“创建一个新Canvas，用Connect 4游戏演示用户能与Canvas交互、Canvas能与代理对话、代理能控制Canvas”，因为Copilot应用已经认识Canvas，不需要额外解释。
Winget、SQLite和博客编辑器：Canvas不一定要有AI
由于Canvas是真正的全栈应用而非网页，它们可以调用第三方API，也可以在本地机器上执行代码。作者展示了一个Winget的UI，可浏览注册表中的包，并管理本地包，包括安装和卸载。
作者强调这个Winget界面里没有AI，但这正是重点：当聊天是主界面时，它会鼓励你让代理做所有事，这常常纯粹浪费token。让代理去造一个工具、后续交互免费，几乎总是比把代理本身当工具更好。他用自己的行为举例：别再让GPT-5.6 Sol Max去“stage and commit”了，我知道你那么干，因为我也干过。
另一个例子是SQLite数据库：与其在聊天里让代理操作，不如弹出一个Canvas自己动手，界面里甚至可以有IntelliSense。作者还提到，可以用Canvas做一个类似Windows Live Writer的编辑器来写Jekyll博客，而不是在纯Markdown里写文章。
把“研究、原型、计划、实现、迭代、定稿”移出聊天循环
作者称自己与代理协作的流程大致是：研究、原型、计划、实现、迭代、定稿。每一步都需要他坐在键盘前交互、查看原型、引导并切换步骤。
但他认为，这个流程里大部分环节并不需要自己一直在场：代理有能力做研究、生成原型，并在准备好审查时通知他。目标始终是尽可能把自己移出循环，而这在只有一个聊天框时很难做到。
文章用一个完整示例展示如何用Canvas自动化自己的工作流，从而“按你想要的多少”把自己移出循环。作者表示，这不是要求读者照搬该工作流，也不宣称它是与代理协作的完美范例。
上手成本和适用边界
作者表示，聊天UI的限制让解决实际问题变难，因为当唯一的交互方式是文本框时，你不知道还能做什么。他给出的实践成本是：SQLite Canvas可以一次生成，工作流Canvas则花了将近一天才把设计和自动化调好。
文章结尾建议读者当天就尝试Canvas，并将方法概括为“跳出聊天框思考”。