| name | quality-gate |
| description | 代码提交前一站式质量门控：自动运行完整检查清单，不通过不放行。当用户说'审查代码'、'能上线吗'、'准备提交'、'代码质量'、'跑下测试'、'检查安全'、'这代码能用吗'时触发。核心特点：单元测试+E2E测试+安全扫描+AI置信度评估+代码规范检查，一键输出质量报告，替代人工Code Review环节。 |
来源: 蒸馏（融合 testing-patterns + webapp-testing + test-driven-development + security-audit + confidence-check + opinionated-engineer）
发布时间: 2026-05-15
理念: "代码提交前必须经过门控——不是针对人，是针对质量。"
🛡️ Quality Gate — 代码质量门控
代码提交前的一站式检查。不通过，不放行。
🎯 五维质量检查
Quality Gate
├── 🧪 测试维度 (Testing)
│ ├── 单元测试覆盖率 ≥ 80%
│ ├── 集成测试通过率 100%
│ ├── E2E 核心场景通过
│ └── 边界条件覆盖
├── 🔒 安全维度 (Security)
│ ├── OWASP Top 10 扫描
│ ├── 依赖漏洞检查 (Snyk)
│ ├── 敏感信息泄露检测
│ └── 输入校验完整性
├── 📐 规范维度 (Standards)
│ ├── 代码风格 (ESLint/Prettier)
│ ├── 类型检查 (TypeScript)
│ ├── 命名规范
│ └── 注释完整性
├── 🧠 逻辑维度 (Logic)
│ ├── AI 置信度评估
│ ├── 圈复杂度 < 10
│ ├── 重复代码检测
│ └── 潜在 Bug 识别
└── 📊 性能维度 (Performance)
├── bundle 大小
├── 首屏加载时间
├── 内存泄漏检测
└── 数据库查询优化
🛠️ 检查流程
Step 1: 自动收集代码
AI：
1. 读取本次变更的文件
2. 识别变更范围（前端/后端/数据库/配置）
3. 加载相关测试文件
Step 2: 运行五维检查
维度1: 测试检查
□ 单元测试
├── 测试文件是否存在？
├── 覆盖率 ≥ 80%？
├── 所有测试通过？
└── 边界条件是否覆盖？
□ 集成测试
├── API 契约是否匹配？
├── 数据库操作是否正确？
└── 错误场景是否测试？
□ E2E 测试（如适用）
├── 核心用户流程是否通过？
├── 跨页面状态是否正确？
└── 响应式布局是否正常？
维度2: 安全检查
□ 输入校验
├── 所有 API 入口有校验？
├── SQL 注入防护？
├── XSS 防护？
└── 文件上传限制？
□ 认证授权
├── 敏感操作需要认证？
├── 权限粒度是否合理？
└── Token 过期处理？
□ 依赖安全
├── 无高危漏洞依赖？
├── 密钥未硬编码？
└── 日志未泄露敏感信息？
维度3: 规范检查
□ 代码风格
├── ESLint 0 错误？
├── Prettier 已格式化？
└── 命名符合团队规范？
□ 类型完整
├── TypeScript 0 错误？
├── 无 any 类型滥用？
└── 函数返回值已标注？
□ 文档完整
├── 公共 API 有 JSDoc？
├── 复杂逻辑有注释？
└── README 已更新？
维度4: 逻辑检查
□ AI 置信度评估
├── 对实现的信心（1-10）
├── 对边界的信心（1-10）
└── 对架构的信心（1-10）
□ 代码质量
├── 圈复杂度 < 10？
├── 函数长度 < 30 行？
├── 无重复代码？
└── 无死代码？
维度5: 性能检查
□ 前端性能
├── bundle 大小合理？
├── 图片已优化？
├── 无内存泄漏？
└── 核心 Web Vitals 达标？
□ 后端性能
├── 数据库查询有索引？
├── N+1 查询已解决？
├── 缓存策略合理？
└── 并发处理正确？
Step 3: 生成质量报告
╔══════════════════════════════════════════════════════╗
║ Quality Gate 质量检查报告 ║
╠══════════════════════════════════════════════════════╣
║ 检查时间: 2026-05-15 14:32 ║
║ 检查范围: src/auth/**, src/task/** ║
╠══════════════════════════════════════════════════════╣
║ 🧪 测试维度 ████████░░ 覆盖率 82% ✅ 通过 ║
║ 🔒 安全维度 ██████████ 0 高危漏洞 ✅ 通过 ║
║ 📐 规范维度 █████████░ 2 警告 ⚠️ 通过 ║
║ 🧠 逻辑维度 ████████░░ 置信度 8.5 ✅ 通过 ║
║ 📊 性能维度 █████████░ LCP 1.8s ✅ 通过 ║
╠══════════════════════════════════════════════════════╣
║ 综合评分: 8.7 / 10 ║
║ 状态: ✅ 通过（可提交） ║
╚══════════════════════════════════════════════════════╝
⚠️ 警告详情：
- src/auth/service.ts:42: 函数 login() 长度 45 行，建议拆分为 < 30 行
- src/task/dto.ts:15: 缺少 JSDoc 注释
建议：
1. 拆分 login() 函数为 validate + generateToken + audit 三个子函数
2. 为 CreateTaskDto 添加字段说明注释
💡 使用示例
示例1：提交前检查
用户：审查这段代码，能提交吗？
AI（运行 Quality Gate）：
1. 收集变更：src/payment/**（+3 文件，-1 文件）
2. 运行五维检查...
3. 生成报告：
综合评分: 6.2 / 10
状态: ❌ 不通过（2 项阻塞）
阻塞项：
1. 🔒 安全: 支付回调接口缺少幂等性校验
风险: 重复处理支付，导致重复扣款
修复: 添加唯一请求 ID + 去重逻辑
2. 🧪 测试: 支付模块覆盖率 45%（要求 ≥ 80%）
缺失: 错误场景测试（网络超时、签名失败）
修复: 补充 5 个边界测试用例
警告项：
3. 📐 规范: 函数 processPayment() 圈复杂度 15
4. 🧠 逻辑: 对并发处理的信心 5/10
修复后重新运行 Quality Gate？
示例2：快速检查
用户：快速检查下，赶时间
AI（精简模式）：
只运行阻塞项检查：
□ 安全漏洞 - ✅ 通过
□ 核心测试 - ✅ 通过
□ 类型检查 - ✅ 通过
快速评分: 7.5 / 10
状态: ✅ 通过（建议上线后补充文档）
示例3：修复后复测
用户：已修复，再检查一次
AI（增量检查）：
只检查变更部分：
1. 幂等性校验 - ✅ 已添加
2. 测试覆盖率 - ✅ 85%（+40%）
3. 圈复杂度 - ✅ 8（从 15 降到 8）
综合评分: 8.9 / 10
状态: ✅ 通过（可提交）
🆚 与被蒸馏 Skill 的关系
| 被蒸馏 Skill | 在 Quality Gate 中的角色 | 何时单独使用 |
|---|
| testing-patterns | 测试维度策略 | 不需要，quality-gate 自动调用 |
| webapp-testing | E2E 测试执行 | 不需要，quality-gate 自动调用 |
| test-driven-development | 测试先行的方法论 | 不需要，quality-gate 自动调用 |
| security-audit | 安全维度扫描 | 不需要，quality-gate 自动调用 |
| confidence-check | AI 置信度评估 | 不需要，quality-gate 自动调用 |
| opinionated-engineer | 规范维度检查 | 不需要，quality-gate 自动调用 |
| git-commit | 提交规范检查 | 单独使用（提交信息格式） |
🚀 快速开始
用户：审查代码 / 能上线吗 / 准备提交
AI：
1. 收集本次变更
2. 运行五维检查（测试/安全/规范/逻辑/性能）
3. 生成质量报告（评分 + 阻塞项 + 警告项）
4. 判定：通过 / 不通过
5. 提供修复建议
"Quality Gate 不是拦路虎，是护城河。"
