你可能会说
服务器需要金丝雀发布，帮我一步步操作。
新版先放给一小部分用户（如 5%），观察没问题再逐步扩大比例。
新版先放给一小部分用户（如 5%），观察没问题再逐步扩大比例。比全量上线更安全。
生活类比
像矿工带金丝雀下井——先让小鸟试试有没有毒气，鸟没事人才进去。
🎮 动手试试
关于「金丝雀发布」，以下哪个描述最准确？
你可以这样告诉 AI
帮我设计金丝雀发布流程：用 Nginx 按权重分流，10% 流量先到新版，监控错误率 30 分钟再全量切换。
金丝雀发布是按比例逐步放量（5%→50%→100%），出了问题只影响小部分用户；蓝绿部署是一次性切换所有流量，但回滚只需秒级切换。
高风险变更需要验证
大版本更新或重构后，先让 5% 用户尝鲜，用真实流量验证新版本的稳定性，确认无误后再全量放开。
和 AI 协作时
想让 AI 帮你做金丝雀发布，说「帮我设计金丝雀发布流程：用 Nginx 按权重分流，10% 流量到新版，持续观察 30 分钟错误率」。
紧急热修复
小范围的 bug 修复、安全补丁等低风险变更，不需要渐近式发布流程，直接全量上线更快。
与渐进发布无关的项目
客户端 App 的版本更新由用户主动升级或应用商店审核控制，无法像服务端一样按流量比例做金丝雀发布。
新版先放给一小部分用户（如 5%），观察没问题再逐步扩大比例。比全量上线更安全。
像矿工带金丝雀下井——先让小鸟试试有没有毒气，鸟没事人才进去。
和 AI 沟通时提到「用金丝雀发布」，就是先让 5% 用户用新版，没问题再全量放开。