CI/CD 流水线审计 Prompt:又快又可信

CI 慢、爱炸、绿色还撒谎,就该审一遍。12 个可直接复制的 Prompt(GitHub Actions / GitLab CI / CircleCI)——缓存、并行、密钥、门禁,附 2026 年 runner 成本。

“CI 怎么这么慢”,答案多半埋在 YAML 里,可没人愿意读那 600 行。好的流水线审计 Prompt 会先把维度列清楚(缓存、并行、密钥、门禁),强制模型从真实日志里拿证据,最后给出一份按优先级排好的 action 列表,而不是靠感觉。下面 12 个模板,直接连同你的 workflow 文件一起粘进 Claude Opus 4.7、GPT-5.5 或 Gemini 3.1 Pro 即可。

一句话总结

  • 把 workflow YAML 和一段最近的运行日志一起粘进下面任意一个 Prompt。1M token 的模型(Opus 4.7、Sonnet 4.6、Gemini 3.1 Pro)一次就能吞下整个 .github/workflows/ 目录。
  • 按这个顺序审五件事:运行时长、缓存命中率、并行度、门禁诚实度、密钥暴露。
  • 2026 年最大的收益来自 path filter 和 content-hash 缓存键,而不是换更快的 runner——GitHub 在 2026 年 1 月把托管 runner 降价最高 39%,算力已经很少是瓶颈。
  • 永远别让 AI 自动改门禁和密钥。起草可以,合并前必须人审。

适合哪些人

平台工程师、被 25 分钟 CI 磨疯的 tech lead、想发得更快的创业者,以及任何眼看着 CI 账单涨得比团队还快的人。只要你维护的是 GitHub Actions、GitLab CI 或 CircleCI,这里每个 Prompt 都用得上。

什么时候别用

没测试的流水线别审——审计补不了缺失的概念。另外,没有运行时长基线之前别动任何参数,否则你根本判断不出某次修改到底有没有用。

一个审计 Prompt 要带什么

下面每个模板都带这六个要素。你要自己写,也把这六个补齐:

  • 角色:AI 扮演谁(SRE、Release Captain、staff 工程师、QA Lead)。
  • 上下文:技术栈、分支、失败日志、diff、dashboard URL。
  • 目标:一个具体可交付物——根因、checklist、计划、ticket 列表或 runbook。
  • 限制:AI 不能做什么(别自动修、别瞎造文件路径)。
  • 输出格式:编号清单、markdown 表格、JSON、unified diff 或可运行代码。
  • 信号:一两条”好输出”示例,或一条反例。

用哪个模型跑

模型(2026 年 6 月)上下文为什么适合审 CIAPI $/1M(入/出)
Claude Opus 4.71M tokenSWE-bench Verified 第一(87.6%);多文件 YAML 推理最强5 / 25
Claude Sonnet 4.61M token快、便宜,适合批量审计3 / 15
Gemini 3.1 Pro1M token跨多个 workflow 文件的长上下文召回强2 / 12
GPT-5.5Plus 应用内约 320 页终端/agent 类得分最高(Terminal-Bench 2.0 82.7%)5 / 30

整个 .github/workflows/ 目录加运行日志,上面三个 1M token 模型都能一次读完。ChatGPT Plus(每月 20 美元)应用内窗口约 320 页,日志特别大就拆开,或转到 API。

12 个可直接复制的 Prompt 模板

发送前先替换 [方括号] 占位符。

1. 端到端流水线审计

You are a platform engineer. Audit this `[filename]` for: (1) total runtime + biggest single step, (2) cache hit-rate signals (missing keys, stale paths), (3) parallelism opportunities, (4) gates that warn but don't fail, (5) secrets exposure. Output a ranked action list with the estimated minutes or risk saved per item.

替换:[filename],例如 .github/workflows/ci.yml

2. 缓存审计

Audit caching for this pipeline. For each cache step: (1) is the cache key content-hash based or static? (2) does the path actually cover the heavy install? (3) are restore-keys listed for partial hits? (4) what is the TTL / invalidation strategy? Output one fix per cache step.

3. 并行度审计

Find parallelism opportunities: (1) jobs that needlessly `needs:` another, (2) tests that could shard, (3) build + lint + typecheck running sequentially when they could run in parallel, (4) matrix entries that don't need full coverage. Output a YAML diff.

4. 门禁诚实度审计

Audit gates: which steps set `continue-on-error: true`, use `if: always()`, or report success while the underlying tool failed? Output a table: step | currently | should be | severity. Flag any gate that has masked a real failure.

5. 密钥 / OIDC 审计

Audit secret handling: (1) long-lived secrets that could move to OIDC, (2) secrets used in `echo` or step output, (3) PRs from forks with access to secrets, (4) secret names that leak their purpose. Output a remediation list ordered by exposure risk.

6. 自建 vs 托管 runner 决策

