CI/CD 怎么用：AI 改完的代码，凭什么判断它能上线

0030 秒速览：三句话，和你的下一个动作

读完这篇你能做到两件事：① 打开 AI 给你的那份流水线配置，两分钟内说出「它什么时候跑、跑哪几步、哪一步失败会挡住合并」；② 知道在 AI 编程里拿它当验收机器用，而不是当省事工具用。

如果只记三句话

接下来 60 秒：你的第一个动作

打开你的一个 GitHub 仓库，在网页上新建文件 .github/workflows/hello.yml，粘贴下面这九行（一行都不用改），提交：

name: 我的第一条流水线

on:
  push:

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "流水线跑起来了"

然后点仓库顶部的「Actions」，看它从黄点变成绿勾。这一步值的不是那条命令行，是你亲眼看到的那个状态变化。完整的走查（包括怎么故意弄红它、看红灯长什么样）在 §05。

关键数字（先有个量级感）

不确定自己该看哪一节？

01CI 和 CD 是两个东西，而 CD 还是两个意思

你大概率已经摸到过它的一半了：某个项目你把它连上了 Vercel（或 Cloudflare Pages、Netlify），之后你在本地改完代码一推送，过一分钟线上就变了。那条链子里，平台其实替你做了三件事——拉取新代码、重新构建、把结果发布出去。CI/CD 就是把这条链子写成明文清单、并且让它在每次改动时都自动跑的东西。

所以先别背三个字母。先把「它不是什么」划清楚，因为绝大多数人第一次听到 CI/CD 时，脑子里装的是别的东西。

它不是什么

它是什么：一句话版本

「持续集成」这四个字到底在集成什么

CI 是 Continuous Integration 的缩写。翻译过来是「持续集成」，这四个字里最费解的是集成——它不是「集成开发环境」那个集成，而是软件行业的一个旧词，意思是把不同人（或不同时间）写出来的改动合成到同一份代码里。

持续的意思是：不要攒着。别等三个月发布一次，那时候把大家的改动合到一起。而是每改一点就合一次，一天合好几次。

为什么非要频繁合？因为分歧会随时间长大。假设你和另一个人（或者你和三天前的你自己）同时改了一个文件：改动放一天，冲突可能只是同一行；放三个月，两边都基于完全不同的底稿写了几百行，最后合并就变成一件需要重新做一遍的工作。软件行业把这种「两份改动合不拢」的情况叫做冲突，合的动作叫合并。

CD 有两个意思，而且两个意思差别很大

CD 这个缩写是有歧义的，官方文档和行业书里经常混用，这是新手最容易被绕晕的一处。它其实是两个不同的承诺：

这两个词只差几个字母，风险却完全不同：持续交付错了，你还有一道人工闸门；持续部署错了，坏版本会自己走到用户面前。所以别人跟你说「我们上了 CD」时，值得追问一句：是能一键发，还是自动发？——这句话能立刻把对方的话分出层级。

那 CI/CD 里到底有几步

把缩写拆开，一条典型的流水线是这样的（每一步的名字你都可能在别人的 YAML 里见到）：

这六步里，只有最后一步是「发布」。前面五步的存在意义是同一件事：让坏东西到不了最后一步。

易混的几组词，先用一张表分清

没有它的时候，会发生什么

不装流水线，不代表你没有流程，只代表流程跑在你脑子里。手动发布会有三个几乎必然的后果：

而在 AI 编程的场景里，还有第四个后果，比上面三个都严重：AI 一天能改十次，你验不完。验不完的时候人只有两条路——要么停下来不验，要么开始相信 AI 说的「改好了」。你手上那十几个半途停下的项目，多半就停在两种感觉之间：「让它继续改，我越来越不知道它在干什么」和「我自己又判断不了对不对」。

流水线是这两难之间少见的出路：它不要求你看懂代码，只要求你把「什么样算过关」写成机器能执行的话。这件事你做得来，而且做完之后，判断权就回到你手上了。

