@GitHub 进 Slack 与 Teams 正式可用：在对话里查 Bug、开 PR
GitHub 2026-11-06 宣布 @GitHub 在 Slack 与 Teams 正式可用：对话里查缺陷、建 issue、改代码、开 PR；Teams 新增 Canvas，AI 产出的 issue 与 PR 标注来源对话。
2026-11-08 · GitHub Changelog（官方原文，2026-11-06，一手）
发布 2026-11-08核实 2026-11-08要点
- 2026-11-06，
@GitHub在 Slack 与 Teams 正式可用（GA）：在对话里直接排查缺陷、创建 issue、实施改动、开 pull request。 - 🆕 Teams 侧新增 Canvas：实现方案、代码改动、预览可以贴在对话旁边一起审，评审讨论不必跳出 Teams。
- 🆕 从消息里自动识别仓库：不用每次手动选 repo，会话直接起；官方同时简化了未登录、无默认仓库、需切仓库、需应用授权这四种卡点的流程。
- 🆕 来源可追溯：
@GitHub创建的 issue 与 PR 会在描述里标注「Created from a Slack/Teams conversation with @username」。 - 修掉一个会让跟进消息没有响应的缺陷——此前对话一旦断在追问上，工作就得重开。
- 入口：
slack.github.com/teams.github.com。官方本条没有列出支持的计划、仓库数、并发会话或计费口径。
为什么这条比它看起来更重要
「在 Slack 里让机器人建个 issue」不是什么新能力——几年前就有社区机器人干这事。真正变的是执行位置：以前 IM 里的机器人只能转发指令给人，或者调用一个受限的 API；这次 @GitHub 能直接改代码、开 PR，也就是把 Copilot Coding Agent 的执行链挂到了 IM 的对话流上。
这带来三个可观测的变化：
① 需求入口从「issue 表单」变成「一段聊天」。 官方给的场景是排查缺陷、实施改动、开 PR——这些动作此前需要有人在本地 IDE 或 GitHub 界面上做。当入口变成聊天，提需求的人不再需要会写 issue 模板，但「需求是否描述清楚」这件事就没人把关了。 由 @GitHub 反向从消息里猜仓库，也说明它预期输入是「随手一句话」。
② 沉淀物变了。 对话里的结论如果只留在 Slack，三个月后没人找得到；这次强制在 issue / PR 描述里写「来自与 @username 的 Slack 对话」，等于给 AI 产出加了一条血缘。这是这次更新里对工程组织最有价值的一条，比 Canvas 更实用。
③ Teams 有了 Canvas，Slack 没有。 官方只给 Teams 加了「在旁边审阅方案与预览」的能力。同一功能在两个 IM 上不同步，通常意味着两边的集成深度不一样——Slack 侧目前更像是「会话入口」，Teams 侧开始有「评审台」的意思。
与另外两条常驻化路线的位置
2026 年下半年，把 Agent 塞进人已经在用的地方成了主线，但落点完全不同：
| 路线 | 代表 | 触发方式 | 产物落在哪 |
|---|---|---|---|
| IM 内执行 | @GitHub（Slack / Teams） | 人在对话里 @ 它 | 仓库里的 issue / PR |
| IM 内常驻待命 | Copilot Automations、Coze 类平台 | 定时 / 事件 / 24 小时在线 | 平台自己的任务与产物 |
| 独立常驻 Agent | Claude Duet、OpenAI Dots、Perplexity Teammates | 给一个长期职责 | 各自的云虚拟机与工作区 |
三者的差别不在模型，在**「谁来验收」**。第一类的验收点天然落在 PR review 上，是最容易被现有流程吸收的一种；第三类要新建验收习惯，所以定价也最贵（$20 到 $200 一个月不等）。
对团队的实际影响
- 已经在 Slack 里做 on-call 的团队受益最直接：故障排查的上下文本来就在频道里，现在可以把「查完顺手修」留在同一个地方。但要防止「聊天里改生产」——PR 仍是闸门，别让自动合并绕过它。
- 需要补一条规范：
@GitHub从消息猜仓库，猜错仓库的代价是往错的 repo 开 PR。多仓库、名字相近（web/web-admin）的组织，建议在频道里显式写全owner/repo。 - 计费口径不明：这类对话式执行通常按 Copilot 的 AI credits 走，但官方本条没写。在拿到明确口径前，别把它放进「免费」的心理账户。
AI 之家 观点
一、这条更新的战略含义大于功能含义：GitHub 承认「开发者已经不在 GitHub 里工作」了。 代码在 GitHub，讨论在 Slack / Teams，评审在 PR——三者分离多年。Copilot 最初把 AI 塞进 IDE，是因为开发者在那儿；这次塞进 IM，是因为需求的源头在那儿。先占住需求的入口，比先占住写代码的位置更值钱。
二、来源标注是这次最该被抄的设计。 「Created from a Slack/Teams conversation with @username」这句话，解决了 AI 产出最难回答的问题：这条 issue 是谁让谁做的。没有这句话，半年后回看仓库，一堆 issue 无法归因到人和对话。建议所有接入 AI 生成内容的工作流都照抄这个模式——不是写「AI 生成」，而是写「谁在什么场景下让 AI 做的」。
三、但「从消息猜仓库」是个需要盯着的自动化。 便利性与准确性在这里直接冲突：自动识别省了一次点击，猜错却要花时间收拾（错误的 PR、错误的 issue、错误的通知对象）。官方的兜底是让人在会话开始前确认仓库，但很多人的习惯是「先让它跑起来」。这类默认行为上线后，最常见的投诉不会是「不好用」，而是「它动了不该动的仓库」。
四、给团队的三条动作：① 把 PR 闸门守死，IM 入口只产出 PR，不产出合并；② 在多仓库组织里要求显式写 owner/repo；③ 等官方补计费口径后再推广，别按「免费」做预算。
待核实
- 支持哪些 Copilot 计划（Free / Pro / Business / Enterprise 是否都能用），官方本条未列。
- 计费与额度：一次会话消耗多少 AI credits，是否计入 Copilot 套餐限额。
- 权限继承：
@GitHub用的是发起人的权限还是应用安装的权限——决定它能碰到哪些仓库。 - Slack 侧是否也会上 Canvas，官方只说 Teams 有。
- 对话与会话的留存期，以及审计日志能否导出。
相关阅读
- GitHub Copilot 工具卡
- Copilot 代码审查开始可编程治理
- Copilot Automations 转为共享并自我改进
- Copilot 进 JetBrains Air：云端任务的三个治理缺口
来源
常见问题
@GitHub 在 Slack 和 Teams 里能做什么？
官方表述是「把对话变成代码」：调查缺陷、创建 issue、实施改动、开 pull request，全在对话内完成。Teams 侧另有 Canvas，可在对话旁边审阅实现方案、代码改动与预览。
支持哪些计划，额度怎么算？
该条 Changelog 只写了「generally available」与两个入口地址（slack.github.com / teams.github.com），没有列出支持的 Copilot 计划、仓库数量、并发会话数或计费口径。这些需要另行查文档，本站不推断。
AI 建的 issue 能看出是从聊天里来的吗？
能。官方写 @GitHub 创建的 issue 与 PR 会在描述里带上「Created from a Slack/Teams conversation with @username」，这是这次更新里对审计最有用的一条。