GitHub Copilot 常见任务
这页适合处理什么任务
- 平台已经是默认工作系统，issue、PR、review 都在 GitHub 内发生。
- 任务边界能写进 issue，而不是必须靠本地探索才能收敛。
- 你想复用的是平台内交付动作，而不是编辑器操作习惯。
前置条件
- 先完成 GitHub Copilot 快速开始。
- 任务已经能从 issue 描述直接看出范围。
- PR review 是主要交付方式。
使用前先固定三件事
- issue 模板里必须有范围、禁区、验收和交付物。
- PR 模板里必须要求验证说明和剩余风险。
- reviewer 需要知道这轮只看什么，而不是替工具补需求澄清。
步骤
任务 1：Issue -> Draft PR
适合最清晰、最可标准化的任务，例如：
- 一个已有复现路径的 bugfix
- 一条缺失测试
- 一个边界很清楚的小型文档或脚本调整
开始前至少准备这三样东西：
- 明确 issue 链接
- 验收命令或验收行为
- 不能改的目录或文件
默认要求可以直接写成：
请先复述 issue 的目标、范围、禁止修改区和验收方式。
给出最小计划，只推进第一轮最小改动。
最后生成 draft PR 说明，必须包含改动摘要、验证方式、剩余风险和下一步建议。
成功信号：
- draft PR 能直接让 reviewer 判断是否继续
- 改动范围和 issue 范围一一对应
- PR 不是只有 diff，还有验证证据
切换条件：
- 如果 issue 本身说不清楚，就先退出平台流，回到需求或本地探索
- 如果改动开始需要深度仓库排查，就切到 Claude Code 常见任务 或 OpenAI Codex 常见任务
任务 2：根据 review comment 回改
适合已有 PR 的小步迭代，不适合顺便扩大需求。开始前要先整理：
- 哪些 review comment 属于本轮
- 哪些 comment 必须延后到下一轮
- 本轮回改后的验证方式
默认要求：
先总结当前需要处理的 review comment，只处理这一轮明确列出的意见。
不要扩大到无关重构。
改完后回报本轮改动摘要、验证结果，以及哪些 comment 仍未处理。
成功信号：
- 改动和 comment 明确对应
- reviewer 不需要自己猜哪些意见已关闭
- 没有趁回改顺 手引入新一轮大改
切换条件：
- 如果 comment 指向的是更大结构问题，就不要继续在单轮 PR 里硬改，先拆成新 issue
- 如果回改必须做多阶段实现，切到 Spec-First Runbook
任务 3：把 Jira / issue 任务拉回 PR 流
适合平台型协作，尤其是任务来源在 Jira、但最后仍要在 GitHub review 的场景。前提是任务系统已经写清，不能把平台当成替代需求澄清的地方。
开始前先补齐：
- 来源任务链接
- 当前 owner 和 reviewer
- 这次交接只收口到什么程度
默认要求：
请根据来源任务整理一个 GitHub 内可 review 的执行摘要。
只推进当前已确认范围，不替代需求澄清。
交付时必须把来源任务、验证方式和剩余风险写回 PR 说明。
成功信号：
- Jira / issue 和 PR 之间 有可追踪映射
- review 人只看 PR 就能理解任务来源和当前状态
- 平台只承担收口，不承担模糊需求补全
切换条件：
- 如果任务系统本身写不清，先回去修任务系统
- 如果真正的工作大头发生在本地或后台执行，就改用 Local -> Background -> Cloud Runbook
验收清单
每次任务完成后都检查：
- issue 和 PR 是否仍然一一对应
- PR 是否包含验证和风险说明
- 是否有人类 reviewer 能快速判断下一步
- 这轮是否仍保持了最小范围，而不是顺手做大
常见误用
- 把 GitHub Copilot 当成需求澄清器，issue 还没写清就直接推进
- 用平台流处理明明需要本地深潜的任务
- 把 draft PR 当成“先放上去再说”，不写验证和风险
- 根据 review 回改时顺手做无关优化，导致每轮 PR 都变大
下一步
- 去 GitHub Copilot 排错。
- 去 Issue / Jira -> Draft PR 示例。
- 如果你需要仓库内更强控制，再去 Claude Code 快速开始。