“给我一份上线清单”换来的是 30 条没人看的通用条目。真正能给发布降风险的 Prompt，必须按服务来（Next.js？App？Postgres 迁移？），门禁卡在可观测信号上（错误率、p99），最后给出一句话 go/no-go。DORA 研究把这条线说得很直白：最强的团队把变更失败率压在约 5%，出问题后在一小时内恢复服务。空泛的清单做不到，明确、按信号卡口的清单才能。
TL;DR
- 下面每个 Prompt 都钉死了角色、明确的服务/技术栈、单一交付物，以及一句强制的 GO / NO-GO，让 AI 没法和稀泥。
- 占位符用
[方括号]，发送前先替换。 - 把 diff 或迁移脚本直接贴进你的 AI 工具。截至 2026 年 6 月，务实的默认选择是用 Claude Code（Opus 4.7 / Sonnet 4.6）处理终端里的 diff，或用 Cursor 做编辑器内审查。见下文”用哪个 AI 工具跑最顺”。
- 最高杠杆的四个：#1 go/no-go、#2 expand → migrate → contract 迁移、#4 灰度、#7 回滚 playbook。
适合哪些人
Release Captain、值班工程师、每周发布的创业团队，以及所有需要在 #releases 里写”这玩意儿能不能上”的人。
什么时候不建议这样写
小服务真正持续部署就别用，清单成本大于风险。团队没有可观测性也别用，那只是表演——一个”和基线比”的灰度，如果根本没有基线 dashboard，就毫无意义。
Prompt 结构：六个要素
每个上线 Prompt 都要带这六个要素：
- 角色：让 AI 扮演谁（Release Captain / QA Lead / SRE / staff 工程师）。
- 上下文：仓库 / 框架 / 运行时 / 分支 / diff / 失败日志。
- 目标：一个具体可交付物——checklist、计划、测试文件、review 笔记、根因、ticket 列表。
- 限制：AI 不能做什么（别自动修、别静默改写、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON schema、unified diff，或可直接运行的代码。
- 信号：1-2 条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 上线前 go/no-go
- 灰度 / 分阶段 rollout 计划
- 回滚 playbook
- 从 diff 推导 release notes
- 面向干系人的发布公告
13 个可直接复制的 Prompt 模板
占位符用 [方括号]，发送前逐个替换，并把真实产物（diff、迁移 SQL、changelog）原样贴进去，让模型针对你的代码推理，而不是泛泛的技术栈。
1. 按服务定制的 go/no-go
You are a release captain. Generate a go/no-go checklist for a [stack] service deploying [changeSummary]. Sections: (1) Build & tests green, (2) Schema migration (none / forward-only / breaking), (3) Feature flag state, (4) Observability — dashboards live, alerts armed, (5) Rollback path tested. End with a single line: "GO" or "NO-GO + reason".可替换变量： [stack] 技术栈（例如 Next.js + Postgres + Vercel）、[changeSummary] 本次变更摘要
2. schema 迁移发布计划
For this DB migration, plan a safe release in 3 phases: (1) Expand: add new columns / tables without removing old, (2) Migrate: backfill + dual-write, reads still hit the old column, (3) Contract: remove old once nothing reads it. For each phase: deploy order, monitoring, expected duration, rollback. One PR per phase. Don't suggest a single big-bang migration.这就是 expand/contract 模式：每个阶段都向后兼容，所以任何一步都能单独回滚，不丢数据。
3. feature flag 灰度计划
Plan a percentage rollout for `[flagName]`: (1) 1% internal users 1 hour, (2) 10% real users 24 hours, (3) 50% 24 hours, (4) 100%. For each step: success metric, alert rule, rollback action. Include criteria to abort early. Don't propose 100% on day 1.可替换变量： [flagName]
4. 灰度（canary）部署计划
Design a canary plan for `[serviceName]`: (1) Route 5% traffic to new version, (2) Compare p50 / p99 / error rate against baseline for 30 minutes, (3) If error rate stays under 1% and p99 within +10%, promote; else auto-rollback. Specify exact thresholds and a [dashboardURL] placeholder. Rollback must be a version flip, not a redeploy.可替换变量： [serviceName]、[dashboardURL]
5. 移动端 / App Store 发布预检
Pre-flight checklist for a mobile release: (1) Build signed and verified on a physical device, (2) App-store metadata diff vs last release, (3) Push notification + IAP verified in sandbox, (4) Crash-free rate baseline noted, (5) Phased rollout enabled at 10%. Flag any item NOT addressable from CI.6. 从 diff 写 release notes
Generate user-facing release notes from this changelog: [changelog]. Sections: New, Improved, Fixed, Internal (omit if empty). Each bullet under 15 words. No bug ticket numbers. No "refactor", "chore", "bump dep" — those go in Internal. Tone: factual, no marketing language.可替换变量： [changelog]——或者直接把 git log / git diff 管道喂进去（见下文工具一节）。
7. 回滚 playbook
Write a rollback playbook for `[serviceName]` covering: (1) Re-deploy previous build (exact command), (2) Revert schema migration if applicable, including dual-write reversal, (3) Disable feature flag, (4) Clear CDN cache, (5) Comms — who to notify, in what channel, when. Max 7 numbered steps. Target: code rollback under 5 minutes.可替换变量： [serviceName]
8. 发布前依赖检查
Audit dependencies for this release: (1) Lockfile changes since last release, (2) Any new direct deps — owner / size / risk, (3) Any peer-dep mismatches, (4) Any deps that introduced new permissions (e.g., a postinstall script). Output a table.9. 可观测性就位检查
Confirm observability is armed for this release: (1) Dashboards exist for the new endpoints — list URLs, (2) Alerts on error rate + p99 + saturation, (3) Logs include trace IDs propagated end-to-end, (4) New metrics appear in production (not zero). Anything missing is a NO-GO.10. 对外沟通计划
Draft customer-facing comms for this release: (1) Status page entry if there's any downtime risk, (2) Changelog post — title + 3 bullets, (3) Tweet / LinkedIn post for one user-visible feature, (4) Email to affected customers only if breaking. Plain language. No internal jargon.11. 对内沟通计划
Draft an internal release message for #releases: (1) Title with version + date, (2) 3-bullet what-changed, (3) Owners on call, (4) Known risks, (5) Rollback link. Under 200 words.12. hotfix 发布计划
Plan a hotfix release for a Sev-2 bug: [bugSummary]. Constraints: must ship in under 4 hours, no schema changes allowed, no flag rollout (full deploy). Output: (1) Branch + cherry-pick plan, (2) Minimal test set to run, (3) Comms to leadership, (4) Post-mortem owner.可替换变量： [bugSummary]
13. 发布后 30 分钟验证
For 30 minutes after deploy, validate: (1) Error rate within 1% of baseline, (2) p99 latency within +20% of baseline, (3) New endpoints serving 2xx over 99%, (4) Critical user journey (login → key action → success) works on prod. Output a script-style checklist.用哪个 AI 工具跑最顺（2026 年 6 月）
这些 Prompt 的前提是模型能看到你真实的 diff。两种务实搭法：
- Claude Code（终端）：把变更直接管道喂进去，例如
git diff main...HEAD | claude -p "$(cat release-prompt.txt)"。它只跑 Anthropic 模型——迁移和回滚这类推理用 Opus 4.7（最强，SWE-bench Verified 87.6%），快速生成 release notes 用 Sonnet 4.6。两者都是 1M token 上下文，大 diff 一次就能塞进去。没用过？先看 Claude Code 新手指南。 - Cursor（编辑器）：把 Prompt 贴进 chat，让 diff 在上下文里；Cursor 可跑 Sonnet 4.6、Opus 4.7、GPT-5.5 或 Gemini 3.1 Pro。截至 2026 年 6 月，Cursor Pro 为 20 美元/月。怎么选见 Claude Code vs Cursor。
要可复用，就把 Prompt 存成 slash command 或 CI 步骤。Claude Code 接进 GitHub Actions 后，可以在每次打 tag 时自动生成 release notes（Prompt #6）。
容易踩的坑
- 30 条通用清单——太长，没分级，没人看完。
- 不卡可观测性——从用户推文上才发现回归。
- 没有回滚路径——首次失败直接变事故。
- 一次性大迁移——一半生产事故的源头。
- 周五下午上线——值班直接崩。
- 不检查”告警还在不在”——发现 6 周前就被静默了。
- 不通知客户 / 支持——一线被打个措手不及。
怎么把这些 Prompt 磨得更利
- 每份清单末尾必须有一句 GO / NO-GO，逼出明确决策，而不是凭感觉。
- 把”告警就位”设成 NO-GO 条件，不是警告。静默的告警比没告警更糟。
- schema 永远 expand → migrate → contract，每个 PR 一阶段，任一步都能干净回滚。
- 任何碰热路径的改动，5% 灰度 30 分钟都胜过 5 分钟 100% 直推。自动指标门禁（错误率超 1% 自动回滚）才是让渐进式发布”无聊”的关键。
- 回滚要预演。一次彩排就能暴露陈旧的 runbook。
- release notes 绑定 diff，不绑定愿望清单。喂给模型的是
git diff，不是你的路线图。 - 周五别发，除非有完整的周末值班。
FAQ
- 每次发布都要清单吗？：不必。纯 CSS 改动不需要。改动碰到数据 / auth / 支付 / 热路径时再用。
- 清单多长合适？：7-12 条。再多就没人跑完。给必过项打上严重级别标签。
- AI 能替我跑检查吗？：部分可以。build 状态、lockfile diff、列 dashboard URL 都容易自动化；灰度的指标对比和”这到底安不安全”的判断还得人眼。
- 灰度比例多少合适？：基线是 5% × 30 分钟，错误率超 1% 或 p99 漂移超 +10% 就自动回滚。流量极低的产品再往下调。
- 回滚要多快？：代码 5 分钟内，schema 30 分钟内。DORA 最强团队整体恢复在一小时内；如果单次回滚比这还慢，先修回滚路径再发下一次。
- hotfix 可以跳过整套检查吗？：可以跳慢的（全套 e2e），快的（build 绿、告警就位、回滚就绪）必须保留。Prompt #12 就是为这种场景设计的。
- 该用哪个模型跑？：迁移、回滚这类一旦出错代价很大的，用 Opus 4.7；release notes 和沟通文案这类求快的，用 Sonnet 4.6 或 Gemini 3.1 Pro。