GitHub Copilot CLI 最佳实践：把它当成终端助手，而不是自动驾驶

GitHub Copilot CLI 真正有价值的地方，不是“替你操作电脑”，而是把你的意图快速变成一条可审查的候选命令。

这件事听起来不大，但如果你平时终端用得多，收益很直接：少查文档，少切窗口，少去回忆 find、git、gh 那些不值得硬背的参数组合。

前提是你得把它当成草稿生成器，不是权威来源。

这两个心态差很多。前者能提效，后者容易出事。

它适合什么场景

我觉得 Copilot CLI 最适合四类场景：

1. 你知道要什么结果，但记不清语法

   • 找今天改过的大日志文件
   • 看某个文件最近一个月是谁改过
   • 列出当前仓库失败的 workflow run

2. 你需要临时拼一个管道

   • find、xargs、jq、sort、uniq、awk 这种组合
   • 偶尔用一次，没必要背

3. 你想先摸清楚情况，再决定怎么做

   • 看目录结构
   • 看 Git 状态
   • 看 GitHub 上的对象状态

4. 你对当前工具链不够熟

   • 先让它给个方向
   • 但最后还是自己判断

反过来说，如果这条命令你本来就很熟，直接敲通常更快。

先把边界想清楚：??、git?、gh?

这三个入口，最好别混着用。

• ??：本地 Shell 和系统操作
• git?：Git 仓库状态和历史
• gh?：GitHub 平台对象和远端操作

例如：

?? find directories larger than 1GB under the current path

git? show me the commit that introduced this file

gh? list open pull requests assigned to me in this repository

为什么要分这么清楚？因为它们对应的是三种完全不同的风险面：

• Shell 命令可能动你的文件和进程
• Git 命令可能改历史
• GitHub 命令可能直接改远端状态

你脑子里边界越清楚，出错概率越低。

提问时别只说“做什么”，要把约束也说出来

很多人提问太虚，问题不在 AI，而在提示本身没说清楚关键约束。

一个比较稳的提问方式，至少说清楚这四件事：

• 你想得到什么结果
• 作用范围是什么
• 有什么约束
• 这是“先看”还是“直接做”

不够好的提问

?? tar extract

好一点的提问

?? extract archive.tar.gz into ./backup-restore without overwriting existing files

不够好的提问

git? undo last commit

好一点的提问

git? undo the last commit but keep the changes in my working tree, do not delete any files

不够好的提问

gh? workflows

好一点的提问

gh? list the most recent failed GitHub Actions runs for this repository

实战里最好用的 prompt，通常都不花哨，就是三件事：动作、对象、安全约束。

先让它“看”，再让它“动”

这是最重要的习惯之一。

很多命令其实都可以拆成两步：

1. 先列出、先预览
2. 确认无误后再执行

比如清理文件，先看范围：

?? list all .tmp files older than 7 days under ./var

确认路径和结果都对，再问执行版本：

?? delete all .tmp files older than 7 days under ./var

Git 操作也一样。不要一上来就问“怎么回滚”，先问“最安全的方式是什么”。

git? explain the safest way to undo the last pushed commit on a shared branch

这类问题比直接索要命令更靠谱，因为安全方案不一定是最短命令。

GitHub 上的远端操作也一样，先看对象，再做改动：

gh? show the pull requests merged this week in this repository

先把对象、范围、状态都确认清楚，再进入写操作。

把生成的命令当成代码审

Copilot CLI 生成的命令，最合适的处理方式不是“复制运行”，而是“像看同事提交的 patch 一样看它”。

建议按这个顺序审：

1. 目标对象是什么

   • 路径、分支、远端、PR、workflow、进程，具体是哪个？

2. 范围有多大

   • 当前目录、递归子目录、整个仓库、所有分支，还是全部对象？

3. 有没有危险参数

   • -f、--force、--hard、删除、覆盖、历史重写

4. 它默认了什么前提

   • 是不是假设你用的是 Bash？
   • 是不是假设某个工具已经装好？
   • 参数是不是偏 GNU 风格？

5. 引号和转义对不对

   • 特别是路径里有空格、glob、特殊字符时

命令一长，人最容易跳着看。比较稳的方式是从左到右读一遍，确认自己能用中文把它解释出来，再执行。

破坏性命令，标准必须更高

有些命令，不能按“看起来差不多”这个标准来放行。

比如：

• 递归删除
• 权限修改
• reset --hard
• rebase 共享分支
• push --force
• 大批量 rename / move
• 你没核对过目标的 kill 命令
• 批量远端变更

一个很实用的原则是：

只要命令可能破坏数据，就先让它给“预览版”。

例如：

?? show which files under ./build would be deleted if I remove files older than 14 days

git? explain how to revert the effect of the last two commits on a shared branch without rewriting history

gh? show the pull requests that would match this search before I act on them

