准备上线新编辑器时，代码合入并不意味着每位用户都要立刻看到它。功能开关可以先让内部账号试用，再逐步扩大范围；发生问题时也能关闭新路径。
每个开关都需要明确用途、负责人和删除日期。没有这些信息的开关会变成难以测试的隐藏分支。
明确开关的用途
每新增一个开关，都记录类型、所有者、受众、默认值、失效时间与关闭后的预期行为：
| 类型 | 用途 | 例子 |
|---|---|---|
| 发布开关 | 降低新代码上线风险 | 只对内部账号启用新编辑器 |
| 权益开关 | 区分购买或授权能力 | Pro 用户可导出历史报告 |
| 运维开关 | 在异常时保护系统 | 暂停高成本批量任务 |
| 实验开关 | 比较明确方案 | 两种 onboarding 说明页 |
不要用实验开关承载长期权限，也不要用权益开关代替服务器端授权。对于安全或计费功能，服务端必须独立验证当前主体的权限；前端开关只能控制呈现，不能成为保护边界。
写下清理时间和关闭后的行为
最小开关记录可以是：
key: new_report_editor
owner: product@example.com
default: off
audience: internal → invited workspaces → 10% eligible users
success signal: report completion rate
stop condition: error rate or support tickets increase
remove by: 2026-10-15到期时间非常重要。开关完成使命后，要删除旧分支、配置和测试，而不是长期保留“以防万一”。开关数量增长时，先审计哪些没有所有者、没有访问记录或已经全量开启；这些通常是最优先的清理对象。
选择受众和停止条件
先选择适合的受众：内部账号、愿意试用的用户、低风险工作区，或稳定的随机分桶。保证同一用户在实验期内始终看到同一版本，否则反馈和行为数据都难以解释。
放量前定义三个东西：
- 价值动作：用户完成什么才说明改动值得继续；
- 护栏指标：错误、取消、支持请求或耗时出现什么变化应立即暂停；
- 决策时间：何时检查、谁能决定扩大、停止或删掉。
如果样本很小，不要给结果贴上“显著提升”的标签。把数据当作线索，结合用户访谈、会话中的错误与反馈记录判断。小产品的优势不是做大规模统计，而是能快速联系到真实用户问“刚才为什么没有完成”。
让实验回答一个问题
“改版首页看看转化”通常同时改了受众、文案、价格与流程，结果无法解释。更好的实验问题是：“把导入前的隐私说明放在按钮旁，是否能减少因不确定而中断的试用？”
实验开始前写一张简短假设卡：目标人群、当前行为、变更、主指标、护栏、最短观察窗口、停止条件和不做的推论。实验结束后无论结果好坏都记录；未提升不等于失败，它可能阻止了你投入更多开发时间。
设计事件时保留隐私边界
实验需要事件，但不需要收集一切。事件名表达用户动作，不表达敏感内容；例如记录 report_exported，而不是完整报告正文。避免把邮箱、搜索词、访问令牌或输入文本拼入事件属性。
分桶规则、事件保留期和供应商访问权限都应能被解释给用户。关于最小事件集、数据保留和同意边界，参阅《隐私优先的产品分析》。
全量上线后的清理
- 默认路径、关闭路径与回退提示都经过测试。
- 开关拥有者和清理日期明确。
- 服务端权限不依赖前端开关。
- 实验有价值动作、护栏与停止条件。
- 用户在实验期内分桶稳定，且可从数据中排除内部测试。
- 全量上线后已删除旧分支、过期配置和不再需要的事件。
功能开关的成功不是数量多，而是让每一次改变都能更安全地开始、更清楚地学习、更干净地结束。