GitHub Copilot CLI 命令行工具深度使用指南

前言

我以前使用 Copilot，主要还是在 IDE 里。写代码时补全一段逻辑，选中文件让它解释一下，或者在侧边栏里让它帮我改一个函数。这种方式很方便，但它没有覆盖我一天里所有开发动作。

很多任务其实发生在终端里。拉分支、看 diff、跑测试、查日志、定位构建失败、处理 PR、整理发布说明，这些动作本来就不在编辑器里完成。每次终端里遇到问题，再切到 IDE 或浏览器问 AI，节奏就会被打断一次。问题越复杂，来回切换越多。

GitHub Copilot CLI 正好补了这个位置。它把 Copilot 放进终端，让 AI 能围绕当前目录、当前仓库、Git 状态、命令输出和会话历史继续工作。2026 年 2 月进入 GA 后，它已经不是早期那种命令解释工具，而是更接近一个终端里的 coding agent。

这篇主要记录我会怎么理解和使用 Copilot CLI。它的价值不只是能在命令行里聊天，更重要的是把开发过程里的几类动作串起来：先理解代码，再规划任务，再修改文件，再审查 diff，最后创建 PR 或导出结果。

一、先把 Copilot CLI 的定位理清楚

很多人第一次接触 Copilot CLI，会把它和早期的 gh copilot 混在一起。早期 GitHub CLI 里有 gh copilot suggest、gh copilot explain 这类命令，主要用来解释命令、生成 shell 命令或辅助 Git 操作。现在的 Copilot CLI 已经换了一个使用方式，它是独立的 copilot 命令，也有自己的交互界面、会话机制、agent 能力和斜杠命令体系。

这个差异会影响整篇文章的写法。如果继续围绕 suggest、explain、fix 这些命令展开，很容易把当前 Copilot CLI 写成旧版命令助手。现在更应该把它看成终端里的 AI 开发环境。

我会这样区分它们：

对比项	早期 gh copilot 思路	当前 Copilot CLI 思路
入口	GitHub CLI 扩展里的子命令	独立 copilot 命令
典型任务	解释命令、生成命令、辅助 Git 操作	规划任务、修改代码、审查 diff、创建 PR、远程委托
交互方式	一次性问答更多	交互式会话更多
上下文	偏当前命令或输入内容	当前目录、仓库、文件、Git 状态、会话历史
自动化程度	偏辅助建议	可以进入 agent 工作流
团队扩展	相对有限	支持 MCP、skills、custom agents、plugins、hooks

我现在会把 Copilot CLI 放在三个场景里使用。

第一个场景是 终端里的即时分析。比如构建失败、测试报错、shell 命令看不懂、Git 状态比较乱，这时候直接在终端里让 Copilot 解释当前情况，比复制来复制去更省事。

第二个场景是 小范围代码任务 。比如修一个测试、改一个脚本、补一个校验、生成一段迁移说明。这类任务不一定需要打开完整 IDE 流程，在 CLI 里通过 /plan、自然语言提示、/diff、/review 就能完成一轮。

第三个场景是 把结果接回 GitHub 工作流。比如让 Copilot 创建 PR、审查当前分支、委托远程 agent 处理任务、用 GitHub MCP 查询 issue 或 PR。这个部分才是 GitHub 自己做 CLI 的优势，它不只是接入模型，还能进入 GitHub 的协作流程。

二、安装后先完成几项基础设置

Copilot CLI 的安装方式比较多。日常使用里，macOS 和 Linux 可以直接用 Homebrew，跨平台可以用 npm，Windows 可以用 WinGet。npm 方式需要注意 Node.js 版本，当前要求 Node.js 22 或更高版本。

常见安装命令如下：

# npm，适合所有平台
npm install -g @github/copilot

# macOS / Linux
brew install copilot-cli

# Windows
winget install GitHub.Copilot

# macOS / Linux install script
curl -fsSL https://gh.io/copilot-install | bash

安装后直接启动：

copilot

第一次进入时，如果当前环境没有登录 GitHub，会提示使用 /login 完成授权。这里要留意组织策略。如果 Copilot 来自公司或组织，管理员可能在组织设置里关闭了 Copilot CLI，这种情况下本地安装成功也不能正常使用。

