08 - 运维部署食谱

用 AI 辅助构建可靠的 CI/CD、容器化和部署方案。

适用场景

场景	典型信号	推荐食谱
项目首次部署	无 CI/CD，手动构建上线	食谱 1：CI/CD 流水线
应用容器化	需要统一开发/生产环境	食谱 2：Dockerfile 编写
多环境管理混乱	敏感信息硬编码、配置散落各处	食谱 3：环境配置管理
部署流程不可靠	手动操作易出错、缺少验证	食谱 4：部署脚本编写
上线后缺少可观测性	故障靠用户反馈才知道	食谱 5：监控与告警配置
缺少应急预案	出问题后手忙脚乱	食谱 6：故障恢复预案

食谱 1：CI/CD 流水线配置

场景描述

为项目配置持续集成/持续部署流水线，覆盖检查、测试、构建、部署全流程。

核心模板

text

为项目配置 CI/CD 流水线。

项目信息：
- 技术栈：{{技术栈}}
- 代码仓库：{{仓库平台}}（如 GitHub / GitLab）
- 部署目标：{{部署平台}}（如 Cloudflare Pages / Vercel / AWS）
- 包管理器：{{包管理器}}（如 pnpm / npm / yarn）

流水线要求：
- 触发条件：{{触发规则}}（如 push to main、PR 创建时）
- 步骤：lint → typecheck → test → build → deploy
- Node.js 版本：{{Node版本}}
- Secrets：{{密钥列表}}

约束：
- 缓存依赖安装加速构建
- 失败时不部署
- PR 只检查不部署，main 才部署

输出 {{CI配置文件}} 的完整配置。

变量说明

变量	示例
`{{技术栈}}`	`Next.js 14 + TypeScript`
`{{仓库平台}}`	`GitHub` / `GitLab`
`{{部署平台}}`	`Cloudflare Pages` / `Vercel`
`{{包管理器}}`	`pnpm` / `npm`
`{{触发规则}}`	`push to main, PR to main`
`{{Node版本}}` / `{{密钥列表}}`	`20` / `CLOUDFLARE_API_TOKEN`
`{{CI配置文件}}`	`.github/workflows/deploy.yml`

好坏对比

❌ "帮我写一个 GitHub Actions 配置"
✅ "为 pnpm + Next.js 项目配置 GitHub Actions，push to main 时自动部署到 Cloudflare Pages，PR 时只运行 lint + test，需要缓存 pnpm store"

实战案例

text

为 VitePress 文档站配置 GitHub Actions。
部署目标：Cloudflare Pages（项目名 ai-dev-lifecycle）
包管理器：pnpm 9，构建：cd site && npm run build
main push 时 build + wrangler 部署，PR 时只 build 验证。
Secrets：CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID
注意：wrangler --commit-message 必须纯 ASCII。

生成结果（GitHub Actions 关键片段）：

yaml

steps:
  - uses: actions/checkout@v4
  - uses: pnpm/action-setup@v4
    with: { version: 9 }
  - uses: actions/setup-node@v4
    with: { node-version: 20, cache: pnpm }
  - run: pnpm install --frozen-lockfile
  - run: cd site && npm run build
  - if: github.ref == 'refs/heads/main'
    run: cd site && npx wrangler pages deploy .vitepress/dist
      --project-name=ai-dev-lifecycle --commit-message="deploy from CI"
    env:
      CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

Claude 增强 💡

读取 package.json，确保 workflow 步骤与 scripts 中的命令一致
用 @.github/workflows/ 引用现有 CI，做增量改进而非从零开始

食谱 2：Dockerfile 编写

场景描述

编写多阶段 Dockerfile，兼顾构建速度、镜像体积和安全性。

核心模板

text

为项目编写 Dockerfile。

项目信息：
- 技术栈：{{技术栈}}
- 包管理器：{{包管理器}}
- 构建命令：{{构建命令}}
- 启动命令：{{启动命令}}
- 监听端口：{{端口}}

要求：
- 多阶段构建（multi-stage build）
- 基础镜像：{{基础镜像}}（如 node:20-alpine）
- 最终镜像只含运行时依赖，不含 devDependencies
- 利用 layer cache：先复制 lockfile 装依赖，再复制源码
- 非 root 用户运行
- 附带 .dockerignore

输出 Dockerfile 和 .dockerignore。

变量说明

