灰度發佈與功能開關方案提示詞（按比例 / 白名單放量、關鍵指標監控、一鍵回滾、開關清理）
重要功能上線想先給一小部分用戶試用、出問題能馬上關掉，或者想讓未完成的功能先合入主幹而不影響用戶時用：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 條評論
還沒有評論，來搶沙發～