We currently use [provider]. Decide whether to add self-hosted runners for: (1) heavy CPU steps (build, e2e), (2) steps needing a custom OS, (3) steps that hit a private network. For each, give a cost / maintenance estimate and a recommendation.

替换:[provider] —— GitHub Actions / GitLab CI / CircleCI。

7. matrix 精简

Audit the build matrix: (1) are all combinations necessary, or do some only catch known issues? (2) could we run only `node-lts` on PRs and the full matrix on main? (3) are deprecated versions still tested? Output a trimmed matrix.

8. 必需 vs 阻塞检查

List which checks are currently REQUIRED by branch protection. Decide for each: keep / move to optional / remove. Criteria: false-positive rate, runtime, redundancy with another check. Output a table.

9. 账单审计

Our CI costs [monthlyCost] per month on [provider]. Audit for spend: (1) top 3 jobs by minutes, (2) % of runs cancelled mid-way, (3) PR-triggered runs that could be path-filtered, (4) cron jobs running too often. Output the top 3 savings with estimated minutes recovered.

替换:[monthlyCost][provider]

10. path filter 机会

Find path-filter opportunities: (1) frontend-only PRs that don't need backend tests, (2) docs-only PRs running full e2e, (3) mobile changes triggering the web pipeline. Output `paths:` blocks per workflow.

11. 抽离 reusable workflow

Identify steps repeated across 3+ workflows that could become a reusable workflow or composite action: (1) setup (node + pnpm + cache), (2) lint, (3) test reporters, (4) deploy. Output the refactor plan plus the reusable workflow stub.

12. PR 影响热力图

For the last 50 PRs, count how often each pipeline job ran AND whether it actually exercised the changed files. Identify the top 3 jobs that ran on PRs they couldn't fail. Output a path-filter or conditional to skip them.

2026 年 runner 成本(用来核对审计结论)

当某个 Prompt 估出”省下多少分钟”,用现价折算成钱。以下为 2026 年 6 月价格:

平台免费额度(私有仓库)默认每分钟说明
GitHub Actions(Linux 2 核)2,000 分钟/月(Free)、3,000(Team)$0.006托管价 2026 年 1 月降价最高 39%;16 核 Linux 现 $0.042/分钟
GitHub Actions(macOS)计入同一额度$0.062macOS 分钟消耗额度约为 Linux 的 10 倍
GitLab CI400 分钟/月(Free)、10,000/人(Premium $29)$0.010超额按每 1,000 分钟 $10 计费
CircleCI30,000 credits/月(Free)$0.006(Medium Linux,10 credits/分钟)免费档约合 3,000 分钟 Medium Linux

公开仓库在三家都免费。GitHub 原定对自建 runner 收的每分钟费用在社区反对后已推迟,所以截至 2026 年 6 月,GitHub 上自建 runner 仍然免费——在你测算迁移前,请到 GitHub Actions runner 价格页 复核。

容易踩的坑

  • 直接缓存 node_modules——恢复慢,跨操作系统还会崩。应该缓存包管理器的 store 目录。
  • 每个 PR 都跑全套 e2e。
  • “不想被挡”就给测试加 continue-on-error: true——绿色就是这么撒谎的。
  • fork 的 PR 能拿到 secret,这是常见的凭据泄漏路径。
  • 没有 path filter,于是每个 PR 跑所有 job。
  • 自建 runner 没有生命周期管理,是实打实的安全风险。
  • 每个 PR 都跑全 matrix;matrix 应只留给 main 和 release 分支。

怎么把结果推得更深

  • cache key 用 lockfile 和 package.json 做 content hash。
  • 只要平台支持,就用 OIDC 取代长期云密钥。
  • 刻意区分必需 / 可选检查——必需就等于一个信任信号。
  • path filter 比换 runner 更省钱,何况托管算力现在更便宜了。
  • reusable workflow 去重,并把安全补丁集中到一处。
  • 记录每个 PR 的 CI 分钟数,方便揪出 flake 修复对象。
  • 快失败:先跑便宜的检查(lint、typecheck),再跑贵的(e2e)。

FAQ

  • 什么时候该上自建 runner? 当托管成本超过自建维护成本,且你需要特殊硬件或私网访问时。2026 年 1 月托管降价后(16 核 Linux $0.042/分钟),划算的天平比 2025 年更偏向托管。
  • CI 多快算合理? PR 上小于 10 分钟。再慢,开发行为就开始退化,大家不再等绿。
  • GitHub Actions 缓存可靠吗? 可靠,前提是 cache key 确定。别用日期 key,改用 lockfile 哈希。
  • AI 能写整条流水线吗? 起草可以,原样上线不行。合并前安全边界和密钥处理必须人审。
  • Docker layer 缓存怎么做? 镜像构建有用——把 cache 推到 registry,别只留本地 Docker,否则 runner 复用不了。
  • 怎么发现假绿 CI? 跑模板 4(门禁诚实度),再在 YAML 里搜 continue-on-error|| true

相关阅读

标签: #Prompt #编程 #CI/CD #GitHub Actions #DevOps