从想法到 PR：用 GitHub Copilot CLI 开发的实战指南
大多数开发者本来就在终端里完成大量实际工作。
我们会在终端里初始化项目、跑测试、排查 CI 失败，也会在代码进入评审前先做一些快速、机械性的修改。GitHub Copilot CLI 正是贴合这种现实：它帮助你在终端里直接把“意图”转成“可评审的 diff”，然后再把这些工作自然衔接到编辑器或 pull request。
这篇博客将带你走一遍使用 Copilot CLI 创建并迭代应用的实战流程，内容基于一套新的 GitHub Skills 练习。Skills 练习提供的是循序渐进的动手教程；而本文重点解释每一步为什么有效，以及在真实项目中该在什么时候使用。
Copilot CLI 是什么（以及不是什么）
Copilot CLI 是一个运行在终端里的、理解 GitHub 上下文的 coding agent。你可以用自然语言描述需求，用 /plan 在动代码前先梳理方案，然后在任何命令执行或变更落地前，先审阅具体命令或 diff。Copilot 可能会在内部推理，但只有在你明确批准后，才会执行命令或应用修改。
在实践中，Copilot CLI 可以帮助你：
- 基于你的意图探索问题
- 用
/plan提出结构化计划（也可以按 Shift + Tab 进入规划模式），或者给出你可审阅的具体命令与 diff - 生成或修改文件
- 在失败发生的位置直接解释问题
它不会做的事：
- 在未经你批准的情况下静默执行命令或应用修改
- 取代严谨的设计工作
- 消除代码评审的必要性
对“运行什么、改什么、发布什么”，你始终拥有控制权。
第 1 步：先说清意图，而不是先搭脚手架
与其一上来就选框架或复制模板，不如先明确你要构建什么。
在空目录下运行：
copilot
> Create a small web service with a single JSON endpoint and basic tests
如果你不想进入交互模式，也可以用单条 prompt 直接生成提案：
copilot -p "Create a small web service with a single JSON endpoint and basic tests"
在 Skills 练习中，这个模式会反复出现：先描述意图，再决定哪些建议命令值得执行。
在这个阶段，Copilot CLI 的作用是探索问题空间。它可能会：
- 推荐技术栈
- 梳理文件结构
- 提出初始化命令
不会有任何内容自动执行。你会先检查，再决定是否执行。这让 CLI 成为在确定设计前进行试验的理想场所。
第 2 步：只脚手架化你愿意负责的部分
当你看到一个自己认可的方向后，再让 Copilot CLI 帮你搭脚手架：
> Scaffold this as a minimal Node.js project with a test runner and README
这是 Copilot CLI 最能立刻体现价值的阶段。它可以：
- 创建目录与配置，
- 串好基础项目结构，
- 生成原本需要你手敲或复制的样板代码。
Copilot CLI 并不会“接管”项目结构。它只是按常见约定给出脚手架建议，你应把它当作起点，而不是标准答案。
核心约束是：你始终对结果负责。把输出当成同事提交的代码——审阅、修改，或者直接丢弃。
第 3 步：在失败发生处迭代
直接在 Copilot CLI 里运行测试：
Run all my tests and make sure they pass
如果出错，就在同一会话里围绕这个具体失败继续追问：
> Why are these tests failing?
如果你想要可落地的方案而不是解释，可以试试：
> Fix this test failure and show the diff
这种模式——运行（!command）、检查、提问、审阅 diff——能让 agent 基于真实输出工作，而不是停留在抽象 prompt 上。
💡**实用建议：**在实际使用中，explain 适合你需要“理解原因”时；suggest 更适合你需要“可审阅的具体方案”时。在这篇指南中了解 Copilot CLI 的 slash commands。
第 4 步：处理机械性或全仓库变更
Copilot CLI 也非常适合这类“描述简单、执行繁琐”的改动：
> Rename all instances of X to Y across the repository and update tests
因为这类改动往往机械且范围明确，所以易于评审，也易于回滚。CLI 会给你具体 diff，而不是一大段生成文本。
第 5 步：当需要“打磨代码”时，切换到编辑器
到某个阶段后，速度的重要性会让位于精度。
这就是自然切换到编辑器或 IDE 的时机，你可以在那里：
- 推敲边界场景
- 精炼 API
- 做出设计决策
Copilot 在那里同样可用，但关键在于你为什么切换环境。CLI 帮你快速推进到“真实可运行的东西”；IDE 则让你把代码打磨成你真正想要的样子。
一个实用经验法则：
- **CLI：**用
/plan，生成/diff，低仪式成本快速推进 - **IDE：**当你需要精炼逻辑并做出可在评审中自证的决策时，使用
/IDE - **GitHub：**提交代码，用
/delegate命令创建 pull request，并进行异步协作
第 6 步：在 GitHub 上交付
当变更状态良好后，进行提交并创建 pull request——这些都可以在 Copilot CLI 里用自然语言完成：
Add and commit all files with a applicable descriptive messages, push the changes.
Create a pull request and add Copilot as a reviewer
到这一步，工作成果就具备了可持续价值：
- 团队可评审
- CI 可测试
- 可进入异步迭代
这也是 Copilot 价值持续累积的地方：它不是只在单一界面给建议，而是融入一条以交付为终点的流程。Skills 练习刻意在这里收束，因为 Copilot 真正的长期价值体现在 commit、pull request 与 review 中（而不只是建议本身）。
一条工作流，三个关键时刻
理解 Copilot 的一个好模型是：
- CLI：低仪式成本快速验证价值
- IDE：塑形并精炼代码
- GitHub：评审、协作与发布
Copilot CLI 的强大之处，恰恰在于它融入这套体系，而不是试图取代它。
带走这条原则
当你把 Copilot CLI 当作“提升推进速度的工具”，而不是“替代判断力的系统”时，它价值最大。
用得好，它能让你更快把意图落成具体变更：探索想法、搭建项目、诊断故障，以及在终端里完成机械性工作。需要精细决策时，转到编辑器；准备共享成果时，落到 GitHub 的 pull request——可评审、可测试、可交付。
相比任何单一命令，这条流转路径更重要。
如果这份指南只带走一句话，那就是：当 Copilot 自然融入开发者本就熟悉的软件构建方式时，它效果最好。先在 CLI 里解卡点或快速推进，再在 IDE 里放慢节奏做可负责的决策，最后依靠 GitHub 让工作成果长期可用。
作者
GitHub 高级服务交付工程师
探索更多 GitHub 内容
文档（Docs）
掌握 GitHub 所需的一切内容，集中在一个地方。
GitHub
在 GitHub 上构建下一代产品。无论你来自哪里、是谁，都能在这里构建任何东西。
客户案例（Customer stories）
了解使用 GitHub 构建产品的公司与工程团队。
The GitHub Podcast
关注 GitHub 播客节目，了解 GitHub 开源开发者社区内外的主题、趋势、故事与文化。
