缺陷预防专家

SKILL.md

---
name: defect-prevention-expert
description: |
  缺陷预防方法论专家，覆盖逆向操作、依赖踏空、同屏并发、新旧交替、状态迁移、因果判定六类场景。
  适用于需求设计、研发设计、需求评审、设计评审、测试用例评审、代码评审全阶段。
  帮助团队在早期识别潜在缺陷，降低修复成本，提升软件质量。

  Use when:
  - 需求设计/评审阶段，需要识别潜在缺陷和风险点
  - 研发设计/评审阶段，需要评估架构健壮性
  - 测试用例评审阶段，需要系统化设计测试场景
  - 代码评审阶段，需要发现代码逻辑缺陷
  - Keywords: "缺陷预防", "评审", "风险识别", "测试策略", "质量提升", "逆向操作", "依赖踏空", "并发冲突", "新旧兼容", "状态迁移", "因果图"

  Output: 根据评审类型输出对应的分析报告（需求风险清单/设计缺陷报告/代码审查意见/测试场景补充建议等）
  Not for: 具体的代码修复（用 bug-fixing），性能优化（用 performance-optimization），纯代码重构（用 refactoring）
version: 1.0.0
metadata:
  language: zh
  version: 1.0.0
  last_updated: 2026-06-08
  platform: universal
---

# 缺陷预防专家 v3.1

**核心承诺**：在软件交付全生命周期中系统性识别缺陷，根据评审类型动态适配分析流程，将问题消灭在萌芽阶段。

---

## 工作流概览（分支路由结构）

```
Phase 0: 评审类型识别与分支路由
  │
  ├─ 识别评审类型（7 种）
  ├─ 根据类型路由到对应的工作流（Stage 1-7）
  └─ 输出：评审计划
  │
  ├─→ Stage 1: 需求设计阶段工作流
  ├─→ Stage 2: 研发设计阶段工作流
  ├─→ Stage 3: 需求评审阶段工作流
  ├─→ Stage 4: 设计评审阶段工作流
  ├─→ Stage 5: 编码实现阶段工作流
  ├─→ Stage 6: 测试用例评审阶段工作流
  └─→ Stage 7: 代码评审阶段工作流
  │
Phase 8: 知识沉淀（通用）
  │
  ├─ 更新缺陷模式库
  ├─ 更新检查清单
  └─ 输出：知识更新记录
```

---

## 何时使用

**触发条件：**

- 需求设计阶段：识别需求漏洞和边界场景
- 研发设计阶段：设计健壮的架构和边界处理逻辑
- 需求评审阶段：识别潜在风险点
- 设计评审阶段：审查技术方案和架构设计
- 编码实现阶段：实现并发控制、版本兼容、依赖检查
- 测试用例评审阶段：设计系统化测试场景
- 代码评审阶段：发现代码逻辑缺陷和安全漏洞

**关键词触发：**
- "评审" + "需求/设计/代码/测试用例"
- "缺陷预防"、"风险识别"
- "逆向操作"、"依赖踏空"、"并发冲突"、"新旧兼容"
- "测试策略"、"质量提升"

## 不适用场景

