把 GitHub issue 交给 Copilot，拿回一份可以接着讨论的 PR

你已经把一个小功能写成 GitHub issue：哪里需要改、当前表现是什么、希望出现什么结果。与其再把同样的材料复制到编辑器聊天框，GitHub Copilot 的云端代理可以直接接手这条 issue，完成代码变更后，把讨论带到 PR 中。

这条路径值得关注，是因为产物天然落在团队已经使用的协作位置。需求是 issue，改动是分支和提交，下一步是审阅；无需先把整段终端对话整理成另一份交接文档。

指派之前，issue 就是任务输入

官方启动说明中，从 issue 右侧 Assignees 选择 Copilot，还可以补充 Optional prompt，例如相关文件、项目惯例或测试要求。代理会接收指派那一刻的标题、正文和已有评论。

比如，教学任务可以是“把上传失败时的一般报错改成可区分文件类型错误与网络错误的提示”。issue 中写清当前触发位置和预期文案，补充现有测试目录，就比单写“优化错误处理”更接近一个可以完成的修改。这里的中文示例只是组织需求的示意，不是官方演示效果。

有一个影响协作的细节：指派以后再加到原 issue 的评论，代理不会自动看到。后续新信息应放到 PR，而不是继续堆在原讨论串。这会直接改变团队应该去哪里补充需求。

当前文档把启动方式区分得很清楚：指派 issue 总会创建 PR；代理工作完成后，请求你审阅。另一方面，从 Agents 面板提交提示词，默认先在分支上工作，你可以看 diff、继续提要求，准备好了再创建 PR。也可以在最初提示里明确要求开 PR。

如果问题已经定型，issue 路径可以把它推进到团队审阅。如果还在研究可行做法，先留在分支里迭代更自然。两者都能进入代码协作，却不必在同一个时点制造 PR。

GitHub 上的 Copilot 总览说明，云端代理会在临时云开发环境读取文件、编辑代码、运行测试和 linter，并处理分支、提交与推送。会话日志提供了理解改动的线索，队友也可以接着检查。日志是审阅材料，测试是否覆盖真实需求仍要看具体输出。

这项云端能力需要付费 Copilot 计划，还受组织和仓库设置控制。更重要的是，一次任务只能修改启动时指定的 GitHub 仓库，不能把跨几个仓库的联动发布一次包办。任务过大时，把接口、调用方或测试拆成清楚的协作单位，会更容易接手。

我更看重的是这条路径留下的成果：一个能看代码差异、能追问、能继续提交的 PR。对于原本就靠 issue 和代码审阅协作的团队，它把模型的工作放进既有流程；最终是否合并，依然取决于团队对需求和代码的判断。