让 AI 整理一份待处理的 PR 清单，通常不难。麻烦往往出现在清单生成之后。哪些需要优先审核，哪些已经处理，哪些要暂缓合并？如果这些变化都要靠追加消息来表达，对话越长，查找和核对当前进度就越费劲。
项目管理工具提供了看板、表单和筛选器，但遇到临时出现的工作流程，仍然需要配置和调整。聊天框方便表达需求，持续操作一组任务时，又会让人想念那些可以直接点击的按钮。
GitHub Copilot app 中的Canvases（画布扩展），把这两种交互接在了一起。开发者描述需要的工作界面，由 Agent 创建出来，随后双方在同一个界面里查看和修改任务。官方入门指南
Canvas 方便了人机协作的界面逻辑：它不再要求工作流去适应工具，而是让界面围绕开发者当下真实的工作流动态成形。它是一块由开发者与 Copilot 智能体实时双向共享的可定制交互工作台，把过去“下达命令后干等结果”的单向等待，重构成并肩工作的即时协同。
如果你需要在工作流中接入API，自由切换全球200+大模型，魔芋提供合规保障、财务开票、企业级网关、技术支持与定制服务，助力更高效地管理应用AI能力。
Konjac AI — Unified AI API for China & Global LLMsThe Konjac AI Large Model Aggregation Platform (Large Model Gateway Platform) specializes in delivering high-performance, low-cost AI model services across multiple categories, empowering developers and enterprises to focus on product innovation.https://www.konjac.ai/sign-up?aff=qBX9
一、Canvas 让人和 Agent 操作同一份工作状态
Canvas 可以理解为运行在 Copilot app 中的一个可定制工作界面。它可以做成任务看板、Issue 分诊面板、发布清单或电子表格，具体形态取决于需要完成的工作。
它的关键能力是双向交互。人通过按钮、字段和卡片修改内容，Agent 通过画布提供的可调用能力读取或更新内容，双方围绕同一份状态推进任务。
官方文档给过一个看板例子。人可以在界面里创建和移动卡片，同时让 Agent 使用get_board、add_card、move_card等能力操作看板。这些名称属于示例，实际能力需要在创建或修改画布时定义。画布扩展文档
开发者 Copilot Agent │ │ │ 点击、编辑、移动卡片 │ 调用画布提供的能力 ▼ ▼ 同一份画布状态 │ ▼ 看板、清单或其他工作界面这里要分清“状态发生变化”和“触发模型处理”。GitHub 的说明提到，用户操作可以发送给 Agent，也可以由画布在本地处理。因此，不能把双向交互理解为每点一次按钮，模型就一定重新推理一次。具体行为取决于扩展的实现。交互机制说明
从选用工具的角度，可以这样比较三种方式。
| 比较维度 | 项目管理工具 | 以对话为主的 AI 助手 | Copilot Canvas |
|---|---|---|---|
| 界面从哪里来 | 产品内置功能与配置 | 对话消息与输出内容 | 根据需求生成并持续修改 |
| 人怎样调整工作 | 编辑字段、移动任务、执行流程 | 追加指令，要求修改或执行 | 使用界面控件，也可以继续提要求 |
| 怎样查看当前进度 | 查看任务记录和报表 | 查看回复及关联产物 | 查看共享界面中的数据和变化 |
| 更适合的任务 | 需要长期统一管理的业务流程 | 提问、讨论、解释和一次性生成 | 需要反复查看、筛选、修改的具体任务 |
这张表比较的是交互侧重点。聊天助手同样可以连接外部工具和持久化数据，项目管理软件也支持自动化。Canvas 值得关注的地方，是它让开发者可以围绕眼前的任务定制界面，并让 Agent 参与操作。
二、用 /create-canvas 创建发布说明看板
在 GitHub Copilot app 中打开一个 Agent 会话，输入/create-canvas，再说明你希望它支持的工作。按照官方指南，需求里最好写清三件事。
要完成什么工作，例如整理多个会话中完成的功能，准备版本发布说明。
人需要怎样操作，例如修改摘要、调整分类、勾选审核状态。
Agent 可以做什么，例如新增条目、补充关联 PR、更新变更说明。
官方使用了跨会话跟踪 Release Notes 的例子。下面是在这一思路上细化的中文提示词，其中的字段、审核规则和保存要求都是向 Agent 提出的需求。
/create-canvas 创建一个发布说明看板，用于整理多个 Copilot app 会话中完成的功能和修复。 每条记录包含标题、变更类型、简短说明、关联 PR 和审核状态。 我需要在界面中编辑说明、调整分类，并按变更类型和审核状态筛选记录。 允许 Agent 新增和更新条目。新条目默认待审核，保留我已经完成的人工修改。 请明确条目的保存位置，让后续会话能够继续使用；无法访问的历史会话或 PR 不要补写。 提供导出 Markdown 的按钮，只导出已经审核的条目。Agent 完成构建后，画布会在应用右侧面板打开。生成结果可以继续调整，具体控件和布局也会随需求而变化。创建画布的官方示例
第一版出来后，建议先检查一条完整流程。让 Agent 新增一条记录，手动修改它并标记为已审核，再让 Agent 补充信息，看看人工修改有没有被覆盖。最后重新打开画布，确认记录还在，导出的内容也符合要求。
这些检查比界面上有多少按钮更有用。发布说明涉及多个会话时，数据从哪里来、存到哪里、更新时怎样保留人工判断，都需要在需求中说清。
三、界面可以继续改，扩展也可以复用
画布创建后，可以继续用自然语言调整。例如给发布看板增加一个版本筛选器，或者要求它单独展示缺少关联 PR 的条目。
增加目标版本筛选器，并标出尚未填写关联 PR 的记录。 保留现有条目及人工审核结果。保留数据应当作为明确要求，并在改动后验证。界面能够生成和修改，并不自动保证任何结构调整都能无损迁移旧数据。
保存扩展时，可以选择项目范围或个人范围。官方文档给出了两个位置。
| 使用范围 | 保存位置 | 用途 |
|---|---|---|
| 项目级 | .github/extensions | 随代码仓库提交，供团队共享 |
| 个人级 | ~/.copilot/extensions | 保存在本机，作为个人扩展复用 |
扩展通常包含描述元数据和依赖的package.json，以及定义行为的入口文件，例如extension.mjs。需要持久化的数据还可以保存在额外的 JSON 文件中，具体实现允许不同。扩展结构与保存位置
这也说明，“不用手写前端代码”描述的是创建体验，画布背后仍然有代码、依赖和数据处理逻辑。GitHub 在另一篇文章中将它描述为运行在应用内的小型全栈应用，并展示了调用第三方 API、操作本机工具等用法。作者也提到，复杂工作流的设计和自动化曾花去大半天时间。画布的实现与使用示例
如果希望画布读取 CI 结果或更新 GitHub 数据，就需要把相应的数据连接和操作逻辑做进去。生成了一个按钮，只能说明界面已经有了入口，还需要确认它实际执行了什么。
四、从现成扩展开始，减少重复搭建
除了自己创建，也可以在 Awesome Copilot 的 Canvas Extensions 目录 中寻找接近需求的社区扩展，再交给 Agent 调整。
例如，目录中的Artifact Explorer用于浏览 PR 和 GitHub Actions 产物，包括测试结果、静态站点、终端录制及源文件。对于需要集中查看构建产物的工作，可以先了解这个扩展的功能和使用要求。Artifact Explorer
如果需要从零定制，GitHub 的官方演示也提供了几个具体方向，包括用卡片处理 Issue、用可拖动和筛选的图展示代码结构，以及查看会话对应的 Git worktree。它们可以帮助你判断，手里的任务适合做成清单、看板，还是关系图。官方场景演示
第一次尝试，可以把范围收得很小。一个只有新增、编辑、审核和导出功能的发布清单，就足够检查 Canvas 是否适合自己的工作。等这条流程跑通，再加入跨会话数据、外部接口和更复杂的自动化。
能让下一次发布少翻几段聊天记录、少核对几次进度，这张画布就已经派上用场了。