编程开发 编辑复核
Feature Flag 灰度发布计划
用人群、流量、指标、开关、回滚和清理时间设计灰度，避免开关长期存在或缺少默认安全状态。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名发布工程负责人。请把灰度当成可观察、可停止的发布过程，明确默认值、权限、数据兼容和最终清理日期。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 定义开关作用域、默认状态、目标人群和逐级比例
2. 为每阶段写功能、性能、错误和业务指标门禁
3. 准备异常处理、回滚、数据兼容和客服沟通
4. 登记开关负责人、到期时间和删除验收
输入变量：
- 功能（{{feature}}）：说明开关控制的行为和依赖。
- 灰度人群（{{audience}}）：说明按账号、地区、设备或比例分组。
- 监控指标（{{metrics}}）：提供技术和业务指标及基线。
- 清理约束（{{cleanup}}）：说明关闭、删除和数据迁移的期限。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先在默认关闭状态测试，再让少量真实用户进入。
- 灰度结束必须删除开关或明确长期 owner，避免逻辑分叉。
WHEN IT FITS
适用判断
适合这些情况
- 功能有一定风险，需要小流量验证后再放开。
- 你有可用的灰度机制，能按比例或按用户分组。
- 需要提前定好放量节奏和回退条件。
换个做法更好
- 改动没有用户可感知的风险：直接上线，灰度是额外成本。
- 你要设计的是 A/B 实验：用《增长实验设计与复盘》，目的是比较而非降险。
- 没有可观测的指标：灰度了也看不出好坏。
FAILURE MODES
常见翻车与修正
- 放量计划只有比例，没写每一档要观察什么。
要求每一档标明观察指标、观察时长和继续放量的判断条件。
- 没有回退条件，出问题时靠临场判断。
要求写明具体的负面阈值（错误率、耗时、关键转化），达到即回退，不需要开会讨论。
- 忘了 flag 的清理，功能全量后开关永久留在代码里。
补充要求：写明 flag 的下线时间和清理动作，包括代码和配置两处。
ACCEPTANCE
怎么判断输出合格
- 每一档放量都有观察指标、时长和继续条件。
- 回退阈值是具体数值，不需要临场判断。
- 写明了 flag 的清理时间和动作。
- 考虑了灰度期间新旧行为并存带来的数据口径问题。
SAFETY BOUNDARY
使用边界
- 灰度计划要明确回滚触发条件和责任人，没有明确条件时问题会拖到影响扩大才处理。
- 开关本身的失效场景也要覆盖：配置服务不可用时功能应该退到哪个状态。