夜雨聆风CI/CD 配置不难写，但特别费时间。矩阵策略、缓存路径、Secret 权限，一个 pipeline 配半天是常有的事。2026 年的 AI 模型已经完全能搞定这些了。这篇文章带你用 Claude 或 Cursor 从零生成完整 GitHub Actions 工作流，附 5 套复制即用的场景模板。
一、一个太熟悉的场景
新项目搭好了，万事俱备，只差 CI。你打开 GitHub Actions 文档，心想"就几个关键字，十分钟的事"。
然后现实给你上了一课。你开始搜：pnpm 缓存 action 叫什么来着？setup-node 现在用 v3 还是 v4？矩阵测试能不能只跑两个 Node 版本？Docker 推送到 ghcr.io 需要设什么权限？secrets.GITHUB_TOKEN 和自定义 secret 到底有什么区别？
一个小时过去了，你还在 GitHub Marketplace、StackOverflow 和官方文档之间来回切。CI 终于配好了，跑了一下，matrix job 串行跑了 15 分钟。又调试了半小时才发现少了一个关键配置项。
这不是你一个人的经历。每个开发者都这样过来的。CI/CD 配置真正的难点从来不在 YAML 的语法上。YAML 一共就十几个关键字，看一眼就会。真正费时间的，是那些分散在几十个文档页面里的经验性知识。这些知识你没办法一次性记住，每次都得重新查。
但是你猜怎么着？AI 这件事已经能干了，而且干得比想象中靠谱得多。不光是能写，还能写对。
二、为什么 AI 特别适合写 CI/CD
CI/CD 配置有几个特点，刚好是 AI 的强项。
首先，规则明确但排列组合无穷。GitHub Actions 的语法规范就摆在那里，规则是死的。但是不同语言、不同包管理器、不同部署方式排列组合之后，写法千差万别。AI 的专长就是把明确规则按项目需求组合成正确配置。
其次，答案天然分散。写一条完整的 CI/CD pipeline 可能要参考五六个文档页面。cache action 的文档告诉你缓存路径怎么写，docker login action 的文档告诉你认证怎么设，matrix strategy 的文档告诉你并行测试怎么配，permissions 的文档告诉你什么权限能干什么事。AI 一次性把它们全合成到一份 YAML 里，你不用来回翻了。
第三，80% 的内容是套模板。绝大多数项目的 CI 流程都是 checkout 代码、装依赖、跑检查、构建、部署这几步。AI 生成标准模板然后按你的项目细节微调，比从零开始写快太多了。
还有一点很重要：2026 年的 AI 模型已经不会犯 YAML 语法错误了。你回想一下两年前，让 AI 写 YAML 的时候缩进还在乱来。现在的模型对 YAML 的缩进规则、多行字符串、条件表达式的理解已经非常准确，基本不需要二次修正。
三、三种实操方式，见效越来越快
方式 1：Claude / ChatGPT 直接写
最直接也最快。把下面这段 prompt 复制过去，括号里的内容换成你项目的实际情况。
帮我生成 GitHub Actions CI 工作流。
项目：React + TypeScript，包管理 pnpm，Node 20。
需求：
1. PR 到 main 自动触发
2. 缓存依赖，加快构建速度
3. 运行 lint、类型检查、单元测试
4. 全部通过才算 CI 通过十秒之内拿到一份完整的 .github/workflows/ci.yml。你不用知道 pnpm 缓存用的是哪个 action，也不需要去查怎么配才能让缓存生效。AI 比你还清楚 pnpm 缓存的正确写法。
方式 2：Cursor Composer 上下文感知
比上面更省事。如果你项目已经在本地了，打开 Cursor，用 Composer 模式，就一句话：
帮我建 GitHub Actions CI。先读 package.json 判断技术栈，然后生成 workflow。Cursor 读完你的项目配置再生成。你的项目用 Node 还是 Python 还是 Go，它自己看 package.json 判断。pnpm 还是 npm 还是 yarn，它从 lockfile 里看出来。lint、test、build 这些命令直接从 scripts 里取。你不用告诉 AI 任何项目信息，它自己看了上下文帮你判断。基本是一键生成。
跟方式 1 的本质区别在于，你不用描述你的技术栈。对那种"我也不知道我项目用了什么"的懒人特别友好。
方式 3：GitHub Agentic Workflows
这是 GitHub 2026 年 2 月才推出的新功能，目前还在技术预览阶段。核心卖点是：用自然语言写 CI/CD，完全不用碰 YAML。
现在的标准写法是一大段 YAML：定义事件触发条件、jobs 和 steps、actions 的版本号和参数。Agentic Workflows 的写法只需要一段 Markdown 描述：
# CI Pipeline
When a PR is opened against main, run tests.
Check out code, install Node.js, run npm test.
If tests fail, comment on the PR with details.GitHub 的 AI Agent 在 Actions Runner 上自己解析这段描述，自己决定怎么 checkout、怎么装运行环境、用什么顺序执行测试。测试挂了甚至还会分析错误原因尝试自动修复。
这功能目前还不推荐在生产环境用。但它传递的信号很明确：以后写 CI/CD 可能真的不需要手写 YAML 了。这个方向的确定性很高。
三种方式怎么选：日常开发，一个项目一条 pipeline，方式 1 最快；一次性要给多个项目批量配置 CI，方式 2 效率最高；想提前了解一下未来趋势，可以拿方式 3 做实验。
四、完整实战演示
用一个真实的全栈项目来做完整演示，从需求到可用的配置文件每一步都走一遍。
项目背景：Next.js 14 + TypeScript + TailwindCSS + Prisma + PostgreSQL 数据库。部署在 Vercel，容器镜像推送到 GitHub Container Registry。
需求很清晰。PR 到 main 的时候要跑 ESLint 代码检查、TypeScript 类型检查和单元测试。main 分支 push 之后构建 Docker 镜像并推送到 ghcr.io，前提是代码质量检查必须先通过。
给 AI 写 prompt 我踩过很多坑，最后总结出一个高效模板。这个模板的结构我验证了几十个项目，成功率确实很高：
[角色] 你是一个 DevOps 工程师
[项目信息] 框架、语言、包管理、数据库、部署方式
[需求列表] 分点写清楚触发时机和具体要做什么
[约束条件] Node 版本、包管理版本等硬性要求按照这个结构写出来的 prompt：
你是 DevOps 工程师，帮我为 Next.js 14 项目生成 GitHub Actions。
项目信息：
- 框架：Next.js 14 (App Router)
- 语言：TypeScript
- 包管理：pnpm 9
- 数据库：Prisma + PostgreSQL
- 部署：Vercel
需求：
1. PR 到 main 时跑 ESLint + tsc + vitest，pnpm 缓存加速
2. main push 时构建 Docker 推送到 ghcr.io
3. Docker job 依赖 quality job，失败不构建镜像
约束：Node 20，用 pnpm/action-setup，不要手写 cache 路径AI 生成的核心配置：
name: CI/CD Pipeline
on:
pull_request:
branches: [main]
push:
branches: [main]
env:
NODE_VERSION: '20'
jobs:
quality:
if: github.event_name == 'pull_request'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
with:
version: 9
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- name: Lint
run: pnpm lint
- name: Type Check
run: pnpm type-check
- name: Test
run: pnpm test
docker:
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
needs: quality
runs-on: ubuntu-latest
permissions:
packages: write
steps:
- uses: actions/checkout@v4
- name: Login to GHCR
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and Push
uses: docker/build-push-action@v6
with:
push: true
tags: |
ghcr.io/${{ github.repository }}:latest
ghcr.io/${{ github.repository }}:${{ github.sha }}仔细看看 AI 自动帮你处理了哪些细节。pnpm 的缓存它用了 pnpm/action-setup 这个官方 action，而不是手写 cache path。这是最好的实践，因为官方 action 自动处理了缓存路径在不同操作系统上的差异。Docker 镜像推送配好了 packages: write 权限，不配这个权限直接推会报 403。needs: quality 这行确保代码质量检查没过的 commit 不会浪费资源去构建镜像。双标签 latest 加 commit SHA，latest 方便日常使用，SHA 方便版本回滚和追溯。
这些细节如果手动写，起码要翻三四次 GitHub Actions 文档。AI 一口气全给你了。
五、拿到配置后必查三样
AI 生成的配置大部分是对的，但有三样东西你一定要自己检查。这三样如果出问题，CI 会静默挂掉，排查起来极其费劲。
第一样是 Secret 名称。AI 不知道你仓库 Settings 里实际配了哪些 Secret。它生成的 secrets.DOCKERHUB_TOKEN 可能在你仓库里叫 secrets.DOCKER_TOKEN。拿到配置后全局搜索 secrets. 这个关键字，逐个去仓库 Settings → Secrets 页面核对。一个没配对的 Secret 会导致 CI 在工作流中间突然停止，日志里只会显示一句模模糊糊的拒绝信息。
第二样是 Action 的版本号。AI 生成的 actions/setup-node@v4 可能已经出 v5 了。去 GitHub Marketplace 上查一下每个 action 的最新版本。差一个小版本号通常不会报错，但偶尔会有 breaking change。比如 v3 到 v4 之间 Node 版本参数的名字就改过。
第三样是缓存策略。这个建议很明确：只要是用 pnpm，就用 pnpm/action-setup 这个专用 action，不要手写 cache path。手写的 cache path 在不同操作系统上可能路径不一致，而且 pnpm store 的路径还会随 pnpm 版本变化。专用 action 把这些都处理好了。
六、5 套 Prompt 模板（直接复制用）
经过反复迭代和验证，这五套模板覆盖了日常前端和后端开发中最常见的 CI/CD 场景。直接复制，把项目名替换一下就能用。
前端项目 CI
前端 CI：React + TypeScript + Vite，包管理 pnpm。
PR 到 main 跑 lint + type-check + unit test + build。
需要 pnpm 缓存，Node 20。Python 项目 CI + 自动发布 PyPI
Python CI/CD：Poetry 管理依赖。
PR 跑 pytest + ruff lint + mypy 类型检查。
push tag 构建 wheel 并发布到 PyPI，使用 trusted publishing。
Python 3.11 + 3.12 两个版本矩阵测试。Monorepo 差异化构建
pnpm monorepo：packages/web（Next.js）和 packages/api（Go）。
PR 时只对变更的子项目跑 CI，用 paths-filter 实现。
web：build + lint。api：go test + golangci-lint。定时任务 + 通知
每天凌晨 2 点跑全量测试，使用 cron 触发。
如果测试失败，通过 Slack Webhook 发送通知。Docker 多架构构建
Docker 多架构构建：buildx 构建 amd64 和 arm64 两个架构。
main 分支 push 时触发，推送到 ghcr.io。
tag 使用 commit SHA，不使用 latest。每个模板丢给 Claude，三十秒拿到可用配置。五个项目全部配上 CI 不超过五分钟。
七、一个常见的误区
"AI 写的配置你敢直接上生产？万一漏了什么步骤呢？"
这个问题我听到太多次了。它的逻辑前提是"手写的配置就不会漏步骤"，但实际情况是，你手写的配置漏步骤的概率跟 AI 差不多。CI/CD 配置的可靠性从来不取决于来源，取决于你怎么审查。
换一个角度来看这个事。你自己手写一条 pipeline，需要一边翻文档一边试错。翻到 cache action 那一页查参数，翻到 permissions 那一页查 Docker 推送需要什么权限，翻到 matrix strategy 那一页查并行怎么配。快则二十分钟，慢则一个下午过去了。AI 十秒就给你生成初版，你花两分钟审查。哪个效率更高不言自明。
而且迭代过程也是一样的。你跑完发现有个地方不对，告诉 AI"把测试改成并行跑"，它三秒改好。你自己改的话又得去研究 matrix strategy 的文档。
AI 在这个场景里并不是要替代你的判断。它真正在做的，是帮你省掉那些纯粹的机械查找和语法记忆工作。你省下来的精力可以放在更需要判断的地方：理解业务需求、设计测试策略、制定部署流程。这些才是真正需要人的地方。
八、快速总结
用 AI 写 CI/CD 的流程可以浓缩成四步。第一步，把上面的 Prompt 模板复制给 Claude 或 Cursor，改动里面的项目名和技术栈信息，15 秒。第二步，拿到生成的 YAML 配置，检查 Secret 名称、Action 版本号、缓存策略这三样最关键的东西，两分钟。第三步，提交到仓库跑一次 CI，看日志确认每个步骤都正常通过了。第四步，如果某个步骤有问题，把错误信息丢回给 AI 让它改，三秒拿到修正版本。
从零到上线一条完整 pipeline，全部加起来不超过十分钟。这不是夸张的数字。你可以现在就打开 Claude，把我文章里的任何一套模板丢进去试试。
打开 Claude 或 Cursor，把文章里的 Prompt 模板复制过去。五分钟后回来看看你的项目 CI 变成了什么样。评论区晒一下人生中第一条 AI 帮你生成的 GitHub Actions workflow。
觉得有用？点个"在看"，让团队里还在手写 YAML 的同事们也试试这个效率翻倍的玩法。