| 场景 | 应使用的 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:  评审后必须跟踪待办事项的完成情况，不能评审完就结束              │
└──────────────────────────────────────────────────────────────────────────┘
```

---

## Phase 0: 评审类型识别与分支路由

> **目标**：明确评审类型，路由到对应的工作流

### 0.1 评审类型识别矩阵

| 评审类型 | 输入文档 | 分析重点 | 输出格式 | 路由至 |
|---------|---------|---------|---------|--------|
| **需求设计** | 无（从零开始） | 需求完整性、边界场景、异常流程 | 需求风险清单 | Stage 1 |
| **研发设计** | 需求文档 | 架构合理性、数据一致性、扩展性 | 设计缺陷报告 | Stage 2 |
| **需求评审** | 需求文档/PRD | 需求漏洞、边界场景、异常流程 | 需求评审报告 | Stage 3 |
| **设计评审** | 设计文档/架构图 | 技术方案、架构设计、可行性 | 设计评审报告 | Stage 4 |
| **编码实现** | 设计文档/接口定义 | 并发控制、版本兼容、依赖检查 | 编码检查清单 | Stage 5 |
| **测试用例评审** | 测试用例文档 | 覆盖度、边界条件、异常场景 | 测试场景补充建议 | Stage 6 |
| **代码评审** | 代码/API 文档 | 逻辑正确性、并发安全、代码质量 | 代码审查意见 | Stage 7 |

### 0.2 路由决策流程

```
用户请求
  │
  ├─ 是否从零开始设计需求？ → Stage 1: 需求设计阶段
  ├─ 是否有需求文档，需要设计技术方案？ → Stage 2: 研发设计阶段
  ├─ 是否有需求文档，需要评审？ → Stage 3: 需求评审阶段
  ├─ 是否有设计文档，需要评审？ → Stage 4: 设计评审阶段
  ├─ 是否有设计文档，需要编码实现指导？ → Stage 5: 编码实现阶段
  ├─ 是否有测试用例，需要评审？ → Stage 6: 测试用例评审阶段
  └─ 是否有代码，需要评审？ → Stage 7: 代码评审阶段
```

### 0.3 范围确认清单

- [ ] 评审类型已识别（Stage 1-7）
- [ ] 输入文档已提供（或明确从零开始）
- [ ] 重点关注领域已识别（逆向/依赖/并发/兼容/状态/因果）
- [ ] 输出格式已确定（对应该阶段的模板）

### 0.4 输出：评审计划

```markdown
## 评审计划
- **评审类型**: [Stage 1-7 之一]
- **输入文档**: [文档列表或"无（从零开始）"]
- **分析重点**: [该阶段的重点关注领域]
- **输出格式**: [对应该阶段的报告模板]
```

---

## Stage 1: 需求设计阶段工作流

> **适用场景**：从零开始设计需求，需要识别潜在缺陷和边界场景

### 1.1 输入要求

- 业务背景描述
- 目标用户和核心功能
- 关键业务流程（主流程）

### 1.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 同一用户在同一界面，一系列连续顺序操作后改变前置操作 | 改变前置操作后，后续联动是否正确处理？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→总价是否重算？） |
| 依赖踏空 | 业务数据/事务变更或消失（强依赖/弱依赖） | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 多端/多用户操作场景 | 多端同时操作同一资源，冲突如何解决？ |
| 新旧兼容 | 是否有历史数据或旧系统 | 新版本如何兼容旧数据？升级策略是什么？ |
| **状态迁移** | **系统状态流转是否合法、是否有非法跳转** | **订单能否从“已取消”直接跳到“已发货”？审批流能否跳过“主管审批”？** |
| **因果判定** | **多个条件组合导致的不同结果是否覆盖完全** | **“满100元且新用户且非特价商品”才可用优惠券，各种组合是否都测试到了？** |

### 1.3 分析流程

1. **梳理业务流程**：主流程 → 分支流程 → 异常流程
2. **识别关键数据依赖**：数据实体、关联关系、级联规则
3. **应用六大方法论**：逐项分析逆向/依赖/并发/兼容/状态/因果场景
4. **生成风险清单**：按 P0-P3 分级，附改进建议

### 1.4 检查清单

```markdown
### 逆向操作场景
- [ ] 用户操作路径是否覆盖正向和逆向流程？
- [ ] 修改前置操作后，后续操作是否正确处理？
- [ ] 级联依赖关系是否完整定义？（如省市区联动）
- [ ] 状态回退场景是否有明确的处理规则？

### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 历史数据的保护机制是否定义？
- [ ] 降级方案是否可行且用户体验可接受？

### 并发操作场景
- [ ] 是否涉及多端操作？冲突解决机制是否定义？
- [ ] 是否涉及多用户协作？数据一致性方案是否明确？
- [ ] 实时同步的频率和延迟要求是否合理？