变量	示例
`{{技术栈}}` / `{{包管理器}}`	`Express + TypeScript` / `pnpm`
`{{构建命令}}` / `{{启动命令}}`	`pnpm build` / `node dist/server.js`
`{{端口}}` / `{{基础镜像}}`	`3000` / `node:20-alpine`

好坏对比

❌ "帮我写个 Dockerfile"
✅ "为 pnpm + TypeScript 的 Express 项目写多阶段 Dockerfile，基于 node:20-alpine，最终镜像不含 devDependencies，非 root 用户，端口 3000"

实战案例

text

为 Next.js 14 + Prisma 项目写 Dockerfile。
pnpm 9，构建阶段需 prisma generate，最终镜像含 prisma client 运行时。
三阶段：deps → build → runner，standalone output，目标 < 200MB。
DATABASE_URL 运行时注入，监听 3000。

Claude 增强 💡

读取 package.json 和现有 Dockerfile，分析依赖结构生成优化的多阶段构建
用 docker build --progress=plain . 验证构建过程，检查 layer cache 命中率

食谱 3：环境配置管理

场景描述

管理多环境配置和敏感信息，确保开发/测试/生产环境的配置隔离与类型安全。

核心模板

text

为项目设计环境配置管理方案。

项目信息：
- 技术栈：{{技术栈}}
- 部署环境：{{环境列表}}（如 development / staging / production）
- 部署平台：{{部署平台}}

需要管理的配置：
- {{配置项列表}}

要求：
- .env.example 模板含所有变量及注释
- 敏感信息不入 Git
- 用 zod 实现类型安全的配置校验
- 说明各平台的 Secrets 配置方式

输出：.env.example、.gitignore 规则、配置校验代码。

变量说明

变量	示例
`{{技术栈}}` / `{{部署平台}}`	`Next.js 14 + Prisma` / `Vercel`
`{{环境列表}}`	`development, staging, production`
`{{配置项列表}}`	`DATABASE_URL, NEXTAUTH_SECRET, STRIPE_KEY`

好坏对比

❌ "帮我管理环境变量"
✅ "为 Next.js + Prisma 项目设计环境配置方案，管理 DATABASE_URL / NEXTAUTH_SECRET / STRIPE_KEY，dev/prod 隔离，用 zod 运行时校验"

实战案例

text

技术栈：Next.js 14 + Prisma + NextAuth，部署 Vercel。
配置项：DATABASE_URL（dev 本地/prod Supabase）、NEXTAUTH_SECRET、
NEXTAUTH_URL（每环境不同）、STRIPE_SECRET_KEY（仅 prod）、NEXT_PUBLIC_APP_URL。
输出：.env.example、src/lib/env.ts（zod 校验）、Vercel 配置指南。

生成结果（zod 配置校验）：

typescript

// src/lib/env.ts — runtime validation for environment variables
import { z } from "zod";
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  NEXTAUTH_SECRET: z.string().min(32),
  NEXTAUTH_URL: z.string().url(),
  STRIPE_SECRET_KEY: z.string().startsWith("sk_").optional(),
});
export const env = envSchema.parse(process.env);

Claude 增强 💡

搜索项目中所有 process.env.XXX 引用，交叉比对 .env.example，找出缺失变量
用 /check Skill 检查 .gitignore 是否正确排除了 .env 文件

食谱 4：部署脚本编写

场景描述

编写自动化部署脚本，封装构建、上传、验证为可重复执行的命令，支持预检和回退。

核心模板

text

为项目编写部署脚本。

项目信息：
- 技术栈：{{技术栈}}
- 部署目标：{{部署平台}}
- 部署方式：{{部署方式}}（如 wrangler CLI / Vercel CLI / rsync）

脚本要求：
- 部署前检查：{{预检项}}（如 git 干净、测试通过）
- 构建：{{构建命令}}
- 部署：{{部署命令}}
- 部署后验证：{{验证方式}}（如 curl 健康检查）
- 支持 --dry-run（只检查不部署）
- 失败时输出错误信息和排查建议

输出可执行的 {{脚本语言}} 部署脚本。

变量说明

变量	示例
`{{技术栈}}` / `{{部署平台}}`	`VitePress` / `Cloudflare Pages`
`{{部署方式}}`	`wrangler CLI` / `Vercel CLI` / `rsync`
`{{预检项}}`	`git clean, build success`
`{{构建命令}}` / `{{部署命令}}`	`npm run build` / `npx wrangler pages deploy`
`{{验证方式}}` / `{{脚本语言}}`	`curl -f https://site.pages.dev` / `bash`