02跑在谁的机器上：「我本地是好的」为什么不算数

这一节讲的是全篇最该先建立的一个事实。它只有一句话，但它能解释你以后遇到的一大半奇怪现象。

那台机器长什么样

它是一个真实存在的计算机，只是你看不见它。它的特点是：干净——上一次运行的残留不会留下，你的桌面、你装过的软件、你电脑里的密码，它一样都没有。临时——跑完就扔，下次是新的一台。由平台统一维护——操作系统和常用工具是预装好的，但你自己项目依赖的那些库，得每次现装。

行业里管这台机器叫 runner（执行器）。平台提供的叫 托管 runner；你也可以把自己的一台服务器接进去当 runner（叫自托管 runner），但那样你就得自己负责它的安全、补丁和在线率——除非你的项目必须访问内网或特殊硬件，否则没必要。

这个事实解释了三种「怪事」

怪事一：我本地跑得好好的，为什么它说失败？

因为「你本地」和「那台机器」是两套不同的环境，你的电脑上有很多你没意识到的东西：装过的全局工具、缓存下来的依赖、设好的环境变量、特定版本的系统。流水线失败的原因里，很大一部分不是「代码写错了」，而是「那台机器上少了一件事」。

最常见的具体形态：你在本地装依赖时装了一堆东西，机器上重新装一遍时，某个包的版本和你的不同，于是行为不一样。这不是流水线的毛病，这是流水线替你发现的、你原本不知道的隐患——你的项目其实一直依赖着「你电脑的当前状态」，而这种依赖是无法交给别人的。

怪事二：为什么每次都要重新装依赖、重跑一遍？

因为机器是新的，什么都不记得。这正是它可信的原因（结果只取决于代码和清单，不取决于「上次留下的什么」），代价是每次都要从头来。为了不让「从头来」太慢，各平台都提供了缓存机制：把「装依赖」的结果存起来，下次直接取。这就是你在别人的 YAML 里看到的那些 cache 步骤存在的原因——它们不是装饰，是在买时间。

怪事三：为什么不干脆把数据库密码写进去？

因为那台机器是别人维护的、每次是新的、而且执行过程会留下日志。给它什么，它就能看到什么；日志里出现什么，能看到日志的人就能看到什么。第 07 节整节都在讲这件事，这是全篇唯一一处「不看会真的出事」的地方。

你会在 YAML 里怎么指定「要一台什么样的机器」

清单里有一行专门写这个，叫 runs-on（跑在什么上）。它的值是一串标签，比如：

# 要一台最新版 Ubuntu 系统的机器（最常用的选择）
runs-on: ubuntu-latest

# 也可以点名要 Windows 或 macOS（比如要给 iPhone 打包）
runs-on: windows-latest
runs-on: macos-latest

标签里的 latest 意思是「当前默认的那个版本」。这一点值得注意：它会在平台更新默认版本时悄悄变化，所以「今天能跑」不代表「三个月后还能跑」。这也是「可核对断言」里要盯的一类东西。

「那台机器免费吗」——钱的常识

GitHub 的托管机器对公开仓库是不限时长的；私有仓库每月有一份免费额度，用超了按分钟计费，不同套餐额度不同。这个额度会变，具体数字以官方计费页为准（第 15 节给了链接）。你要建立的是量级感：一条只跑几分钟检查的流水线，在一个人的项目里几乎不可能花到钱；真正吃时间的是「每次都在全新机器上重装一大堆依赖」这类没加缓存的配置。

03一次 push 之后，机器按什么顺序干活

这一节把「按清单执行」这句抽象的话，摊成一次真实的运行过程。看完你会有一个能立刻用上的能力：打开任何一个项目的流水线页面，你能看懂现在进行到哪一步了。

从你按下推送，到红灯或绿灯亮起

这一路上出现的九个词，各在哪一层

