摘要： GitHub 已把 Copilot cloud agent 深度接入 Slack。团队可以在频道、线程或私聊中通过 @GitHub 提交 Bug，上下文会被带入独立的 Slack Code 会话；Copilot 随后在受控云端环境中读取获准仓库、调查失败、修改代码、运行验证，并创建 Pull Request 供人审查。本文给出从权限准备、仓库配置、Bug 提示词到 PR 验收的完整流程，同时说明线程隐私、默认仓库、GitHub Actions 审批、分支保护和人工合并边界。适合已使用 Slack 与 GitHub 的开发团队立即小范围试点，但不建议让 Copilot 自动合并生产代码。
核心结论
现在可以直接在 Slack 中让 GitHub Copilot 调查 Bug、实现修复并创建 PR。正确做法不是把 Slack 当成远程终端，而是把它作为任务入口和协作界面：@GitHub 接收线程上下文，Copilot cloud agent 在 GitHub 管理的云端执行环境中工作，最终把代码变更送回 GitHub PR，由现有 CI、Code Owners、分支保护和人工审批决定是否合并。
- 值得使用： 尤其适合错误复现明确、影响范围有限、验收条件可写清楚的 Bug，以及测试补全、文档修正和低风险重构。
- 前置条件： 需要付费 Copilot 计划、启用 Copilot cloud agent、安装或升级 GitHub App for Slack，并连接个人 GitHub 账号；Business/Enterprise 还需要管理员开启相关策略。
- 最关键的提示词不是“修复它”，而是仓库、现象、预期、证据、范围、验证和禁止事项。 Slack 线程越杂乱，Agent 越容易带入错误上下文。
- Copilot 可以调查、改代码、验证并开 PR，但 PR 不是正确性证明。 生成结果仍需审查，敏感仓库应保留 Actions 审批、必需检查、Code Owners 与人工合并。
- 隐私边界必须提前确认。 官方文档说明，
@GitHub会捕获整个 Slack 线程作为任务上下文，并将相关上下文存入 Agent 生成的工件；敏感信息应改用私聊或先清理线程。
这项能力到底做了什么
GitHub 在 2026 年 8 月更新了 Slack 中的 Copilot 体验。用户可在直接消息、频道或线程中提及 @GitHub，让 Copilot 使用对话和获准的 GitHub 上下文回答代码问题、分类 Bug、更新或创建 Issue、调查失败、实现变更、验证结果并打开 PR。
官方把任务协作空间称为 Slack Code。当任务开始后，系统为它建立专用代码频道；团队成员可以在其中补充背景、观察进度和继续 Steering。建立 Slack Code 后，应在该频道中继续引导，不要在原始线程与专用频道之间分散新指令，否则上下文容易分叉。
这条链路可以概括为：
Slack Bug Thread
→ @GitHub / Copilot cloud agent
→ Slack Code session
→ permitted GitHub repository
→ secure cloud sandbox
→ investigation + code change + tests
→ Pull Request
→ CI + human review + merge decisionSlack 负责沟通与任务入口；GitHub 负责身份、仓库权限、分支、执行、PR 和审计。Copilot 并不是在 Slack 服务器里运行代码，也不应该从聊天消息中接收生产密钥。
使用前必须满足的条件
结论是：先完成组织策略、GitHub App 权限和仓库范围配置，再让团队在 Slack 中 @GitHub。否则常见结果是无法启动 Agent、选错默认仓库，或任务能分析却不能创建分支和 PR。
| 检查项 | 要求 | 常见问题 | 建议 |
|---|---|---|---|
| Copilot 计划 | Copilot cloud agent 面向付费计划 | 账号无 Agent 权限 | 先确认个人席位与组织策略 |
| 企业策略 | Business/Enterprise 管理员启用 cloud agent | 用户有 Copilot 但 Agent 被禁用 | 在组织/企业策略中启用 |
| Slack App | 安装或升级 GitHub App for Slack | 旧权限只支持通知与 PR 管理 | 审核新增权限后升级 |
| 账号连接 | Slack 中的 GitHub App 连接个人 GitHub 账号 | 无法识别仓库权限 | 首次使用按提示授权 |
| 默认仓库 | 设置默认 repository，或在提示中明确仓库 | PR 建到错误仓库 | 生产任务始终显式写 owner/repo |
| 仓库允许范围 | Repository owner 可排除仓库 | Agent 无法访问目标仓库 | 只开放试点仓库和必要范围 |
| CI 与保护规则 | 配置必需检查、审批和 Code Owners | PR 创建后缺少质量门禁 | 合并前强制测试与人工审批 |
如果 GitHub App for Slack 已经用于通知，但管理员不愿授予 Copilot 所需新增权限，旧功能仍可继续使用；Agent 功能是可选的。管理员应查看新增权限和数据处理边界，而不是无条件升级整个 Workspace。
第一步：安装并连接 GitHub App for Slack
实际界面可能随 GitHub 更新略有变化，但设置逻辑保持一致：
- 在 Slack Workspace 中安装或升级官方 GitHub App。
- 由 Slack 管理员审核 App 请求的权限。
- 确认 GitHub 侧已启用 Copilot cloud agent；企业账号检查组织或 Enterprise Policy。
- 在 Slack 中首次提及
@GitHub，按提示连接自己的 GitHub 账号。 - 设置默认仓库，但把它视为便利项，不作为生产任务的唯一仓库选择依据。
- 发送只读测试请求，例如询问某个公开模块的位置，确认身份与仓库上下文正确。
- 再选择一个低风险测试仓库，执行首次 Bug 调查与 PR 创建。
不要在公共频道粘贴 Access Token、Actions Secret、数据库连接字符串、客户数据或完整生产日志。GitHub App 使用自己的授权链路，Copilot 不需要用户把凭证写入提示词。
第二步：为仓库准备 Agent 可执行上下文
Slack 中的一段自然语言无法替代仓库内的工程说明。仓库应明确构建、测试、目录边界和安全规则，让同一规则同时服务 GitHub.com、IDE、Code Review 与 Slack 发起的 Agent 任务。
可以在 .github/copilot-instructions.md 中提供仓库级说明：
## Repository overview
- Application: Node.js 22 + TypeScript
- Package manager: pnpm
- Main source: src/
- Tests: tests/
## Required verification
1. Run `pnpm lint`.
2. Run `pnpm test`.
3. Run `pnpm build`.
4. Add a regression test for every bug fix.
## Change boundaries
- Do not modify database migrations unless the task explicitly requests it.
- Do not change authentication or billing code without human approval.
- Never add secrets, tokens, customer data, or production endpoints.
- Prefer the smallest change that fixes the reproduced failure.本文不重复泛讲 Copilot instructions 的全部写法。针对 Slack Bug 流程，最重要的是让文件回答四件事：如何复现、如何验证、哪些目录不能碰、哪些动作必须升级给人工。
还应保证 CI 的命令与说明一致。如果 Agent 在云端运行 pnpm test，而 CI 实际使用另一个脚本，Copilot 的“验证通过”可能与合并门禁不一致。
第三步：在 Slack 中提交一条可执行的 Bug 任务
最有效的请求应包含“事实包”，而不是只说“修复 Bug”。推荐在一个干净线程中先整理信息，然后提及 @GitHub。
@GitHub 请调查并修复 owner/repo 中的登录重定向 Bug，并创建 PR。
现象：
- 用户在 /login 登录成功后偶尔被重定向回 /login。
- 仅在 returnTo 参数包含查询字符串时出现。
预期：
- 登录成功后跳转到同源且允许的 returnTo。
- 非法或跨域 returnTo 必须回退到 /dashboard。
已知证据：
- 错误日志关键字：redirect_loop_detected
- 可能相关文件：src/auth/redirect.ts
- 相关测试：tests/auth/redirect.test.ts
任务要求：
1. 先复现并说明根因。
2. 实现最小修复。
3. 增加覆盖查询字符串与跨域输入的回归测试。
4. 运行 lint、test、build。
5. 在 PR 描述中列出根因、变更、验证结果与风险。
禁止事项：
- 不修改登录协议和数据库结构。
- 不降低现有 URL 安全校验。
- 如果证据不足，先报告，不猜测修改。这类提示词比“请查看上面的报错并修一下”更可靠，因为它把观察事实与实施假设分开，并给出验收标准。若线程里已经讨论过多个相互矛盾的方案，应在 @GitHub 前发一条最终结论，明确哪些是已否决方案。
默认仓库与目标分支
GitHub 官方文档说明，默认仓库会成为回答上下文，也是 Copilot 创建 Issue 或 PR 的默认位置。为了避免在同名仓库或 Fork 中操作，建议提示中写完整 owner/repo；如不能基于默认分支工作，也应明确 base branch。
整个线程会被读取
官方安全说明强调：在 Slack 线程中提及 GitHub 时，Copilot cloud agent 会捕获整个线程作为上下文，并将上下文保存在生成工件中。频道里若含客户数据、未公开漏洞或内部凭证，应先移到受限频道或改用直接消息，并删去不必要信息。
第四步：在 Slack Code 中跟踪与 Steering
Agent 创建专用 Slack Code 后，后续补充应只发在那里。有效 Steering 是增加验证信息或收紧范围，而不是每几分钟改一次目标。
推荐的跟进消息：
补充信息：该问题在 Node.js 22 可复现，Node.js 20 未观察到。
请保持当前范围，只比较 URL 解析差异，不升级依赖。请在提交修复前展示：
1. 失败测试如何复现旧行为；
2. 修复后测试结果；
3. 是否触及认证、Cookie 或跨域策略。不推荐的做法包括：在原线程继续给相反指令、让不同成员重复触发多个 Agent 会话、把另一个 Bug 临时塞入当前任务，以及要求 Agent 跳过测试直接开 PR。一个 Slack Code 会话最好只对应一个清晰目标和一个 PR。
第五步：审查 Copilot 创建的 PR
Copilot 完成任务后可以打开 PR，并把链接带回 Slack。此时工作并没有结束。审查者需要验证“修复了什么”和“没有破坏什么”。
建议按以下清单审查：
- 根因是否有证据。 PR 是否包含失败用例、日志或代码路径，而不是仅给合理猜测。
- Diff 是否最小。 是否出现无关格式化、依赖升级、配置变更或大范围重构。
- 测试是否先失败后通过。 新增回归测试能否在旧代码上暴露 Bug，而不是只验证新实现。
- 安全边界是否保持。 URL、认证、权限、输入、文件路径和外部请求是否仍经过校验。
- CI 是否真实运行。 区分 Agent 在会话中声称运行测试与 GitHub Checks 的独立结果。
- PR 描述是否可追溯。 应链接 Slack 任务、Issue 或错误记录，并说明未解决部分。
- 人工审批是否满足。 检查 Code Owners、Required Reviews 与 Branch Protection。
GitHub 官方说明，Copilot 生成的 PR 仍应彻底审查。如果仓库要求 PR Approval，提交任务的用户对 Copilot PR 的审批可能不计入所需审批数，仍需另一名审查者批准。团队应以实际仓库规则为准。
Slack 到 PR 的完整工作流
下面是一条适合企业小团队的标准操作链：
- 支持或研发人员在 Slack 线程整理 Bug 事实，删除敏感信息。
- 值班工程师确认仓库、影响、严重度和是否适合交给 Agent。
- 通过
@GitHub提交包含复现、范围、验证和禁止事项的任务。 - Copilot 建立 Slack Code，会话只处理当前 Bug。
- Agent 在许可仓库和云端环境中调查、修改并运行验证。
- 证据不足时，Agent 返回问题；团队补充日志或最小复现。
- Agent 创建 PR，并在描述中记录根因、变更和测试。
- GitHub 执行 Actions、静态扫描和分支保护门禁。
- 人工审查 Diff、回归测试、安全影响与部署计划。
- 由有权限的人员合并；生产发布仍遵循原有审批流程。
- 将 PR 与 Slack 线程、Incident 或 Issue 关联，保留审计链。
安全设置：哪些门禁不能取消
保留 GitHub Actions 人工批准
GitHub 关于 cloud agent 风险缓解的文档指出，Copilot PR 中的 Actions workflow 不会在无人批准的情况下自动运行，需要具有写权限的用户批准。这有助于阻止恶意 Issue、PR 或自动化链诱导 Workflow 执行危险代码。不要为了追求“全自动”取消这一保护。
限制网络、Secret 与 MCP 工具
Copilot cloud agent 可能通过配置使用 MCP 工具或其他开发服务。企业只应允许经过审核的 Server 和工具；GitHub 文档目前说明，cloud agent 的 MCP 支持存在能力与认证限制，因此不能假设 IDE 中可用的所有 MCP 配置都能原样用于云端 Agent。
不允许自动合并生产 PR
Agent 生成代码、Agent Review、CI 通过三者叠加，仍不等于人类责任可以移除。涉及认证、支付、权限、数据删除、迁移、生产配置和客户数据的修改必须由相应 Code Owner 审查。
Slack 线程最小化
只把完成任务所需的信息交给 Agent。生产日志应截取相关字段并脱敏；漏洞细节使用受限频道；Secret 通过 GitHub Secrets 或受控凭证系统提供，绝不粘贴进 Slack。
哪些 Bug 适合交给 Copilot
| Bug 类型 | 适合程度 | 原因 | 人工要求 |
|---|---|---|---|
| 明确失败测试 | 高 | 输入、输出和验收边界清楚 | 审查修复范围 |
| UI 文案或样式回归 | 高 | 影响范围通常较小 | 视觉验收 |
| 单模块空值/边界错误 | 高 | 易复现且可加回归测试 | 检查异常路径 |
| CI 配置小错误 | 中 | Agent 可读取日志，但可能影响供应链 | 必须审查权限 |
| 性能退化 | 中 | 需要基准与真实数据 | 人工验证 Benchmark |
| 并发或分布式故障 | 低到中 | 复现和因果链复杂 | 提供 Trace 与压测环境 |
| 认证、支付、IAM | 低 | 业务与安全风险高 | 专业审查、双人批准 |
| 生产数据损坏 | 低 | 需要现场证据和恢复决策 | Incident 流程优先 |
最适合的首批试点不是最严重的 Bug，而是“可复现、可测试、权限低、回滚容易”的问题。建立成功样本后，再扩展到更复杂任务。
常见问题与排查
@GitHub 没有启动 Copilot
先检查 GitHub App 是否升级、个人账号是否连接、Copilot cloud agent 是否对账号启用，以及组织策略是否允许。还要确认 App 在当前频道有权限、目标仓库没有被 owner 排除。
Copilot 使用了错误仓库
通常是默认 repository 与任务目标不一致。后续请求使用完整 owner/repo，并明确 base branch。已在错误仓库创建的任务不要强行迁移，结束会话后从正确仓库重新发起更容易审计。
Agent 只调查，没有创建 PR
不同入口的默认行为可能不同。GitHub 文档说明，从 Issue 指派通常会创建 PR；从普通 Prompt 开始时可能先在 Branch 上工作，再由用户要求打开 PR。Slack 提示中明确写“调查、实现、验证并创建 PR”，并在 Slack Code 中确认当前阶段。
Agent 看不到后来添加的上下文
Issue 指派场景中，Copilot 在指派时接收 Issue 标题、正文和既有评论，之后新增的 Issue 评论未必进入任务；官方建议把后续信息发到 PR。Slack 场景则应把 Steering 保持在对应 Slack Code 会话中。
PR 测试显示通过，但 CI 未运行
Agent 会话内的测试输出与 GitHub Actions Check 是两类证据。查看 PR Checks，必要时由有写权限人员批准 Workflow 运行；未出现独立 CI 结果时，不应把 Agent 自报的测试结果当作合并依据。
风险、限制与实施边界
- 功能与界面可能变化： Slack 新体验在快速演进，具体菜单、权限和 Slack Code 呈现以 GitHub 当前文档及 Workspace 实际界面为准。
- 上下文可能过多或错误： 整个线程会进入任务，闲聊、过期结论和敏感信息会降低质量并扩大数据暴露。
- Agent 可能错误归因： Copilot 能形成合理假设，但复杂 Bug 仍可能来自环境、依赖、竞态或外部系统，需要真实证据验证。
- 测试覆盖有限： Cloud sandbox 与生产环境不完全相同，网络、Secret、数据量和外部依赖差异会影响复现。
- 自动化链存在 Prompt Injection： Issue、日志、网页、依赖文档和 MCP 工具输出都可能包含恶意指令。工具权限必须最小化。
- 费用与额度： Copilot cloud agent 面向付费计划，模型请求可能计入相应使用量；具体套餐、Premium Request 规则和额度以 GitHub 当前定价与账号页面为准。
- PR 不应自动发布： 付款、删除、发布、发信、权限与生产数据库操作必须保留人工审批和隔离。
如需补充 GitHub Copilot 的仓库指令和 Agent 配置，可阅读 AI Stack Nav 的 GitHub Copilot 教程搜索。准备建设完整自动修复链路的团队，还可以查看 CI 自动修复与 PR 工作流专题。
事实依据与来源
- GitHub 官方已确认： Slack 中可通过
@GitHub启动 Copilot cloud agent，会话可调查、规划、写代码、创建 Issue 与 PR，并使用 Slack 对话上下文。 - GitHub 官方已确认： Agent 会创建专用 Slack Code；建立后应在该频道继续协作和 Steering。
- GitHub 官方已确认： 线程上下文会被捕获并存入 Agent 生成的工件；敏感任务可使用直接消息以限制上下文。
- GitHub 官方已确认： Copilot cloud agent 对付费 Copilot 计划开放；Business/Enterprise 用户可能需要管理员开启策略，仓库所有者可排除仓库。
- GitHub 官方已确认： Cloud agent 可在后台完成任务并创建 PR，但输出必须由用户审查；Actions 与分支保护仍承担安全门禁。
- 实施建议： 本文提供的 Bug 提示词、仓库说明、十一阶段工作流和审查清单不是 GitHub 强制格式，需要结合团队仓库与合规要求调整。
- 未进行第三方性能测试： 本文没有声称 Copilot 能将修复时间缩短某个比例，也不保证每类 Bug 都能自动修复。
FAQ
在 Slack 中使用 GitHub Copilot 需要什么套餐？
Copilot cloud agent 面向付费 Copilot 计划。Business 或 Enterprise 组织还可能要求管理员启用相应策略。实际可用功能、Premium Request 计费和额度以 GitHub 当前套餐页及账号 Usage 页面为准。
Slack 里应该提及 @Copilot 还是 @GitHub？
GitHub 官方 Slack 集成使用 @GitHub 作为入口。在直接消息、频道或线程中写 @GitHub 加任务描述，系统会根据账号连接与权限启动 Copilot cloud agent。
Copilot 会读取整个 Slack 频道吗？
官方明确说明的是：当你在 Slack 线程中提及 GitHub 时，Agent 会捕获整个线程作为上下文。不要因此假设它可任意读取所有频道；实际访问仍受 Slack App 权限约束。敏感任务应使用受限频道或直接消息。
Copilot 一定会自动创建 PR 吗？
取决于任务入口和指令。Issue 指派通常会自动创建 PR；普通 Prompt 可能先产生 Branch 或会话结果。在 Slack 请求中明确写“调查、实现、验证并创建 PR”，完成后检查返回链接和 GitHub PR 状态。
可以让 Copilot 自动合并 PR 吗？
不建议，尤其是生产仓库。保留 Required Checks、Code Owners、分支保护和人工批准。认证、支付、数据删除、IAM、发布和生产配置变更必须由责任人审查。
Copilot 能访问生产日志和监控系统吗？
只有在组织显式配置、授权相关工具且云端 Agent 支持相应集成时才可能访问。默认不要假设可访问。更安全的方式是向任务提供脱敏日志片段，或通过经过审核的只读 MCP 工具接入。
Slack 消息里的密钥会被 Copilot 使用吗？
不要发送密钥。线程会作为上下文进入 Agent 工件，任何 Token、密码、客户数据或生产连接信息都可能扩大暴露范围。Secret 应通过 GitHub Secrets 或企业凭证系统管理。
Copilot 修复 PR 是否还需要代码审查？
必须需要。Agent 可能误判根因、遗漏边界情况或引入安全问题。审查者应核对失败复现、Diff、回归测试、CI、安全影响和回滚方案。
最适合第一个试点的任务是什么？
选择一个能稳定复现、有明确失败测试、只影响单个模块、不涉及敏感权限且容易回滚的 Bug。不要用支付、认证或生产数据损坏作为首次试点。
参考来源
- GitHub Docs：Integrating Copilot cloud agent with Slack
- GitHub Changelog：The new GitHub Copilot experience in Slack
- GitHub Docs：About GitHub Copilot cloud agent
- GitHub Docs：Kick off a task with Copilot agents
- GitHub Docs：Risks and mitigations for Copilot cloud agent
- GitHub Docs：Review output from Copilot
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
