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 最擅長據以行動的那種輸入。