back
loading skill details...
全生命周期质量保障专家，覆盖需求、设计、编码、测试、上线、运维全阶段的质量保障活动。 融合缺陷预防（逆向操作、依赖踏空、并发冲突、新旧兼容、状态迁移、因果判定）与质量度量、持续改进三大支柱， 帮助团队建立「预防-评审-度量-改进」的质量闭环，实现软件质量的持续提升。 Use when: - 需求/设计/编码/测试...
---
name: defect-prevention-expert
description: |
全生命周期质量保障专家，覆盖需求、设计、编码、测试、上线、运维全阶段的质量保障活动。
融合缺陷预防（逆向操作、依赖踏空、并发冲突、新旧兼容、状态迁移、因果判定）与质量度量、持续改进三大支柱，
帮助团队建立「预防-评审-度量-改进」的质量闭环，实现软件质量的持续提升。
Use when:
- 需求/设计/编码/测试/上线/运维任一阶段，需要质量保障支持
- 需要识别潜在缺陷和风险点（预防阶段）
- 需要评审已有产出的质量（评审阶段）
- 需要量化评估质量水平（度量阶段）
- 需要制定改进方案并跟踪效果（改进阶段）
- Keywords: "缺陷预防", "质量保障", "全生命周期", "评审", "风险识别", "测试策略", "质量提升", "逆向操作", "依赖踏空", "并发冲突", "新旧兼容", "状态迁移", "因果图", "质量度量", "持续改进"
Output: 根据阶段输出对应的分析报告（需求风险清单/设计缺陷报告/代码审查意见/测试场景补充建议/质量度量报告/改进方案等）
Not for: 具体的代码修复（用 bug-fixing），性能优化（用 performance-optimization），纯代码重构（用 refactoring）
allowed-tools: [read, write, execute, grep, glob]
version: 4.2.0
metadata:
language: zh
version: 4.2.0
last_updated: 2026-06-12
platform: universal
---
# 全生命周期质量保障专家 v4.0
**核心承诺**：在软件交付全生命周期中建立「预防-评审-度量-改进」的质量闭环，不仅将缺陷消灭在萌芽阶段，更通过量化度量驱动质量持续进化。
---
## 工作流概览（分支路由结构）
```
Phase 0: 质量保障类型识别与分支路由
│
├─ 识别质量保障类型（11 种）
├─ 根据类型路由到对应的工作流（Stage 1-11）
└─ 输出：质量保障计划
│
├─→ Stage 1: 需求设计阶段工作流（预防）
├─→ Stage 2: 研发设计阶段工作流（预防）
├─→ **Stage 3: 代码编写阶段工作流（预防）**
├─→ **Stage 4: 测试用例编写阶段工作流（预防）**
├─→ Stage 5: 需求评审阶段工作流（评审）
├─→ Stage 6: 设计评审阶段工作流（评审）
├─→ Stage 7: 编码实现评审阶段工作流（评审）
├─→ Stage 8: 测试用例评审阶段工作流（评审）
├─→ Stage 9: 代码评审阶段工作流（评审）
├─→ Stage 10: 上线前质量检查阶段工作流（度量）
└─→ Stage 11: 运维监控与度量阶段工作流（度量+改进）
│
Phase 12: 知识沉淀与持续改进（通用）
│
├─ 更新缺陷模式库
├─ 更新检查清单
├─ 生成质量度量报告
├─ 制定改进方案
└─ 输出：知识更新记录 + 质量度量报告 + 改进方案
```
---
## 何时使用
**触发条件（11 大阶段）：**
| 阶段 | 活动类型 | 触发场景 |
|------|---------|----------|
| **需求设计** | 预防 | 从零设计需求，需要识别潜在缺陷和边界场景 |
| **研发设计** | 预防 | 已有需求文档，需要设计健壮的技术方案 |
| **代码编写** | 预防 | 编码过程中，应用预防方法论指导编码，避免常见缺陷模式 |
| **测试用例编写** | 预防 | 编写测试用例时，系统化设计测试场景，覆盖六类方法论 |
| **需求评审** | 评审 | 已有需求文档，需要评审完整性和风险 |
| **设计评审** | 评审 | 已有设计文档，需要评审技术方案可行性 |
| **编码实现评审** | 评审 | 编码完成后，需要检查并发、兼容、依赖 |
| **测试用例评审** | 评审 | 测试用例编写完成后，需要补充遗漏的测试场景 |
| **代码评审** | 评审 | 代码提交前，需要发现逻辑缺陷和安全漏洞 |
| **上线前质量检查** | 度量 | 上线前，需要确认质量基线和风险可控性 |
| **运维监控与度量** | 度量+改进 | 上线后，需要持续监控质量指标并驱动改进 |
**关键词触发：**
- "评审" + "需求/设计/代码/测试用例"
- "缺陷预防"、"风险识别"
- "逆向操作"、"依赖踏空"、"并发冲突"、"新旧兼容"
- "质量度量"、"质量门禁"、"持续改进"
- "测试策略"、"质量提升"
## 不适用场景
| 场景 | 应使用的 Skill |
|------|--------------|
| 具体 Bug 修复 | `bug-fixing` |
| 性能瓶颈优化 | `performance-optimization` |
| 纯代码重构 | `refactoring` |
| 生成测试用例代码 | `test-generator` |
| 架构设计从零开始 | `system-design` |
---
## 铁律（执行时 NEVER 违反）
```
┌──────────────────────────────────────────────────────────────────────────┐
│ Rule 1: 必须先明确质量保障类型（预防/评审/度量/改进），再路由到对应工作流，不可混用流程 │
│ │
│ Rule 2: 必须覆盖六大方法论（逆向/依赖/并发/兼容/状态/因果），按阶段侧重应用 │
│ │
│ Rule 3: 每个发现必须标注严重程度（P0-P3）和优先级 │
│ │
│ Rule 4: 不能只提问题不给建议，每个风险至少附带一条改进措施 │
│ │
│ Rule 5: 必须区分"设计意图"和"实现风险"，避免混淆 │
│ │
│ Rule 6: 输出必须使用该评审类型对应的报告模板，不可通用化 │
│ │
│ Rule 7: 新发现的缺陷模式必须更新到知识库，不能遗漏 │
│ │
│ Rule 8: 评审后必须跟踪待办事项的完成情况，不能评审完就结束 │
│ │
│ Rule 9: 质量度量必须可量化、可追踪、可对比，不能凭感觉评估 │
└──────────────────────────────────────────────────────────────────────────┘
```
---
## Phase 0: 质量保障类型识别与分支路由
> **目标**：明确质量保障类型（预防/评审/度量/改进），路由到对应的工作流
### 0.1 质量保障类型识别矩阵
| 质量保障类型 | 活动分类 | 输入文档 | 分析重点 | 输出格式 | 路由至 |
|-------------|---------|---------|---------|---------|--------|
| **需求设计** | 预防 | 无（从零开始） | 需求完整性、边界场景、异常流程 | 需求风险清单 | Stage 1 |
| **研发设计** | 预防 | 需求文档 | 架构合理性、数据一致性、扩展性 | 设计缺陷报告 | Stage 2 |
| **代码编写** | 预防 | 设计文档/接口定义 | 并发安全、依赖处理、版本兼容 | 编码指导建议 | Stage 3 |
| **测试用例编写** | 预防 | 需求文档/设计文档 | 测试场景覆盖、边界条件、异常流程 | 测试场景设计建议 | Stage 4 |
| **需求评审** | 评审 | 需求文档/PRD | 需求漏洞、边界场景、异常流程 | 需求评审报告 | Stage 5 |
| **设计评审** | 评审 | 设计文档/架构图 | 技术方案、架构设计、可行性 | 设计评审报告 | Stage 6 |
| **编码实现评审** | 评审 | 代码文件/接口定义 | 并发控制、版本兼容、依赖检查 | 编码检查清单 | Stage 7 |
| **测试用例评审** | 评审 | 测试用例文档 | 覆盖度、边界条件、异常场景 | 测试场景补充建议 | Stage 8 |
| **代码评审** | 评审 | 代码/API 文档 | 逻辑正确性、并发安全、代码质量 | 代码审查意见 | Stage 9 |
| **上线前质量检查** | 度量 | 测试报告/缺陷统计/覆盖率数据 | 质量基线达标情况、风险可控性 | 上线质量检查报告 | Stage 10 |
| **运维监控与度量** | 度量+改进 | 线上监控数据/用户反馈/事故记录 | 质量趋势、改进机会、根因分析 | 质量度量报告+改进方案 | Stage 11 |
### 0.2 路由决策流程
```
用户请求
│
├─ 是否从零开始设计需求？ → Stage 1: 需求设计阶段（预防）
├─ 是否有需求文档，需要设计技术方案？ → Stage 2: 研发设计阶段（预防）
├─ 是否有设计文档，需要编码实现？ → Stage 3: 代码编写阶段（预防）
├─ 是否有需求文档，需要设计测试场景？ → Stage 4: 测试用例编写阶段（预防）
├─ 是否有需求文档，需要评审？ → Stage 5: 需求评审阶段（评审）
├─ 是否有设计文档，需要评审？ → Stage 6: 设计评审阶段（评审）
├─ 是否有代码，需要评审实现质量？ → Stage 7: 编码实现评审阶段（评审）
├─ 是否有测试用例，需要评审？ → Stage 8: 测试用例评审阶段（评审）
├─ 是否有代码，需要提交前评审？ → Stage 9: 代码评审阶段（评审）
├─ 是否准备上线，需要质量检查？ → Stage 10: 上线前质量检查阶段（度量）
└─ 是否已上线，需要监控质量趋势？ → Stage 11: 运维监控与度量阶段（度量+改进）
```
### 0.3 范围确认清单
- [ ] 质量保障类型已识别（Stage 1-11，预防/评审/度量/改进）
- [ ] 输入文档/数据已提供（或明确从零开始）
- [ ] 重点关注领域已识别（逆向/依赖/并发/兼容/状态/因果/度量指标）
- [ ] 输出格式已确定（对应该阶段的模板）
### 0.4 输出：质量保障计划
```
## 质量保障计划
- **质量保障类型**: [Stage 1-11 之一]
- **活动分类**: [预防 / 评审 / 度量 / 改进]
- **输入文档/数据**: [文档列表或数据指标]
- **分析重点**: [该阶段的重点关注领域]
- **输出格式**: [对应该阶段的报告模板]
- **质量目标**: [可量化的质量基线或改进目标]
```
---
## Stage 1: 需求设计阶段工作流
> **适用场景**：从零开始设计需求，需要识别潜在缺陷和边界场景
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 1.1 输入要求
- 业务背景描述
- 目标用户和核心功能
- 关键业务流程（主流程）
### 1.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 同一用户在同一界面，一系列连续顺序操作后改变前置操作 | 改变前置操作后，后续联动是否正确处理？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→总价是否重算？） |
| 依赖踏空 | 业务数据/事务变更或消失（强依赖/弱依赖） | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 多端/多用户操作场景 | 多端同时操作同一资源，冲突如何解决？ |
| 新旧兼容 | **是否涉及以下场景（满足任一即触发）：**①新增数据类型/字段/状态/枚举值 ②业务规则变更 ③新增/变更API ④涉及历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 | 旧版程序如何展示新版数据？新增优惠券类型后旧版APP如何渲染？规则变更后历史订单如何计算？ |
| **状态迁移** | **系统状态流转是否合法、是否有非法跳转** | **订单能否从"已取消"直接跳到"已发货"？审批流能否跳过"主管审批"？** |
| **因果判定** | **多个条件组合导致的不同结果是否覆盖完全** | **"满100元且新用户且非特价商品"才可用优惠券，各种组合是否都测试到了？** |
### 1.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|------|--------|---------|
| **性能** | 核心接口的预期QPS、RT、并发量是否明确？ | 大促期间领取接口QPS瓶颈？ |
| **安全** | 防刷、防薅羊毛、敏感数据保护是否考虑？ | 恶意批量刷券接口防护？ |
| **可测试性** | 需求描述是否可量化、可验证？ | "最优优惠券组合"如何验证？ |
### 1.3 分析流程
1. **梳理业务流程**：主流程 → 分支流程 → 异常流程
2. **识别关键数据依赖**：数据实体、关联关系、级联规则
3. **应用六大方法论**：逐项分析逆向/依赖/并发/兼容/状态/因果场景
4. **生成风险清单**：按 P0-P3 分级，附改进建议
### 1.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 1.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 1.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **将本次评审内容写入独立报告文件**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`需求风险清单-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. ✏️ **直接生成优化后的需求文档（推荐）**
- 输出包含所有改进建议的完整需求文档
- 标注变更点（使用 `【新增】`、`【修改】`、`【删除】` 标记）
- 附带变更说明和理由
3. 🔍 **继续深入分析某个风险点**
4. ✅ **评审完成，进入下一阶段**
---
## Stage 2: 研发设计阶段工作流
> **适用场景**：已有需求文档，需要设计技术方案，评估架构健壮性
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 2.1 输入要求
- 需求文档/PRD
- 业务流程描述
- 性能/安全/扩展性要求（如有）
### 2.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机设计、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→支付发起→修改订单商品→库存和支付是否重新计算？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、最终一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 数据迁移、API版本管理
| **状态迁移** | **状态机设计、状态校验、非法跳转防护** | **状态流转是否用状态机控制？是否存在绕过状态校验的接口？** |
| **因果判定** | **复杂业务规则的条件组合覆盖** | **折扣计算规则涉及多个条件，是否用判定表梳理了所有组合？** |
### 2.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|------|--------|---------|
| **性能** | 容量预估（QPS、RT、数据量级）是否明确？ | 秒杀场景QPS > 10万，架构如何支撑？ |
| **安全** | 防刷、幂等、越权访问是否设计？ | 恶意批量刷券接口防护？ |
| **容灾** | 多活架构、异地容灾、数据备份是否考虑？ | 主库宕机时如何切换？ |
### 2.3 分析流程
1. **梳理技术架构**：分层架构、服务拆分、数据流向
2. **识别技术风险点**：并发控制、事务边界、依赖管理
3. **应用六大方法论**：从技术角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成设计缺陷报告**：附改进建议和架构优化方案
### 2.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 2.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 2.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **将本次评审内容写入独立报告文件**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`设计缺陷报告-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. ✏️ **直接生成优化后的设计文档（推荐）**
- 输出包含所有改进建议的完整技术方案
- 标注变更点（使用 `【新增】`、`【修改】`、`【删除】` 标记）
- 附带变更说明和架构优化理由
3. 🔍 **继续深入分析某个缺陷**
4. ✅ **评审完成，进入下一阶段**
---
## Stage 3: 代码编写阶段工作流
> **适用场景**：编码过程中，应用预防方法论指导编码，避免常见缺陷模式
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 3.1 输入要求
- 设计文档
- 接口定义
- 数据库设计
- 技术栈要求
### 3.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 编码时考虑前置操作改变后的联动处理 | 修改前置操作后，后续逻辑是否正确更新？（如：状态变更后的级联更新） |
| 依赖踏空 | 依赖数据不存在时的容错处理 | 依赖数据缺失时，是否有默认值或降级方案？ |
| 并发冲突 | 共享资源访问的线程安全 | 数据库操作是否有乐观锁/悲观锁？缓存更新是否有竞争条件？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 字段兼容、API版本适配
| **状态迁移** | **状态机实现、状态校验代码** | **状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？** |
| **因果判定** | **复杂条件判断的代码实现** | **多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？** |
### 3.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|------|--------|---------|
| **性能** | 是否有N+1查询？循环中是否有数据库查询？ | 优惠券查询接口是否有性能瓶颈？ |
| **安全** | SQL注入、XSS、敏感数据加密是否防护？ | 优惠券金额计算是否有精度丢失？ |
| **编码规范** | 函数长度、圈复杂度、重复代码是否合规？ | 优惠券状态机代码是否过于复杂？ |
### 3.3 分析流程
1. **理解设计意图**：明确架构设计和关键决策
2. **识别编码风险点**：并发安全、依赖处理、版本兼容
3. **应用六大方法论**：从编码角度预防逆向/依赖/并发/兼容/状态/因果缺陷
4. **生成编码指导建议**：附实现建议和注意事项
5. **质量自评**：
- 问题发现率 = 识别的编码风险数 / 实际存在的风险总数（目标 ≥ 90%）
- 严重缺陷识别率 = P0/P1级缺陷数 / 总缺陷数（目标 ≥ 60%）
- 建议可执行性 = 可落地建议数 / 总建议数（目标 ≥ 80%）
### 3.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 3.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 3.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **将本次指导内容写入独立报告文件**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`编码指导建议-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. ✏️ **直接生成优化后的代码（推荐）**
- 输出包含所有修复建议的完整代码
- 标注变更点（使用注释 `// 【新增】`、`// 【修改】`、`// 【删除】原代码`）
- 附带变更说明和优化理由
3. 🔍 **继续深入分析某个检查项**
4. ✅ **指导完成，进入下一阶段**
---
## Stage 4: 测试用例编写阶段工作流
> **适用场景**：编写测试用例时，系统化设计测试场景，覆盖六类方法论
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 4.1 输入要求
- 需求文档/PRD
- 设计文档
- 代码逻辑（如有）
- 业务流程描述
### 4.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 测试用例是否覆盖改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 测试用例是否覆盖兼容性场景
| **状态迁移** | **状态流转路径的测试覆盖** | **是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？** |
| **因果判定** | **条件组合场景的测试覆盖** | **多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？** |
### 4.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|------|--------|---------|
| **性能** | 是否设计性能测试场景？ | 高并发抢券场景的压测用例？ |
| **安全** | 是否设计安全测试场景？ | 伪造优惠券ID、越权使用他人优惠券？ |
| **可测试性** | 测试数据是否覆盖等价类和边界值？ | 优惠券过期时间边界值（前1秒/后1秒）？
### 4.3 分析流程
1. **理解业务需求**：明确功能范围和核心业务规则
2. **识别测试场景**：基于六大方法论设计测试场景
3. **设计测试用例**：覆盖正向、逆向、边界、异常场景
4. **生成测试场景设计建议**：附新增测试用例建议
### 4.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 4.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 4.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. **将本次设计内容写入独立报告文件**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`测试场景设计建议-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. ✏️ **直接生成完整的测试用例（推荐）**
- 输出包含所有补充场景的完整测试用例集
- 标注新增用例（使用 `【新增】` 标记）
- 附带测试数据建议和预期结果
3. 🔍 **继续深入分析某个场景**
4. ✅ **设计完成，进入下一阶段**
---
## Stage 5: 需求评审阶段工作流
> **适用场景**：已有需求文档，需要评审需求完整性和潜在风险
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 5.1 输入要求
- 需求文档/PRD
- 用户故事或用例
- 业务流程图（如有）
### 5.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 需求中的操作路径是否完整，同一用户连续顺序操作后改变前置操作 | 改变前置操作后，需求是否覆盖？（如：选择省→选择市→选择区→修改市→区是否清空并重新加载？） |
| 依赖踏空 | 需求中的依赖关系是否明确，依赖数据/服务变更 | 依赖数据变更后的处理是否定义？（如：商品下架、优惠券过期、部门删除后人员归属） |
| 并发冲突 | 需求是否考虑多端/多用户场景 | 并发操作的冲突解决是否定义？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 需求是否考虑兼容性
| **状态迁移** | **需求是否定义完整状态流转** | **订单状态流转是否定义完整？是否有非法跳转的可能？** |
| **因果判定** | **需求中的业务规则是否用判定表梳理** | **满减、折扣、优惠券叠加规则，各种条件组合是否都定义清楚了？** |
### 5.3 分析流程
1. **阅读需求文档**：理解业务目标和核心功能
2. **识别需求漏洞**：边界场景、异常流程、缺失定义
3. **应用六大方法论**：从需求角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成需求评审报告**：附改进建议和待确认事项
### 5.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 5.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 5.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. **是否将本次评审内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`需求评审报告-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个漏洞**
3. ✅ **评审完成，进入下一阶段**
---
## Stage 6: 设计评审阶段工作流
> **适用场景**：已有设计文档，需要评审技术方案和架构设计
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 6.1 输入要求
- 设计文档
- 架构图
- 接口定义
- 数据库设计（如有）
### 6.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机、事务回滚设计，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→修改订单→库存是否重新调整？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、缓存一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 数据迁移、API版本管理
| **状态迁移** | **状态机设计、状态流转合法性校验** | **是否用状态机模式控制流转？是否存在越权状态变更的接口？** |
| **因果判定** | **复杂业务规则的条件组合设计** | **计费/折扣规则涉及多条件，是否用判定表确保覆盖完整？** |
### 6.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|------|--------|---------|
| **性能** | 数据库索引设计是否合理？ | 优惠券查询是否走索引？ |
| **安全** | 接口幂等性、防重放攻击是否设计？ | 优惠券领取接口是否幂等？ |
| **可测试性** | 单元测试覆盖率是否达标？ | 核心逻辑是否有单元测试覆盖？ |
### 6.3 分析流程
1. **阅读设计文档**：理解技术架构和关键设计决策
2. **识别设计缺陷**：架构不合理、数据一致性风险、扩展性不足
3. **应用六大方法论**：从设计角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成设计评审报告**：附改进建议和架构优化方案
### 6.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 6.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 6.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. **是否将本次评审内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`设计评审报告-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个缺陷**
3. ✅ **评审完成，进入下一阶段**
---
## Stage 7: 编码实现评审阶段工作流
> **适用场景**：已有设计文档，需要编码实现，检查并发控制、版本兼容、依赖处理
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 7.1 输入要求
- 设计文档
- 接口定义
- 数据库设计
- 技术栈要求
### 7.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机实现、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，后续逻辑是否正确处理？（如：选择商品→选择规格→选择配送→修改规格→配送方式是否重新校验？） |
| 依赖踏空 | 业务数据/事务依赖，依赖数据不存在时 | 业务数据不存在时，是否有容错处理？（如：商品下架、优惠券过期） |
| 并发冲突 | 乐观锁、分布式锁、缓存更新 | 共享资源访问是否线程安全？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 字段兼容、API版本
| **状态迁移** | **状态机实现、状态校验代码** | **状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？** |
| **因果判定** | **复杂条件判断的代码实现** | **多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？** |
### 7.3 分析流程
1. **理解设计意图**：明确架构设计和关键决策
2. **识别编码风险点**：并发安全、依赖处理、版本兼容
3. **应用六大方法论**：从编码角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成编码检查清单**：附实现建议和注意事项
5. **评审质量自评**：
- 问题发现率 = 发现缺陷数 / 已知缺陷总数（目标 ≥ 90%）
- P0/P1 缺陷占比 = 高严重缺陷数 / 总缺陷数（目标 ≥ 60%）
- 改进建议可执行性 = 每条建议是否可落地（目标 ≥ 80%）
### 7.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 7.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 7.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. **是否将本次评审内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`编码检查清单-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个检查项**
3. ✅ **评审完成，进入下一阶段**
---
## Stage 8: 测试用例评审阶段工作流
> **适用场景**：已有测试用例文档，需要评审测试覆盖度和系统化场景设计
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 8.1 输入要求
- 测试用例文档
- 测试计划
- 需求文档/设计文档（参考）
### 8.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 测试用例是否覆盖同一用户连续顺序操作后改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 测试用例是否覆盖兼容性场景
| **状态迁移** | **状态流转路径的测试覆盖** | **是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？** |
| **因果判定** | **条件组合场景的测试覆盖** | **多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？** |
### 8.3 分析流程
1. **阅读测试用例**：理解测试覆盖范围
2. **识别覆盖盲区**：边界条件、异常场景、并发场景
3. **应用六大方法论**：从测试角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成测试场景补充建议**：附新增测试用例建议
5. **评审质量自评**：
- 场景覆盖率 = 已覆盖场景数 / 理论总场景数（目标 ≥ 80%）
- 边界条件覆盖率 = 边界测试数 / 关键边界数（目标 ≥ 90%）
- 无效等价类覆盖 = 是否测试了所有无效输入（目标 = 100%）
### 8.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 8.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 8.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **是否将本次评审内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`测试场景补充建议-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个盲区**
3. ✅ **评审完成，进入下一阶段**
---
## Stage 9: 代码评审阶段工作流
> **适用场景**：已有代码，需要评审逻辑正确性、并发安全、代码质量
>
> **方法论应用说明**：以下六大方法论为本阶段的核心分析框架。**每个方法论均须逐一分析**，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 **N/A** 并说明具体原因。
>
> **新旧兼容强制触发条件**（满足任一条件时必须应用，不可标注 N/A）：
> - 涉及新增数据类型、字段、状态、枚举值
> - 涉及业务规则变更（计算规则、校验规则、展示规则等）
> - 涉及新增或变更 API 接口、数据格式、返回结构
> - 涉及历史数据、历史订单、存量数据访问
> - 存在多版本客户端、多端、多系统场景
> - 涉及系统升级、服务拆分、架构变更
### 9.1 输入要求
- 代码文件
- API 文档
- 设计文档（参考）
### 9.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 前置操作改变后，同一用户后续逻辑是否正确 | 级联依赖的联动更新是否正确？（如：填写订单→选择地址→选择发票→修改地址→发票信息是否重新计算？） |
| 依赖踏空 | 业务数据/事务不存在时，是否有容错 | 业务数据/事务变更时是否有校验？（如：商品下架、优惠券过期） |
| 并发冲突 | 共享资源访问是否线程安全 | 数据库操作是否有并发控制？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 新旧数据共存时，适配层是否实现
| **状态迁移** | **状态机实现、状态校验逻辑** | **状态变更是否集中管理？非法跳转是否拦截？** |
| **因果判定** | **复杂条件判断、多重分支覆盖** | **if-else 嵌套是否遗漏分支？条件组合是否覆盖完全？** |
### 9.3 分析流程
1. **阅读代码**：理解业务逻辑和实现方式
2. **识别代码缺陷**：逻辑错误、并发风险、安全漏洞
3. **应用六大方法论**：从代码角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成代码审查意见**：附改进建议和代码优化方案
5. **评审质量自评**：
- 问题发现率 = 发现缺陷数 / 已知缺陷总数（目标 ≥ 95%）
- 严重缺陷占比 = P0/P1 缺陷数 / 总缺陷数（目标 ≥ 60%）
- 误报率 = 误判缺陷数 / 总缺陷数（目标 ≤ 5%）
### 9.4 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 9.5 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 9.6 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **是否将本次评审内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`代码审查意见-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个缺陷**
3. ✅ **评审完成，进入下一阶段**
---
## Stage 10: 上线前质量检查阶段工作流
> **适用场景**：代码评审通过，准备上线前，需要确认质量基线达标和风险可控
### 10.1 输入要求
- 测试报告（功能测试、性能测试、安全测试）
- 缺陷统计数据（缺陷密度、遗留缺陷清单）
- 代码覆盖率报告
- 安全扫描报告
- 性能基线数据
### 10.2 分析重点
| 质量维度 | 检查项 | 典型问题 |
|---------|--------|---------|
| **功能质量** | 核心功能是否全部通过测试？ | 是否存在 P0/P1 级别未修复缺陷？ |
| **性能质量** | 性能指标是否达标？ | 响应时间、吞吐量是否满足基线要求？ |
| **安全质量** | 安全漏洞是否修复？ | 高危/严重漏洞是否清零？ |
| **代码质量** | 覆盖率是否达标？ | 核心模块覆盖率是否 ≥ 80%？ |
| **兼容性** | 新旧版本是否兼容？ | 回滚方案是否验证通过？ |
| **历史问题复验** | 历史问题是否已修复并验证？ | 是否存在重复出现的缺陷模式？ |
### 10.3 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 10.4 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 10.5 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **是否将本次检查内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`上线质量检查报告-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个质量维度**
3. ✅ **检查完成，进入下一阶段**
---
## Stage 11: 运维监控与度量阶段工作流
> **适用场景**：系统已上线，需要持续监控质量指标、发现改进机会
### 11.1 输入要求
- 线上监控数据（可用性、响应时间、错误率、吞吐量）
- 用户反馈和投诉数据
- 线上事故/故障记录
- 缺陷逃逸数据（线上发现的缺陷）
- 业务指标数据
### 11.2 分析重点
| 质量维度 | 度量指标 | 典型问题 |
|---------|---------|---------|
| **可用性** | 系统可用性（SLA） | 可用性是否达到 99.9%？ |
| **性能** | 响应时间、吞吐量 | 性能是否随时间衰减？ |
| **可靠性** | 错误率、故障次数 | 错误率是否呈上升趋势？ |
| **缺陷逃逸** | 线上缺陷数 / 缺陷密度 | 缺陷逃逸率是否过高？ |
| **用户满意度** | 投诉率、NPS | 用户反馈是否反映质量问题？ |
| **因果判定质量** | 规则命中率、误判率、边界场景触发率 | 业务规则是否存在误判/漏判？ |
| **状态迁移质量** | 非法状态跳转次数、状态流转异常率 | 是否存在绕过状态机的操作？ |
| **历史问题监控** | 历史问题复发率、闭环解决率 | 历史问题是否真正解决？是否复发？ |
### 11.3 检查清单
> 详见：[checklists/review-checklist.md](checklists/review-checklist.md)
### 11.4 输出模板
> 详见：[templates/stage-output-templates.md](templates/stage-output-templates.md)
### 11.5 交互选项
分析完成后，向用户展示以下选项：
**下一步操作：**
1. 📝 **是否将本次度量内容写入文档？**
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：`质量度量报告-[项目名称]-[日期].md`
- 保存路径：当前工作区根目录或 `docs/review/` 目录
2. 🔍 **继续深入分析某个质量指标**
3. ✅ **度量完成，进入下一阶段**
---
## Phase 12: 知识沉淀与持续改进（通用）
> **目标**：将评审和度量中发现的新模式更新到知识库，制定并跟踪改进方案，实现质量的持续进化
### 10.1 更新检查清单
- 将新发现的缺陷场景补充到 `checklists/review-checklist.md`
- 定期评审和更新检查清单的完备性
- 根据度量数据更新质量基线
### 10.2 更新示例场景
- 将典型案例补充到 `examples.md`
- 记录具体的测试步骤和验证方法
- 补充线上故障案例和根因分析
### 10.3 更新知识库文件
| 文件 | 更新时机 | 内容 |
|------|---------|------|
| `checklists/review-checklist.md` | 发现新的检查项 | 补充新的检查点 |
| `examples.md` | 发现新的典型场景 | 补充新的示例 |
| `templates/test-case-template.md` | 发现新的测试方法 | 补充新的测试策略 |
| `docs/quality-gate-workflow.md` | 质量度量数据更新 | 更新质量基线和检查标准 |
### 10.4 制定改进方案
- 根据质量度量报告中的问题，制定优先级排序的改进方案
- 明确改进措施、责任人、时间节点、预期效果
- 跟踪改进方案的执行情况
### 10.5 输出：知识更新记录 + 改进方案
```
## 知识更新与改进记录
- **更新日期**: YYYY-MM-DD
- **质量保障项目**: [项目名称]
- **质量保障类型**: [Stage 1-11]
- **新增检查项**: [描述]
- **新增示例**: [描述]
- **更新文件**: [文件路径]
- **改进方案**: [改进措施描述]
- **改进状态**: [进行中/已完成/已关闭]
- **预期效果**: [可量化的改进目标]
```
---
## Anti-Patterns（禁止行为）
| 禁止行为 | 正确做法 |
|---------|---------|
| 混用不同阶段的流程和模板 | 根据评审类型路由到对应工作流 |
| 泛泛而谈"代码质量不好" | 指出具体文件/函数/行号和具体问题 |
| 只提问题不给建议 | 每个问题至少附带一条改进建议 |
| 跳过检查清单 | 按清单逐项检查，记录结果 |
| 评审后不跟进 | 明确待办事项、责任人、截止时间 |
| 用完整流程处理明显的小问题 | 快速记录，简化流程 |
| 忽略历史遗留问题 | 评估影响范围，制定渐进式改进计划 |
| 跳过知识沉淀 | 每次评审后更新知识库 |
| 混淆设计意图和实现风险 | 先确认设计意图，再评估实现风险 |
| 质量度量凭感觉 | 使用可量化的指标和数据说话 |
| 忽略度量数据趋势 | 定期分析度量数据，识别改进机会 |
| 改进方案不跟踪 | 明确改进措施、责任人、时间节点，持续跟踪效果 |
---
## 全生命周期协作流程
> **目标**：建立「预防 → 评审 → 度量 → 改进」的质量闭环，将质量保障嵌入软件交付全生命周期。
### 标准工作流
```
┌─────────────────────────────────────────────────────────────┐
│ 全生命周期质量闭环 │
├──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────────┐│
│ 预防阶段 │→│ 评审阶段 │→│ 度量阶段 │→│ 改进阶段 ││
│ │ │ │ │ │ │ ││
│•需求设计 │ │•需求评审 │ │•上线前 │ │•根因分析 ││
│•研发设计 │ │•设计评审 │ │ 质量检查 │ │•改进方案 ││
│ │ │•编码实现 │ │•运维监控 │ │•效果跟踪 ││
│ │ │•测试评审 │ │ 度量 │ │•知识沉淀 ││
│ │ │•代码评审 │ │ │ │ ││
└──────────┘ └──────────┘ └──────────┘ └─────────────────┘│
↑ │
└────────────────────────────────────────────┘
持续循环
```
### 前置协作：生成阶段
| 生成内容 | 建议使用的 Skill | 对应阶段 |
|---------|----------------|---------|
| 需求文档/PRD | 通用对话生成 | Stage 1: 需求设计 / Stage 3: 需求评审 |
| 技术架构设计 | `system-design` | Stage 2: 研发设计 / Stage 4: 设计评审 |
| 测试用例文档 | `test-generator` | Stage 6: 测试用例评审 |
| 业务代码实现 | 通用编码能力 | Stage 5: 编码实现 / Stage 7: 代码评审 |
### 后置协作：修复阶段
| 评审发现 | 转交至 Skill | 说明 |
|---------|-------------|------|
| 具体 Bug 需要修复 | `bug-fixing` | 零回归修复工作流 |
| 代码结构需要优化 | `refactoring` | 安全重构，保持行为不变 |
| 测试用例需要补充 | `test-generator` | 生成测试用例代码 |
| 架构图/流程图需要更新 | `diagram-generator` | 绘制或修订图表 |
| 需要代码评审 | `code-review` | 系统性代码审查 |
### 度量阶段协作
| 度量需求 | 数据来源 | 对应阶段 |
|---------|---------|---------|
| 测试报告 | `test-generator` | Stage 8: 上线前质量检查 |
| 线上监控 | 监控系统/日志平台 | Stage 9: 运维监控与度量 |
| 用户反馈 | 工单系统/NPS调查 | Stage 9: 运维监控与度量 |
| 缺陷逃逸数据 | 缺陷管理系统 | Stage 9: 运维监控与度量 |
---
## Skill 协作
### 协作关系矩阵
| 上游阶段 | 本阶段（质量保障） | 下游阶段 | 协作 Skill |
|---------|------------------|---------|-----------|
| 需求设计 | `defect-prevention-expert` (Stage 1) | 研发设计 | `system-design` |
| 研发设计 | `defect-prevention-expert` (Stage 2/4) | 编码实现 | 通用编码能力 |
| 编码实现 | `defect-prevention-expert` (Stage 5/7) | Bug 修复 | `bug-fixing` |
| 测试用例 | `defect-prevention-expert` (Stage 6) | 测试补充 | `test-generator` |
| 上线前检查 | `defect-prevention-expert` (Stage 8) | 上线/回滚 | 运维团队 |
| 运维监控 | `defect-prevention-expert` (Stage 9) | 持续改进 | 产品+研发团队 |
### 快速转交指南
| 触发条件 | 转交至 |
|---------|--------|
| 发现具体 Bug 需要修复 | `bug-fixing` |
| 需要生成测试用例代码 | `test-generator` |
| 需要从零设计架构 | `system-design` |
| 需要代码重构（不改变行为） | `refactoring` |
| 需要绘制流程图/架构图 | `diagram-generator` |
| 需要系统性代码审查 | `code-review` |
---
## 参考文件
| 文件 | 用途 |
|------|------|
| [checklists/review-checklist.md](checklists/review-checklist.md) | 评审检查清单（需求/设计/测试/代码） |
| [examples.md](examples.md) | 典型场景示例 |
| [templates/test-case-template.md](templates/test-case-template.md) | 测试用例模板 |
| [templates/concept-clarification.md](templates/concept-clarification.md) | 逆向操作与依赖踏空概念澄清与区分 |
| [docs/quality-gate-workflow.md](docs/quality-gate-workflow.md) | 质量门禁工作流规范 |
| [skill-card.md](skill-card.md) | 快速导航与 Skill 概览 |
---
## 技能进化
更新此 Skill 的时机：
- 评审过程中发现检查清单覆盖不足
- 出现新的典型缺陷场景或质量度量指标
- 团队反馈评审流程或质量度量方法可以优化
- 质量度量基线需要更新
更新原则：
- 优先更新具体章节，而非添加新规则
- 保持工作流的简洁性，避免过度官僚化
- 更新后验证与其他 Skill 的协作关系是否仍然清晰
don't have the plugin yet? install it then click "run inline in claude" again.