我一般会在第一次安装后先做五件事。

2.1 确认版本和账号

进入 CLI 后先看版本和当前用户，避免本机多个 GitHub 账号混在一起。

/version
/user show

如果有多个账号，可以用 /user switch 切换。团队项目里尤其要确认这一点，不然可能出现本地看得到仓库、Copilot 却没有对应权限的情况。

2.2 配置终端输入

复杂任务很难用一行提示词说清楚，我会先打开多行输入配置。

/terminal-setup

这个命令会配置 Shift + Enter 或 Ctrl + Enter 这类多行输入能力。配置好以后，写任务描述会舒服很多，尤其是需要同时写目标、约束、测试命令和禁止修改范围时。

2.3 选择模型

/model 可以切换模型。这里不用一上来就选最强模型。简单解释、命令建议、小范围代码问题可以用更快的模型；跨文件重构、复杂排查、架构迁移再选择推理能力更强的模型。

/model

我一般会按任务复杂度来选，而不是一直使用同一个模型。

任务类型	模型选择思路
解释命令、理解日志	选择响应快的模型
小范围修 bug	选择代码能力和速度比较平衡的模型
多文件重构	选择推理能力更强的模型
长文档或大仓库分析	关注上下文窗口大小
成本敏感任务	先用轻量模型探索，再切换强模型执行

2.4 设置显示风格

主题不是关键能力，但长时间使用终端时会影响阅读。可以通过 /theme 切换显示模式，也可以通过 /statusline 调整状态栏显示。

/theme
/statusline

我会把当前模型、目录、分支、上下文窗口这些信息放在状态栏里。这样在长会话里不容易忘记自己正在哪个项目、哪个分支、哪个模型下工作。

2.5 检查更新策略

Copilot CLI 更新很频繁。如果是个人项目，可以保持 stable 更新；如果是公司项目，我会先确认团队是否允许使用 prerelease。配置目录里有更新通道设置，不建议团队成员各自随意切到预发布版本，否则排查问题时很难确认差异来自代码还是工具版本。

三、上下文管理决定回答质量

Copilot CLI 最容易被低估的能力，是上下文管理。它能看到当前目录、文件、Git 状态和历史会话，但这并不意味着上下文越多越好。无关文件太多，模型会被干扰；会话太长，旧判断会影响新任务；目录选错，它可能一开始就从错误位置理解项目。

3.1 /cwd 先把工作位置放对

/cwd 或 /cd 可以查看和切换当前工作目录。

/cwd apps/api

在 monorepo 里，我会尽量先切到具体模块，再开始提问。比如我要排查支付服务，就先进入 services/payment；我要分析前端页面，就先进入 apps/web。这样 Copilot 搜索和读取文件时，会更容易聚焦到相关区域。

我以前直接在仓库根目录问过一些问题，结果模型会把 docs、examples、packages、scripts 都放进考虑范围。它不是不能回答，但容易绕一大圈。终端工具和 IDE 不一样，当前目录是非常重要的上下文入口。

3.2 /add-dir 控制跨目录访问

有些任务确实需要跨目录。比如前端页面要看 API 类型，后端服务要看 shared schema，文档生成要读取多个模块。这时可以用 /add-dir 添加额外目录。

/add-dir ../shared
/add-dir ../docs
/list-dirs

/list-dirs 用来确认当前允许访问哪些目录。这个命令在大仓库里很有用，尤其是仓库里包含生产配置、客户数据样例或密钥模板时，我不会直接把整个仓库都开放给 AI。先给它必要目录，缺上下文再补，比一开始全放开更稳。

3.3 /context、/compact 和 /clear 处理长会话

长会话用久以后，回答质量会波动。/context 可以查看 token 使用情况，/compact 可以压缩历史对话，/clear、/new 或 /reset 可以开启新对话。

/context
/compact
/clear

我会在这几种情况下清理上下文：