这不是保守，是减少那种“一条命令省一分钟，后面补锅一下午”的情况。

Shell、Git、GitHub 三类操作，信任级别不一样

很多人容易把所有命令都当成一个风险级别，这是不对的。

Shell

Shell 往往本地破坏面最大，因为它能动任意文件、目录和进程。

所以 ?? 我更建议先用于：

• 查看
• 搜索
• 提取
• 分析
• 一次性管道

对真正修改文件系统的命令，尤其要谨慎。

Git

Git 的危险点不在“看起来复杂”，而在“会不会改变历史语义”。

• git log 很安全
• reset --hard 不安全
• 私人分支上 rebase 可能没问题
• 共享分支上就未必

所以 git? 最有价值的地方，其实常常不是“直接生成命令”，而是解释差异、比较方案、给恢复思路。

GitHub CLI

gh 的对象模型通常比 Shell 清晰，因为它操作的是明确的 PR、issue、run、workflow。
但它的问题在于：很多变更是远端可见的，影响的不只是你自己。

比较稳的方式还是一样：先 list、先 show、先确认对象身份，再做 mutation。

一开始多拿它做“探索”，少拿它做“自动化”

很多事故，都是因为太早把工具当执行器了。

更稳的起步方式是：

• 先让它解释
• 先让它列出
• 先让它帮你缩小范围
• 然后你再决定动不动手

比如下面这些，都是很合适的早期用法：

?? show the largest files in this directory tree

git? show branches merged into main but not deleted

gh? list workflow runs triggered by pull requests

这类场景风险低，但能很快帮助你建立两个东西：

1. 你对工具输出质量的感知
2. 你自己审命令的习惯

这两个东西建立起来之后，再谈更强的操作。

第一个答案不对，就收窄问题，不要原地争辩

命令看起来不对时，最没用的做法是继续用同样模糊的方式重问一遍。

更有效的是收窄范围。

太泛

?? clean logs

收窄后

?? list .log files larger than 200MB under ./logs, sorted by size descending

太泛

git? fix branch issue

收窄后

git? my branch is 3 commits ahead of main and 2 behind; show the safest way to update it before opening a PR

太泛

gh? check CI

收窄后

gh? list failed check runs for the current branch's pull request

问题越具体，它猜的空间越小。CLI 工具里，这一点特别关键。

别为了它重建工作流，把它接到你已有流程里就够了

Copilot CLI 最好用的状态，不是你围着它转，而是它嵌进你本来就可靠的习惯里。

比如：

• 你本来就常用 shell history
• 你本来就有一些安全 alias
• 你本来就会先看 git diff
• 你本来就用 gh 看远端状态

这些都不要丢。Copilot CLI 只是帮你更快把意图变成命令草稿。

如果你已经有安全包装函数，就继续用。
比如你本来就不用直接删除，而是移动到本地回收站，那就继续保持这个习惯，并按这个方向提问：

?? move these generated files to my local trash location instead of permanently deleting them

重点不是它能不能完美理解你的全部环境，重点是你自己得知道你在什么环境里工作。

信任要分阶段建立

别第一天就让它碰高风险操作。

我更建议按阶段建立信任。

第一阶段：只做只读

拿它做：

• list
• find
• filter
• repo 状态查看
• GitHub 状态查看

第二阶段：做低风险本地操作

比如：

• 格式转换
• 解压
• 日志分析
• 分支查看
• 非破坏性的 Git 操作

第三阶段：做可控写操作

比如：

• 范围明确的文件移动
• 你完全理解的分支操作
• 明确指定对象的 GitHub 变更

第四阶段：高风险操作，但必须加预览和备份

只有在前面几阶段都足够稳定后，才考虑：

• 历史修复
• 大批量处理
• 带 force 的操作
• 递归式改动

如果一开始就跳到第四阶段，问题通常不在工具。

一个很实用的执行前检查单

在你按下回车之前，至少问自己这几个问题：

• 我现在所在目录对吗？
• 目标仓库、目标分支对吗？
• 这条命令改的是本地状态、Git 历史，还是 GitHub 远端状态？
• 有没有更安全的预览版可以先跑？
• 每个参数我都看懂了吗？
• 如果同事问我“这条命令是干嘛的”，我能解释清楚吗？

如果最后一个问题答不上来，就先别执行。

最后一句话

GitHub Copilot CLI 不是终端自动驾驶。

它更像一个反应很快的助手：帮你回忆语法、拼装管道、先摸清状态、减少查资料的来回切换。用得对，它很省时间。用得不对，它只是把犯错速度也一起提上去了。

比较成熟的用法，其实就五条：

• 提问时说清意图和约束
• 先探索，再执行
• 高风险命令单独对待
• 分清 Shell / Git / GitHub 的边界
• 慢慢建立信任，不要一步到位

做到这些，它就足够有用了。