结论先说
如果你今天就想开始用 GitHub Copilot CLI，最短且相对安全的路径是这样：
- 用
npm install -g @github/copilot或brew install copilot-cli安装 Copilot CLI。 - 在你真正要操作的仓库目录里启动
copilot，首次运行先执行/login，信任目录时先选“仅本次会话”再决定要不要长期记住。 - 先用交互模式做探索，多文件改动前切到 plan mode，一次性小任务才用 programmatic mode。
如果你最近看过旧教程，但里面没提 trusted folder、plan mode 或权限设置，最好按 GitHub 现在的 beginner guide 和 quickstart 重走一遍。现在最容易踩坑的不是安装命令，而是第一次启动时你让 Copilot 读什么、改什么、跑什么。
这篇教程适合谁
这篇文章适合已经习惯在终端里工作的开发者，希望让 Copilot 在仓库阅读、小范围代码修改、Git 操作和有边界的自动化上提供帮助，但又不想把整台机器完全交给它。
如果你想要的是下面这些效果，这套方式就适合你：
- 尽量留在终端里，不在浏览器、IDE、Shell 之间来回跳
- 让 Copilot 带着上下文检查仓库、解释改动或起草代码
- 在 Copilot 想写文件或跑命令时，把授权范围收紧
- 学习新的 Copilot CLI，而不是已经退役的 GitHub CLI Copilot 扩展
如果你看的是旧教程，先更新这三点
GitHub 现在的文档里，有三件事会直接影响你的上手方式：
- 主入口是独立的
copilot命令，GitHub 在 About GitHub Copilot CLI 里分别写了 interactive interface 和-p的 programmatic interface。 - 第一次启动会出现目录信任提示。GitHub 的 quickstart 和 usage guide 都明确写了：当前会话里，Copilot 可以读取、修改并执行该目录及其子目录下的文件。
- plan mode 和
/delegate都已经是正式文档里的标准流程，不是藏起来的技巧。plan mode 见 About GitHub Copilot CLI，/delegate见 delegate guide。
很多旧教程只写到“安装并登录”为止，真正容易出错的权限边界反而没展开。
安装前需要确认什么
| 要求 | 检查什么 | 为什么重要 |
|---|---|---|
| Copilot 权限 | 账号是否有有效的 GitHub Copilot 套餐或 seat | 没有权限就无法完成 CLI 认证 |
| Node.js 22+ | 只对 npm 安装路径有要求 | Node 太旧会导致官方 npm 安装流程失败 |
| Windows 上的 PowerShell 6+ | Windows 路径需要它 | GitHub 文档写的是 PowerShell 或 WSL |
| 组织策略 | 检查 org 或 enterprise 是否禁用了 Copilot CLI | 即使你有 seat，也可能被组织策略拦住 |
截至 2026-04-13，GitHub 的 Copilot plans 页面 显示个人方案包括 Free、$10/月的 Pro、以及 $39/月的 Pro+。实际判断比价格表简单：想试用 CLI，不一定非得上高价方案，但你必须有有效的 Copilot 权益；另外，GitHub 的 安装文档 也明确写了，组织或企业策略仍然可能直接禁用 Copilot CLI。
最快且相对安全的上手方式
第一步：选一种安装方法
GitHub 的 安装文档 目前列了四种安装路径：npm、Homebrew、WinGet 和直接安装脚本。
对大多数开发者来说，最干净的两种还是：
npm install -g @github/copilot
或者在 macOS / Linux 上：
brew install copilot-cli
如果你的 ~/.npmrc 里有 ignore-scripts=true，同一份文档给出的 npm 变体是：
npm_config_ignore_scripts=false npm install -g @github/copilot
我的建议是：
- 如果你本来就用
brew upgrade维护终端工具，优先brew install copilot-cli - 如果机器上已经有 Node.js 22+，而且你想在 macOS / Linux / Windows 走同一条路径，优先
npm install -g @github/copilot - 只有在包管理器不方便用时，再考虑安装脚本
第二步：启动、登录，然后先做保守的目录信任选择
安装完成后，用下面的命令进入交互界面：
copilot
第一次运行时，先执行：
/login
GitHub 的 认证文档 说明，交互式使用默认推荐走 OAuth device flow。如果你需要非交互环境，GitHub 也支持通过 COPILOT_GITHUB_TOKEN、GH_TOKEN 或 GITHUB_TOKEN 做环境变量认证，并且明确要求 fine-grained PAT 需要包含 Copilot Requests 权限。
这种 token 方式更适合 CI、容器或其他 headless 环境。对大多数本机开发者来说，第一次直接走 /login 更省事。
登录之后，Copilot 会询问你是否信任当前目录里的文件。GitHub 的 getting started guide、usage guide 和 configuration guide 都把范围写得很清楚：在当前会话中，Copilot 可以读取、修改并执行该目录及其子目录下的文件。
你通常会看到三个选项：
Yes, proceed：只信任当前会话Yes, and remember this folder for future sessions：以后也记住这个目录No, exit：退出
对新手来说，比较稳妥的默认做法是：
- 在新仓库或不熟悉的代码目录里，先选仅本次会话信任
- 只有当目录是你反复使用且完全可控的工作目录时，才选长期记住
- 不要从 home 目录启动 Copilot，也不要从混着代码、密钥、客户文件或其他无关资料的大目录启动
如果你后面确实需要把范围扩到当前仓库之外，GitHub 文档里提到的 /add-dir 和 /cwd，都比“直接从更大的父目录启动”更安全。
第三步：先用交互模式，不要一上来就自动化
GitHub Copilot CLI 现在有两种主要使用方式：
- 交互模式：适合在终端里持续来回对话
- 程序式模式：适合执行一个 prompt 然后退出
第一次上手，交互模式通常更好，因为你能先看到 Copilot 想做什么，再决定给不给权限。
一个不错的首个提示词是：
Give me an overview of this project. Show the main entry points, likely build command, test command, and one risky area to avoid touching first.
这个提示词的好处在于，它强制 Copilot 先读仓库再碰改动。
第四步：动代码之前先切到 plan mode
2026 这一轮变化里，最有价值的一点就是 plan mode 已经被正式写进产品文档。
GitHub 的 CLI overview 和 usage guide 都写明，你可以在交互界面里通过 Shift+Tab 切换到 plan mode，也可以在普通模式里直接用 /plan。
例如：
/plan Add a new REST endpoint for category listing without changing the current response format.
为什么在真实仓库里，plan mode 应该成为默认习惯：
- 它会在写代码前先问清问题
- 它让范围在改文件前就变得可见
- 它能降低“小改动最后变成整仓重写”的概率
如果你只记住这篇文章里一个习惯，那就记住这一条：任务一旦跨多个文件，先用 plan mode。
第五步：programmatic mode 只留给窄任务
GitHub 的 programmatic guide 介绍了 -p / --prompt 这种程序式接口。同一份文档也强调尽量最小化权限，所以这种模式更适合“一次跑完一个明确结果然后退出”的任务。
例如：
copilot -p "Summarize the last 5 commits in this repository" --allow-tool='shell(git log:*)'
它适合的场景：
- commit 摘要
- 快速检查仓库
- 一次性的文档改写
- 有边界的 Git 查询
它不适合的场景：
- 开放式功能开发
- 风险较高的重构
- 你还没先想清楚权限边界的任务
GitHub 在 CLI overview 和 tool permissions guide 里都明确提醒：如果你给出过宽的自动批准权限，Copilot 基本就拥有了和你一样的文件与 shell 能力。这个边界要当真，不要把它当法律免责声明。
第一次上手，按这个顺序就够了
第一次在真实仓库里用，顺序尽量保守一点：
| 阶段 | 让 Copilot CLI 做什么 | 继续之前你要确认什么 |
|---|---|---|
| Explore | 解释仓库结构、脚本和近期改动 | 文件地图和命令是否真的对 |
| Plan | 提出结构化实现方案 | 范围在改动前是否可接受 |
| Execute | 做经过批准的小改动 | diff 是否还在计划范围内 |
| Verify | 跑测试或总结失败原因 | 检查是否真的通过 |
| Delegate | 把一个有边界的任务后台转交出去 | 最终分支或 PR 是否值得保留 |
顺序别反。先让它读，再让它改，你后面清理烂摊子的概率会低很多。
三个值得直接复制的提示词
1. 仓库上手提示词
Read this repository and give me:
1. the main entry points
2. the build and test commands
3. the folder I should read first
4. one risky area where changes could have side effects
Do not write code.
2. 安全规划提示词
/plan Add a new CLI flag to this tool.
Constraints:
- preserve existing output format
- do not add dependencies
- list tests before implementation
3. 一次性终端摘要
copilot -p "Show me what changed in package.json and explain whether it affects build or runtime behavior" --allow-tool='shell(git diff:*)'
这三个提示词好用，是因为它们会逼着 Copilot 先检查，再规划，最后才自动化。
常见错误以及怎么避免
错误 1：在错误的目录里启动 copilot
第一个常见错误，往往发生在你输入提示词之前：直接在一个很大的父目录、home 目录，或者混着一堆无关文件的工作区里启动 copilot。
修正方法：先进入你真正要操作的仓库，再启动 copilot。如果后面确实要扩范围，用 /add-dir 或 /cwd，不要一开始就信任一个过大的目录。
错误 2：过早给宽权限
最容易制造本可避免的问题的方式，就是在还不清楚 Copilot 在你仓库里会怎么表现时，就给它很宽的 shell 权限。
修正方法：先批准最小可用的工具范围。比如先允许一个具体的 git 只读命令，再决定是否放开更广的写权限或 shell 权限。
错误 3：多文件任务直接跳过 plan mode
如果你能先审计划，再看它改仓库，Copilot 就会更容易被信任。
修正方法：任务只要跨多个文件，先用 /plan。
错误 4：把安装失败误判为环境问题，其实是策略拦截
GitHub 的 安装文档 明确提到，即使用户本身有 Copilot 权限，组织或企业策略依然可能禁用 Copilot CLI。
修正方法：如果登录或使用被挡住，先检查 entitlement 和 policy，再考虑重装。
错误 5：忽略 Node.js 版本要求
GitHub 的 安装文档 目前要求 npm 安装路径使用 Node.js 22 或更高版本。
修正方法：如果旧机器上 npm install -g @github/copilot 失败，优先考虑升级 Node，或者换成 Homebrew 路径。
/delegate 什么时候真的值得用
GitHub 当前的文档把 /delegate 定义为：把任务交给 GitHub 上的 Copilot cloud agent，而不是在你本地终端里悄悄开一个后台 worker。GitHub 的 delegate guide 明确说，它会把当前会话推送到 GitHub，可能要求你把未暂存改动作为 checkpoint 提交到一个新分支，然后为 cloud agent 打开一个 draft PR，在后台继续处理。
只有当你本来就希望得到一个 GitHub 可见的分支和 draft PR 时，再用 /delegate。如果你只是想让 Copilot 在本地终端里继续想一会儿，那它不是合适的工具。
更适合的场景：
- 文档更新
- 隔离得很干净的小清理任务
- 带明确验收标准的 issue 驱动型工作
不太适合的场景：
- 正在进行中的调试
- 探索式重构
- 你还在摸清问题本身的任务
一个简单规则是：任务能用一段话说清楚，而且你也愿意它最终变成 draft PR，再用 /delegate。
FAQ
想高效使用 GitHub Copilot，必须离开终端吗？
不用。这正是 Copilot CLI 的价值：仓库阅读、规划、Git 操作和有边界的代码工作，都可以留在 shell 里完成。
第一次启动时，要不要直接把目录设成长期信任？
通常不要。尤其是新仓库、不熟悉的 checkout，或者混合工作目录，先选“仅本次会话”更稳。真正反复使用、而且你完全可控的目录，再考虑长期记住。
初学者应该先用交互模式还是程序式模式？
先用交互模式。这样在 Copilot 碰文件或命令之前，你还有更多机会去引导、拒绝和纠正。
开自动批准后，Copilot CLI 还安全吗？
只有在你明确希望它在那个环境里拥有较广权限时，答案才接近“可以”。GitHub 自己的文档已经提醒：宽泛的自动批准，实质上就是把和你相同级别的 shell 与文件能力给了 Copilot。
照着这一套走就行
进入目标仓库，运行 copilot，完成登录，目录信任先选当前会话，先让它做仓库概览，改代码前切到 plan mode，只有在任务很明确时再放宽工具权限。对大多数第一次上手的开发者来说，这一套已经够用。
核验说明
已于 2026-04-13 核验。选题触发核对官方 GitHub Blog beginner guide。安装方式、npm 路径要求 Node.js 22+、Windows 需要 PowerShell 6+、以及组织策略限制，核对 Installing GitHub Copilot CLI。OAuth /login、环境变量认证、token 优先级，以及 Copilot Requests PAT 权限，核对 Authenticating GitHub Copilot CLI。trusted folder 提示、交互用法、仅本次会话与未来会话信任差异，核对 Getting started with GitHub Copilot CLI、Using GitHub Copilot CLI 和 Configure GitHub Copilot CLI。plan mode 与权限边界警告，核对 About GitHub Copilot CLI 和 Allowing and denying tool use。程序式 -p 用法核对 Running GitHub Copilot CLI programmatically。/delegate 的 checkpoint、分支与 draft PR 行为，核对 Delegate tasks to GitHub Copilot CLI。当前个人套餐信息核对 GitHub Copilot plans。