CI 基础：让检查自动化

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，在每个 pull request 上运行我们的 lint、类型检查和测试。"

CI 的重点并不是自动化本身，而是它把检查从你的记忆里挪到了流水线里——在那里，再疲惫的夜晚也跳不过去。等基本流程跑出绿灯之后，有两个值得做一次的升级。第一，把这些检查设为主分支上的必需状态（GitHub 上的"分支保护规则"），这样一个红色的构建会真正卡住合并按钮，而不只是显示一个你可以无视的警告。第二，当 CI 失败时，把失败日志直接贴给 AI："这次运行的 CI 失败了，这是输出——诊断并修复它。" 日志是一份精确的、机器生成的 bug 报告，而这恰恰是 AI 最擅长据以行动的那种输入。