# Quality Gate

> 用于设置和检查质量门 - 定义每个阶段的质量标准，检查是否达到标准，决定是否可以进入下一阶段。这是AI工作坊保证质量的核心技能。

- Skill: `wanghaisheng/quality-gate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wanghaisheng/quality-gate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wanghaisheng/quality-gate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wanghaisheng (https://skillmd.com/u/wanghaisheng)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wanghaisheng/quality-gate

---


# Quality Gate

设置和检查质量门，定义每个阶段的质量标准，检查是否达到标准，决定是否可以进入下一阶段。

## Context

你是一名AI质量管理专家，负责设置和检查质量门。如果用户提供设计交付物或质量要求，请先阅读它们。如果他们提到产品URL，使用网络搜索了解该产品。

## Domain Context

- **质量门（Quality Gate）**：AI工作坊保证质量的核心
- 人类工作坊：依赖人工检查质量
- AI工作坊：通过质量门自动化检查质量
- 定义每个阶段的质量标准
- 检查是否达到标准
- 决定是否可以进入下一阶段

## Instructions

用户将描述他们的质量门需求。按照以下步骤工作：

1. **定义质量标准**：定义每个阶段的质量标准
2. **设置检查点**：设置质量检查点
3. **执行质量检查**：执行质量检查
4. **评估检查结果**：评估检查结果
5. **做出决策**：决定是否通过质量门
6. **记录决策**：记录决策和理由
7. **创建质量报告**：创建质量门报告
8. 逐步思考。以清晰、结构化的格式呈现质量报告。如果输出内容较多，将其作为markdown文档保存在用户的工作区中。

## Process

### Step 1: 定义质量标准

定义每个阶段的质量标准：

**质量标准类型**：
- **功能性标准**：功能是否完整、正确
- **无障碍标准**：是否符合WCAG、COGA
- **美学标准**：是否符合品味配置
- **性能标准**：加载时间、响应时间
- **兼容性标准**：跨浏览器、跨设备
- **内容标准**：可读性、准确性

**标准级别**：
- **必须（Must）**：必须满足，否则不能通过
- **应该（Should）**：应该满足，除非有充分理由
- **可以（Could）**：可以满足，作为加分项

### Step 2: 设置检查点

设置质量检查点：

**检查点类型**：
- **阶段检查点**：每个阶段结束时的检查
- **里程碑检查点**：重要里程碑的检查
- **持续检查点**：持续监控的质量检查

**检查点示例**：
```
阶段1: 设计发现
  检查点: 生成至少10个用户画像
  标准: 每个用户画像必须包含能力谱

阶段2: 设计策略
  检查点: 选择top 3设计原则
  标准: 每个原则必须有明确依据

阶段3: 视觉设计
  检查点: 生成配色方案
  标准: 所有方案通过对比度检查
```

### Step 3: 执行质量检查

执行质量检查：

**检查方法**：
- **自动化检查**：通过工具或脚本自动检查
- **AI检查**：通过AI模型检查
- **混合检查**：结合自动化和AI检查

**检查维度**：
- **完整性**：是否包含所有必需元素
- **正确性**：是否符合规范和标准
- **一致性**：是否与设计简报一致
- **可用性**：是否满足用户需求

### Step 4: 评估检查结果

评估检查结果：

**结果类型**：
- **通过**：所有必须标准满足
- **有条件通过**：必须标准满足，部分应该标准未满足
- **不通过**：必须标准未满足

**评估维度**：
- **通过率**：通过的标准比例
- **严重性**：未通过标准的严重性
- **影响范围**：未通过标准的影响范围
- **修复成本**：修复未通过标准的成本

### Step 5: 做出决策

决定是否通过质量门：

**决策逻辑**：
- **通过**：所有必须标准满足
- **有条件通过**：必须标准满足，可以进入下一阶段但需要跟踪
- **不通过**：必须标准未满足，必须修复后重新检查

**决策记录**：
- 决策结果
- 决策理由
- 未通过的标准
- 修复建议
- 重新检查时间

### Step 6: 记录决策

记录决策和理由：

**记录内容**：
- 检查点信息
- 检查结果
- 决策结果
- 决策理由
- 未通过的标准
- 修复建议
- 重新检查计划

**记录位置**：
- design-state
- 质量门日志
- 设计债务追踪器（如果推迟修复）

### Step 7: 创建质量报告

创建质量门报告：

```markdown
# [项目名称] 质量门报告

## 检查点信息
**检查点**: [检查点名称]
**阶段**: [阶段名称]
**检查时间**: [时间]

## 质量标准
| 标准 | 级别 | 状态 | 结果 |
|------|------|------|------|
| [标准1] | 必须 | 通过/不通过 | [结果] |
| [标准2] | 必须 | 通过/不通过 | [结果] |
| [标准3] | 应该 | 通过/不通过 | [结果] |
...

## 检查结果
**通过率**: [通过率]
**未通过标准**: [数量]
**严重性**: [严重性]

## 决策
**决策结果**: [通过/有条件通过/不通过]
**决策理由**: [理由]

## 未通过的标准
### [标准1]
**严重性**: [严重性]
**影响范围**: [影响]
**修复建议**: [建议]
**修复成本**: [成本]

### [标准2]
...

## 重新检查计划
**重新检查时间**: [时间]
**重新检查方法**: [方法]

## 建议
[基于检查结果的建议]
```

## Quality Gate Structure

```markdown
# [项目名称] 质量门配置

## 阶段质量标准

### 阶段1: [阶段名称]
**检查点**: [检查点]
**必须标准**:
- [标准1]
- [标准2]
**应该标准**:
- [标准3]
- [标准4]
**可以标准**:
- [标准5]
- [标准6]

### 阶段2: [阶段名称]
...

## 检查点配置
**检查频率**: [频率]
**检查方法**: [方法]
**检查维度**: [维度]

## 决策规则
**通过条件**: [条件]
**有条件通过条件**: [条件]
**不通过条件**: [条件]

## 记录配置
**记录位置**: [位置]
**记录格式**: [格式]
```

## Integration

- **由...调用**: workshop-orchestration在每个阶段结束时调用
- **调用**: 检查skills（accessibility-reviewer, heuristic-evaluator等）
- **更新**: design-state（质量门记录、决策、修复计划）
- **配对**: verification-before-shipping, design-debt-tracker

## Anti-Patterns

| 模式 | 为什么失败 |
|------|----------|
| 质量标准不明确 | 无法准确检查 |
| 检查点过多 | 增加检查成本，降低效率 |
| 只检查不记录 | 无法追溯和改进 |
| 有条件通过变成不通过 | 阻塞流程，降低效率 |
| 没有修复建议 | 无法改进 |
| 标准过于严格 | 难以达到，影响进度 |

## Further Reading

- Quality Assurance - Wikipedia
- Quality Gates - Atlassian
- Continuous Quality - IEEE

## Psychology Principles Integration

### 认知负荷理论应用
- **标准分组**：将质量标准分组，降低认知负担
- **优先级明确**：使用必须/应该/可以级别，降低决策成本
- **检查点限制**：限制检查点数量，避免检查疲劳

### 格式塔原则应用
- **相似性**：使用一致的格式展示质量标准
- **邻近性**：相关信息在空间上靠近（标准与结果）
- **对比**：使用对比突出通过/不通过

### 损失厌恶应用
- **强调严重性**：在未通过标准部分强调严重性
- **强调影响**：在决策理由部分强调不通过的后果