GitHub in Slack and Teams：支持多仓库，改进对话上下文利用

1. 仓库不同，对话仍可继续

GitHub 在 2026年10月15日的更新日志中宣布支持多仓库。仓库是集中存放项目代码和变更历史的空间。此次改进允许用户在一次对话中请求处理位于不同空间的任务。

例如，即使界面代码和服务器代码位于不同仓库，也可以请求同时检查两者以调查缺陷。关键在于对话不再局限于单个仓库，而不是将多个仓库合并为一个。

2. 从创建议题到查看拉取请求

原文给出了四种使用示例。第一种是在指定仓库中创建议题，以跟踪对话中提到的缺陷，并利用该对话的上下文。这是将讨论内容转化为工作项的例子。

第二种是修复界面仓库中的缺陷并发起拉取请求。拉取请求是将修改后的代码提交供审查、以便后续合入项目的提议。这里通过一次请求串联代码修改与审查请求的创建。

第三种是汇总自己在多个仓库中发起的拉取请求，并指出需要关注的项目。第四种是结合界面和服务器仓库的代码调查议题。这两种示例分别用于查看分散的工作，以及排查跨仓库的问题。

3. 调用位置和 Slack 上下文利用方式也有变化

在消息中调用 GitHub 的位置也更加灵活。现在不仅可以在消息开头，还可以在任意位置提及 @GitHub。原文还说明，此次改进让对话中的仓库切换更加便捷。

在 Slack 中，共享的消息和串联对话的线程可以用作任务上下文。这减少了为重新说明此前讨论而复制粘贴细节的麻烦。不过，原文并未说明 Teams 是否也提供同样的上下文利用功能。

4. 改进任务启动和中断后的恢复

GitHub 表示，已在这两款通讯工具中减少错误、改进任务启动，并优化中断后的任务恢复流程。这些可靠性改进与多仓库支持一同发布。

不应将这一说明理解为任务必定能不中断地完成。原文没有给出错误减少幅度、任务启动时间或恢复成功率等数据。因此，可以了解改进方向，但没有依据通过数值比较速度或稳定性的提升程度。

5. 需同时考虑切换负担和审查范围

好处在于减少了为不同仓库切换对话的负担。尤其在需要联合检查多个仓库代码的调查中，相关请求可以保持在同一对话流程中。Slack 对话上下文的利用还能进一步减少重新传达此前讨论的工作。

不过，一次处理多个仓库的便利性与结果审查范围需要分开考虑。团队不仅应衡量减少对话切换的收益，也应考虑核查请求对象与结果分别属于哪个仓库的负担。

原文没有说明一次对话可处理的仓库数量上限、切换仓库的具体操作方式，以及套餐与计费范围。考虑采用时，需要另行确认这些实际使用条件。

此次改进的核心是将多个仓库的任务串联到一次对话中；决定是否采用时，应同时衡量切换的便利性与审查任务范围的负担。