非程序员看流水线页面时最大的障碍是：一堆词都在，但不知道谁包含谁。下面这张表按「从大到小」排，看完你会知道每个词指的是页面上的哪一块。

作业是同时跑还是排队跑

默认同时跑：一份清单里写三个作业，平台就分配三台机器，三个一起开工。想让谁等谁，要显式写出来，用 needs（需要）这个词：

jobs:
  # 作业名你随便起，这里叫 check
  check:
    runs-on: ubuntu-latest
    steps:
      - run: echo "先做检查"

  # 这里写 needs: check，意思是「等 check 成功了再开始」
  deploy:
    needs: check
    runs-on: ubuntu-latest
    steps:
      - run: echo "检查通过了，才轮到发布"

这就是「让坏东西到不了发布」在文件层面的样子：发布那个作业需要检查作业成功。你以后读配置，看到 needs 就该意识到这里有一道顺序上的关卡。

界面上你只需要看三处

第一次打开流水线页面，日志会长得吓人。实际上验收只需要看三处：

04读懂 AI 写的那份 YAML：九个词逐词拆

你不必会写，但必须会读——因为这份文件就是「机器判断你项目的规则」。AI 写它只需要几秒，而它写错了，你手上不会有任何提示：不会报错，不会有人告诉你，只会安安静静地什么都检查不了。这一节的目标是让你能在两分钟内回答：「这份配置，在我的仓库里什么时候会跑、跑哪几步、哪一步失败会挡住合并。」

先说清楚 YAML 是什么，以及它为什么这么容易错

YAML 是一种纯文本的填写格式，用缩进表达「谁属于谁」，像抽屉套抽屉：缩进多一格，就表示「这一行属于上面最近的那一层」。

九个词，逐个拆

下面九个词覆盖了绝大多数 GitHub Actions 配置的骨架。每一个都给你「它回答什么问题」和「长什么样」。

还有两个你会在稍复杂的配置里遇到，先认个脸：if（「满足条件才跑这一步」，它是「某一步被跳过」的最常见原因）、permissions（「给这段自动化多大的权限」，默认偏宽松，是安全审查的重点）。

一份带注释的最小配置，逐行读一遍

# 这份清单的名字，会显示在页面上
name: 基础检查

# 什么时候跑：有人推到 main 分支，或有人提交合并请求时
on:
  push:
    branches: [main]
  pull_request:

jobs:
  # 作业名：检查（这个名字会出现在页面上，也会被用来做「必须通过」的规则）
  check:
    runs-on: ubuntu-latest        # 用哪种机器
    steps:
      # 第 1 步：把这份代码下载到机器上（几乎所有清单的第一行）
      - uses: actions/checkout@v5

      # 第 2 步：装好指定版本的 Node.js
      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # 第 3 步：装项目依赖
      - run: npm ci

      # 第 4 步：这就是「检查」本身——失败了整条流水线就变红
      - run: npm run lint
      - run: npm test

注意这份配置里没有一行是「发布」。它只做一件事：每次改动都替你验一遍。对绝大多数一个人维护的项目来说，这已经是最值钱的那一半了——发布可以继续用平台自带的自动部署。

AI 写这份文件时最常出错的三处

两分钟读懂一份配置：五个问题

05最小例子：给一个半成品项目接上第一条流水线

这一节全程在 GitHub 网页上完成，不需要你在本地装任何东西。整个过程的目标不是「学会写 YAML」，而是拿到一次亲眼看见的绿灯和一次亲眼看见的红灯——因为你要建立的能力是「判断」，而判断只能从见过开始。

先对号入座：你是哪一种起点

第一段：先看见一次绿灯

这段做完大约三分钟。你会发现「配流水线」这件事本身并不难——难的是它到底该检查什么。

name: 我的第一条流水线

on:
  push:
  workflow_dispatch:

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "流水线跑起来了"
      - run: echo "当前时间 $(date)"