### 新旧兼容场景
- [ ] 是否有历史数据或旧系统共存？
- [ ] 版本升级策略是否明确（停服 vs 不停服）？
- [ ] 数据迁移方案是否评估？
- [ ] 回滚方案是否可行？

### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退是否有明确规则？
- [ ] 终态（如已完成/已取消）是否允许变更？

### 因果判定场景
- [ ] 是否识别了所有影响结果的条件？
- [ ] 多个条件组合的情况是否覆盖完全？
- [ ] 是否有判定表或决策树梳理业务规则？
- [ ] 条件优先级和冲突处理是否明确？
```

### 1.5 输出模板：需求风险清单

```markdown
## 需求风险清单 — [项目名称]

### 业务场景概述
- **核心功能**: [一句话描述]
- **目标用户**: [用户群体]
- **关键流程**: [主流程描述]

### 风险清单（按严重程度排序）

| 编号 | 风险类型 | 严重程度 | 描述 | 影响范围 | 建议措施 |
|------|---------|---------|------|---------|---------|
| R001 | 依赖踏空 | P1 | ... | ... | ... |

### 建议补充的需求点
1. [补充点1]
2. [补充点2]

### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
```

---

## Stage 2: 研发设计阶段工作流

> **适用场景**：已有需求文档，需要设计技术方案，评估架构健壮性

### 2.1 输入要求

- 需求文档/PRD
- 业务流程描述
- 性能/安全/扩展性要求（如有）

### 2.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机设计、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→支付发起→修改订单商品→库存和支付是否重新计算？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、最终一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| **状态迁移** | **状态机设计、状态校验、非法跳转防护** | **状态流转是否用状态机控制？是否存在绕过状态校验的接口？** |
| **因果判定** | **复杂业务规则的条件组合覆盖** | **折扣计算规则涉及多个条件，是否用判定表梳理了所有组合？** |

### 2.3 分析流程

1. **梳理技术架构**：分层架构、服务拆分、数据流向
2. **识别技术风险点**：并发控制、事务边界、依赖管理
3. **应用六大方法论**：从技术角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成设计缺陷报告**：附改进建议和架构优化方案

### 2.4 检查清单

```markdown
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
- [ ] 是否考虑了水平扩展能力？

### 数据一致性
- [ ] 并发控制的实现方案？（乐观锁、悲观锁、分布式锁）
- [ ] 事务边界是否合理？
- [ ] 分布式事务的处理方案？
- [ ] 最终一致性的补偿机制？

### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 循环依赖是否避免？
- [ ] 依赖变更的兼容性处理？
- [ ] 依赖消失的降级策略？

### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
- [ ] 新旧数据共存的适配层设计？
- [ ] 废弃字段/接口的清理计划？

### 状态管理
- [ ] 状态流转是否用状态机控制？
- [ ] 状态校验逻辑是否集中管理？
- [ ] 是否存在绕过状态校验的接口？
- [ ] 状态变更是否记录审计日志？

### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合是否覆盖完全？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 规则变更是否影响现有数据？

### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？（缓存什么、何时失效）
- [ ] 大数据量的分页方案？
- [ ] 慢查询的预防机制？

### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
- [ ] SQL注入、XSS等常见漏洞的防护？
- [ ] 接口防重放、防刷机制？
```

### 2.5 输出模板：设计缺陷报告

```markdown
## 设计缺陷报告 — [项目名称]

### 技术架构概述
- **架构模式**: [分层架构/微服务/事件驱动等]
- **技术栈**: [主要技术选型]
- **数据流向**: [关键数据流转描述]

### 设计缺陷清单（按严重程度排序）

| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 并发安全 | P1 | ... | ... | ... |

### 架构优化建议
1. [建议1]
2. [建议2]

### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
```

---

## Stage 3: 需求评审阶段工作流

> **适用场景**：已有需求文档，需要评审需求完整性和潜在风险

### 3.1 输入要求

- 需求文档/PRD
- 用户故事或用例
- 业务流程图（如有）

### 3.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 需求中的操作路径是否完整，同一用户连续顺序操作后改变前置操作 | 改变前置操作后，需求是否覆盖？（如：选择省→选择市→选择区→修改市→区是否清空并重新加载？） |
| 依赖踏空 | 需求中的依赖关系是否明确，依赖数据/服务变更 | 依赖数据变更后的处理是否定义？（如：商品下架、优惠券过期、部门删除后人员归属） |
| 并发冲突 | 需求是否考虑多端/多用户场景 | 并发操作的冲突解决是否定义？ |
| 新旧兼容 | 需求是否考虑历史数据 | 新旧系统共存的策略是否明确？ |
| **状态迁移** | **需求是否定义完整状态流转** | **订单状态流转是否定义完整？是否有非法跳转的可能？** |
| **因果判定** | **需求中的业务规则是否用判定表梳理** | **满减、折扣、优惠券叠加规则，各种条件组合是否都定义清楚了？** |

### 3.3 分析流程

1. **阅读需求文档**：理解业务目标和核心功能
2. **识别需求漏洞**：边界场景、异常流程、缺失定义
3. **应用六大方法论**：从需求角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成需求评审报告**：附改进建议和待确认事项

### 3.4 检查清单

```markdown
### 需求完整性
- [ ] 边界条件是否明确？（空值、最大值、最小值）
- [ ] 异常场景是否定义？（网络异常、数据异常）
- [ ] 性能要求是否量化？（响应时间、并发量）
- [ ] 安全要求是否考虑？（权限、敏感数据）

### 逆向操作场景
- [ ] 是否考虑了用户修改前置操作后的系统行为？
- [ ] 级联依赖关系是否完整定义？
- [ ] 状态回退场景是否有明确的处理规则？

### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 降级方案是否可行且用户体验可接受？

### 并发操作场景
- [ ] 多端操作同一资源的冲突解决机制是否定义？
- [ ] 多用户并发修改的数据一致性方案是否明确？

### 新旧交替场景
- [ ] 版本升级策略是否明确？
- [ ] 历史数据的兼容性访问方案是否定义？

### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退/撤销是否有明确规则？

### 因果判定场景
- [ ] 复杂业务规则是否梳理了所有条件组合？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 是否遗漏了某些条件组合？
```

### 3.5 输出模板：需求评审报告

```markdown
## 需求评审报告 — [项目名称]

### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **需求文档**: [文档名称/链接]

### 发现的需求漏洞（按严重程度排序）

| 编号 | 漏洞类型 | 严重程度 | 描述 | 建议措施 |
|------|---------|---------|------|---------|
| G001 | 边界场景缺失 | P1 | ... | ... |

### 建议补充的需求点
1. [补充点1]
2. [补充点2]

### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]

### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
```

---

## Stage 4: 设计评审阶段工作流

> **适用场景**：已有设计文档，需要评审技术方案和架构设计

### 4.1 输入要求

- 设计文档
- 架构图
- 接口定义
- 数据库设计（如有）

### 4.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机、事务回滚设计，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→修改订单→库存是否重新调整？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、缓存一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| **状态迁移** | **状态机设计、状态流转合法性校验** | **是否用状态机模式控制流转？是否存在越权状态变更的接口？** |
| **因果判定** | **复杂业务规则的条件组合设计** | **计费/折扣规则涉及多条件，是否用判定表确保覆盖完整？** |

### 4.3 分析流程

1. **阅读设计文档**：理解技术架构和关键设计决策
2. **识别设计缺陷**：架构不合理、数据一致性风险、扩展性不足
3. **应用六大方法论**：从设计角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成设计评审报告**：附改进建议和架构优化方案

### 4.4 检查清单

```markdown
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？

### 数据一致性
- [ ] 并发控制的实现方案？
- [ ] 事务边界是否合理？
- [ ] 最终一致性的补偿机制？

### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 依赖消失的降级策略？

### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？

### 状态管理
- [ ] 状态机设计是否合理？
- [ ] 状态校验逻辑是否集中？
- [ ] 非法状态跳转是否有防护？

### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合覆盖是否完整？
- [ ] 规则冲突时的优先级是否定义？

### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？

### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
```

### 4.5 输出模板：设计评审报告

```markdown
## 设计评审报告 — [项目名称]

### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **设计文档**: [文档名称/链接]

### 发现的设计缺陷（按严重程度排序）

| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 架构设计 | P1 | ... | ... | ... |

### 架构优化建议
1. [建议1]
2. [建议2]

### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]

### 评审结论
- [ ] 通过
- [ ] 有条件通过（需修改后二次评审）
- [ ] 不通过
```

---

## Stage 5: 编码实现阶段工作流

> **适用场景**：已有设计文档，需要编码实现，检查并发控制、版本兼容、依赖处理

### 5.1 输入要求

- 设计文档
- 接口定义
- 数据库设计
- 技术栈要求

### 5.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 状态机实现、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，后续逻辑是否正确处理？（如：选择商品→选择规格→选择配送→修改规格→配送方式是否重新校验？） |
| 依赖踏空 | 业务数据/事务依赖，依赖数据不存在时 | 业务数据不存在时，是否有容错处理？（如：商品下架、优惠券过期） |
| 并发冲突 | 乐观锁、分布式锁、缓存更新 | 共享资源访问是否线程安全？ |
| 新旧兼容 | 字段兼容、API 版本 | 新旧数据共存时，适配层是否实现？ |
| **状态迁移** | **状态机实现、状态校验代码** | **状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？** |
| **因果判定** | **复杂条件判断的代码实现** | **多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？** |

### 5.3 分析流程

1. **理解设计意图**：明确架构设计和关键决策
2. **识别编码风险点**：并发安全、依赖处理、版本兼容
3. **应用六大方法论**：从编码角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成编码检查清单**：附实现建议和注意事项

### 5.4 检查清单

```markdown
### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？

### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？

### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？

### 新旧兼容
- [ ] 数据结构变更的兼容处理是否实现？
- [ ] API版本管理是否实现？
- [ ] 新旧数据共存的适配层是否实现？

### 状态迁移处理
- [ ] 状态变更是否集中管理？
- [ ] 非法状态跳转是否有拦截？
- [ ] 状态回退逻辑是否正确实现？

### 因果判定处理
- [ ] 复杂条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？
- [ ] 是否可使用策略模式或表驱动简化？

### 代码质量
- [ ] 函数长度是否合理？（建议<50行）
- [ ] 圈复杂度是否过高？（建议<10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？

### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？

### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 权限校验是否完整？
```

### 5.5 输出模板：编码检查清单

```markdown
## 编码检查清单 — [项目名称/模块]

### 实现要点
- **核心功能**: [一句话描述]
- **技术栈**: [主要技术选型]
- **关键接口**: [接口列表]

### 检查项执行结果

| 检查项 | 状态 | 备注 |
|--------|------|------|
| 逆向操作处理 | [通过/需改进] | ... |
| 依赖踏空处理 | [通过/需改进] | ... |
| 并发安全 | [通过/需改进] | ... |
| 新旧兼容 | [通过/需改进] | ... |

### 实现建议
1. [建议1]
2. [建议2]