• 从前端任务切到后端任务
• 从排查问题切到真正修改代码
• 前面讨论过多个废弃方案
• Copilot 开始引用不存在的文件或函数
• 当前任务涉及敏感内容，不希望继承前面的会话历史

清理上下文不是多余动作。AI 会话和人脑一样，临时判断积累太多以后，后面的决策会受影响。任务边界清楚，执行阶段会更干净。

3.4 /resume 和 /session 保留可继续的工作

Copilot CLI 可以恢复之前的会话。/resume 或 /continue 能切换到历史会话，/session 能查看和管理当前会话信息。

/session info
/session rename auth-refactor
/resume

我会给重要会话命名，比如 auth-refactor、ci-failure、release-note。这样第二天继续处理时，不需要翻一堆自动生成的会话标题。

复杂任务通常不会一次做完。会话能恢复，意味着我可以让 Copilot 保留前一天的分析过程，第二天继续从计划或 diff 开始，而不是重新解释项目背景。

四、真正开始做事前，先让它规划

很多人用 AI 改代码时会直接说帮我重构这个模块。这个提示词太宽。Copilot 可能会直接开始修改文件，最后生成一堆 diff，方向对不对要等改完才知道。

我更愿意先用 /plan。

/plan 梳理当前登录模块，规划把 token 刷新逻辑抽成独立 service 的改造方案。先不要修改文件。

/plan 的价值在于把任务拆开。它会先给出实现路径，说明要看哪些文件、改哪些部分、测试怎么验证。这个阶段如果方向不对，修正成本最低。

一个合适的规划提示词，通常要包含四类信息。

信息	示例
目标	把 token 刷新逻辑抽成独立 service
范围	只处理 apps/api/src/auth 目录
约束	不修改数据库字段，不改变接口返回结构
验证	最后运行 npm test -- auth

我会这样写：

目标：
把当前认证模块里的 token refresh 逻辑抽成独立 service。

范围：
只分析和修改 apps/api/src/auth 目录，必要时可以读取 packages/shared/types。

约束：
保留现有接口返回结构，不修改数据库字段，不改变错误码。

验证：
改完以后运行 npm test -- auth。
先输出计划，不要直接改文件。

这种写法比简单说重构认证模块更可控。Copilot 需要先理解你的边界，再进入实现。

计划确认以后，可以让它继续执行。执行过程中，如果它要运行命令或修改文件，会根据权限设置提示确认。这个确认步骤不要嫌烦，尤其是在真实项目里。AI 改文件之前先让人看一眼，是必要的安全阀。

五、用 /diff 和 /review 把修改收回来

让 Copilot 改完文件以后，我不会直接提交。第一步一定是看 diff。

/diff

这个命令会展示当前目录的改动。它和普通 git diff 的区别在于，可以和 Copilot 会话继续结合。你可以让它解释某个 diff，也可以让它对某个文件的修改给出理由。

接下来我会用 /review 做一轮自动审查。

/review 检查这次改动有没有改变原有认证行为，重点看错误处理、权限判断和测试覆盖。

/review 不会替代人的 code review，但它适合在提交前扫一遍明显问题。比如无关文件改动、异常路径没处理、测试覆盖不够、命名不一致、重复逻辑没有删干净。这些问题越早发现越好。

如果改动方向不对，可以用 /undo 或 /rewind 回退上一轮操作。

/undo

这个命令给了我一个比较重要的心理安全感。AI 工具一旦能写文件，开发者就会担心它改过头。有明确的回退入口以后，可以让它尝试方案，再根据 diff 决定是否保留。

我一般会把 Copilot CLI 的修改流程控制成这样：

明确任务
  ↓
/plan 先看方案
  ↓
执行小步修改
  ↓
/diff 查看改动
  ↓
/review 先做一轮自动审查
  ↓
运行测试
  ↓
决定提交或 /undo

这个流程看起来比直接让 AI 改慢一点，但它能减少返工。尤其是对业务项目来说，少一点失控比快几分钟更重要。

六、PR 和远程任务适合边界清楚的工作

Copilot CLI 可以直接进入 GitHub 协作流程。/pr 可以查看、创建、修复或自动处理当前分支的 Pull Request。/delegate 可以把任务交给远程仓库中的 Copilot，让它生成一个 AI 创建的 PR。