第二段：让机器真的替你检查

第一段那份配置其实什么都没检查（echo 只是打印一句话，永远成功）。现在换成一份真正会拦人的。前提：你的项目里已经有 package.json（Node.js 项目的清单文件：写着它要用哪些外部库，以及几条可以一条命令跑起来的任务），并且它有 lint 和 test 这两条命令（没有的话，先让 AI 帮你加——这件事本身就是个好任务，第 08 节会讲怎么交代）。

name: 检查

on:
  push:
    branches: [main]
  pull_request:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm          # 把「装依赖」的结果存起来，下次直接取，省时间

      - run: npm ci            # 严格按锁文件装依赖（比 npm install 更适合流水线）
      - run: npm run lint      # 检查格式与低级错误
      - run: npm test          # 跑测试——这一行才是「检查」的主体
      - run: npm run build     # 确认能构建出成品

几个词顺手解释掉：锁文件（package-lock.json）是记录「精确到小版本」的依赖清单，它保证你机器上装的和别人装的完全一样，所以流水线上用 npm ci（严格照锁文件装）而不是 npm install（可能顺手升级）。node-version: 22 是你指定的运行环境版本，写死它才有可复现性；不写就会用平台默认的，而默认会变。

第三段：静态站自动上线（GitHub Pages）

如果你做的就是一堆 HTML/CSS，这一段直接给你结果：每次推到 main，网站自动更新。这份配置的核心不是命令，而是最上面那段权限声明和并发控制——它们是官方模板里就有、而你最容易在抄的时候抄丢的部分。

name: 发布静态站

on:
  push:
    branches: [main]
  workflow_dispatch:      # 允许在页面上手动点一下就跑

permissions:              # 只给这件事需要的权限，其余一律不给
  contents: read          # 读代码
  pages: write            # 写托管页面
  id-token: write         # 领取一次性凭证（发布类动作需要）

concurrency:              # 同一时间只允许一次发布，避免两次发布互相踩
  group: pages
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}   # 运行页面上会显示线上地址
    steps:
      - uses: actions/checkout@v7
      - uses: actions/configure-pages@v6
      - uses: actions/upload-pages-artifact@v5
        with:
          path: .            # 把整个仓库当一个静态站上传
      - id: deployment
        uses: actions/deploy-pages@v5

用之前还要在仓库里打开一次开关：Settings → Pages → Build and deployment → Source 选「GitHub Actions」。不打开的话，流水线会绿着但页面不更新——这是最典型的一种「看起来成功、其实什么都没发生」。

这份配置里最值钱的一课：版本号没有任何二手来源可以信

上面四个现成动作后面跟的版本号，是我在2026-09-23 当天从每个动作的官方仓库逐个数出来的。之所以要专门说这件事，是因为同一天我读到的三个「官方」来源给出了三套不同的答案：

跑通之后，你手里多了三样东西

这一段里最容易卡住的地方

06绿灯不等于挡住合并：让机器真正有否决权

到这里你有了绿灯，但它还只是一条信息。信息不会拦任何人：红灯亮着，你照样点得动「Merge」按钮，AI 也照样合得了。这一步要做的，是把信息换成否决权——这是整篇文章里性价比最高的一次点击。

先分清这两件事

在哪里打开

两条路，选一条即可（两条会同时生效，不是二选一）：

还有一档选项值得知道：「Require branches to be up to date before merging」（合并前分支必须是最新的）。打开它，别人刚合进去的改动会让你的检查重新跑一遍——更严格，也更慢。一个人开发时，可以先用默认、不开它。

这一步里最容易踩的三个坑

为什么一个人开发（还带着 AI）反而更该设

很多人会觉得，「就我一个人，谁会乱合」。但在 AI 编程的场景里，这条规则的真正作用对象不是「别人」：

07唯一一处「不看会真的出事」的地方：密钥

