| 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
用户将描述他们的质量门需求。按照以下步骤工作:
- 定义质量标准:定义每个阶段的质量标准
- 设置检查点:设置质量检查点
- 执行质量检查:执行质量检查
- 评估检查结果:评估检查结果
- 做出决策:决定是否通过质量门
- 记录决策:记录决策和理由
- 创建质量报告:创建质量门报告
- 逐步思考。以清晰、结构化的格式呈现质量报告。如果输出内容较多,将其作为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
认知负荷理论应用
- 标准分组:将质量标准分组,降低认知负担
- 优先级明确:使用必须/应该/可以级别,降低决策成本
- 检查点限制:限制检查点数量,避免检查疲劳
格式塔原则应用
- 相似性:使用一致的格式展示质量标准
- 邻近性:相关信息在空间上靠近(标准与结果)
- 对比:使用对比突出通过/不通过
损失厌恶应用
- 强调严重性:在未通过标准部分强调严重性
- 强调影响:在决策理由部分强调不通过的后果