做项目看板时，Copilot 能给你现搭一个界面

你大概见过这种场面。

Agent 已经跑了两个小时，聊天框里堆着排查过程、改动说明和几句「已完成」。你想知道哪几个 PR 还没过测试、哪个 Issue 要先处理、刚才那条任务究竟卡在哪里，只能往回翻。翻着翻着，任务状态和聊天记录搅成一锅粥。

GitHub 昨天放出的 Copilot Canvas 教程 有个挺实在的想法。别只让 Agent 在聊天框里报进度，给人和 Agent 放一张能一起改的板。

Canvas 是 GitHub Copilot app 里的共享交互界面。它可以是看板、Issue 分诊台、发布检查表、仪表盘、表单或表格。你能拖卡片、改字段、点筛选，Agent 也能在工作时更新同一份状态。

好家伙，终于不是把聊天记录当项目管理系统了。

官方截图展示了 Canvas 作为 Agent 会话侧边栏里的共享工作面板。

它补上的，不是一张新界面

聊天很适合把意图说清楚。

「帮我看看这些失败测试」「把发布说明补齐」「这批 Issue 哪些该先做」都很适合从对话开始。但一旦任务开始跨几轮、跨多个 PR，聊天框对状态就不太友好了。人记不住，Agent 也未必每次都把旧上下文带得恰到好处。

Canvas 想补的是这个中间层。

你在同一个工作面板里看到待办、正在处理、需要确认和已经验证的东西。Agent 可以调用这个面板暴露出来的动作更新卡片，人也能直接纠正状态，再让 Agent 接着往下干。官方文档把这种方式概括得很准确，重点不是多一个 UI，而是让工作有一个可见、可修改、能核对的工件。文档 还列了计划、分诊、浏览器会话、发布检查表和表格这些适合的场景。

这东西有点子牛逼的地方，不在它能画一块板。

在于板上的状态不是聊天摘要，而是下一步真的会被人和 Agent 一起操作的状态。

先把这三句话写清楚

官方给 /create-canvas 的提示很简单，先交代工作流、人能做什么、Agent 能做什么。很多 Canvas 会在这里翻车，不是因为界面丑，而是需求里只写了「给我做一个项目面板」。这句话等于没说。

如果你在盯一个仓库的 Issue 和 PR，可以从这段开始。它是基于官方能力整理的示例，不是独立实测结果。

/create-canvas
创建一个仓库分诊面板。
人可以查看、筛选和调整 Issue 的优先级。
Agent 可以汇总最近失败的测试、为卡片补充排查摘要，
但不能自动关闭 Issue 或修改生产环境。

这里最重要的不是「分诊面板」四个字，而是后两句。谁有直接操作权，谁只能提供信息，谁需要人确认，先写进去。以后界面要加字段、按钮或筛选器，才不会变成一张花哨的便签墙。

发布前的检查清单也很合适。比如让 Agent 收集本次合并的功能，再把人工需要确认的版本号、文案、回滚说明留成清晰的勾选项。

/create-canvas
创建一个发布检查清单。
人可以勾选验收项、补充回滚负责人和标记阻塞项。
Agent 可以从当前会话整理变更和测试结果，
但发布动作必须保持人工确认。

还有一种，我觉得特别适合总被 Agent 会话淹没的团队。把进行中的 Agent 任务、已改文件、测试状态和下一步计划摆到一块。要是同事接手时不必翻五十屏聊天，已经值回票价。

/create-canvas
创建一个 Agent 任务交接板。
显示任务目标、已调查内容、已改文件、测试结果和下一步计划。
人可以标注风险和调整优先级。
Agent 只能更新自己执行过的记录，并为每项测试附上可追溯的命令或链接。

这三段的共同点，是都把「看到什么」「谁来改」「怎样算完成」说具体了。Canvas 不是替你想工作流，它只会把你说清楚的部分做得更可见。

别把 Canvas 当成自动化的终点，它更像让任务状态可见、可改、可验收的协作桌面。

个人小工具，什么时候该进仓库

官方文档给了两个保存位置。个人画布可以放在 ~/.copilot/extensions，适合先试一个自己的习惯。项目画布放在 .github/extensions，可以跟仓库一起提交，让团队复用。

我会用一个很笨但很有效的判断法。

连续两周都在同一个任务上来回复制提示词，团队有人接手后能看懂这张板的字段，改动还能通过仓库评审，那就该放进 .github/extensions。它已经不是你的私人快捷方式，而是团队工作流的一部分。

反过来，如果它只服务一次临时排查，字段全是你自己的缩写，或者连谁维护都没想好，先留在个人目录。仓库不是 Canvas 养老院。每多一份共享扩展，就多一份需要维护、审查和解释的约定。

GitHub 文档提到，画布扩展通常会有入口文件、元数据和保存状态的工件。对团队来说，这句话的翻译就是，别把它当一张截图。它是能进入版本控制、能被审查、也可能需要迁移的代码和状态。

真正需要盯住的是那条边界

Canvas 让 Agent 有了更顺手的操作面板，不等于该给它更多操作权限。

第一版最好只让 Agent 做收集、归类、补充摘要和更新自己产生的记录。关闭 Issue、改负责人、触发部署、碰生产数据这些动作，仍然应该保留人工确认和清晰审计。看板能帮你更早发现状态不对，不能替你替结果签字。

还有一个容易被忽略的坑，别把面板上的「完成」当成真实完成。让每张卡片至少能回到一个证据，测试命令、PR、构建链接、变更文件或明确的人工确认。没有证据的绿色勾，和聊天框里的「我搞定了」差不了多少。

所以我会拿这张小验收单过一遍。

• 这张板有没有服务一个具体的高频任务，而不是笼统地管理一切
• 人和 Agent 能做的动作有没有分开写清楚
• 每个完成状态能不能回到一个可核对的证据
• 放进仓库后，别人能不能不靠口头说明就接手
• 有写入、部署或权限变更时，人工确认还在不在

五项都能回答清楚，再考虑把它变成团队的固定工具。

Canvas 这件事让我有点开心。Agent 协作最烦的往往不是它不肯干活，而是它干完以后，大家不知道该信什么、改什么、谁来接下一棒。

聊天把任务叫醒，画布把任务留在桌上。剩下的验收，还是得我们自己做。

你们团队里，最想从聊天记录里捞出来放到一张共享板上的工作，是什么？