前面六节都是关于「怎么把事做对」；这一节是关于「怎么不出事」。它值得单独占一节，因为流水线里几乎所有严重事故，最后都落在同一件事上：那段自动运行的代码，拿到了不该拿到的东西，而把它拿走的东西不是人写的，是顺着配置进来的。

先看清楚事故长什么样

密钥（行业里也写作 secret、凭据、token、API key）指的是那类「拿着它就能以你的身份做事」的一串字符：数据库密码、云服务的访问密钥、第三方接口的 key、能改你代码的令牌。它在流水线里通常会死在三处：

正确姿势：把密钥放进平台的保险箱，用名字引用

平台的机制很简单：密钥存在仓库设置里，YAML 里只写它的名字，运行时平台才把值注入到机器上。

- run: ./deploy.sh
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

为什么「别人提交的合并请求」拿不到你的密钥

这一条是官方刻意设计的，原话是：

道理很直白：在一个公开仓库上，任何人都可以提交一份合并请求。如果平台把密钥交给这类运行，那等于任何人提一次请求就能把你的密码打出来。所以平台选择扣住不给。

代价是：你那些「需要密钥才能跑」的检查，在外部人提交的合并请求上跑不了。于是就有了一类看起来很聪明的做法——换一个触发方式，让别人的请求也能拿到密钥。这个做法的名字叫 pull_request_target，官方文档称它是最常被误用的触发器，还给这类事故起了个名字叫「pwn request」。

更省事也更安全的做法：让它领一张「临时工牌」

上面讲的都是「怎么保管长期密钥」。还有一条路是干脆不存：让你的流水线在运行时向云服务商换一张几分钟后就失效的临时凭据。这个机制叫 OIDC（你可以就理解成「现场办工牌」）：平台先和云服务商约定好信任关系，运行时由平台证明「这条流水线确实是我这边跑的、跑的是这个仓库的这个分支」，服务商才发一张短命凭证。

原理与配置入口见官方文档：docs.github.com — OpenID Connect。个人项目不必急着上它，但你应该知道「密钥不一定非得存着」这件事存在——它是判断别人建议是否专业的一个标志。

交给 AI 之前的三条红线

这三句之所以必须显式说，是因为 AI 的默认目标是「让这次任务通过」，而权限收紧、密钥外置这类要求，在「让它跑通」这件事上全是阻力。你不说，它多半会选阻力最小的路。

08AI 编程里怎么用：把它当裁判，而不是当省事工具

前面七节讲的都是「流水线是什么」。这一节回答你真正的问题：我带着 AI 写代码，这套东西对我的用处跟对一个程序员一样吗？

答案是：对你更值钱，但值钱的地方完全不同。一个会写代码的人用 CI，图的是「省得我每次手动跑一遍」；你不写代码，图的是——它能把你和 AI 之间那句「我改好了」，换成一件你亲眼看得见的事实。

为什么它恰好补上了你最缺的那块

你的处境是：必须做决定，但判断不了实现。AI 给你一段改动，末尾写着「已修复，测试全部通过，可以合并了」。这句话你没办法核——你既不会读代码，也无法确认它是不是真的跑了测试、跑的是不是那套测试、有没有把跑不过的那几个先删掉。

流水线做的是把这句话变成一条记录：某个时间、某台机器、某个提交、跑了几条命令、结果是什么。它带来三样 AI 的话给不了的东西：

把「完成」的定义写进给 AI 的任务卡

你最缺的东西是一句能照着念的话。下面这段可以直接复制，把方括号里的内容换成你的项目实际情况：

这个任务算完成的定义，不是你说「改好了」，而是：

1. 我能在 GitHub 的 Actions 页面看到这次改动对应的运行，并且它是绿的。
2. 绿的这一次里，下面这些检查都真的跑了（不是被跳过、不是被注释掉）：
   [npm run lint / npm test / npm run build]
