问把一个idea变成一个可运行的程序总共分几步？答案是三步。今天就来分享一下Copilot CLI提的三种工作模式，用 Shift + Tab 一键切换：
| 模式 | 核心特点 | 适合场景 |
|---|---|---|
| Plan（计划） | 先分析需求，生成执行计划，等你确认 | 复杂任务、需要澄清需求 |
| Command（执行） | 按确认的计划逐步执行，每步可审批 | 中等复杂度、需要监督 |
| Autopilot（自动驾驶） | 完全自主执行，遵循编码规范，零打扰 | 计划已确认、长时间后台任务 |
三种模式不是孤立的，而是同一个任务的不同阶段——从对齐理解到放手执行的自然过渡。
实战：开发一个 PDF 转 Markdown 工具
第一步：Plan 模式——先对齐，再动手
我输入了一个简单描述：”开发一个 PDF 转 Markdown 转换程序”。
Copilot 没有立刻开始写代码，而是先扫描工作区，试图理解当前状态，然后主动提出几个关键问题：
- 你希望做成后台服务还是独立函数？
- 支持批量处理还是单文件？
- 输入输出放在同一目录还是分开？
这种”追问”机制很有意思。很多 AI 编程工具的问题是：你说一句它做一句，做完才发现理解有偏差。Plan 模式把需求对齐放在了执行之前，省去了反复修改的麻烦。
第二步：Autopilot 模式——定好规矩，放手干
确认计划后，切换到 Autopilot 模式。这时候 Copilot 开始完全自主工作：
- 自动读取
.github/copilot-instructions.md中的团队编码规范 - 按照确认的计划编写代码
- 自动生成单元测试并运行验证
- 全程无需人工干预
一个小细节：Autopilot 不是黑盒，可以用 /context 命令查看本次会话消耗的 token 数量，对成本心里有数。
第三步：Command 模式——18个测试来验证结果
Copilot 根据Instructions.md的要求，已经为这个功能自动编写了 18 个单元测试，覆盖了单文件转换、批量处理、特殊字符、目录结构保持、错误边界等场景。他使用的是他自己创建的pdf样本文件，你可以通过Command模式指定一个你想要的PDF 文件来测试后，验证测试case全部通过。
任务完成，从需求描述到可运行代码，中间的对齐、编码、测试都由 Copilot 自主完成。
这套工作流为什么值得关注
1. 需求澄清前置
Plan 模式的追问不是走形式，而是在执行前消灭理解偏差。对于开发工作来说，”做对”比”做快”更重要。
2. 规范自动继承
Autopilot 不会随意编码，而是遵循你在 copilot-instructions.md 中定义的团队规范。这意味着代码风格、测试覆盖率、架构约束都能被自动遵守，不需要人盯着。
3. 从”结对”到”委派”
传统 Copilot 是”你写它补”的结对编程；CLI 的三模式更像是“你定方向，它去执行”的任务委派。对于长时间运行的重构、批量处理、后台生成 POC 这类任务，这种模式更自然。
与 VS Code Copilot 怎么配合
两者不是替代关系，官方推荐的组合用法：
- 快速问答、代码解释 → VS Code Chat
- 探索陌生代码库 → VS Code Agent Mode
- 复杂多文件任务、长时间运行 → Copilot CLI
- 后台批量处理 → Copilot CLI
实际体验中，可以在 VS Code 里用 Chat 澄清需求，然后交给 CLI 在后台执行，关掉编辑器也没事，回来直接看结果。
写在最后
Copilot CLI 的三模式设计，本质上是在探索一个问题的答案：人类和 AI 的协作边界应该画在哪里？
我的体会是，这个边界不应该是固定的，而是可以动态调整的——复杂任务先用 Plan 对齐，确认后切 Autopilot 放手执行，需要精细控制时再切回 Command 逐步审批。Shift + Tab 一键切换，让这种调整变得毫无摩擦。
理解AI，用好AI，让AI帮助自我进化，加油。
