技能介绍

解决什么问题

部署上线从来不是「把代码推到生产环境」就结束了。很多团队的发布流程靠约定和经验：有人记得跑测试就跑，没人记得就跳过；上线后没人盯监控，问题从用户投诉里才暴露出来；出问题想回滚，发现回滚脚本两周没人维护了。这个技能要解决的就是这类发布可靠性缺失的问题——让每一次上线都是可逆的、可观测的、渐进式的。

核心能力

技能围绕一次安全发布给出完整工作流：

发布前检查清单：覆盖代码质量（测试、lint、审查）、安全（密钥、依赖漏洞、CORS 配置）、性能（Core Web Vitals、N+1 查询、包体积）、无障碍（键盘导航、对比度、axe-core 检查）、基础设施（迁移、DNS、健康检查端点）和文档（README、ADR、changelog）六个维度，每一项都是可勾选的具体条目。
特性开关策略：把部署和发布解耦。每个开关必须有负责人和过期日期，全量上线后两周内清理，禁止嵌套开关，CI 中同时测试开和关两种状态。
分阶段放量：不是全量推开，而是按阈值逐步推进。错误率、P95 延迟、客户端 JS 错误、业务指标四项指标分别对应「推进 / 观察 / 回滚」三档决策线，比如错误率超过基线 2 倍直接回滚，P95 延迟超过基线 50% 立即回滚。
监控与上线后验证：上线后第一小时逐项验证——健康检查返回 200、错误率正常、关键用户流程可用、日志正常流动、回滚手段已就绪。

适用边界与注意点

这个技能是流程框架，不替代你的 CI/CD 工具链，也不提供具体监控平台的接入代码。清单里提到的工具（如 axe-core、Lighthouse）需要你自己集成到流水线中。另外，表里的阈值是通用默认值，金融或医疗等高敏感场景需要按业务风险重新校准。最需要警惕的是那些听起来很耳熟的借口：「测试环境没问题，生产肯定行」、「这个功能简单，不需要开关」、「监控过阵子再加」——技能里专门列出了这些合理化借口及其对应的事实，发布评审时不妨拿出来对一遍。