“CI 怎么这么慢”答案多半在 YAML 里——但没人愿意读 600 行。好的流水线审计 Prompt 要列维度（缓存、并行、密钥、门禁），强制证据，输出按优先级排好的 action。
适合哪些场景
平台工程师、被 25 分钟 CI 磨疯的 tech lead、想发得更快的创业者、CI 账单比团队涨得还快的人。
什么时候不建议这样写 Prompt
没测试的流水线别审——审计修不了缺概念。没 perf baseline 别动。
Prompt 结构公式
每个流水线审计 Prompt 都要带这六个要素：
- 角色：AI 扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL。
- 目标：一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
- 限制：AI 不能做什么（别自动修、别瞎造文件路径）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可运行代码。
- 示例 / 信号：1-2 条”好输出”示例，或反例。
这套 Prompt 适合用在哪
- 把 CI 时间砍半
- 验证门禁该红的时候真的红
- 密钥 / OIDC 迁移
- 自建 vs 托管 runner 决策
- CI 账单审计
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.可替换变量： filename，例如 .github/workflows/ci.yml
2. 缓存审计
Audit caching for this pipeline. For each cache step: (1) Cache key — content-hash based or static? (2) Path — does it actually cover the heavy install? (3) Restore-keys correctly listed for partial hits? (4) TTL / invalidation strategy. Output a fix per cache.3. 并行度审计
Find parallelism opportunities: (1) Jobs that needlessly `needs:` another, (2) Tests that could shard, (3) Build + lint + typecheck running sequential when they could be parallel, (4) Matrix entries that don't need full coverage. Output a YAML diff.4. 门禁诚实度审计
Audit gates: which steps are `continue-on-error: true`, set `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` / step output, (3) PRs from forks with access to secrets, (4) Secret names that look like they're leaking purpose. Output remediation list.6. 自建 vs 托管 runner
We currently use {provider}. Decide whether to add self-hosted runners for: (1) Heavy CPU steps (build, e2e), (2) Steps needing custom OS, (3) Steps that hit private network. For each: cost / maintenance estimate + recommendation.可替换变量： provider —— GitHub Actions / GitLab / 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 PR and 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 cost {monthlyCost}. 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 top 3 savings.可替换变量： monthlyCost 月成本
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 web pipeline. Output `paths:` blocks per workflow.11. 抽离 reusable workflow
Identify steps repeated across 3+ workflows that could be a reusable workflow / composite action: (1) Setup (node + pnpm + cache), (2) Lint, (3) Test reporters, (4) Deploy. Output the refactor plan + 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.容易踩的坑
- 直接缓存
node_modules——慢、跨 OS 还崩。 - 每个 PR 跑全套 e2e。
- “不想被挡”就
continue-on-error: true。 - fork PR 能拿到 secret——常见泄漏路径。
- 没 path filter——每个 PR 跑所有 job。
- 自建 runner 没生命周期管理——安全风险。
- PR 上跑全 matrix；matrix 应只在 main / release 上跑。
优化技巧
- cache key 用 content hash（lockfile、package.json）。
- 尽量用 OIDC 取代长期云密钥。
- 必需 / 可选检查刻意区分——必需 = 信任信号。
- path filter 比换 runner 省得更多。
- reusable workflow 去重 + 中心化安全补丁。
- 记录每 PR 的 CI 分钟数，便于揪 flake。
- 快失败：先跑便宜（lint / typecheck），再跑贵的（e2e）。
实操加深
使用这些 prompt 时，不要只替换一个主题词就直接交付。围绕「CI/CD 流水线审计 Prompt：又快又可信模板」先补齐受众、渠道、长度、语气、参考样例、禁止样式和成功标准，再让模型输出 2 个不同版本做横向比较。好的结果应该能被另一个人直接复用，而不是只有顺滑但空泛的表达。
如果输出看起来像通用模板，下一轮要增加一个真实场景、一个反例和一个可检查指标，例如点击率、转化动作、字数、平台限制或品牌禁区。这样改出来的内容才更像可用资产，而不是一次性的灵感草稿。
FAQ
- 什么时候上自建 runner？: 托管成本 > 自建维护 + 需要特殊硬件或私网时。
- CI 多快算合理？: PR 上 < 10 分钟。再慢开发行为开始退化。
- GitHub Actions 缓存可靠吗？: 可靠，前提是 key 确定。别用日期 key。
- AI 能写流水线吗？: 草稿可以，原样上线不行——安全边界 / secret 必须人审。
- Docker layer 缓存怎么做？: 镜像构建有用，但 cache 要推到 registry，别只本地。
- 怎么发现假绿 CI？: 用模板 4，并搜
continue-on-error/|| true。