官方教程中文版实战工作流
实战工作流
把 GitHub Copilot 的官方能力落成 TDD、代码审查、PR 摘要和团队上线的可复用剧本。
这一组不是功能清单，而是把 Copilot 放进真实工程流程的操作剧本（playbook）。判断标准很简单：第二个开发者照着做，能得到同样的输入、检查点和退出条件——能复现，才是工作流；只能讲故事，是 demo。
1. 本组定位
flowchart TD
Need["真实工程任务"] --> Pick{"先选剧本"}
Pick --> TDD["TDD: 测试先行"]
Pick --> Review["Code Review: 风险审查"]
Pick --> Summary["PR Summary: 上下文压缩"]
Pick --> Rollout["Rollout: 团队上线"]
TDD --> Gate["测试 / diff / 人工确认"]
Review --> Gate
Summary --> Gate
Rollout --> Governance["权限 / 内容排除 / 计费 / 指标"]
Gate --> SOP["沉淀团队 SOP"]
Governance --> SOP
style Pick fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Gate fill:#fef3c7,stroke:#d97706,stroke-width:2px
style SOP fill:#dcfce7,stroke:#16a34a,stroke-width:2px2. 本组页面
TDD 工作流
用 Red / Green / Refactor 三段循环约束 Copilot，先写失败测试，再做最小实现。
代码审查工作流
把 Copilot review 变成风险预筛，而不是让它替代 reviewer。
PR 摘要工作流
让 Copilot 生成摘要草稿，再由作者补齐背景、风险、测试和回滚。
团队上线清单
从目标、试点、策略、内容排除、计费、指标到回滚，完成组织级 rollout。
3. 先选哪一篇
个人开发者先读 TDD 和 PR 摘要。它们改动小、反馈快，能立刻看出 Copilot 是否真正改善工作流。
团队负责人先读代码审查和团队上线。它们决定 Copilot 能否进入 reviewer、仓库策略、计费和指标体系。
已经有治理压力的组织先回到 安全、治理与计费，再读本组。没有内容排除、访问策略和计费视图时，剧本越多，风险越难解释。
4. 剧本写法
每一条 Copilot 剧本都要写清 4 件事：
- 输入：issue、需求、测试文件、diff、PR、仓库规则或组织目标。
- Copilot 动作：生成测试、解释 diff、审查风险、生成摘要、建议 rollout 指标。
- 人工检查：测试是否失败在正确原因、review 是否可复现、摘要是否覆盖风险、策略是否符合组织边界。
- 退出条件：测试通过、review 关闭、PR 描述完成、试点指标达标或回滚。
深读：为什么这里不用表格
教程站会在手机、平板、窄屏文档栏和桌面宽屏之间切换。剧本内容经常包含长链接、命令、文件路径和中文长句，表格在移动端容易产生横向滚动。
这一组统一使用卡片、编号清单、折叠说明和 Mermaid 图，保证移动端也能读。
本组自检
- 是否每篇都有清楚的输入、动作、人工检查和退出条件？
- 是否避免把 Copilot 的自然语言输出当最终事实？
- 是否能从失败样例反推应该修改 prompt、测试、规则还是权限？
- 是否有团队 SOP、仓库说明或管理员策略承接这些经验？
通过标准：Copilot 不只是“能回答”，而是进入了可复用、可验证、可回滚的工程流程。
官方来源
- GitHub Copilot documentation —— GitHub 官方 Copilot 文档总入口。
- GitHub Copilot in VS Code —— VS Code 官方 Copilot 入口。
- Set up a test-driven development flow in VS Code —— VS Code 官方 TDD 指南。
- Achieving your company's engineering goals with GitHub Copilot —— GitHub 官方组织 rollout 目标页。