“给我一份上线清单”得到的是 30 条没人看的通用条目。好的上线 Prompt 必须按服务（Next.js？App？Postgres 迁移？）来，门禁在可观测信号上（错误率、p99），最后给出一句话 GO/NO-GO。
适合哪些场景
Release Captain、值班工程师、每周发布的创业团队、需要在 #releases 里写”能不能上”的所有人。
什么时候不建议这样写 Prompt
小服务真正持续部署别用——清单成本大于风险。团队没可观测性别用——只是表演。
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 模板
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, (3) Contract: remove old. For each phase: deploy order, monitoring, expected duration, rollback. Don't suggest a single big-bang migration.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 metrics within +10%, promote; else auto-rollback. Specify exact thresholds and the dashboard URL placeholder.可替换变量： serviceName
5. 移动端 / App Store 发布预检
Pre-flight checklist for a mobile release: (1) Build signed and verified on 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 ≤ 15 words. No bug ticket numbers. No "refactor", "chore", "bump dep" — those go in Internal. Tone: factual, no marketing language.可替换变量： changelog
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.可替换变量： 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., 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. ≤ 200 words.12. hotfix 发布计划
Plan a hotfix release for a Sev-2 bug: {bugSummary}. Constraints: must ship in < 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 > 99%, (4) Critical user journey (login → key action → success) works on prod. Output a script-style checklist.容易踩的坑
- 30 条通用清单——太长没人看完。
- 不卡可观测性——从用户推文上发现回归。
- 没回滚路径——首次失败直接变事故。
- 一次性大迁移——一半生产事故的源头。
- 周五下午上线——值班崩溃。
- 不检查”告警还在不在”——发现 6 周前被静默了。
- 不通知客户 / 支持——售前售后被打个措手不及。
优化技巧
- 每份清单末尾一句话 GO / NO-GO，强制决策。
- 告警未就位算 NO-GO，不是警告。
- schema 永远 expand → migrate → contract，每个 PR 一阶段。
- 5% 灰度 30 分钟胜过 5 分钟 100% 直推。
- 回滚要演练，一次彩排能发现陈旧 runbook。
- release notes 绑定 diff 不绑定愿望清单。
- 周五别发，除非有完整值班。
FAQ
- 每次发布都要清单吗？: 不必，纯 CSS 改动不需要。改动到数据 / auth / 支付 / 热路径时再用。
- 清单多长合适？: 7-12 条，多了没人跑完。
- AI 能替我跑检查吗？: 部分可以——build 状态、lockfile diff、dashboard URL。多数还需人眼。
- 灰度比例多少合适？: 5% × 30 分钟基线，流量极低的产品再缩。
- 回滚要多快？: 代码 5 分钟内，schema 30 分钟内。慢就先修回滚路径再发下次。
- hotfix 可以跳过整套检查吗？: 可以跳慢的部分（全套 e2e），快的部分（build 绿、告警就位、回滚就绪）保留。