好坏对比

❌ "写一个部署脚本"
✅ "为 VitePress 写 bash 部署脚本，部署到 Cloudflare Pages，预检 git 干净 + 构建成功，部署后 curl 验证，支持 --dry-run"

实战案例

text

为文档站写 scripts/deploy.sh。
VitePress → Cloudflare Pages（ai-dev-lifecycle）
构建目录：site/.vitepress/dist
流程：预检 git clean → build → wrangler deploy（ASCII commit msg）→ curl 验证
用 git hash 作为 commit message，支持 --dry-run。

生成结果（bash 脚本核心逻辑）：

bash

#!/usr/bin/env bash
set -euo pipefail
DRY_RUN=false && [[ "${1:-}" == "--dry-run" ]] && DRY_RUN=true

[[ -n "$(git status --porcelain)" ]] && echo "ERROR: Dirty worktree" && exit 1
cd site && npm run build && cd ..
HASH=$(git rev-parse --short HEAD)
[[ "$DRY_RUN" == true ]] && echo "[DRY RUN] deploy-${HASH}" && exit 0

cd site && npx wrangler pages deploy .vitepress/dist \
  --project-name=ai-dev-lifecycle --commit-message="deploy-${HASH}"
sleep 10 && curl -sf https://ai-dev-lifecycle.pages.dev > /dev/null \
  && echo "Deploy OK!" || echo "WARNING: Health check failed."

Claude 增强 💡

读取现有部署配置（wrangler.toml / vercel.json / 现有脚本），基于实际配置生成脚本
让 Claude 用 --dry-run 先验证流程再执行实际部署

食谱 5：监控与告警配置

场景描述

为生产环境配置健康检查、关键指标监控和告警通知，做到问题早发现、早响应。

核心模板

text

为项目配置监控告警方案。

项目信息：
- 技术栈：{{技术栈}}
- 部署平台：{{部署平台}}
- 当前规模：{{用户规模}}

监控需求：
- 健康检查端点：{{健康检查路径}}
- 关键指标：{{业务指标}}
- 告警渠道：{{告警方式}}（如 Slack / Email / webhook）
- 告警级别：{{级别定义}}

输出：
1. 健康检查 API 端点实现
2. {{监控平台}} 告警规则配置
3. 告警响应 SOP

约束：避免告警风暴，区分 warning / critical 级别。

变量说明

变量	示例
`{{技术栈}}` / `{{部署平台}}`	`Next.js + Prisma` / `Vercel + Supabase`
`{{用户规模}}`	`日活 1000，QPS < 50`
`{{健康检查路径}}` / `{{业务指标}}`	`/api/health` / `响应时间、错误率`
`{{告警方式}}` / `{{级别定义}}`	`Slack webhook` / `连续3次失败 → critical`
`{{监控平台}}`	`UptimeRobot` / `Grafana`

好坏对比

❌ "帮我加个监控"
✅ "为 Next.js 配置监控：/api/health 检查 DB + Redis，UptimeRobot 每 5 分钟探测，连续 3 次失败发 Slack 告警"

实战案例

text

Next.js 14 + Prisma + Redis，部署 Vercel。
1. /api/health 端点：检查应用存活、DB 连接、Redis ping，返回 JSON
2. GitHub Actions cron 每 15 分钟健康检查
3. 连续 2 次失败发 Slack notification

生成结果（健康检查端点）：

typescript

// app/api/health/route.ts
import { NextResponse } from "next/server";
import { prisma } from "@/lib/prisma";

export async function GET() {
  const checks: Record<string, { status: string; latency?: number }> = {};
  const t = Date.now();
  try {
    await prisma.$queryRaw`SELECT 1`;
    checks.database = { status: "ok", latency: Date.now() - t };
  } catch {
    checks.database = { status: "error", latency: Date.now() - t };
  }
  const ok = Object.values(checks).every((c) => c.status === "ok");
  return NextResponse.json(
    { status: ok ? "healthy" : "degraded", checks },
    { status: ok ? 200 : 503 }
  );
}

Claude 增强 💡

读取项目中所有外部依赖（数据库、缓存、第三方 API），为每个依赖生成健康检查逻辑
用 /health-report Skill 生成项目健康度评估，识别缺少监控的关键路径

食谱 6：故障恢复预案

场景描述

