GitHub 官方博客放出了一篇写给新手的教程，主题很具体：在 GitHub Copilot app 里用 /create-canvas 这个技能，通过自然语言描述生成一块可以自定义的 canvas 界面。听上去又是"一句话生成 UI"的老调重弹。但真正的重点不在生成，而在于这块画布是双向的——你改它，智能体看得见；它改它，你也看得见。
Canvas 不是长得好看的聊天记录
能被点击的东西，和一段回复是两码事
聊天窗口里的答案再漂亮，本质还是一段文字。你只能读，最多复制粘贴，然后自己找个地方把它变成能用的东西。Canvas 换了条路：让智能体把结果直接渲染成有按钮、有输入框、有列表的界面。你在上面点、填、勾，操作结果回到智能体那一侧，它再顺着你的动作往下干。官方教程里用的说法是"双向共享界面"，说白了就是——这块画布不是给你看的，是给你用的。
"双向"这两个字值多少钱
单向生成的东西，你只有两个选择：接受，或者推翻重做。双向就不一样了。你在看板上改一个数字、换一个筛选条件、拖一条记录，状态变了，智能体立刻知道，并且能据此调整后续逻辑。这中间没有"重新描述一遍需求"的损耗，也没有复制粘贴的搬运成本。对工作流类任务来说，这个差别是决定性的——因为工作流的核心从来不是生成一次结果，而是反复调整、持续运行。
为什么偏偏是画布
因为很多任务根本没法用文字说清楚。比如"帮我把这批 issue 按紧急程度排个序"，文字答案是一串带序号的列表，你想调换两条，就得再写一段话解释。而一块看板能让你直接拖。智能体擅长的东西和人类擅长的东西不一样，画布恰好是这两者的接缝处：语义理解交给模型，判断和取舍留给人。
上手路径：从一句人话开始
斜杠命令就是你的起点
用法不复杂。在 Copilot app 的对话里敲出 /create-canvas，后面跟上你想做的事情。它和普通提问的区别在于，你要描述的是一块界面该长什么样、要解决什么问题，而不是让模型给你一段文字答案。教程把它定位成新手友好技能，这个定位是准的——它不要求你懂前端框架，也不要求你会写组件。
描述写得像需求，出来的东西才像成品
这里有个容易踩的坑。很多人第一次用，会写"给我做一个项目管理面板"，然后抱怨生成的东西太空。问题不在工具，在描述。"项目管理面板"这五个字没有任何可执行信息。换成"左边一列是待办事项，右边一列是已完成，每张卡片显示标题和负责人，点一下能移到另一列"——同样是自然语言，但每一句都能落到具体元素上。你说的是人话，但要说得足够具体，具体到别人听完能画出来。
迭代的正确姿势是接着改，不是从头再来
第一版几乎不可能正好合心意。有人习惯推翻重来，重新写一段描述，这其实是浪费。更好的做法是直接在现有画布上指出哪里不对：某个区域太挤、某列没必要、按钮位置该换。因为界面是活的，智能体拿到的是增量修改指令，而不是从零开始的模糊需求。改上三五轮，一块真正顺手的东西就出来了。
把画布焊进工作流，才是它真正的位置
让它替你盯着一堆数字
这类场景最直观。仓库的 issue 数量、PR 的等待时长、构建失败率，这些东西每天都在变，纯靠翻页面很累。让智能体生成一块监控画布，把关键指标摆在一起，需要的时候刷新一下。它不替代正经的监控系统，但胜在搭得快、改得快，指标口径变了随时调。
审批、筛选、打标签这些高频小动作
工作流里最耗人的往往不是大决策，而是一堆零碎动作：这条 issue 该打哪个标签，这个 PR 要不要现在合，这封反馈归到哪一类。做成一块画布，批量勾选、一键提交，剩下的交给智能体处理。省下的时间不算多，但它省掉的是上下文切换，那个才是真正贵的东西。
把散乱的输出收拾成一张能看的板子
智能体一次能吐出大量信息，问题是怎么看。让它把分析结果组织成表格、时间线、分组卡片，你扫一眼就抓住重点。这种用法门槛最低，也最容易见效。做多了你会发现，其实是在把一批原本要人肉整理的活，前移给了模型。
别急着全押上，几个坑得先想清楚
数据从哪来，权限边界在哪
画布好用的前提是它能拿到数据。能拿到什么、拿到什么程度，取决于你授予的权限。让一块自动生成的界面去碰仓库里的敏感信息之前，先确认它背后的智能体被允许访问哪些范围。自动生成的东西，出问题的速度也很快。
这块界面以后归谁维护
自己临时用的工具，坏了随时重做，没问题。但如果一块画布被塞进了团队流程，隔了两个月没人说得清它是怎么来的、依赖什么逻辑，那就是负担了。用得越顺手的东西，越该给它留个说明。这不是流程洁癖，是基本的工程习惯。
有时候老老实实写个脚本更省事
画布解决的是"人要看、人要判断"的环节。如果一件事从头到尾都不需要人参与，那它就是一条定时任务或者一个脚本的活，套一层界面反而多此一举。判断标准很简单：中间有没有一步是需要人做决定的。有，画布合适；没有，别硬上。
门槛降下来之后，稀缺的是什么
从会写提示词，到会设计交互
生成界面这件事本身，正在变得不那么值钱。真正拉开差距的，是你能不能想清楚：这个任务里哪一步该由人做决定，哪一步该交给模型，界面该怎么摆才能让人的判断更快更准。这套东西以前属于产品经理和交互设计师的活，现在写工作流的人也得会一点。
官方愿意出新手教程，本身就是个信号
GitHub 专门为 Copilot app 写这样一篇面向初学者的指南，说明它不打算让 canvas 只停留在演示视频里。当一个能力开始配上"怎么一步步做"的文档，通常意味着它要进入日常使用阶段了。现在花半小时试一下，比半年后被动跟进要划算。
