第 8 章 CI/CD · 不过检查，不许上线

easycode · Agent Skill

第一册第 11 章见过流水线，第二册第 10 章在 .github/workflows/ 里认过它的脸。这一章把它接上前两章，变成制度的最后一环，CI/CD，把"检查"变成"门禁"。

CI（持续集成）说的是每次 push，机器自动跑一遍全部检查，构建通不通，测试过不过，链接死没死。CD（持续部署）说的是检查全绿，自动上线。合起来一句话，红灯挡路，绿灯放行，全程无人值守。读一个真实形状的登记表，GitHub Actions 的 workflow，第三册第 6 章的 YAML 现学现用。

on: push
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm test
      - run: npm run docs:build

逐行读。每次 push 触发，租一台干净机器，取代码，装 Node，按清单装依赖，跑测试，跑构建。任何一步失败，整条红灯，PR 上一个大大的 ❌，不过检查，不许合并。这就是第 6 章说的"从文字毕业成机制"的最高形态，规矩不再依赖任何人的自觉，包括你的。

你的站每天都在演示这套东西。books.stickmancharles.com 每次 push，Cloudflare 拉代码，跑 npm run docs:build，先装配再构建，顺带校验全站每一条内链，全绿才上线。有一次你写错一个章节链接，构建直接红灯把它挡在了线下。那一次，这套机制就挣回了它的全部成本。CI 拦住的每一个错误，都是没能到达用户的错误。

CI/CD 和搭档的关系值得单独说，门禁是给 AI 产量配的刹车。它一天能发起十次改动，你不可能每次都全量人肉验证。于是分工落定，机器审回归（测试加构建），人审意图（PR 里读它想干什么）。两道关各司其职，速度和下限同时保住。

最后回收一个决定，为什么 PDF 不进 CI（当时的任务书里定的）？CI 处理的是构建产物，每次 push 都该重新生成的东西。PDF 是发行物，需要被主动冻结的版本。两者的区别下三章还会遇到，不可逆的东西，永远不交给自动化。

关键领悟

CI/CD 把第 7 章的测试从"可以跑"变成"必须过"。机器审回归，人审意图，这是 AI 高产时代唯一撑得住的验收分工。

试一试

给你的任意一个仓库加上面那条最小 workflow（没有测试就先只跑 build）。然后故意 push 一个坏提交，亲眼看一次红灯。见过红灯的人，才真的信任绿灯。