技能介绍

问题：未经测试的改动可能直接进入生产

当团队快速迭代时，常出现三类问题：一是开发者跳过本地检查直接提交，导致低级错误（如语法错误、类型不匹配）流入主分支；二是CI流水线仅覆盖部分检查（如仅跑测试），遗漏lint、类型检查或安全审计，使潜在问题未被拦截；三是部署流程缺乏回滚机制，一旦生产环境出错只能手动修复，耗时且易引入新问题。这些问题叠加会导致发布风险升高、故障恢复时间延长，甚至破坏团队对发布流程的信任。

核心机制：质量门禁流水线与反馈闭环

该技能通过强制质量门禁和自动化反馈机制解决上述问题：

合并前门禁（不可跳过）：每个PR必须依次通过lint→类型检查→单元测试→构建→安全审计，任一环节失败则阻断合并，直接在分支上修复后重新触发。例如，类型错误需读报错处修正，测试失败则走调试-恢复流程，禁止跳过测试或放宽规则。
CI配置模板：基于GitHub Actions的基础流水线包含actions/checkout@v4、setup-node（带依赖缓存）、npm ci、tsc --noEmit等步骤；集成测试通过services: postgres启动健康检查容器，凭证由Secrets管理；E2E测试用Playwright安装chromium并上传失败报告。
失败反馈环：CI失败时复制具体报错（如npm run lint --fix后的修正内容）喂给Agent，要求“修复并本地验证后再推”，形成开发-验证闭环。
部署策略：每个PR触发预览环境供手动测试；特性开关支持灰度发布（1%→10%→100%）和A/B测试，且需明确生命周期（创建→测试→灰度→全量→移除死代码）；生产发布采用分级流程（PR合并→staging验证→生产部署→15分钟监控窗），并预设workflow_dispatch手动回滚接口。

适用边界与注意点

适用场景：新建项目的CI流水线搭建、现有流水线的检查项增改、部署流程优化或CI失败调试。
不适用场景：纯本地一次性脚本（但仍建议添加基础门禁）；已高度稳定的项目（可简化流程但需保留关键检查）。
密钥管理红线：CI环境必须使用独立Secrets，禁止硬编码或复用生产密钥；.env文件需本地管理，.env.test可提交但需剔除真实密钥。
性能优化触发条件：当CI时长超过10分钟时，按“缓存依赖→并行job→路径过滤→矩阵分片→测试套件优化→升级runner”的顺序逐步优化，避免过度拆分影响可读性。