“能发吗？“得到一个 👍，结果跟着一个后悔。上线风险评审要点明爆炸半径、定义指标、设定终止条件，并确认客服 / 沟通到位——然后再去推任何百分比。
适合哪些场景
工程经理、创业者、和工程共担上线的 PM、看过 100% 上线变 100% 回滚的人。
什么时候不建议这样写 Prompt
只有 10 个客户用的付费选项里的小改动别用。纯基建变更别用——那是另一种 review。
Prompt 结构公式
每个上线风险 Prompt 都要带这六个要素：
- 角色：AI 扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL。
- 目标：一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
- 限制：AI 不能做什么（别自动修、别瞎造文件路径）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可运行代码。
- 示例 / 信号：1-2 条”好输出”示例，或反例。
这套 Prompt 适合用在哪
- 上线前 rollout 计划
- 终止条件定义
- 客服 / 沟通就绪
- A/B vs rollout 决策
- 老功能下线计划
12 个可直接复制的 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.可替换变量： featureName
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: success 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. 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 cohort definition.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) Alerts armed, (4) Rollback / kill-switch tested, (5) Support docs published, (6) Customer comms drafted, (7) On-call assigned. Each item GO / NO-GO.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.8. 沟通计划
Draft comms: (1) In-product release note, (2) Email to existing affected users (if behaviour changes), (3) Tweet / LinkedIn 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.可替换变量： old
10. 上线复盘
Rollout {featureName} hit an abort criterion. Write a brief retro: (1) What broke, (2) Detection time, (3) Rollback time, (4) Why didn't earlier phase catch it, (5) One process change. ≤ 250 words. No blame.可替换变量： featureName
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.容易踩的坑
- “功能小”就跳过分阶段。
- 没终止条件——一直推下去因为没人想喊停。
- 先放给付费客户——爆炸半径和声誉成本都高。
- 不让客服知道——被打个措手不及。
- 不验证可逆——到 50% 才发现回不去。
- A/B 和 rollout 混着用——测的是两回事。
- 没沟通——客户从推特看到的。
优化技巧
- 从 1% 真实用户起步，再小看不到信号。
- 终止条件是具体数字，不是”看着不对”。
- 指标搭配反指（成功 + 副作用），单看 engagement 涨不算赢。
- 回滚必须在第一阶段前测，不是第四阶段后。
- 用户可感知的变更要 in-app + 邮件 + status page 三路沟通。
- sunset 慢推：30 天内 3 次触达。
- 每次终止 rollout 都做复盘——多半是监控漏了。
实操加深
使用这些 prompt 时，不要只替换一个主题词就直接交付。围绕「Feature 上线风险评审 Prompt：12 个安全发布模板」先补齐受众、渠道、长度、语气、参考样例、禁止样式和成功标准，再让模型输出 2 个不同版本做横向比较。好的结果应该能被另一个人直接复用，而不是只有顺滑但空泛的表达。
如果输出看起来像通用模板，下一轮要增加一个真实场景、一个反例和一个可检查指标，例如点击率、转化动作、字数、平台限制或品牌禁区。这样改出来的内容才更像可用资产，而不是一次性的灵感草稿。
FAQ
- 每个功能都要分阶段吗？: 不必。纯 UI / 文案改不用；动行为、auth / 支付 / 数据要。
- 第一波放给谁？: 员工 → power user → 新注册 → 一般用户 → 企业。
- A/B 还是 rollout？: 测增量用 A/B；防回归用 rollout。目标不同。
- 中止要多快？: 代码 < 5 分钟，数据 < 30 分钟——和正常 deploy 一样。
- sunset 怎么沟通？: 30+ 天内 3 次触达：产品内 banner、邮件、status page。
- feature flag 什么时候能删？: 100% 稳定 30 天后。再拖就成新债务。
相关阅读
- 上线检查 Prompt
- 上线检查 Prompt
- 代码审查 Prompt
- PR 审查 Prompt
- Changelog 生成 Prompt：12 个让 release notes 有用的模板
- 编程开发 Prompt 总目录
标签: #Prompt #编程 #发布 #Feature flag