GitHub Actions

它是什么

想象有一份清单，在你每次保存工作时都自己跑一遍——"跑测试、构建、放上线"——而你一根手指都不用动。这就是「/CD（Continuous Integration / Continuous Delivery，持续集成 / 持续交付）」：替你检查代码并发布上线的自动化。GitHub Actions 是 GitHub 内置的 CI/CD 系统。你在仓库里添加一个「YAML（一种便于人类阅读的纯文本设置文件）」来描述工作流（workflow）——也就是在 push、或定时计划等事件发生时自动运行的一组步骤。每个工作流都在 GitHub 托管的机器（称为"runner"，即 GitHub 为这趟活儿租给你的一台全新电脑）上运行，因此你无需管理任何自有服务器就能测试、构建和部署代码。它是把"代码已推送"自动化到"应用已上线"最常见的方式。

优势

直接内置于 GitHub——无需另设独立的 CI 服务。
由仓库事件触发：在每个 PR（pull request，一项待定变更）上跑测试，在每次推送到 main 时部署。
庞大的可复用 action 市场，覆盖常见任务（环境配置、部署、检查）。
为 Linux、macOS 和 Windows 提供托管 runner；对公开仓库有慷慨的免费分钟数。
提供密钥管理和环境保护，让部署更安全。

取舍

YAML 工作流很快就会变复杂；调试失败的流水线（即那一连串自动步骤）可能很繁琐。
私有仓库的分钟数是计量收费的，重度使用会花钱。
由于它在远程 runner 上运行，在本地重现失败很别扭。
第三方 action 很方便，但它们是需要审核的供应链依赖。

最适合

直接从仓库自动化测试、构建和部署——在每个 pull request 上运行你的测试套件，并在 main 更新时部署到你的托管服务（比如 Cloudflare Pages）。

与 vibe coding 的契合度

GitHub Actions 与 vibe coding 是绝配，因为 AI 助手可以为你写出整条流水线。让它添加一个工作流，安装依赖、运行测试，并在推送到 main 时部署——它知道常见的 action 名称和 YAML 结构。真正的价值在于它是一张安全网：一旦每次变更都自动跑测试，AI 就无法悄悄合入会破坏构建的东西。提示：告诉 AI 助手你的托管服务和包管理器，好让它挑选正确的部署 action 和缓存设置，并把密钥放在仓库设置里，绝不要放进 YAML。

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm test