“能发吗？“得到一个 👍，然后跟着一个后悔。上线风险评审要点明爆炸半径、定义护栏指标、设定数字化的终止条件，并确认客服和沟通到位——然后再去推任何百分比。下面这 12 个 Prompt，把这套评审变成一份 10 分钟跑完的清单，让你用 Claude Opus 4.7、GPT-5.5 或 Gemini 3.1 Pro 来跑，而不是靠”我看着没问题”。
太长不看（TL;DR）
- 把你的 diff、flag 名字、dashboard 链接粘进下面的 Prompt，模型会给你一份分阶段计划、终止阈值和一版沟通草稿——是拿来改的，不是闭眼直接发的。
- 实践中靠谱的分阶段节奏（截至 2026 年 6 月）：内部 → 1% → 10% → 50% → 100%，每一步都配一个护栏指标和一个数字化的终止阈值。
- 终止条件必须是具体数字（错误率、转化下跌、工单激增），不能是”看着不对就停”。LaunchDarkly 这类平台的 guarded rollout（带护栏的发布）会在被监控指标回归时自动暂停或自动回滚——你的 Prompt 要产出的，正是这些护栏需要的阈值。
- 这类评审最合适用长上下文的推理模型。三家旗舰现在都是 1M token 窗口，整个 diff 加上 runbook 一次就能粘进去。
适合哪些人
工程经理、创业者、和工程共担上线的 PM，以及任何看过 100% 上线变成 100% 回滚的独立开发者。只要你走 feature flag 发布（LaunchDarkly、Statsig、Unleash、Flagsmith、ConfigCat、PostHog），或自研开关，这套都用得上。
什么时候不用这套 Prompt
只有 10 个客户用的付费选项里的小改动、纯文案改动，跳过完整评审就行。纯基建变更（部署、库表迁移）需要的是另一种 review——见文末的部署和上线检查 Prompt。但凡碰到 auth、支付、数据写入或可见行为的改动，都走完整 ramp。
用哪个模型跑
2026 年 6 月这三家旗舰都能胜任，而且现在都是 1M token 上下文，整个 diff 加 runbook 一次就装得下。
| 模型 | 上下文 | API 进/出（$/1M） | 评审场景适配 |
|---|---|---|---|
| Claude Opus 4.7 | 1M | $5 / $25 | 对可逆性和爆炸半径推理最深；SWE-bench Verified 87.6% |
| GPT-5.5（Thinking） | 1M（完整 1M 仅 $200 Pro） | $5 / $30 | 终端 / 运维清单强；Terminal-Bench 2.0 82.7% |
| Gemini 3.1 Pro | 1M | $2 / $12 | 大 diff 长上下文过一遍最便宜 |
订阅层面，Claude Pro（$20/月，年付 $17）或 ChatGPT Plus（$20/月）跑这套评审都没问题；Plus 的应用内上下文约 320 页，所以 diff 要挑着粘。要对真实分支做 CLI 评审，Claude Code 或 Cursor 可以直接读 diff。
12 个可直接复制的 Prompt 模板
把反引号占位符（`[featureName]`、`[old]`）换成你的真实值。每个 Prompt 都点明角色、可交付物和一条硬限制，免得模型滑回空泛建议。
1. 上线风险 triage
For feature `[featureName]`, assess: (1) Blast radius (% users / which segments), (2) Reversibility (instant flag flip / requires deploy / requires migration backtrack), (3) Detection lag (how long before we'd notice broken), (4) Support load impact. Output GREEN / YELLOW / RED with a one-line reason each.2. 分阶段 rollout
Design a phased rollout: (1) Internal / employees only, (2) 1% real users 24h, (3) 10% 24h, (4) 50% 48h, (5) 100%. For each phase: guardrail metric, alert threshold, abort criteria, who decides to advance. Don't propose Day 1 = 100%.3. 终止条件
Define abort criteria for this rollout: (1) Error rate threshold per endpoint, (2) Conversion drop threshold, (3) Support ticket spike threshold, (4) On-call paging count, (5) SLO error-budget burn rate. Specify exact numbers, not "if it looks bad". Include who has authority to abort.4. cohort / 定向计划
Choose target cohorts for the first rollout: (1) Internal employees, (2) Power users (engaged 30+ days), (3) New signups (less harm if broken), (4) Specific orgs we trust. Avoid: paid enterprise, accessibility-flagged users. Output a cohort definition I can paste into a feature-flag targeting rule.5. A/B vs rollout
Should this be a rollout or an A/B test? Criteria: (a) Are we measuring uplift vs catching regressions? (b) Is sample size sufficient for an A/B? (c) Is the metric well-defined? (d) How long would we keep the variant arm alive? Recommend one, with reasoning.6. 上线前 checklist
Generate a launch checklist: (1) Feature flag live in target env, (2) Dashboards exist with new metrics, (3) Guardrail metric + alert armed, (4) Rollback / kill-switch tested, (5) Support docs published, (6) Customer comms drafted, (7) On-call assigned. Each item GO / NO-GO with the missing owner.7. 客服就绪
Audit support readiness: (1) Help-center article live, (2) Macro / canned reply created, (3) Internal Slack channel for escalation, (4) Known limitations documented. Output: missing items + owner + due date.8. 沟通计划
Draft comms: (1) In-product release note, (2) Email to existing affected users (if behaviour changes), (3) One social post for one user-visible benefit, (4) Status-page entry if any risk of degradation. Keep each ≤ 100 words.9. 老功能下线计划
We're sunsetting feature `[old]`. Plan: (1) Deprecation banner at T-30, (2) Email at T-14, (3) Read-only at T-7, (4) Full removal at T. Per phase: comms + opt-out / migration path. Customers must hear about it 3 times via different channels.10. 上线复盘
Rollout `[featureName]` hit an abort criterion. Write a brief retro: (1) What broke, (2) Detection time, (3) Rollback time, (4) Why didn't an earlier phase catch it, (5) One process change. ≤ 250 words. No blame, just the system gap.11. 风险厌恶客户的慢 rollout
Some customers (enterprise / regulated) don't want auto-rollout. Design an opt-in path: (1) Default state, (2) UI to opt in, (3) How they roll back, (4) Comms cadence. Don't force changes on customers who told us not to.12. 回滚后再发布
We rolled back. Now we want to retry. Plan: (1) Root cause fixed + tested, (2) Phase plan restarted from 1%, (3) Anything we should monitor that we didn't before, (4) Comms — what to say to customers who saw the old version.Feature flag 平台改变了算法（2026 年 6 月）
上面的 Prompt 保持工具无关，但你发布所用的平台，决定了这套评审有多少能自动化、多少要手动跑。
| 平台 | 回归时自动回滚 | 计费形态（截至 2026 年 6 月） |
|---|---|---|
| LaunchDarkly | 有——guarded rollout 在护栏指标回归时自动暂停或回滚（序贯检验） | 按 MAU / 席位；企业报价常见 $25K+/年 |
| Statsig | 有——flag 转实验、序贯检验 | 按事件计费；现已归入 Amplitude（OpenAI 收购后） |
| Unleash / Flagsmith | 手动门禁 + 渐进 rollout；可开源自托管 | 开源免费版；云端付费 |
| PostHog | flag + 实验 + 分析一体 | 免费额度大方，按用量计费 |
| ConfigCat | 百分比定向、简单门禁 | 有免费版；付费固定套餐 |
如果你的平台支持 guarded rollout，那 Prompt #3 就该产出它需要的精确阈值。SRE 常用的一个触发条件：当 SLO 错误预算的燃烧率超过 2 倍、且 15 分钟窗口内剩余预算掉到 20% 以下时，自动回滚。把这条规则直接喂进你的护栏配置。
容易踩的坑
- “功能小”就跳过分阶段——小功能照样会碰到 auth、支付或数据路径。
- 没终止条件——一直往下推，因为没人想当那个喊停的人。
- 先放给付费客户——爆炸半径和声誉成本都高。
- 不让客服知道——被打个措手不及，CSAT 掉一整周。
- 不验证可逆——到 50% 才发现迁移导致回不去。
- A/B 和 rollout 混着用——测的是两回事（增量 vs 回归）。
- 没沟通——客户从一条社媒帖子里得知，而不是从你这里。
优化技巧
- 从 1% 真实用户起步，再小就看不到信号。
- 终止条件是具体数字，不是”看着不对”。
- 每个成功指标都配一个反指标（engagement 涨但客服负担也涨 = 终止）。
- 回滚要在第一阶段前测，不是第四阶段后。
- 用户可感知的变更要三路沟通：产品内 + 邮件 + status page。
- 慢慢下线：30 天内 3 次触达。
- 每次终止 rollout 都做复盘——多半暴露的是监控漏洞，而不是代码 bug。
常见问题（FAQ）
- 每个功能都要分阶段吗？：不必。纯 UI 改、文案改不用；动行为、碰 auth / 支付 / 数据的要。
- 第一波放给谁？：员工 → power user → 新注册 → 一般用户 → 企业。爆炸半径最小的先上。
- A/B 还是 rollout？：测增量用 A/B；防回归用 rollout。目标不同，也可以串起来用（先 rollout 到 10%，再对变体做 A/B）。
- 中止要多快？：代码 flag 翻转 5 分钟内，任何带数据的 30 分钟内——和正常 deploy 的预期一样。
- AI 能帮我定护栏阈值吗？：它能从你过去的故障数据里草拟合理默认值，但只当起点。把阈值绑到你真实的 SLO 和错误预算上，再交给 flag 平台去执行。
- feature flag 什么时候能删？：100% 稳定约 30 天、无终止之后。再拖就成新债务——给 flag 选好类型（发布 / 运维 / 权限），清理才会内建进流程。
相关阅读
- 上线检查 Prompt
- 部署检查 Prompt
- 代码审查 Prompt
- PR 审查 Prompt
- Changelog 生成 Prompt：12 个让 release notes 有用的模板
- 编程开发 Prompt 总目录
标签: #Prompt #编程 #发布 #Feature flag