如何用 AI 操作 GitHub 命令行

查 PR 和 CI 状态，为什么总要来回切网页

用 GitHub 协作时，很多排障动作被网页操作拖慢。一个 PR 的检查项哪些没过、卡在哪一步，要点进 Checks 页层层展开；想看最近一次 workflow run 为什么失败，得在一堆成功的绿勾里翻出那条红叉，再点进去找出错步骤的日志；要批量看近期 Issue 或按特定字段筛选，网页界面又给不了结构化结果。这些任务本可以在命令行一次拿到答案，却散落在多个页面里反复跳转。

这个技能用 gh 能帮你做什么

它围绕 gh CLI 把 GitHub 上的查询和协作动作打包起来。CI 方面，用 gh pr checks、gh run list 和 gh run view 查看检查状态，定位某次 workflow run 的失败日志和出错步骤，只摘失败项、不展开成功项。Issue 方面，用 gh issue list、view、create 完成查询和创建结构化的 Bug 报告。高级查询方面，用 gh api 配合 --json 与 --jq 取出普通子命令拿不到的字段并做过滤。最后它会清理终端和 HTML 标记，按用户意图把结果整理成摘要、表格或解释。需要注意，在非 Git 目录中操作时，它会始终指定 --repo owner/repo 或直接用 URL，以保证定位到正确仓库。

怎么用它

用法是把要查的 PR、CI 或 Issue 用自然语言说清楚，由它选用合适的 gh 命令并整理结果。例如可以这样对它说：

它适合这些场景：查看某个 PR 的检查项是否通过并定位失败工作流日志；项目维护者要列出近期 Issue 或创建一条结构化 Bug 报告；不在 Git 仓库目录中操作 GitHub、需要显式指定 owner/repo；需要用 GitHub API 查询普通子命令无法直接返回的字段。

大家常问

GitHub 命令行 gh 是什么，跟在 GitHub 网页上点按钮操作有什么区别？

gh 是 GitHub 官方提供的命令行工具，让你在终端直接操作 GitHub。它和网页点按钮调用的其实是同一套 GitHub API，区别在于网页要加载页面、等待渲染、点开层级才能拿到一项信息，而 gh 在终端一行命令直接发 API 请求拿结果，还能用脚本批量执行，并和 jq、grep、管道组合使用。

为什么用 gh pr checks 命令查 PR 检查结果，会比在 GitHub 网页 Checks 页里层层展开看要快？

因为网页 Checks 页是单页应用，要先加载几百 KB 到几 MB 的资源，再分多次 API 请求拉 Check Suite 和 Check Run，每展开一层就再发一次请求重渲染 DOM。gh pr checks 走的是已存在本地的认证 Token，省去 Cookie、Session、CSRF 那套验证链，直接一次 API 请求把 PR 关联的所有 check 平铺打印，省掉渲染和层层点击的开销。

gh run list 和 gh pr checks 都能看 CI 状态，怎么区分什么时候该用哪一个？

两者数据层级不同。gh run list 拉的是仓库级 Workflow Run 列表，可按 workflow 文件、分支、事件类型筛选，适合追溯历史失败、查看不挂在 PR 上的定时或手动 run。gh pr checks 拉的是某个具体 PR 的 Check Suite 和 Status Check 聚合，能看到外部系统提交的 status，适合 Review PR 时判断能不能合并、要不要 watch CI 跑完。

为什么在不是 Git 仓库的目录里用 gh，必须加 --repo owner/repo 才能查到东西？

因为 gh 默认靠当前目录的 .git/config 里 origin 远程 URL 推断 owner/repo，作为 gh pr、gh issue、gh workflow、gh release、gh secret 的目标。一旦目录里没有 .git 文件夹，这条推断就断了，gh 不会去扫账号下所有仓库猜你想操作哪个，所以会抛错，要求你用 --repo owner/repo 或设环境变量 GH_REPO 显式指定仓库。