CI 是 GitHub 协作流程里的最低质量验收。
它不能保证代码一定正确，但可以防止明显的编译失败、测试失败、格式错误和基础安全问题直接进入主分支。
CI 的价值不只体现在“更快上线”，更重要的是让合入决策更可靠，让 reviewer 和作者对变更质量更有信心。相关研究整理见 Git 工作流经验研究笔记。
一个正式团队至少应该有：
示例：
name: ci
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run build
不同语言的命令不同，但原则一致：PR 合入前必须能自动验证最关键路径。
在 GitHub 分支保护中，可以把 CI job 配成 required status checks。
这样 PR 没通过 CI 时不能合入主分支。
多仓库团队不要在每个仓库复制粘贴一份 workflow。
推荐把公共检查抽成 reusable workflows，再由业务仓库按版本调用。这样可以统一 job 名称、权限、缓存策略和基础检查，也更容易配合组织级规则推广。
详细见 Reusable Workflows。
AI 生成代码后，CI 是最低质量保障。
建议至少检查：