3. 你没有为了让它们变绿而删掉或跳过任何测试。
4. 完成后，告诉我：这次运行是第几次、在哪个页面看、我该看到什么。

如果检查不通过，不要说「基本完成」——把失败的那一步日志原文贴给我。

这段话的效果是把验收标准从「形容词」换成「可核对的事实」。它和本仓另一篇《把「批准方案」换成「验收结果」》讲的是同一件事，只是这里连「谁来判断」都交给了机器。

更短的一版，适合你每次只改一小处时顺手带上：

改完先别急着说完成。先推上去，然后去看这次 Actions 运行的结果，
把「第几次运行 + 哪一步 + 什么结论」告诉我，再等我确认。

让 AI 自己读红灯去修——以及为什么必须设两轮上限

红灯的日志正好是 AI 最擅长处理的东西：它是文本、在一个确定的地址上、里面有明确的错误行。所以「失败 → 让 AI 读日志 → 它改 → 再跑一次」这个闭环是可以自动化的，也是 AI 编程里效率最高的一处配合。

让它读日志，而不是让它猜

# 看最近几次运行（哪次红、哪次绿）
gh run list --limit 10

# 看某一次运行里「失败那一步」的日志——这才是有用的那段
gh run view <运行编号> --log-failed

# 懒得重跑一次：让平台把失败的那些作业再跑一遍
gh run rerun <运行编号> --failed

gh 是 GitHub 官方的命令行工具。这三条命令的价值在于：AI 不需要你复述错误。你只要给它运行编号，它自己就能把原文取下来。这比你说「它失败了，好像是缺个包」准确得多——而「准确」正是你付给 AI 的钱。

上限两轮，第三轮换你判断

它会怎么动手脚？有三种形态，都是 GitHub 官方在「如何评审 AI 生成的代码」那一页里点名提醒过的（原文见本节末尾的来源）。好消息是：这三种形态全都不需要你懂代码就能看出来。

让 AI 待在合并请求上：四种现成的自动审查

除了「CI 替你跑检查」，还有另一条路：让 AI 自己来当第一遍审查者。现在主流的几家都提供了现成的东西，全部挂在你已经会用的那套机制上（合并请求 + 状态检查）。

当 AI 自己跑在流水线里：一个真实事故，以及它为什么值得你记住

这一节讲的是一个具体的安全公告。它不是「某个人操作失误」的故事，而是这类自动化的一个结构性风险——你越依赖它，越该知道它的形态。

为什么这件事对你有用：它说明「AI 自动化」和「密钥」放在一起时，攻击的入口不是你的密码，而是 AI 会读的那些文本。在这类流水线里，下面这些东西全都是外部输入，也就是别人可以往里面塞话的地方：

还有一份公开研究得出过同类结论：2026 年 4 月，一家安全研究机构公开了一项实验，把指令藏在 PR 标题和 issue 正文里，让几个主流的 AI 代码审查工具把 API 密钥回帖到了公开页面。需要标注的是：该研究称涉及多家厂商的产品，但我没有找到这些厂商自己发布的公告或编号，因此它属于单一来源——我把它留在这里供你知道有这一类风险，不把它当成已确认的厂商事实。出处见第 15 节。

那几条能真正降低风险的做法

一个人 + AI 的完整流水线，照着搭一遍

把前面所有东西拼起来，一个一个人维护、由 AI 主要写代码的项目，够用的形态是这样三层：

配套的检查配置，就用第 05 节第二段那份，只加一处「把结论写清楚」的小东西——这一步对不写代码的人特别有用，因为你在页面上第一眼看到的就是它：

name: 检查

on:
  push:
    branches: [main]
  pull_request:

jobs:
  check:
    name: 检查（lint + test + build）   # 这个名字会出现在「必须通过」的规则里
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

      - name: 把结论放到运行页面上
        if: always()               # 不管前面成没成，这一步都执行
        run: echo "以上四项全部通过，才算这次改动验收完成"

