Issue 都写好了，就不用再把需求重新敲进聊天框啦。只要仓库和订阅符合要求，直接在 GitHub 网页端的 Issue 页面就能把任务交给 GitHub Copilot Coding Agent——它会在独立环境里分析仓库、修改代码、推送提交，最后建好 Pull Request 再通知你审查。

这个操作路径适合边界清晰、能靠代码和测试验收的任务，比如修一个明确的错误、补个校验逻辑、调整现有页面或者完善文档。GitHub 官方目前把 Issue 委派功能标为公开预览，界面和可用范围后续可能还会调整。动手前得满足几个前提：你用的是付费 Copilot 方案、目标仓库在 GitHub 上、当前账号对这个仓库有写权限，而且仓库没关掉 Copilot cloud agent。另外，托管用户账号名下的仓库用不了这个功能。

先把 Issue 写得能直接当任务用

入口位置：进到目标仓库，打开要处理的那篇 Issue。主要动作：检查标题和描述有没有说清预期效果、影响范围、验收条件，还有哪些内容不能改；相关的错误日志、文件位置、复现步骤也得在委派任务前补全。成功标志：光看 Issue 本身就能明白要改啥、怎么才算达标。失败处理：如果需求还能有好几种解读，先把范围收窄，别把“优化一下”“看看有没有问题”这种太开放的任务直接交给它。

委派任务的时候，Copilot 只会收到 Issue 的标题、描述、当时已经有的评论，还有你之后填的补充要求。委派完再往 Issue 里加的评论，不会自动同步到这次任务里；要是后续需求有变化，得去 Copilot 建的 Pull Request 里接着说明。

从仓库里找到目标 Issue

先打开 Issues 列表

入口位置：仓库名称下面的顶部导航栏。主要动作：点一下 Issues，再从列表里打开你准备委派的那一条。成功标志：页面标题和你要找的目标 Issue 对得上，右边能看到 Assignees、Labels 这些侧边栏选项。失败处理：要是找不到 Issues 入口，先看看仓库是不是关了 Issue 功能，或者你当前打开的是不是有权限操作的那个目标仓库。

图里的橙色框标出来的就是仓库级的 Issues 入口。先核对下左上角的仓库名称再进列表，能避免把任务错交到同名仓库或者分叉仓库里。

调出受理人选择框

入口位置：Issue 详情页右边的 Assignees 区域。主要动作：点一下 Assignees 的标题，或者旁边的设置图标。成功标志：页面会弹出一个能搜索、能勾选的受理人列表。失败处理：要是入口点不动，一般是当前账号没有仓库的写权限；换个有权限的账号，或者找仓库维护者调完权限再继续。

记住要点右边侧边栏的 Assignees，不是 Issue 正文里的@提及或者评论框。等列表弹出来之后再选 Copilot，任务才会进入 Coding Agent 的处理流程。

把 Issue 指派给 Copilot 处理

在 Assignees 列表里选 Copilot

入口位置：刚弹出来的 Assignees 列表。主要动作：找到 Copilot 选项点一下。成功标志：会弹出一个叫 Assign Copilot to issue 的配置对话框，而不是只在普通受理人旁边打个勾。失败处理：要是列表里找不到 Copilot，就挨个排查：你的 Copilot 是不是付费方案、组织策略允不允许用、仓库有没有开 cloud agent，还有这个仓库是不是属于不支持的托管用户账号。

截图里的 Copilot 是专门的智能体选项。要是这里只显示普通成员，你点别的名字也启动不了代码任务。

配置仓库、分支和补充要求

入口位置：刚才弹出的 Assign Copilot to issue 对话框。主要动作：先核对下目标仓库和起始分支对不对，再在 Optional prompt 里补上 Issue 没提到的约束，最后点 Assign 就行。补充要求里适合写清楚必须跑的测试、要沿用的代码模式、允许修改的目录，还有绝对不能碰的配置或者工作流文件。成功标志：Issue 上会显示 Copilot 已经被指派，还会出现任务开始的状态提示。失败处理：要是目标仓库能看到但选不了，说明当前账号可能只有读权限，或者这个仓库没开 cloud agent；先把权限或者仓库设置的问题解决了，别乱选别的仓库绕开限制。

对话框底部依次是目标仓库、起始分支、智能体选择和模型选项。没有特殊要求的话，Copilot 会用 Issue 所在的仓库，还有目标仓库的默认分支；要是跨组织选仓库，或者把私有 Issue 对应到公开仓库，GitHub 会弹出额外警告，这时候得先确认代码和需求不会被泄露出去。

等 Pull Request 生成后做好审查

入口位置：GitHub 顶部的 Agents 面板、仓库的 Agents 标签，或者任务创建后的会话记录里都能找到。主要动作：打开对应的会话，查看运行进度、工具调用情况、测试结果和文件改动；Copilot 写完代码后会创建 Pull Request，还会把任务发起人加为审查者。成功标志：会话关联着一个 Pull Request，提交是 Copilot 创建的，还能追溯到会话记录，Pull Request 里能看到所有改动和验证结果。失败处理：要是发现方向走偏了，趁会话还在运行的时候，发更具体的后续要求就行；如果 Pull Request 已经建好了，就在 PR 里评论并@Copilot，让它基于现有的改动接着调整。

可别因为 Pull Request 是自动生成的就直接合并。先看看文件差异，核对下有没有超出 Issue 的范围，再检查测试、静态分析和构建的结果对不对。Copilot 推送的改动默认不会自动跑 GitHub Actions 工作流；要是合并区域出现了 Approve and run workflows 按钮，先重点检查工作流目录里的变化，还有可能读取的敏感信息，确认安全了再批准运行。

最后核对这份检查清单

1. Issue 的标题、描述、验收条件，还有不能修改的范围都写得足够清楚。
2. 当前账号用的是付费 Copilot 方案，而且对目标仓库有写权限。
3. Assignees 列表里能找到 Copilot，委派对话框里的仓库和起始分支都选对了。
4. 补充要求里写清了必要的测试、代码约束，还有禁止修改的位置。
5. 任务会话能正常打开，最后能关联到 Copilot 创建的 Pull Request。
6. Pull Request 的文件差异、提交记录、测试结果和工作流安全检查都符合 Issue 的目标，再合并。