/pr create

或者：

/delegate 给设置页增加导出 JSON 配置按钮，保持现有组件风格，补充最小测试，不要修改认证逻辑。

我不会把 /delegate 用在边界模糊的大任务上。比如重构整个权限系统、重新设计订单流程、迁移数据库模型，这类任务更适合先在本地用 /plan 和人工审查收敛方案。/delegate 更适合低风险、范围清楚、结果容易通过 PR 审查的任务。

适合委托的任务包括：

• 补充小范围测试
• 修复明确的 UI bug
• 更新文档或 README
• 调整简单配置
• 增加一个边界清楚的小功能
• 根据 issue 描述实现一个小改动

不太适合直接委托的任务包括：

• 涉及核心业务规则的重构
• 多系统联动的架构调整
• 数据库迁移和数据修复
• 安全策略或权限模型变化
• 需要大量产品判断的需求

/pr 和 /delegate 的价值不在于省掉审查。它们更适合把执行环节往前推，把结果交回 PR 流程。最终还是要看 diff、跑测试、让团队 review。

七、MCP、skills、agents 和 plugins 怎么理解

Copilot CLI 现在的扩展能力不少，容易让人混在一起。MCP、skills、custom agents、plugins、hooks 这些词放在同一篇文章里，很容易写成概念堆叠。我会按用途来分。

扩展能力	解决的问题	适合场景
MCP	连接外部工具和数据源	GitHub issue、PR、Actions、浏览器自动化、内部系统
skills	给 Copilot 注入某类任务说明	前端设计规范、测试生成规则、发布文档格式
custom agents	为特定任务配置专用 agent	code review、代码探索、研究报告、命令执行
plugins	打包和分发一组 agent、skills 或工具	团队共享工具能力
hooks	在关键操作前后加入控制逻辑	审计、拦截高风险命令、统一执行检查

7.1 /mcp 用来接外部上下文

/mcp 可以查看、添加、编辑、删除、启用或禁用 MCP server。Copilot CLI 也内置了一些 MCP server，比如 GitHub API、Playwright、fetch、time 等。GitHub MCP 可以访问 issue、PR、labels、commits、code search、Actions 等信息。

这让 Copilot CLI 不只看本地文件，也能看项目协作信息。比如排查一个 CI 问题时，它可以结合 workflow run 日志；处理一个 issue 时，它可以读取 issue 描述、相关 PR 和提交历史。

MCP 的风险也要注意。外部数据源越多，权限边界越重要。团队使用时应该明确哪些 MCP server 允许使用，哪些必须走审批，哪些只能在隔离环境里运行。

7.2 skills 更适合沉淀团队规范

skills 可以把某类任务的说明写成 SKILL.md，在需要时注入 agent 上下文。比如团队有一套前端组件规范、测试用例格式、发布文档结构，就可以用 skills 固化下来。

使用时可以通过 /skills list 查看可用 skill，也可以添加或 reload skill。

/skills list
/skills reload

我觉得 skills 很适合技术博客、团队代码规范和重复任务。比如让 Copilot 写测试时，总是按照团队约定的命名方式、mock 方式和断言风格执行，而不是每次重新在 prompt 里写一遍。

7.3 custom agents 适合固定角色

custom agents 更像给 Copilot 定义一个专门角色。比如 code-review 用来审查 diff，explore 用来快速探索代码库，research 用来生成调研报告，task 用来执行测试、构建、lint 这类命令。

项目级 agent 可以放在 .github/agents/，用户级 agent 可以放在 ~/.copilot/agents/。这种设计适合团队把常用角色沉淀下来，比如：

• 前端审查 agent
• 安全审查 agent
• 文档生成 agent
• 数据库迁移审查 agent
• 测试补全 agent

我不会一开始就创建很多 agent。先用默认能力跑通几个任务，再把高频、规则清楚的任务抽成 agent，更容易维护。

7.4 hooks 要谨慎启用

hooks 可以在 Copilot 执行关键操作前后介入，比如工具调用前、工具调用后、会话生命周期事件等。企业环境里，它可以用来记录审计日志、禁止危险命令、拦截敏感路径、强制执行检查。