然后配上一段你和 AI 之间固定的开场话术（每次新任务粘一次）：

规则：
1. 你改完先自己跑一遍 [lint / test / build]，再推上来。
2. 我只看 GitHub Actions 页面上的结论，所以推完告诉我：第几次运行、哪一步、什么结论。
3. 不许为了让检查变绿而删测试、跳过测试、或改松检查命令。要改检查，单独提一次并说明原因。
4. 不许把任何密钥写进文件；需要密钥时告诉我它该叫什么名字、在哪里创建。
5. 遇到连续两次修不好，停下来告诉我你怀疑哪里错了，不要继续试。

09六类场景：你现在该上哪一层

流水线不是「要么全上、要么不上」。它是一层一层加的，而且从最低的那层开始加，收益最大、代价最小。下面这张表按「你现在的状态」分流，照自己的那一行看就行。

10什么时候不该做

这一节和上一节一样重要。流水线有它的反面作用：配错、配早、配了不看，它会把你的判断力换成虚假的安全感。下面五种情况，先别上。

同一件事的更便宜做法（它们为什么不能完全替代）

11六个最常见的误解

12红灯先看这五处 / 绿灯可疑的四种情况

红灯：按这个顺序查，别从头读日志

绿灯：四种「绿得不该信」的情况

13一页纸：以后回来只翻这一节

「我要做什么」→ 抄哪一段

YAML 字段速查

页面上那几种标记

命令速查（交给 AI 用，或你自己敲）

gh run list --limit 10        # 最近十次运行：哪次红、哪次绿、编号是多少
gh run view <编号> --log-failed  # 只看失败那一步的日志（最有用的那一段）
gh run rerun <编号> --failed     # 把失败的作业重跑一遍（怀疑是环境抽风时用）
gh pr checks                    # 看当前合并请求上各检查的状态

三段随时可抄的话

14名词速查：别把它们当成什么用

留一张表在这里，是为了你以后在别处看到这些词时能快速归位——尤其是当 AI 或教程把这些词混着用的时候。

15来源与证据边界

这篇里凡是「现在是多少」「当前叫什么」的判断，都来自下面这些页面，核对日期统一为 2026-09-23。

官方文档（一手）

• docs.github.com — GitHub Actions 计费 — 公开仓库与自托管免费、各档私有仓库的分钟与存储额度（§02、§10）
• docs.github.com — 运行机器计价 — 超额单价与「更大机器永远收费」（§02、§10）
• docs.github.com — 工作流语法 — on / jobs / needs / permissions / concurrency 的权威定义（§03、§04、§06）
• docs.github.com — 触发工作流的事件 — 「手动触发需要配置已在默认分支上」等细节（§12）
• docs.github.com — Actions 快速上手 — 官方最小示例（§05 版本对照表里的「配置文档示例」一列）
• docs.github.com — 依赖缓存 — 缓存 7 天未访问即删除、默认上限 10GB/仓库（§04、§13）
• docs.github.com — 重跑运行与作业 — 页面上「Re-run」与命令行的对应（§08、§13）
• docs.github.com — 使用密钥 — §07 引用那句官方原文的出处，也是配置入口
• docs.github.com — 安全使用 pull_request_target — 「最常被误用的触发器」与 pwn request（§07）
• docs.github.com — 安全使用参考 — 最小权限、掩码、防脚本注入（§04、§07）
• docs.github.com — OpenID Connect — 「向云厂商换短寿命访问令牌」的原理（§07）
• docs.github.com — rulesets 可用规则 与 受保护分支 — 「Require status checks to pass before merging」的准确措辞与入口（§06）
• docs.github.com — 评审 AI 生成的代码 — §08 那三种「为了变绿而动手脚」的官方提醒出处

平台变更公告（本篇里时效性最强的部分）

