CI 基础：让检查自动化
（持续集成，Continuous Integration）是一个机器人，每次你推送代码时它都会运行你的那些检查，这样你就不会忘记去运行它们。大多数平台只需一个文件就能搞定。下面是一个最小化的 GitHub Actions 示例：
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm run lint
- run: npm run typecheck
- run: npm test
现在每一次推送都会自动经过 lint、类型检查和测试。如果有任何一项失败，你会在代码能被合并之前看到一个红色标记。你甚至可以让 AI 为你的技术栈写好这个文件——"加一个 GitHub Actions workflow，在每个 上运行我们的 lint、类型检查和测试。"
一旦打开分支保护，红色的检查就不只是警告你——它会在构建重新变绿之前，从物理上锁住合并按钮：
pull request
│
▼
┌──────────────┐ 全部通过 ┌───────────────┐
│ CI runs │ ───── ✓ green ─────▶ │ 允许合并 │ ──▶ main
│ lint · types │ └───────────────┘
│ · tests │ 有任一失败
└──────────────┘ ───── ✗ red ──────▶ ┌───────────────┐
│ 阻止合并 │ 🔒
└───────────────┘
修复、推送、重跑
CI 的重点并不是自动化本身，而是它把检查从你的记忆里挪到了流水线里——在那里，再疲惫的夜晚也跳不过去。等基本流程跑出绿灯之后，有两个值得做一次的升级。第一，把这些检查设为主分支上的必需状态（GitHub 上的"分支保护规则"），这样一个红色的构建会真正卡住合并按钮，而不只是显示一个你可以无视的警告。第二，当 CI 失败时，把失败日志直接贴给 AI："这次运行的 CI 失败了，这是输出——诊断并修复它。" 日志是一份精确的、机器生成的 bug 报告，而这恰恰是 AI 最擅长据以行动的那种输入。