1. 产品介绍
把“已经部署”和“用户已经看见”分开
PostHog把产品使用分析、会话回放、实验和功能开关放在同一套工具里。团队可以了解用户怎样使用产品，也可以决定某个新功能先向谁开放。本文聚焦功能开关：代码已经上线，但是否展示新功能，由用户使用时的开关判断决定。
例如，一个预约网站准备把三页表单改成一页。如果直接向所有人开放，提交失败会影响全部用户；如果先只给内部人员，再逐步扩大，就能在较小范围发现问题。开发者需要事先把新旧路径接入开关，而不是安装一个分析工具就自动获得两套页面。
2. 核心使用流程
先把开与关两条路径接好
以预约网站从三页表单改为一页为教学情境。使用功能开关前，开发者需要在应用里接好新旧两套页面、确定按用户还是组织判断，并准备用户编号与行为记录：编号用来识别同一个人，行为记录包括开始填写、提交成功和出错。部署代码是把能力放上线，开启功能才决定哪些人看到它。
稳定身份是持续体验的前提；已登录用户应使用稳定 ID（识别同一个用户的固定编号）。权限仍由服务端执行，不能因为前端隐藏按钮就认为接口已经拒绝未授权访问。开关负责开放范围，不能替代认证。
从内部范围开始，观察实际使用
- 定义第一批对象：渐进开放指南从自己、内部团队、测试用户或组织逐步推进。先明确这一轮究竟影响谁，再改条件或比例。
- 确认开放结果与界面：检查目标对象是否看到正确路径。排障文档指出身份变化、属性未入库或请求受阻都可能影响结果，加载未完成也不同于明确未向该用户开放。
- 连接行为证据：观察同一批人的进入、开始填写与提交结果，结合事件、回放和异常找出困难，不只看全站平均值。
- 解释比例：配置比例不是每一小批访问者都会恰好达到的数量，少数访问的结果不能直接代表所有用户。
这条过程把“开到多少”变成“哪些人遇到了什么”。如果提交成功与错误事件本身记录不准，就应先修正事件记录，再解释图表。
用观察决定扩大、暂停或关闭
看清本轮结果后，再决定增加范围、继续观察，还是关闭新路径并修正。仅提高比例且其他条件不变时，依据固定规则分配用户会保留已经获得新功能的用户，并可能纳入更多人；更换身份或规则后不能继续假设这一性质成立。
关闭开关改变后续使用路径，不会删除已经提交的预约。旧路径需要事先保持可用，退出动作才能成为准备好的选项。渐进开放的完成点不只是最后达到全量，而是每次范围变化都有清楚的对象、观察依据与后续决定。
3. 设计亮点与借鉴
让同一个人拥有连续的体验
如果每次刷新都重新抽签，预约表单会一会儿三页、一会儿一页，用户很难理解自己做错了什么。PostHog 根据用户身份与固定规则判断是否开放功能；只调整比例、其他条件保持一致时，提高比例会保留已经获得新功能的用户，并可能增加新用户；如果新增区间没有用户，实际新增也可以为0。排障文档说明了这个行为。
设计上的价值不是“随机看起来公平”，而是降低单个用户的来回切换。对应的责任是先定义稳定身份：换了ID、目标对象或规则，就不能继续假设这份连续性天然成立。
放量应扩大圈子，而不是每次把圈子里的人重新洗一遍。
把一项设置连接到它影响的人
“开到20%”是控制动作，“这批人能否完成预约”才是产品问题。把开放条件与事件、回放放在一起，团队能从一条提交失败追到用户经历，而不是只盯着全站平均值。
这里需要认真选择观察对象：已经拿到新版本的人、真正开始使用的人、完成的人，并不总是同一批。只有先区分这些集合，才能知道下降发生在进入功能之前，还是发生在使用过程里。
为退出新路径提前留好入口
渐进开放不只是向前拉一个滑杆。开发者要在上线前确认开关关闭时的旧路径仍可用，团队也要知道何时保持比例、何时停止扩大。这样出问题时的动作才是已经准备好的选择，而不是临时拼出的补救。
值得借鉴的是把发布看成一系列可观察、可调整的决定：每次改变范围，都能解释影响对象、观察依据和下一步。