在 Teams 对话中用 Copilot 推进代码修复

GitHub 把 Teams 里的通知和 Copilot 接到了一起：收到 issue 通知后，可以直接在聊天中 @mention GitHub，让它调查问题、修复 bug 并创建 pull request，再由团队审核、测试和合并。

这次更新的价值，是把「看到问题」到「发起修复」的入口放进讨论现场。另一个需要关注的变化是应用整合：现有 GitHub notifications 用户需要更新，旧版 GitHub app 用户则要迁移。

从收到通知到提交修复，哪些步骤交给 Copilot

原文给出了一条明确的操作链：

1. 一条 bug 报告通知进入 Teams。
2. 用户通过 @github 发起处理，由它调查 issue、修复 bug，并创建 pull request。
3. 团队审查修改、运行测试，然后合并修复。

通知可以出现在频道、群聊或私聊中。团队不必先结束讨论，再切换到另一个入口发起修复任务。

这里的 pull request，可以理解为一份等待团队检查和合并的代码修改提案。Copilot 负责把问题推进到待审查的代码，最终审核、测试和合并仍由团队完成。

不过，原文展示的是产品工作流程，没有提供真实案例、修复成功率或耗时数据。它也没有说明调用时需要补充哪些信息、复杂问题如何处理，以及生成的修改能否自动通过测试。「更快交付代码」是这次更新的目标，还不能据此判断实际能快多少。

已经装过 GitHub 应用，应该更新还是迁移

这次公告涉及两条不同的升级路径，不能只看应用名称里有没有 GitHub。

如果安装的是 GitHub notifications，它现在对应新的 GitHub app in Microsoft Teams。原文要求更新到最新版本，并明确说已有通知能力会继续工作，但没有给出具体版本号。

如果使用的是 legacy GitHub app，则需要安装整合后的 GitHub app。旧应用将改名为 GitHub (deprecated)，并于 11 月 16 日退役。原文没有注明年份，不能自行补上。

在整合后的应用里，用户需要提及 @GitHub，按照提示连接 GitHub 账户并选择仓库。这一步把聊天中的请求关联到具体代码库。

原文在流程示例中使用 @github，在账户连接说明中使用 @GitHub，没有解释大小写差异，也没有列出额外命令或参数。实际操作应以 Teams 中应用的提示为准。

我的判断

我认为这个方向合理：issue 通知原本只是提醒，现在可以成为发起修复的入口。对于已经在 Teams 里讨论问题的团队，它有机会减少从消息跳转到任务处理的操作。

但入口更近，不等于修复更可靠。

相比收到通知后手动打开仓库、在 IDE 中使用 Copilot，这种方式把任务发起环节搬进了聊天。原文没有对照数据，无法证明它在复杂问题、代码质量或总耗时上更有优势，连作者实测的结果也没有提供。

它的适用前提同样明确：团队使用 Teams，代码在 GitHub，并愿意从聊天里启动代码任务。原文没有交代套餐、权限和仓库访问条件，因此不能把这条公告理解为所有账户安装后都能直接使用。

能拿来做什么

• 如果团队已经订阅 GitHub 通知，先确认装的是 GitHub notifications 还是 legacy GitHub app，再分别执行更新或迁移，避免漏掉旧应用的退役安排。
• 可以选择一个描述清楚、容易验证的前端或 Node bug，按「通知、提及 GitHub、生成 pull request」走一次流程，检查修改是否解决问题，并记录实际耗时。
• 把生成的 pull request 纳入现有审核流程，由团队检查代码、执行相关测试并决定是否合并，保留原文流程中的人工验收环节。