先明确任务与结果
先列明仓库、时间范围、已知现象和只读排查目标，要求结果逐项链接到 issue、PR 或代码证据，再决定是否发起修改。官方文档仍把相关集成标为公开预览；多仓库支持不会取消账户、应用和仓库权限要求。
本次变化扩大了上下文，但没有替你确定任务边界
GitHub 10月15日更新说明，在 Slack 与 Microsoft Teams 的同一对话中可以跨多个仓库工作，并改进了提及方式与上下文体验。对本篇场景来说，价值是前后端线索可以放在一次调查中比较，而不必先把它们误认为同一个仓库。
这是一篇实操设计指南，不是我们在真实组织中运行代理的报告。下文仓库名、故障和验收表都是编辑构造的例子；没有创建真实 issue、发送团队消息或执行代码变更，也不宣称某个模型已经定位了故障。
先看当前账户是否具备入口和权限
Slack 集成文档与Teams 集成文档列出付费 Copilot 计划、应用连接、云沙箱和组织策略等前提，并说明公开预览状态。实际权限取决于账户和组织设置，本文不会从更新公告推断任何账户自动获得访问权。
安装应用、能够读取某个讨论线程、允许对某仓库启动代理，是不同的检查。发现权限不足时，让组织按既定流程处理，或把调查缩小到已有权限的资料。不要为了完成一条提示词临时扩大所有仓库的访问范围。默认仓库也要检查：未指定目标时，集成可能按其默认设置工作。
| 范围 | 要记录什么 | 为什么有用 |
|---|---|---|
| 仓库 | 明确的owner/repository名称 | 避免把前端改动归到后端 |
| 分支与时间 | 实际分支、时间范围和时区 | 避免拿不同阶段的状态比较 |
| 线程 | 相关讨论与可用资料 | 减少旧决定混入当前调查 |
| 动作 | 仅调查、提出计划或修改 | 让结果与授权范围一致 |
先要求一份可检查的排查表
@GitHub 请只调查，不创建issue或PR，也不修改代码。范围：example-shop/web 与 example-shop/api；比较当前main与我们提供的上一次正常版本。现象：订单页显示缺少deliveryDate；报错时间与版本号见本线程明确列出的记录。请分别列出每个仓库的相关变动、证据链接、支持或反驳的假设，以及仍缺少的信息。不要把PR标题当作已部署证明。若无权限访问某仓库，标记未知并停止对该仓库推断。只提供与任务有关且获准共享的资料。线程参与者的补充也可能影响上下文；开始新任务时使用独立线程能让边界更清楚。
PR合并、部署和故障原因是三件事
假设结果发现前端 PR 改了字段名，后端 PR 改了返回结构。两条 PR 同时存在，只能说明存在候选线索，不能证明线上正运行这两个版本。继续核对部署版本、实际响应和可复现条件，再判断哪个假设成立。
不要把解释听起来合理，当成排查完成。可以要求每行写出“看到的事实—对应证据—推断—还需验证”。如果链接只落到仓库主页，或引用的代码来自错误分支，这一行仍不满足验收。后续确需安全修复时，可参考自动修复告警的人工检查把建议与验证分开。
把结论降回证据支持的范围
后端昨天合并过相关PR，所以后端就是这次线上故障原因。
后端存在相关PR；尚需确认线上部署版本和实际响应，再验证它是否解释当前故障。
决定改代码前，给调查设一个结束条件
一份合格的调查交付不必强行找到根因。它可以确认两个假设不成立，并精确指出还缺少哪个版本或哪段日志。把未知明确列出，通常比生成一个看似完整的修复 PR 更能帮助负责人接手。
若决定进入修改阶段，重新说明目标仓库、基准分支、允许变更与验收条件。共享上下文中的身份和审核规则，应以当前官方文档及组织设置为准；不能因为是在聊天里启动，就省略仓库正常的审核。关于组织层面的使用条件，可继续阅读Copilot代码审查的计费与权限检查。
调查交付的五项验收
- 每个结论能回到明确仓库与分支的证据。
- 时间线区分合并、部署和故障发生。
- 无权限或缺资料的范围保持未知。
- 假设与观察到的事实分开，未声称执行过不存在的测试。
- 进入修改前重新明确目标和验证要求。
常见问题
多仓库支持是否代表任意仓库都能访问？
不是。账户权限、应用安装范围、组织策略和具体动作要求仍然适用。
这次更新已代表整个集成正式GA吗？
不能这样推断。本文核查时官方集成文档仍写公开预览，具体状态以当前文档为准。
为什么先排查，不直接让AI修？
因为当前部署版本和故障原因可能还没确认。先产出证据表，可以避免在错误仓库或错误假设上开始修改。
