quality-gate

name	quality-gate
description	用于设置和检查质量门 - 定义每个阶段的质量标准，检查是否达到标准，决定是否可以进入下一阶段。这是AI工作坊保证质量的核心技能。
keywords	["质量门","quality gate","质量标准","质量检查","阶段控制"]
tags	["AI编排","质量管理"]
trigger_phrases	["质量门","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: 创建质量报告

创建质量门报告：

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

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

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

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

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

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

### [标准2]
...

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

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

Quality Gate Structure

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

## 阶段质量标准

### 阶段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

认知负荷理论应用

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

格式塔原则应用

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

损失厌恶应用

• 强调严重性：在未通过标准部分强调严重性
• 强调影响：在决策理由部分强调不通过的后果