• github.blog changelog（2026-06-18） — actions/checkout v7 默认拒绝在危险触发下抓取外部分支代码（§05、§07）
• github.blog changelog（2026-06-26） — 对不可信触发只发只读的缓存凭证（§07 的同类加固）
• github.blog changelog（2026-09-17） — ubuntu-latest 将于 2026-10-19 起迁移到 Ubuntu 26.04（§02、§12 那条「代码没改却突然红」）
• github.blog changelog（2026-05-07） — 并发组可排队数量扩大（§04 的 concurrency）
• github.blog changelog（2025-12-16） — 计费调整公告；页内同时保留「自托管将收费」的原始公告与「推迟」的更新（见下方矛盾点）
• github.blog changelog（2026-02-05） — 自托管 runner 最低版本强制要求（§02 提到自托管要多担一份维护）

官方动作仓库（版本号以这里为准）

• actions/checkout（当日最新 v7.0.1）· actions/setup-node（v7.0.0）· actions/cache（v6.1.0）· actions/upload-artifact（v7.0.1）· actions/download-artifact（v8.0.1）
• actions/configure-pages（v6.0.0）· actions/upload-pages-artifact（v5.0.0）· actions/deploy-pages（v5.0.1）
• actions/starter-workflows — 官方入门模板；本文用它作为「官方来源也会滞后」的实例（§05 那张表）

部署平台（「一推就上线」那一层）

• Vercel — 用 Git 仓库部署 — 官方原文：每次分支推送都会产生一次预览部署，生产分支上的改动产生生产部署（页面标注最后修改 2026-09-08）（§09）
• Vercel — Instant Rollback — 把生产环境快速回退到更早的一次生产部署（§09、§12）
• Cloudflare Pages — Git 集成 — 「把 GitHub / GitLab 仓库接上后，推送即自动构建并部署」（§09）
• Netlify — Deploy Previews — 每个合并请求生成一份可预览的部署（§09）
• docs.github.com — 配置 Pages 的发布来源 — Settings → Build and deployment → Source 的两个选项，以及官方推荐「写一个 Actions 工作流来发布」的原文（§05、§12）
• Vercel — 免费档（Hobby）说明 — 「该档仅限非商业、个人用途」的官方原文（§10）
• docs.github.com — GitHub Pages 使用限制 — 站点体积与带宽上限，以及「不打算被当作免费虚拟主机跑商业站点」的原文（§10）

AI 与流水线结合的部分

• Claude Code — GitHub Actions 文档（安装命令 /install-github-app、触发方式与密钥）· anthropics/claude-code-action · 其安全说明（触发者需写权限、默认拒绝机器人）
• 安全公告 GHSA-8q5r-mmjf-575q（CVE-2026-47751，2026-06-10，修复于 1.0.74） — §08 那个真实事故的一手材料
• Codex 的 GitHub 集成（@codex review、@codex fix the CI failures）· openai/codex-action · Codex 手册（套餐与计费口径）
• Copilot 代码审查（默认只留「评论」型审查、不计入批准）· Copilot 云代理（指派 issue 开 PR、会话上限 59 分钟）
• Cursor Bugbot — 自动评审与手动触发（§08 表格里的一行）
• CSA Lab 研究笔记「Comment and Control」（2026-04-17） — 单一来源，见下方证据边界
• zizmor 的检查规则清单 — 一份现成的「流水线配置该被查哪些项」清单（未固定版本、权限过大、危险触发器等）。本文没有让你去装它，只把它的规则当成核对清单来用

本文自己做的核对（不是转述）

§05 那张「三个官方来源给出三套版本号」的表，是本文在 2026-09-23 当天逐个打开各动作仓库的发行页与 README、对照官方入门模板与官方快速上手文档后整理出来的。复核方式：打开对应仓库的 Releases 页面，看排在最上面的大版本号——这一步你自己五分钟就能重做一遍，而且建议你重做，因为它正是本文要教的那个动作。

99一句话总结