灰度发布与功能开关方案提示词（按比例 / 白名单放量、关键指标监控、一键回滚、开关清理）
重要功能上线想先给一小部分用户试用、出问题能马上关掉，或者想让未完成的功能先合入主干而不影响用户时用：AI 设计功能开关的数据结构与判断逻辑、放量节奏和观察指标、回滚条件，以及开关用完后的清理机制。
通用大模型 对话模型通用
你是一名负责线上发布质量的技术负责人。请为下面的功能设计灰度发布方案。 - 功能描述：[功能描述]（例：新的结算页面） - 影响范围与风险：[影响与风险]（例：直接影响下单转化，涉及支付） - 用户分群需求：[分群需求]（例：先内部员工，再 5% 用户，再按城市放量） - 现有基础设施：[基础设施]（例：已有配置中心，没有专门的开关平台） - 前后端技术栈：[技术栈] 请输出： 1. 开关设计： - 开关的类型：发布开关（临时）、实验开关、运维开关（降级用，长期保留）、权限开关；这次属于哪种； - 数据结构：开关名称、默认值、规则（白名单、按比例、按属性）、负责人、创建时间、计划清理时间； - 判断逻辑：按用户编号做稳定的哈希分桶，保证同一个用户每次看到的结果一致，放量比例提高时已经在新版本中的用户不会被移出； - 开关读取失败时的默认行为（通常回到旧版本）。 2. 放量计划：每个阶段的范围、持续时间、进入下一阶段的条件。 3. 观察指标：业务指标（如转化率、支付成功率）、技术指标（错误率、延迟）、用户反馈；新旧两组如何对比；样本量太小时如何避免误判。 4. 回滚：触发回滚的条件与阈值；关闭开关的生效时间（配置推送需要多久）；关闭后正在进行中的用户操作如何处理（例如结算到一半）。 5. 前后端一致：同一个用户在前端和后端读到的开关结果必须一致，说明如何保证。 6. 清理：全量后多长时间内删除开关和旧代码；如何防止开关越积越多（例如定期列出过期开关）。 7. 给出开关判断的核心代码与测试。
高亮处换成你自己的内容：[功能描述]、[影响与风险]、[分群需求]、[基础设施]、[技术栈]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[影响范围与风险] 决定放量节奏：涉及支付和下单的功能，每个阶段要观察更长时间、指标阈值更严格；纯展示类的改动可以放得快一些。[现有基础设施] 没有专门的开关平台时，AI 会给出基于配置中心或数据库的简单实现。
常见坑：
- 用随机数决定用户是否进入新版本，同一个用户刷新一次就在新旧版本之间来回切换。要按用户编号稳定分桶。
- 前端和后端各自判断开关，结果前端显示了新页面，后端却按旧逻辑处理。
- 功能全量后开关一直不删，代码里到处都是新旧两套逻辑，几年后没人知道哪个开关还能动。
追问技巧：追问「把这个开关改造成 A/B 实验，需要补充哪些埋点和分析方法」（可配合 350 号 A/B 测试提示词）。
示例输出
示例，仅供参考（节选）
| 阶段 | 范围 | 持续 | 进入下一阶段的条件 |
|---|---|---|---|
| 1 | 内部员工白名单 | 2 天 | 无严重问题 |
| 2 | 5% 用户 | 3 天 | 支付成功率与旧版相差不超过 0.5 个百分点，错误率无上升 |
| 3 | 30% 用户 | 3 天 | 同上，且转化率无显著下降 |
| 4 | 100% | — | 全量两周后删除开关与旧代码 |
ts
import { createHash } from 'crypto'
// 稳定分桶：同一用户、同一开关，结果固定；提高比例时原有用户保持在新版本
export function inRollout(flag: string, userId: string, percent: number): boolean {
const hash = createHash('sha256').update(`${flag}:${userId}`).digest()
const bucket = hash.readUInt32BE(0) % 10000 // 0 到 9999
return bucket < percent * 100 // percent 取 0 到 100
}同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～