gh：把整个 GitHub 装进终端

先对号入座：很多人装了 gh（GitHub CLI），用法停留在 gh pr list 和 gh pr create，偶尔回网页点两下，感觉它是个可有可无的补充。

翻一遍官方手册会发现格局完全不对。git 和 gh 的分工是一句话的事：git 管你本地的代码，gh 管 GitHub 平台上的一切——PR、Issue、Actions、Projects、Codespaces、Release、Secret，全在命令行里。而且 2026 年的手册里，gh agent-task 和 gh skill 已经和根命令并列——GitHub 官方把 Agent 也接进了这条通道。

三种形态，一个工具

交互式日常。 gh pr status 一条命令汇总"等我 review 的、我打开的、提到我的"三张清单；gh pr checkout 把别人的 PR 拉到本地；gh run watch 终端里盯 CI 流水线，不用刷网页。

脚本自动化。 这是 gh 比网页强的根本原因：--json 输出结构化数据，--jq 服务端过滤。GitHub 的状态从"网页里的信息"变成可以管道处理的数据流：

gh pr list --json number,title,headRefName --jq '.[] | select(.headRefName | startswith("fix/")) | "#\(.number) \(.title)"'

这条管道筛出所有 fix 分支的 PR 编号和标题——所有 GitHub 自动化的起点都是这个模式。

Agent 通道（新边界）。 gh agent-task create/list/view 让 Agent 领任务干活，gh skill install/search/publish 管理 Agent Skills。gh 正在成为"人"和"Agent"共用同一条 GitHub 通道的地方。

三个逃生舱，记住能力边界就不慌

gh api：终极逃生舱。 所有官方命令没覆盖到的 REST 端点直连——不用自己搞 token、拼 curl、处理分页。这意味着 gh 的能力边界等于 GitHub API 的边界，官方命令只是常用路径的快捷方式。

gh extension：社区扩展。 Go/Python/Shell 写的二进制或脚本挂成 gh xxx 子命令。

gh alias：轻量组合。 高频命令组合起个短名，还能批量导入。

配置面刻意做得极小：认证两条路（交互 gh auth login 或脚本 GITHUB_TOKEN），没有守护进程没有本地数据库——gh 是无状态的壳，所有真状态在服务端。这让它在 CI 环境里几乎零成本。

两条红线

Token 权限即天花板。 给太大，脚本一处注入全盘暴露；给太小，自动化跑到一半 403。最小权限 + 按仓库限定是底线；脚本里不检查退出码（gh help exit-codes 专门有文档），自动化会静默烂掉。

新命令还挂着 preview 标签。 agent-task 和 skill 的接口可能变，生产自动化别急着深度依赖。

聊两句：你平时高频用 gh 的哪几个命令？有没有一条"用了就回不去"的 gh 管道——比如 CI 失败自动重建、PR 提醒进终端？评论区贴出来，我置顶我自己每天跑的三条。

往期：Cursor 三课、扫描 PDF 转 EPUB、双模型流水线都在主页；下一篇聊 PoC、MVP 的顺序——顺序错了钱就白烧。关注不迷路。