8 月 21 日，GitHub 干了一件不大不小、但方向感很强的事：把 Copilot 的智能体能力搬进了 Slack 和微软 Teams。
从此以后，AI 编程不再只是一个人对着编辑器的事。在你们团队的聊天群里 @ 一下 GitHub，它就能查代码、修 bug、开 PR，整个线程的人都看得见、能指挥。这篇文章把功能细节、团队到底该怎么用、有哪些坑一次讲清楚。
一、到底更新了什么
简单说，GitHub 在 8 月 21 日同一天发布了两个公测：Copilot in Slack 和 Copilot in Microsoft Teams。核心玩法是一样的——在对话里 @GitHub 就能起一个 AI 智能体会话。
它能做的事包括：
回答代码问题。 直接问”主分支的夜间构建为什么挂了”，它会结合仓库和 GitHub 活动数据给出答案。
自动分流 bug。 把一段报错堆栈丢给它，它能 triage bug 报告、更新已有 issue、甚至自动创建并打标签新 issue。
沙箱里干活。 它能在安全的云沙箱里调查失败原因、实施代码修改、自己验证结果，不用碰你的本地环境。
直接开 PR。 改完代码它会开一个 pull request，并且把对话链接附上，审阅的人点进去就能看到整个来龙去脉。
整个过程是异步的：你开会、通勤、干别的，它在后台继续跑。你随时可以在 Slack 里指挥它，然后回到终端、IDE 或 Copilot 应用里接着处理它开出的 PR。
这里有个很关键的配套动作：Slack 同期上线了”Code 频道”这种新频道类型，专门给 AI 智能体干活用，GitHub 是首发合作方之一。Copilot 可以在里面开一个专属代码频道，团队所有人能看到它执行的每一步——计划、代码 diff、HTML 预览，都能实时看，还能随时加入补充上下文、调整方向或者叫停。Claude Code、Devin、Vercel Agent 也同期接入了，ChatGPT 标注”coming soon”。
二、这件事为什么值得关注
因为它的信号意义大于功能本身：AI 编程正在从”单人工具”变成”团队公共资源”。
过去一年，AI 编程的核心场景是这样的：一个开发者打开 Cursor 或者 Claude Code，把任务丢给 agent，等它出 diff，自己审，自己决定下一步。很好用，但有个问题——它永远是私人的。团队的其他人看不见 agent 在干什么，也参与不了，所有 AI 相关的工作流都藏在个人终端里。
Copilot 进 Slack 和 Teams，等于把这层壳捅破了：对话本身就成了任务上下文，聊天室就成了 AI 的工作台。
以前一个 bug 从被发现到被修复的链路是：销售在群里反馈 → 客服记录 → 产品建 issue → 补充上下文 → 开发问细节 → 终于开始查。现在这条链路被压缩成了：群里 @GitHub → AI 直接查、改、开 PR → 全程大家看得到。
GitHub 自己的表态也很直接：”人类定方向，智能体收尾，这在开发者工作的任何地方都必须成立。”说白了，AI 不是取代谁，而是把你原来要搬来搬去的活，就地消化了。
三、团队到底该怎么用
我建议按这个顺序落地：
先搞清楚门槛。 Slack 版只对 Copilot Business 和 Enterprise 计划开放，Teams 版任何付费 Copilot 计划都能用。消耗的是你们已有的 Copilot 额度和 AI credits，云端沙箱单独计费。前提是管理员先在组织里开启 Copilot 云智能体策略。
从低风险仓库试水。 别一上来就让它改生产代码。先拿内部工具、测试脚本这种项目，让团队体验”群里 @ 一下，AI 出 PR”的完整流程，把信任建立起来。
把审批链设好。 仓库管理员可以要求：凡是 Copilot 账号身份开的 PR，合并前必须额外人工审批。这个建议默认开启——AI 干活再快，也挡不住它偶尔跑偏，人在环里不能省。
注意权限边界。 只有对仓库有写权限的人才能触发代码修改，其他人只能看和补充意见。PR 归属的是 Copilot 应用身份，不是某个人，出问题追责时要有心理准备。
四、有哪些坑
最大的坑是隐私和上下文噪声。
GitHub 官方文档明确写了：你在群里 @GitHub 时，整个线程都会被当作任务上下文抓取，还会存进它生成的工作产物里。这意味着你们在群里吐槽过的、聊跑题的、半成品想法，全都会被 AI 看到。团队要先立规矩：哪些频道可以 @，哪些内容不能出现在被 @ 的线程里。
其次是提示词质量。聊天群里的需求往往是模糊的：”这个页面好像有点问题””用户说登录老失败”。AI 不会自动帮你把模糊需求变清晰，你丢进去什么质量的上下文，它还给你什么质量的产出。所以”谁有资格 @GitHub”、”什么任务可以从群里发起”，最好提前定清楚。
再有就是别指望它替代 IDE。Copilot 在聊天里的强项是交接和协作：把讨论变成 issue、把失败变成 PR。但真正高强度的多文件编辑、复杂重构，它还是不如你在 Cursor、Claude Code 或 Codex 里来得顺手。它是补充，不是替代。
五、老达点评
我看这件事，最在意的是它把”AI 编程”这件事从个人技能变成了团队基础设施。
以前团队里 AI 用得好不好，取决于有没有一两个”玩得转的人”；以后会取决于你们有没有一套”大家都能指挥 AI”的协作方式。Copilot 进聊天室，等于把 AI 的遥控器从少数人手里，发到了全队手里。
对国内团队来说，Slack 和 Teams 未必是你日常用的工具，但这个趋势是相通的：企业微信、飞书、钉钉里长出来的 AI 办公能力（我之前写过企业微信开放 CLI 和 MCP，也横评过办公 Agent 大战），走的都是同一条路——AI 要长在大家已经待着的地方，而不是逼大家去一个新产品里找它。
我的建议很简单：如果你团队在用 Slack 或 Teams，先开个低风险仓库试两周，把”群里 @ 一下，AI 出 PR”的流程跑通，再谈推广。AI 编程的下半场，拼的不是谁能调出更好的 prompt，而是谁的团队能把 AI 用成公共资源。
