GitHub 在 2026 年 9 月 10 日的 Copilot 周更里宣布：Copilot 应用引入 Jira 集成。官方原话是把 Jira issue 放进共享 canvas，由你选择哪些继续往下走，再让 Copilot 把这条上下文带进调查、实现和 PR 准备。同屏安装位还有 Azure DevOps 和 Microsoft Foundry。这和 2026 年 6 月已 GA 的 “GitHub Copilot for Jira”（在 Jira 里把工单指派给云端 Agent）不是同一条产品线：这次是工单进入 Copilot 应用的画布，而不是 Jira 里的指派按钮。
对一边盯 Jira 看板、一边在 GitHub 写代码的人，摩擦是上下文搬运：标题能复制，验收标准和评论线程经常丢。本文只写 Copilot 应用这条 canvas 路径改变了哪一步，以及它还不能替代什么。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么
周更把 Copilot 应用的更新写成一句话工作流：Turn Jira issues into action。操作顺序是：工单进入共享 canvas → 人挑选哪些继续 → Copilot 在后续调查、实现和 PR 准备中沿用该上下文。截图落在应用的 Customize → Canvas 标签，说明 Jira 是以可安装的 canvas / 插件卡片出现，而不是编辑器里的一条 slash 命令。
GitHub 文档把 canvas 定义成“共享的、可交互的工作产物表面”，用来承载计划、看板、仪表盘、清单这类工件；做好的 canvas 出现在应用右侧栏。关键行为是双向：Agent 工作时可以改 canvas，你也可以在同一块表面上编辑。人用 UI 控件，Agent 用同一份数据上的可调用动作。Azure DevOps 插件被文档写成“安装后得到一块用于规划和跟踪 Azure DevOps 工作的 canvas”。Jira 出现在本周 Changelog 的安装位上，但 canvas 扩展文档正文尚未点名 Jira——写集成细节时要以 Changelog 为准，不要把 Azure 文档句式原样套到 Jira。
同一张截图把 Azure DevOps、Microsoft Foundry 和 Jira 并排放，说明 GitHub 把外部工单/项目系统接到 Copilot 应用的方式，是“先装 canvas 扩展，再在右侧栏共事”，而不是给每个系统单独做一套聊天命令。Foundry 出现在安装位上，也不等于本周公告解释了 Foundry 画布的字段；本文事件只取 Jira 这一条。
自定义路径仍然通用：会话里运行 /create-canvas，说明人和 Agent 各自做什么。团队副本放 .github/extensions，个人副本放 ~/.copilot/extensions，常见文件是 package.json 和入口脚本。这能做自建看板，但不能证明 Jira 官方 canvas 的字段映射已经写进这份文档。
一条从工单到 PR 准备的场景
输入是 Jira 里已有的 issue，而不是你在聊天框里复述的一句话需求。安装 Jira canvas 后，工单出现在共享表面上，你可以勾选本轮要做的几条——官方强调 choose what moves forward，默认不是“看板有什么就全做”。选中的上下文进入同一会话的调查和实现阶段，再带到 PR 准备，减少“聊天里的目标和工单里的验收标准不是同一份”的漂移。
交付物仍是 GitHub 上的改动和 PR 草稿，外加右侧栏那块还在更新的 canvas。因为表面双向，Agent 把任务标成进行中或补检查项时，你能直接改，而不必另开一条“纠正 Agent 状态”的 prompt。反馈在两处：canvas 上的工件状态，以及随后的调查/实现输出。Changelog 没有写会自动改 Jira 工作流状态或自动合并 PR。团队副本放进仓库的 .github/extensions 后，其他人拿到的是扩展定义，不是你这次会话里勾选过的那一组 issue。
为什么这会改变工作流
过去 Copilot 接 Jira 主要有两条：在 Jira 里把 issue 指派给云端 Agent（6 月 GA 的 Copilot for Jira），或在 IDE 里粘贴 issue 链接。前者的主场在 Jira，后者的上下文是一次性附件。Canvas 把主场搬到 Copilot 应用：工单列表变成和 Agent 共用的工作表面，挑选动作留在人手里，后续编码阶段不再重新解释需求。
它和 Azure DevOps、Foundry 放在同一安装排，说明 GitHub 把“外部工单系统 → 共享表面 → 编码会话”当成 Copilot 应用的一类扩展，而不是给 Jira 单独做编辑器插件。因果是：上下文生命周期从聊天记录，变成一块可安装、可双向编辑、可沿用到 PR 准备的工件。人少做的是复制粘贴；人多做的是在 canvas 上做优先级裁剪。
限制与人接管点
周更没有写计划档位、操作系统或是否 Preview。文档也没列 canvas 的产品级限额。因此不能写成“所有 Copilot 计划、所有系统开箱即用”，只能写成：入口在 Copilot 应用的 Canvas 标签，下载页由 Changelog 给出。Jira 官方 canvas 的字段、权限、是否回写 Jira 状态，本周公告没有逐项展开。
不要把它和 Copilot for Jira 混用成一次升级。Jira 里指派云端 Agent、进度打回流、从 Jira 里转向会话，仍是 6 月那条产品。也不要把 /create-canvas 理解成已经带了 Jira API：那是自建扩展。人应接管：哪些 issue 进入本轮（choose what moves forward）、canvas 上 Agent 改写的状态是否符合看板规则、以及 PR 准备完成后是否还要回 Jira 关单——公告没有承诺这一步自动化。若组织的工单权限、字段和状态机很严，先用一条非生产 issue 看 canvas 实际拉到哪些字段，再决定要不要把迭代规划搬过去。
Changelog 把后续阶段写成 investigation、implementation、and pull request preparation，没有写测试、代码审查或合并。因此 canvas 解决的是“需求从哪来、怎么被选中、怎么跟着编码会话走”，不是一条自动交付流水线。双向编辑也带来新的冲突面：人和 Agent 同时改同一块表面时，以谁为准要靠团队约定，公告没有给冲突策略。
如何试用
从 Changelog 给出的 Copilot 应用页面安装客户端，打开 Customize 的 Canvas 标签，找 Jira 安装卡片。装好后把 issue 放上共享表面，先只选一条做调查和 PR 准备，看上下文是否在后续步骤里还在。需要理解 canvas 通用机制时，读 Working with canvas extensions；不要用 Azure DevOps 的句子去填 Jira 的未知行为。若团队已经在用 Copilot for Jira，把它当成另一条入口，而不是替换开关。本周周更里 JetBrains 沙箱和企业权限、VS Code Automations、CLI HydraFusion 都是并列条目，不要和 Jira canvas 拼成同一事件。
信息来源
- GitHub Changelog：GitHub Copilot weekly releases — September 7（2026-09-10）
- GitHub Docs：Working with canvas extensions in the GitHub Copilot app
- GitHub Changelog：GitHub Copilot for Jira is now generally available（2026-06-25，用于区分产品线）
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