但 hooks 也会增加复杂度。配置不当时，开发者会觉得工具总是在阻塞自己。我的建议是从高风险场景开始，比如禁止删除生产配置、禁止访问某些目录、限制网络请求。不要一上来给所有操作都加复杂 hook。

八、团队落地要先选低风险场景

Copilot CLI 进入团队以后，最怕一开始就被当成万能自动化工具。团队成员熟悉程度不同，项目风险不同，权限策略也不同，直接全面放开容易出问题。

我会从低风险场景开始推广。

第一类是解释型任务。比如解释错误日志、复杂命令、测试失败原因、历史脚本。这类任务主要读信息，不会直接修改文件。

第二类是辅助审查。比如在提交前运行 /review，让 Copilot 先看一遍 diff。它不能替代正式 code review，但可以提前发现一些低级问题。

第三类是文档沉淀。比如用 /research 做技术调研，用 /share 导出会话或研究结果，再放进团队文档里。

第四类是边界清楚的小修改。比如补测试、改文案、整理 README、修复 lint 问题。这些任务可以逐步尝试 /delegate 或更高自动化权限。

企业环境里还要提前配置几件事：

配置项	建议
组织策略	明确哪些团队可以使用 Copilot CLI
权限模式	默认保持确认，少用全放开模式
MCP server	先启用必要服务，外部服务走审批
hooks	从敏感路径和高风险命令开始
日志审计	保留关键操作记录，方便回溯
使用规范	给团队准备几条示例工作流

Copilot CLI 最适合成为团队里的日常辅助工具，而不是一上来就接管所有开发流程。先让大家在安全任务上用起来，再逐步放到更复杂的工作里。

九、几个我会长期保留的工作流

工具真正融入开发，不是因为命令多，而是因为有几个固定组合能反复使用。

9.1 接手陌生模块

/cwd apps/api
/clear

接着输入：

请梳理当前目录的认证流程，重点说明入口文件、token 生成、刷新逻辑和错误处理。先不要修改文件。

如果输出有价值，可以导出：

/share file session ./docs/auth-flow-notes.md

9.2 做可控重构

/plan 把当前模块里的重复参数校验抽成独立函数，保留现有接口返回结构，先输出计划。

执行后检查：

/diff
/review 检查这次重构是否改变行为，重点看错误处理和测试覆盖。

9.3 排查 CI 失败

这是 GitHub Actions 的失败日志。请先判断最可能的三个原因，按排查顺序输出，不要修改文件。

如果需要读取 workflow：

/add-dir .github/workflows

9.4 交给远程 agent 做小任务

/delegate 修复设置页导出按钮的空状态提示，保持现有样式，补充最小测试，不要修改数据结构。

9.5 做技术调研并沉淀文档

/research 当前项目从 Jest 迁移到 Vitest 的工作量和风险
/share file research ./docs/vitest-migration-research.md

这些组合比背命令列表更有用。命令是工具，工作流才会真正改变开发节奏。

总结

GitHub Copilot CLI 的价值，不只是把 Copilot 搬到终端里。真正值得使用的地方，是它把终端里分散的开发动作串成了一个连续流程：查看目录、控制上下文、规划任务、修改文件、审查 diff、创建 PR、导出结果。

我会把它当成三层工具来用：

• 第一层处理上下文和会话，比如 /cwd、/add-dir、/context、/compact、/clear、/resume。
• 第二层处理开发任务，比如 /plan、/diff、/review、/pr、/delegate、/undo。
• 第三层处理团队扩展，比如 /mcp、/skills、custom agents、plugins、hooks、/share、/research。

它不会自动解决所有开发问题。提示词太模糊、权限放得太开、任务边界不清楚，仍然会让结果失控。用好 Copilot CLI 的关键，是先把它放在合适的工作流里，让它做能观察、能回滚、能审查的事情。

从小任务开始，把上下文、权限和 diff 管住，再逐步引入 agent、MCP、skills 和远程委托。这个顺序更适合真实项目，也更容易让团队接受。