2026年10月23日，GitHub 在官方更新日志里宣布，Teams 里的新 GitHub 应用把通知与 Copilot 合并到了一起。团队不用再在两个应用之间切换：在频道、群聊或私聊里收到仓库动态后，直接在对话里 @GitHub，就能让 Copilot 去查问题、改代码并准备合并请求，最后仍由人审阅、测试再决定是否合并。
收到通知后，三步就能走到合并请求
第一步是收到通知：报错或动态出现在 Teams 频道、群聊或私聊里，团队在同一个对话里就能看到上下文，不用先跳回仓库翻记录。第二步是动手：@GitHub 后，Copilot 会调查问题、动手修复并创建合并请求，过程中它还能读到频道和话题历史，理解这次讨论到底在说什么。第三步是人来收尾：团队审阅合并请求、跑测试，确认没问题再合并——写代码的活交给 Copilot，拍板的活还留在人手里。
两类用户，11月16日之前要做的事不一样
如果你现在用的是旧版 GitHub 应用，11月16日它会被标为“GitHub (deprecated)”并停用，之前要在对话里删掉旧应用、装上新的 GitHub 应用。如果你现在用的是 GitHub Notifications 应用，做法是把应用更新到最新版，它会直接改名为 GitHub 并带上 Copilot 能力，已有的通知功能会继续工作。全球推广从10月中旬开始，预计11月中旬完成，所以同一团队里有人先看到新应用、有人还没看到，也属正常，不必反复重装。
这次改动真正省掉的是什么
省掉的不是写代码本身，而是上下文切换：以前通知在一个应用、Copilot 在另一个应用，问题、讨论和修复各在各处；现在通知、讨论和修复请求出现在同一条对话里，Copilot 还能顺着话题历史往前翻，少了很多“把链接和背景再贴一遍”的体力活。但这不等于把发布交给模型：Copilot 的能力需要符合条件的 Copilot 许可，部分能力还在逐步放开，合并前的人工审阅和测试不能省。真正适合先用起来的，是那些报错清晰、改动范围可控的日常问题；涉及核心架构或敏感权限的改动，仍应走团队原有的评审流程。
