研究、计划和迭代
说明 Copilot cloud agent 如何先研究仓库、生成计划、在 branch 上迭代代码，再创建 pull request。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| Research-plan-iterate | 调研-计划-迭代 | 复杂任务的推进节奏。 |
| 中途纠偏 | steer | 看进展后给反馈调整。 |
| 迭代 | iterate | 分轮推进而非一次到位。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你用调研-计划-迭代的节奏推进 Cloud Agent 的复杂任务。
你是 Cloud Agent 迭代推进顾问。
【角色】
Cloud Agent 迭代推进顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 复杂任务目标：___
- 已知的约束和未知点：___
- 可接受的迭代轮次：___
- 每轮怎么验证：___
- 经验水平：___
【工作流程】
1. 拆出调研、计划、执行各阶段
2. 设计每轮的反馈和纠偏
3. 说明怎么中途调整方向
4. 给迭代收敛标准
5. 给第一步
【输出规范】
▌一、阶段拆分
▌二、每轮反馈纠偏
▌三、中途调整
▌四、收敛标准 + 第一步
【硬约束】
- 复杂任务分轮推进，不一次到位
- 每轮看进展再纠偏
- 收敛标准明确，避免无限迭代
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或权限一律以官方文档为准，禁止照搬过时写法
- 给的每条结论都要落到具体可照做的步骤或示例，不停留在「建议」「考虑一下」这类没法直接执行的空泛表述Cloud agent 的高质量用法不是“直接让它开 PR”，而是先研究、计划、在 branch 上迭代，等 diff 可接受后再创建 PR。GitHub 官方页面明确说明，这些能力只在 GitHub.com 上的 Copilot cloud agent 中可用——某些第三方集成只能直接创建 PR。
阅读目标：读完本章，你应该能把 cloud agent 任务拆成 research、plan、iterate、PR 四段，而不是一次性丢给它。
1. 四段流程
- Research：让 Copilot 先读仓库、回答问题、确认相关文件。
- Plan：让 Copilot 给 implementation plan，并列出开放问题。
- Iterate：在 branch 上看 diff，补充约束，让它继续改。
- PR：准备好后再创建 pull request，并进入普通 review。
flowchart TD
Prompt["任务 prompt"] --> Research["Deep research"]
Research --> Plan["Implementation plan"]
Plan --> ReviewPlan{"计划可接受?"}
ReviewPlan -->|否| Clarify["补充要求"]
Clarify --> Research
ReviewPlan -->|是| Branch["在 branch 上修改"]
Branch --> Diff["审 diff"]
Diff --> Iterate{"需要继续改?"}
Iterate -->|是| Follow["follow-up prompt"]
Follow --> Branch
Iterate -->|否| PR["Create pull request"]
style Research fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Diff fill:#fef3c7,stroke:#d97706,stroke-width:2px
style PR fill:#dcfce7,stroke:#16a34a,stroke-width:2px2. Research 阶段怎么问
适合先问：
研究这个仓库：
找出登录错误是在哪些文件里处理的。
现阶段不要改代码。
列出相关文件和对应的测试。Research 阶段不要急着让它实现。目标是确认它读到的文件和你预期一致。
3. Plan 阶段怎么看
一个可执行计划应包含：
- 目标和非目标。
- 相关文件。
- 实施步骤。
- 风险。
- 测试命令。
- 需要你回答的问题。
计划不合格时，不要直接让它“继续”。用 follow-up prompt 补充约束，例如“不要改 schema”“只处理 web app”“保留旧 API”。
4. Iterate 阶段怎么控范围
迭代阶段要关注 branch diff：
- 是否改了 prompt 里禁止的文件。
- 是否新增依赖或 workflow。
- 是否删除了测试。
- 是否把问题扩展成无关重构。
- 是否有明显未运行测试的迹象。
如果需要改进，使用具体的 follow-up prompt：
保留当前的实现思路。
撤销刚才对配置文件的改动。
补一个回归测试覆盖这条 bug。
不要动 .github/workflows。5. Visual context
官方页面说明可以提供视觉上下文，例如 screenshot 或 UI mockup。适合 UI bug、空状态、错误提示、布局差异。
使用时仍然要脱敏：
- 遮住账号、token、客户名称。
- 不上传内部 URL 或生产数据。
- 截图只保留完成任务所需区域。
深读：为什么先 branch 迭代比直接 PR 更适合不确定任务
直接 PR 适合清晰 issue。对于需要探索的任务，先在 branch 上研究和迭代，可以避免让 reviewer 面对一个方向错误的大 PR。
Cloud agent 的价值不只是写代码，还包括把方案和 diff 提前暴露，让你在 PR 前就能修正方向。
本章自检
完成本章后，用这 4 个问题检查：
- Research 阶段是否列出了相关文件和测试？
- Plan 是否有可执行步骤和开放问题？
- Branch diff 是否只改了允许范围？
- 创建 PR 前是否已经审过主要 diff 和测试结果？
通过标准：PR 创建前，方向、范围和验证都已经被审过一轮。
官方来源
- Research, plan, and iterate on code changes with Copilot cloud agent —— 官方研究、计划和迭代页。
- Kick off a task with Copilot agents on GitHub —— 官方启动任务页。
- Responsible use of GitHub Copilot cloud agent —— 官方 responsible use 页面。