AI 时代，CI/CD 不是可选项
最近看到宝玉在 X 上转发了一条关于 Web Infra Team 的讨论。
原帖大意是：AI 进入团队之后，原来的 Web Infra Team 变得很难分组，职责边界也乱了。宝玉的判断更直接：
大部分公司不再需要 web infra team 了，做好各种 skills 和自动化测试部署（CI/CD），积极拥抱 AI 友好的开源项目，简化设计系统到 design.md。
评论区很有意思。有人赞同，认为中小团队确实没必要再维护一堆自研轮子；也有人反驳，说大厂和复杂系统仍然离不开 Infra。后面宝玉补充了一句关键限定：他说的是“大部分”，尤其是那些以前在中小团队里自建了很多私有工具链、私有框架、私有流程的场景。
我觉得这场讨论真正重要的点，不是“Web Infra Team 还需不需要”，而是另一个问题：
当 AI 可以更快地产生代码之后，什么东西会变得更重要？
我的答案是：验证、交付和工程护栏。
这也是 CI/CD 值得认真理解的原因。它不是一个 DevOps 黑话，也不是大厂专属流程。对普通开发者来说，CI/CD 可以从一个非常朴素的问题开始：
我能不能每次把代码 push 到 GitHub 后，让 GitHub 自动帮我测试、构建，甚至部署？
这篇文章就从这个问题讲起。
不要先背概念：CI/CD 解决什么问题？
先想一个最普通的项目。
你写完代码后，通常要做这些事：
- 安装依赖；
- 检查代码格式；
- 跑测试；
- 构建项目；
- 确认页面或接口没有明显问题；
- 部署到服务器、GitHub Pages、Vercel 或其他平台；
- 如果出错，再回滚或重新发布。
如果这些步骤全靠人手动做，问题很快就会出现：
- 今天记得跑测试，明天可能忘了；
- 你本地能跑，别人电脑上不一定能跑；
- 某次小改动看似无害，却把构建弄坏了；
- 部署流程靠记忆，步骤越多越容易出错；
- AI 一次性改了十几个文件，人很难逐行确认所有影响。
CI/CD 的本质，就是把这些重复、容易漏、需要标准化的流程交给机器执行。
flowchart TD
A[开发者提交代码] --> B[GitHub 触发自动流程]
B --> C[安装依赖]
C --> D[运行测试和检查]
D --> E{是否通过}
E -->|通过| F[构建产物]
F --> G[部署或等待人工确认]
E -->|失败| H[阻止合并或发布]
从这个角度看，CI/CD 不是为了让工程变复杂，而是为了让工程流程从“靠人记住”变成“由系统执行”。
CI：持续集成，先防止代码把项目搞坏
CI 是 Continuous Integration，中文一般叫“持续集成”。
听起来有点抽象，但可以先这样理解：
每次有人提交代码，系统自动检查这次改动有没有把项目搞坏。
常见的 CI 动作包括：
- 安装依赖；
- 运行单元测试；
- 运行代码格式检查；
- 运行 TypeScript 类型检查；
- 构建项目；
- 检查安全漏洞；
- 检查文档或配置是否有效。
如果 CI 失败，就说明这次提交至少没有通过基本工程检查。它不一定代表代码逻辑一定错，但它会提醒你：不要直接把这次改动合进主分支，更不要直接发布。
CI 的价值是“尽早发现问题”。
没有 CI 时，问题可能在线上才暴露；有 CI 时，问题在 pull request、push 或 merge 之前就会暴露。
CD：持续交付或持续部署，把发布流程也自动化
CD 有两个常见含义：
- Continuous Delivery：持续交付；
- Continuous Deployment：持续部署。
对刚接触的人来说，可以先不用纠结术语差异，记住一句话：
CI 负责检查代码有没有问题，CD 负责把通过检查的代码发布出去。
它们的区别大概是：
- 持续交付：系统自动准备好可发布版本，但最后是否发布由人决定；
- 持续部署：只要检查通过，系统自动发布到线上环境。
个人项目里最常见的 CD 场景是：
- 前端项目自动部署到 GitHub Pages、Vercel、Netlify；
- 文档站自动发布；
- 后端服务自动构建 Docker 镜像；
- npm 包或 Python 包自动发布；
- 打 tag 后自动生成 release。
所以 CI/CD 可以拆成一句更好懂的话：
CI 让系统自动检查，CD 让系统自动交付。
GitHub Actions：GitHub 自带的自动化机器
GitHub Actions 是 GitHub 提供的自动化平台。
你可以把它理解为：
GitHub 临时给你一台机器，当你 push、提交 PR、打 tag 或手动触发时，它会按照你写好的脚本自动干活。
GitHub Actions 的配置文件通常放在：
.github/workflows/xxx.yml比如：
.github/workflows/ci.yml它里面有几个核心概念：
- Workflow：一整套自动化流程；
- Event：什么时候触发，比如 push、pull_request、release；
- Job：流程里的一个任务，比如 test、build、deploy；
- Step：Job 里的具体步骤，比如拉代码、装 Node、跑测试；
- Runner：执行这些步骤的机器，比如 ubuntu-latest。
flowchart LR
A[Event
push / pull_request] --> B[Workflow
ci.yml]
B --> C[Job
test-and-build]
C --> D[Step
checkout]
D --> E[Step
setup node]
E --> F[Step
npm ci]
F --> G[Step
test / build]
G --> H[Result
pass or fail]
这就是 GitHub Actions 的基本心智模型。
一个最小的 GitHub Actions CI 示例
假设你有一个 Node.js 项目，比如 React、Vite、Next.js、Vue，最小 CI 可以这样写：
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test-and-build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build project
run: npm run build逐行解释一下：
name: CI：这套流程叫 CI；on：定义什么时候触发；push.branches: [main]：push 到 main 分支时触发；pull_request.branches: [main]：有人向 main 提 PR 时触发；runs-on: ubuntu-latest：使用 GitHub 提供的 Ubuntu 机器；actions/checkout@v4：把仓库代码拉下来；actions/setup-node@v4：安装 Node.js；npm ci：按 lockfile 安装依赖；npm test：跑测试；npm run build：构建项目。
如果其中任何一步失败，整个 CI 就会失败。GitHub 会在 PR 或 commit 上显示红色叉号，提醒你这次改动没有通过检查。
这就是最小可用的 CI。
它不复杂，但很有价值。
如果项目现在没有测试怎么办？
很多人第一次接触 CI/CD 时会卡在这里：项目没有测试，那是不是就不能用 CI？
不是。
你可以从更低成本的检查开始：
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build哪怕只跑一个 npm run build，也能发现很多问题：
- 依赖没装对；
- TypeScript 编译不过；
- 打包时引用了不存在的文件；
- 某些环境变量缺失；
- 某些模块在 Linux 环境下无法运行。
所以 CI/CD 入门不需要一步到位。先让 GitHub 自动帮你构建起来，就是一个很好的开始。
再进一步：自动部署 GitHub Pages
如果你的项目是前端静态站点，构建产物通常在 dist 目录。你可以让 GitHub Actions 在 push 到 main 后自动部署到 GitHub Pages。
一个典型流程是：
name: Deploy to GitHub Pages
on:
push:
branches: [main]
permissions:
contents: read
pages: write
id-token: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: ./dist
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4这个流程做了两件事：
build任务负责拉代码、装依赖、构建项目、上传构建产物；deploy任务依赖build，只有构建成功后才会部署到 GitHub Pages。
这就是一个简单的 CD。
注意这里有一个很重要的工程习惯：部署任务应该依赖构建和检查任务。
不要让部署绕过验证。否则自动化只会把错误更快地送到线上。
为什么 AI 时代 CI/CD 更重要？
回到开头那条 X 讨论。
AI 进入开发流程后，很多公司会发现：过去 Web Infra Team 里一部分“封装脚手架、维护内部组件、写重复工具”的工作，确实会被开源生态和 AI 工作流削弱。
但这不意味着 Infra 变得不重要。
恰恰相反，Infra 的重心会变化：
- 从“大家都必须用我封装的工具”变成“让代码更容易被 AI 理解”；
- 从“流程靠文档提醒”变成“流程由系统自动执行”；
- 从“上线前人工确认一下”变成“自动测试、自动构建、自动阻断”；
- 从“出了问题再查”变成“每次提交都留下可追溯记录”。
AI 写代码有几个特点：
- 产出速度快；
- 一次改动范围可能很大；
- 局部代码看起来合理，但整体行为不一定正确；
- 它可能修好一个问题，又引入另一个问题；
- 人很难逐行理解所有生成内容。
这时候 CI/CD 就不只是“方便”，而是工程护栏。
flowchart TD
A[AI 或人类提交代码] --> B[CI 自动检查]
B --> C[测试]
B --> D[类型检查]
B --> E[构建]
B --> F[安全扫描]
C --> G{全部通过?}
D --> G
E --> G
F --> G
G -->|是| H[允许合并或部署]
G -->|否| I[阻断并反馈错误]
如果没有这些护栏，AI 只是在提高“写代码”的速度；有了这些护栏，AI 才更可能提高“可靠交付”的速度。
这也是为什么宝玉那句话里，我最关注的不是“不要 Web Infra Team”，而是“做好 skills 和自动化测试部署”。
未来更有价值的 Infra，可能不是给团队造一套没人懂的私有框架，而是把项目变成 AI 友好的工程系统：
- README 写清楚怎么启动；
- design.md 写清楚设计系统；
- AGENTS.md 写清楚 AI 协作约束；
- CI/CD 自动验证每次改动；
- 测试覆盖关键路径；
- 部署流程可回滚、可审计、可复现。
这才是 AI 时代真正有用的基础设施。
新手应该从哪里开始？
如果你以前没怎么用过 GitHub CI/CD，不建议一上来就学完整 DevOps 体系。
可以按这个顺序来：
第一步：先让项目自动构建
只做一件事：push 后自动跑 npm run build。
这一步能保证项目至少在 GitHub 的 Linux 环境里能构建成功。
第二步：加入 lint 和类型检查
如果项目有这些命令，就加进去：
npm run lint
npm run typecheck这一步能抓住格式、规范和类型错误。
第三步：加入测试
如果项目还没有测试，可以先从关键函数、关键接口、关键页面开始，不需要追求一开始就覆盖所有代码。
CI 的目标不是制造焦虑，而是让关键路径越来越可靠。
第四步：再考虑自动部署
不同项目的部署目标不同：
- 前端项目：GitHub Pages、Vercel、Netlify；
- 文档项目：GitHub Pages；
- 后端项目：Docker 镜像、云服务器、Kubernetes；
- SDK 或工具库：npm、PyPI、GitHub Release。
部署前一定要先有基本检查。否则 CD 只是“自动把未经验证的代码发布出去”。
第五步：给高风险操作加人工确认
自动化不是所有事情都自动做。
生产环境发布、数据库迁移、删除数据、修改权限这类高风险动作，最好加上人工确认或环境保护规则。
GitHub Actions 支持 environment protection rules，可以让某些部署任务必须经过审批后才执行。
一个适合个人项目的最小实践框架
对个人项目来说，CI/CD 可以很轻，不需要一开始就复杂。
我建议从这个最小框架开始：
flowchart LR
A[push / PR] --> B[安装依赖]
B --> C[构建]
C --> D[测试]
D --> E{通过?}
E -->|否| F[停止]
E -->|是| G[合并或部署]
对应到 GitHub Actions，大概就是：
- 一个
ci.yml：负责构建和测试； - 一个
deploy.yml：负责部署，并且依赖构建成功； - 逐步增加 lint、typecheck、安全扫描、缓存、矩阵测试；
- 不要为了复杂而复杂。
真正重要的是把流程跑起来。
CI/CD 不是大厂专属，它是项目的自动刹车
很多人会觉得 CI/CD 是大厂、平台组、DevOps 工程师才需要的东西。
这个理解已经过时了。
个人博客、开源项目、课程项目、AI Agent 项目，同样需要 CI/CD，只是规模不同。
对个人项目来说，CI/CD 的价值至少有三点：
- 防止低级错误进入主分支：比如构建失败、依赖缺失、测试失败；
- 让项目更容易协作：别人提 PR 时，系统自动告诉你能不能合；
- 给 AI 代码一个客观反馈：AI 写完代码后，不要只靠肉眼看，要让系统自动验证。
AI 时代，代码生产速度变快，错误传播速度也会变快。
CI/CD 就像自动刹车。它不会替你决定产品方向，也不会保证代码完美，但它能在关键时刻拦住明显错误。
结语：从“会写代码”到“能稳定交付”
宝玉那条 X 讨论，表面上是在说 Web Infra Team 的去留；深一层看，其实是在讨论 AI 时代工程基础设施的重新分工。
我的判断是：
造轮子的 Web Infra 会变少，服务 AI 协作的工程基础设施会变多。
CI/CD 就是其中最基础的一层。
它让测试、构建、检查、部署从人的记忆里搬到系统里；它让 AI 写出来的代码接受客观验证；它让项目不再依赖“这次我应该没忘记哪个步骤”。
所以，CI/CD 不是可选项。尤其在 AI 编程时代，它会越来越像项目的基本卫生条件：不一定显眼，但缺了迟早会出问题。
如果你还没用过 GitHub Actions，最好的开始不是读完所有文档，而是给自己的项目加一个最小的 .github/workflows/ci.yml：
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build先让它跑起来。
当你第一次看到 GitHub 自动帮你完成构建，那一刻你就会明白：工程化不是抽象概念，它就是把正确的步骤交给系统反复执行。
参考
AI 时代，CI/CD 不是可选项
OfferPilot：把AI Agent面试准备变成一次真实诊断