### 注意事项
- [注意1]
- [注意2]
```

---

## Stage 6: 测试用例评审阶段工作流

> **适用场景**：已有测试用例文档，需要评审测试覆盖度和系统化场景设计

### 6.1 输入要求

- 测试用例文档
- 测试计划
- 需求文档/设计文档（参考）

### 6.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 测试用例是否覆盖同一用户连续顺序操作后改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | 测试用例是否覆盖兼容性场景 | 是否有新旧数据共存的测试用例？ |
| **状态迁移** | **状态流转路径的测试覆盖** | **是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？** |
| **因果判定** | **条件组合场景的测试覆盖** | **多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？** |

### 6.3 分析流程

1. **阅读测试用例**：理解测试覆盖范围
2. **识别覆盖盲区**：边界条件、异常场景、并发场景
3. **应用六大方法论**：从测试角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成测试场景补充建议**：附新增测试用例建议

### 6.4 检查清单

```markdown
### 测试覆盖度
- [ ] 是否覆盖所有核心功能路径？
- [ ] 边界条件测试是否完整？
- [ ] 异常场景测试是否充分？

### 缺陷预防场景
- [ ] 逆向操作场景测试用例？
- [ ] 依赖踏空场景测试用例？
- [ ] 同屏并发场景测试用例？
- [ ] 新旧数据兼容测试用例？
- [ ] 状态流转路径测试用例？
- [ ] 条件组合场景测试用例？

### 测试数据
- [ ] 测试数据是否覆盖各种边界值？
- [ ] 是否有足够的异常数据？
- [ ] 是否考虑了数据量对性能的影响？

### 测试环境
- [ ] 测试环境是否与生产环境一致？
- [ ] 多端测试设备是否准备齐全？
- [ ] 并发测试的压力工具是否准备？

### 验收标准
- [ ] 通过标准是否明确？
- [ ] 性能指标是否量化？
- [ ] 缺陷严重程度的分级标准？
```

### 6.5 输出模板：测试场景补充建议

```markdown
## 测试场景补充建议 — [项目名称]

### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **测试用例文档**: [文档名称/链接]

### 发现的覆盖盲区（按严重程度排序）

| 编号 | 盲区类型 | 严重程度 | 描述 | 建议补充的测试场景 |
|------|---------|---------|------|------------------|
| T001 | 并发场景缺失 | P1 | ... | ... |

### 建议补充的测试用例
1. [用例1]
2. [用例2]

### 测试数据建议
- [建议1]
- [建议2]

### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
```

---

## Stage 7: 代码评审阶段工作流

> **适用场景**：已有代码，需要评审逻辑正确性、并发安全、代码质量

### 7.1 输入要求

- 代码文件
- API 文档
- 设计文档（参考）

### 7.2 分析重点

| 方法论 | 应用重点 | 典型问题 |
|--------|---------|---------|
| 逆向操作 | 前置操作改变后，同一用户后续逻辑是否正确 | 级联依赖的联动更新是否正确？（如：填写订单→选择地址→选择发票→修改地址→发票信息是否重新计算？） |
| 依赖踏空 | 业务数据/事务不存在时，是否有容错 | 业务数据/事务变更时是否有校验？（如：商品下架、优惠券过期） |
| 并发冲突 | 共享资源访问是否线程安全 | 数据库操作是否有并发控制？ |
| 新旧兼容 | 新旧数据共存时，适配层是否实现 | 字段兼容、API 版本是否处理？ |
| **状态迁移** | **状态机实现、状态校验逻辑** | **状态变更是否集中管理？非法跳转是否拦截？** |
| **因果判定** | **复杂条件判断、多重分支覆盖** | **if-else 嵌套是否遗漏分支？条件组合是否覆盖完全？** |

### 7.3 分析流程

1. **阅读代码**：理解业务逻辑和实现方式
2. **识别代码缺陷**：逻辑错误、并发风险、安全漏洞
3. **应用六大方法论**：从代码角度分析逆向/依赖/并发/兼容/状态/因果
4. **生成代码审查意见**：附改进建议和代码优化方案

### 7.4 检查清单

```markdown
### 功能正确性
- [ ] 业务逻辑是否正确实现？
- [ ] 边界条件是否正确处理？
- [ ] 异常场景是否有容错处理？

### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？

### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？

### 状态迁移处理
- [ ] 状态变更是否有统一的状态机控制？
- [ ] 非法状态跳转是否有拦截逻辑？
- [ ] 状态回退逻辑是否正确实现？

