GitHub Copilot 进入 Teams：通知里 @GitHub 就能修问题并开 PR

GitHub 于 2026 年 10 月 23 日在官方 Changelog 说明，原名「GitHub notifications」的 Teams 应用已升级为整合版 GitHub 应用：用户在频道、群聊或私聊中收到 issue 通知后，@GitHub 即可让 Copilot 排查问题、修复并创建拉取请求；旧的 GitHub 应用将改名为「GitHub (deprecated)」并于 11 月 16 日退役。

这次发布的是什么

GitHub 于 2026 年 10 月 23 日在官方 Changelog 发布一条改进说明：原先名为「GitHub notifications」的 Microsoft Teams 应用改版为一个整合版 GitHub 应用，把通知与 Copilot 接到了一起。官方给出的流程是：bug 报告进到 Teams 之后，在会话里 @GitHub，Copilot 就会去排查这个问题、修掉它并创建拉取请求，团队再评审、测试与合并。

官方同时给了迁移安排：如果已经在用旧的 GitHub notifications 应用，更新到最新版即可，原有通知能力照常；如果用的是更老的那一个 GitHub 应用，它将被改名为「GitHub (deprecated)」并于 2026 年 11 月 16 日退役，届时需要改用整合版应用才能继续在 Teams 里用 Copilot。

这条说明的官方分类是「Improvement」而不是「Release」，也就是说它是在已有应用上的能力扩展，而不是一个新产品。

可用性与限制

• 形态：2026 年 10 月 23 日在官方 Changelog 公布，更新 Teams 侧应用即可使用。
• 入口：在 Teams 的频道、群聊或私聊里收到通知后 @GitHub，并按提示连接 GitHub 账号、选择仓库。
• 前置条件：需要在 Teams 侧安装整合版 GitHub 应用；此前装过 GitHub notifications 的直接更新即可。
• 迁移期限：旧的 GitHub 应用将于 2026 年 11 月 16 日退役。
• 计划要求：官方这条说明没有写明该能力对应哪个 Copilot 套餐，也没有提到额外的管理员开关，可用范围以 GitHub 官方文档为准。
• 权限边界：@GitHub 之后 Copilot 会实际去改代码并开 PR，能访问哪些仓库由所在组织的权限设置决定。

主要功能

• 在 Teams 通知里直接呼叫 Copilot
• 让 Copilot 排查 issue 并给出修复
• 自动创建拉取请求交给人评审
• 支持频道、群聊与私聊三种会话
• 用整合版应用替换两个旧应用
• 保留原有的仓库通知能力

技术原理

官方这条说明本身很短，能确认的技术细节有限，因此只说文档写明的部分。

整合后的 Teams 应用承担两个角色：一是把仓库事件按原有的订阅规则推送到指定会话；二是在会话中识别对 GitHub 的提及，把上下文交给 Copilot 的编程能力去处理。这解释了官方描述的三步流程 —— 收到通知、在会话里触发、Copilot 产出拉取请求 —— 中间没有要求用户切到另一个界面。

从权限角度看，触发之后 Copilot 是在用户选定的仓库范围内活动，所以「连账号、选仓库」这两个步骤不是可选项：它直接决定 Copilot 这次能读什么、能改什么。官方也把最后一步留给了人，说明里写的是团队评审、测试与合并。

至于 Copilot 在 Teams 侧具体用哪个模型、走哪条执行路径、是否与网页端或 IDE 端共用同一套后台，官方在这条说明里没有展开，本文不做推测。

实际体验

本文未做实测，因为官方说明只有一页。以下是可以逐条核对的要点。

其一，迁移动作是有截止日期的：11 月 16 日之后旧应用退役，只装旧应用的用户会失去在 Teams 里继续使用 Copilot 的入口。官方给出的做法是装整合版应用，然后按提示连接 GitHub 账号并选择仓库。

其二，工作方式上它更像是「在通知现场直接派活」：通知本身提供上下文，触发动作提供指令，所以适合那些本来就靠 Teams 沟通、issue 一到就想推进的团队。相比之下，需要在多个仓库之间做统一审阅的团队，仍旧更适合用代码托管平台的界面或命令行。

其三，官方这条说明里没有写套餐要求、区域限制、是否需要管理员先开权限，也没有给出响应时延与实际准确率的任何口径。这些都需要在自己的仓库上验证，不能照搬别处的说法。

项目地址与获取方式

• 官方更新说明：https://github.blog/changelog/2026-10-23-turn-notifications-into-code-with-github-copilot-in-teams/
• Copilot 更新汇总：https://github.blog/changelog/2026/?label=copilot
• Copilot 官方文档：https://docs.github.com/en/copilot
• 请通过 GitHub 官方应用商店与官方仓库获取，避免使用第三方分发的客户端。

适合谁用

• 日常在 Teams 里追 issue 的研发小组：通知即入口，省掉切窗口这一步
• 已经在用 GitHub notifications 的团队：更新应用即可，不影响原有通知
• 想把「收到反馈到出修复」这段链路压到最短的人：Copilot 负责改与开 PR，人只做评审
• 不必用：仓库管理集中在 GitLab、Gitee 等其他平台，或根本不用 Teams 的团队 —— 这次更新只覆盖 GitHub 生态内的 Teams 入口

常见问题

已经装了旧应用还需要做什么？

装过 GitHub notifications 的，更新到最新版即可，原有通知能力照常工作；装的是更老那一个 GitHub 应用的，它会被改名为「GitHub (deprecated)」并于 11 月 16 日退役，需要改用整合版应用才能继续用 Copilot。

一定要选仓库吗？

是。官方流程里，触发之后需要按提示连接 GitHub 账号并选择仓库。这个选择直接决定 Copilot 这次能读到什么、能改什么，选错范围会直接影响它给出的修复。

Copilot 生成的改动能直接合并吗？

不能自动合并。官方流程写的是 Copilot 排查问题、修复并创建拉取请求，之后由团队评审、测试与合并。

需要哪个 Copilot 套餐才能用？

官方这条更新说明没有写套餐要求，也没有提到额外的管理员开关或区域限制，可用的计划与组织策略以 GitHub 官方文档和所在组织的管理员设置为准。

相关工具与内容

• GitHub Copilot 工具页
• GitHub Copilot 深度评测
• AI 编程
• AI 工作助手
• GitHub Copilot 用量指标开始显示自建 skill、Agent 与 MCP 服务器的名称