制定回滚、数据恢复和应急预案，减少生产事故的影响范围和恢复时间。

核心模板

text

为项目制定故障恢复预案。

项目信息：
- 技术栈：{{技术栈}}
- 部署平台：{{部署平台}}
- 数据存储：{{数据库和存储}}
- 部署方式：{{部署方式}}

覆盖场景：
1. 部署后发现 Bug — 快速回滚
2. 数据库迁移失败 — 回滚 migration
3. 第三方服务宕机 — 降级方案
4. 数据误删或损坏 — 数据恢复

每个场景输出：
- 判断标准：何时触发
- 操作步骤：精确到可粘贴的命令
- 验证方法：如何确认恢复成功
- 预防措施：如何避免再发

约束：标注每步预计耗时和所需权限。

变量说明

变量	示例
`{{技术栈}}` / `{{部署平台}}`	`Next.js + Prisma` / `Vercel`
`{{数据库和存储}}` / `{{部署方式}}`	`Supabase PostgreSQL + R2` / `Git 自动部署`

好坏对比

❌ "写个回滚方案"
✅ "为 Vercel 上的 Next.js + Prisma 项目制定故障恢复预案，覆盖 Vercel rollback、Prisma migrate 回滚、第三方降级，每步给可执行命令"

实战案例

text

Next.js 14 + Prisma，Vercel 部署，Supabase PostgreSQL。
场景 1：部署回滚 — Vercel promote 到上一正常版本 + 同步回滚 migration
场景 2：migration 失败 — 生产 DB 回滚步骤 + 数据完整性验证
场景 3：Supabase 不可用 — 只读降级 + 用户提示
每个场景提供可执行命令和检查清单。

生成结果（回滚命令片段）：

bash

# === Scenario 1: Vercel rollback (~30s) ===
vercel ls --limit 5                      # List recent deployments
vercel promote <previous-deployment-url>  # Rollback to stable version
curl -sf https://app.vercel.app/api/health | jq .  # Verify

# === Scenario 2: Prisma migration rollback ===
npx prisma migrate status                          # Check current state
psql $DATABASE_URL -f prisma/rollback/revert.sql   # Execute rollback SQL
npx prisma migrate resolve --rolled-back <name>    # Mark as rolled back

Claude 增强 💡

读取 vercel.json / wrangler.toml 和 prisma/schema.prisma，生成针对性的恢复命令
用 /check Skill 审计现有部署配置，提前发现潜在的恢复障碍

组合技巧

技巧 1：从零搭建完整部署体系（食谱 3 → 2 → 1 → 4）

text

为新项目搭建部署体系。技术栈：Next.js + Prisma + pnpm，部署 Vercel。
按顺序输出：1) .env.example + zod 校验 2) Dockerfile 3) GitHub Actions 4) deploy.sh

技巧 2：上线前保障三件套（食谱 4 + 5 + 6）

text

项目即将上线，补全生产保障。依次输出：
1. 部署脚本（含预检和验证）2. /api/health + 定时监控 3. 回滚操作手册

技巧 3：平台迁移检查清单（食谱 1 + 3 + 4）

text

项目从 Vercel 迁移到 Cloudflare Pages。读取 vercel.json 和现有 CI 配置，
列出需改的文件，生成对应配置，注意环境变量迁移，输出检查清单。

08 - 运维部署食谱 ​

适用场景 ​

食谱 1：CI/CD 流水线配置 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 2：Dockerfile 编写 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 3：环境配置管理 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 4：部署脚本编写 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 5：监控与告警配置 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

食谱 6：故障恢复预案 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 💡 ​

组合技巧 ​

技巧 1：从零搭建完整部署体系（食谱 3 → 2 → 1 → 4） ​

技巧 2：上线前保障三件套（食谱 4 + 5 + 6） ​

技巧 3：平台迁移检查清单（食谱 1 + 3 + 4） ​

相关资源 ​

08 - 运维部署食谱

适用场景

食谱 1：CI/CD 流水线配置

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 2：Dockerfile 编写

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 3：环境配置管理

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 4：部署脚本编写

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 5：监控与告警配置

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

食谱 6：故障恢复预案

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强 💡

组合技巧

技巧 1：从零搭建完整部署体系（食谱 3 → 2 → 1 → 4）

技巧 2：上线前保障三件套（食谱 4 + 5 + 6）

技巧 3：平台迁移检查清单（食谱 1 + 3 + 4）

相关资源