### 因果判定处理
- [ ] 多重条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？是否可用策略模式简化？
- [ ] 条件组合的覆盖是否完整？

### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？

### 代码质量
- [ ] 函数长度是否合理？（建议<50行）
- [ ] 圈复杂度是否过高？（建议<10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？

### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？

### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 敏感信息是否泄露？
- [ ] 权限校验是否完整？
```

### 7.5 输出模板：代码审查意见

```markdown
## 代码审查意见 — [项目名称/模块]

### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **代码文件**: [文件列表]

### 发现的代码缺陷（按严重程度排序）

| 编号 | 缺陷类型 | 严重程度 | 文件:行号 | 描述 | 改进建议 |
|------|---------|---------|-----------|------|---------|
| C001 | 并发安全 | P1 | file.py:123 | ... | ... |

### 代码优化建议
1. [建议1]
2. [建议2]

### 代码质量评估
- **可读性**: [高/中/低]
- **可维护性**: [高/中/低]
- **性能**: [高/中/低]
- **安全性**: [高/中/低]

### 评审结论
- [ ] 通过
- [ ] 有条件通过（需修改后二次评审）
- [ ] 不通过
```

---

## Phase 8: 知识沉淀（通用）

> **目标**：将评审中发现的新模式更新到知识库，持续积累

### 8.1 更新检查清单

- 将新发现的缺陷场景补充到 `checklists/review-checklist.md`
- 定期评审和更新检查清单的完备性

### 8.2 更新示例场景

- 将典型案例补充到 `examples.md`
- 记录具体的测试步骤和验证方法

### 8.3 更新知识库文件

| 文件 | 更新时机 | 内容 |
|------|---------|------|
| `checklists/review-checklist.md` | 发现新的检查项 | 补充新的检查点 |
| `examples.md` | 发现新的典型场景 | 补充新的示例 |
| `templates/test-case-template.md` | 发现新的测试方法 | 补充新的测试策略 |

### 8.4 输出：知识更新记录

```markdown
## 知识更新记录
- **更新日期**: YYYY-MM-DD
- **评审项目**: [项目名称]
- **评审类型**: [Stage 1-7]
- **新增检查项**: [描述]
- **新增示例**: [描述]
- **更新文件**: [文件路径]
```

---

## Anti-Patterns（禁止行为）

| 禁止行为 | 正确做法 |
|---------|---------|
| 混用不同阶段的流程和模板 | 根据评审类型路由到对应工作流 |
| 泛泛而谈"代码质量不好" | 指出具体文件/函数/行号和具体问题 |
| 只提问题不给建议 | 每个问题至少附带一条改进建议 |
| 跳过检查清单 | 按清单逐项检查，记录结果 |
| 评审后不跟进 | 明确待办事项、责任人、截止时间 |
| 用完整流程处理明显的小问题 | 快速记录，简化流程 |
| 忽略历史遗留问题 | 评估影响范围，制定渐进式改进计划 |
| 跳过知识沉淀 | 每次评审后更新知识库 |
| 混淆设计意图和实现风险 | 先确认设计意图，再评估实现风险 |

---

## Skill 协作

| 触发条件 | 转交至 |
|---------|--------|
| 发现具体 Bug 需要修复 | `bug-fixing` |
| 需要生成测试用例代码 | `test-generator` |
| 需要架构设计评审 | `system-design` |
| 需要代码重构 | `refactoring` |
| 需要绘制流程图/架构图 | `diagram-generator` |

---

## 参考文件

| 文件 | 用途 |
|------|------|
| [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) | 六大方法论概念澄清与区分 |

---

## 技能进化

更新此 Skill 的时机：
- 评审过程中发现检查清单覆盖不足
- 出现新的典型缺陷场景
- 团队反馈评审流程可以优化

更新原则：
- 优先更新具体章节，而非添加新规则
- 保持工作流的简洁性，避免过度官僚化
- 更新后验证与其他 Skill 的协作关系是否仍然清晰