← Back to Skills Marketplace
43
Downloads
0
Stars
0
Active Installs
1
Versions
Install in OpenClaw
/install defect-prevention-expert
Description
缺陷预防方法论专家，覆盖逆向操作、依赖踏空、同屏并发、新旧交替、状态迁移、因果判定六类场景。 适用于需求设计、研发设计、需求评审、设计评审、测试用例评审、代码评审全阶段。 帮助团队在早期识别潜在缺陷，降低修复成本，提升软件质量。 Use when: - 需求设计/评审阶段，需要识别潜在缺陷和风险点 - 研发设计/...
README (SKILL.md)
缺陷预防专家 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 输出：评审计划
## 评审计划
- **评审类型**: [Stage 1-7 之一]
- **输入文档**: [文档列表或"无（从零开始）"]
- **分析重点**: [该阶段的重点关注领域]
- **输出格式**: [对应该阶段的报告模板]
Stage 1: 需求设计阶段工作流
适用场景：从零开始设计需求，需要识别潜在缺陷和边界场景
1.1 输入要求
- 业务背景描述
- 目标用户和核心功能
- 关键业务流程（主流程）
1.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 同一用户在同一界面，一系列连续顺序操作后改变前置操作 | 改变前置操作后，后续联动是否正确处理？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→总价是否重算？） |
| 依赖踏空 | 业务数据/事务变更或消失（强依赖/弱依赖） | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 多端/多用户操作场景 | 多端同时操作同一资源，冲突如何解决？ |
| 新旧兼容 | 是否有历史数据或旧系统 | 新版本如何兼容旧数据？升级策略是什么？ |
| 状态迁移 | 系统状态流转是否合法、是否有非法跳转 | 订单能否从“已取消”直接跳到“已发货”？审批流能否跳过“主管审批”？ |
| 因果判定 | 多个条件组合导致的不同结果是否覆盖完全 | “满100元且新用户且非特价商品”才可用优惠券，各种组合是否都测试到了？ |
1.3 分析流程
- 梳理业务流程：主流程 → 分支流程 → 异常流程
- 识别关键数据依赖：数据实体、关联关系、级联规则
- 应用六大方法论：逐项分析逆向/依赖/并发/兼容/状态/因果场景
- 生成风险清单：按 P0-P3 分级，附改进建议
1.4 检查清单
### 逆向操作场景
- [ ] 用户操作路径是否覆盖正向和逆向流程？
- [ ] 修改前置操作后，后续操作是否正确处理？
- [ ] 级联依赖关系是否完整定义？（如省市区联动）
- [ ] 状态回退场景是否有明确的处理规则？
### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 历史数据的保护机制是否定义？
- [ ] 降级方案是否可行且用户体验可接受？
### 并发操作场景
- [ ] 是否涉及多端操作？冲突解决机制是否定义？
- [ ] 是否涉及多用户协作？数据一致性方案是否明确？
- [ ] 实时同步的频率和延迟要求是否合理？
### 新旧兼容场景
- [ ] 是否有历史数据或旧系统共存？
- [ ] 版本升级策略是否明确（停服 vs 不停服）？
- [ ] 数据迁移方案是否评估？
- [ ] 回滚方案是否可行？
### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退是否有明确规则？
- [ ] 终态（如已完成/已取消）是否允许变更？
### 因果判定场景
- [ ] 是否识别了所有影响结果的条件？
- [ ] 多个条件组合的情况是否覆盖完全？
- [ ] 是否有判定表或决策树梳理业务规则？
- [ ] 条件优先级和冲突处理是否明确？
1.5 输出模板：需求风险清单
## 需求风险清单 — [项目名称]
### 业务场景概述
- **核心功能**: [一句话描述]
- **目标用户**: [用户群体]
- **关键流程**: [主流程描述]
### 风险清单（按严重程度排序）
| 编号 | 风险类型 | 严重程度 | 描述 | 影响范围 | 建议措施 |
|------|---------|---------|------|---------|---------|
| R001 | 依赖踏空 | P1 | ... | ... | ... |
### 建议补充的需求点
1. [补充点1]
2. [补充点2]
### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
Stage 2: 研发设计阶段工作流
适用场景：已有需求文档，需要设计技术方案，评估架构健壮性
2.1 输入要求
- 需求文档/PRD
- 业务流程描述
- 性能/安全/扩展性要求（如有）
2.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机设计、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→支付发起→修改订单商品→库存和支付是否重新计算？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、最终一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| 状态迁移 | 状态机设计、状态校验、非法跳转防护 | 状态流转是否用状态机控制？是否存在绕过状态校验的接口？ |
| 因果判定 | 复杂业务规则的条件组合覆盖 | 折扣计算规则涉及多个条件，是否用判定表梳理了所有组合？ |
2.3 分析流程
- 梳理技术架构：分层架构、服务拆分、数据流向
- 识别技术风险点：并发控制、事务边界、依赖管理
- 应用六大方法论：从技术角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计缺陷报告：附改进建议和架构优化方案
2.4 检查清单
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
- [ ] 是否考虑了水平扩展能力？
### 数据一致性
- [ ] 并发控制的实现方案？（乐观锁、悲观锁、分布式锁）
- [ ] 事务边界是否合理？
- [ ] 分布式事务的处理方案？
- [ ] 最终一致性的补偿机制？
### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 循环依赖是否避免？
- [ ] 依赖变更的兼容性处理？
- [ ] 依赖消失的降级策略？
### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
- [ ] 新旧数据共存的适配层设计？
- [ ] 废弃字段/接口的清理计划？
### 状态管理
- [ ] 状态流转是否用状态机控制？
- [ ] 状态校验逻辑是否集中管理？
- [ ] 是否存在绕过状态校验的接口？
- [ ] 状态变更是否记录审计日志？
### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合是否覆盖完全？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 规则变更是否影响现有数据？
### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？（缓存什么、何时失效）
- [ ] 大数据量的分页方案？
- [ ] 慢查询的预防机制？
### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
- [ ] SQL注入、XSS等常见漏洞的防护？
- [ ] 接口防重放、防刷机制？
2.5 输出模板：设计缺陷报告
## 设计缺陷报告 — [项目名称]
### 技术架构概述
- **架构模式**: [分层架构/微服务/事件驱动等]
- **技术栈**: [主要技术选型]
- **数据流向**: [关键数据流转描述]
### 设计缺陷清单（按严重程度排序）
| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 并发安全 | P1 | ... | ... | ... |
### 架构优化建议
1. [建议1]
2. [建议2]
### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
Stage 3: 需求评审阶段工作流
适用场景：已有需求文档，需要评审需求完整性和潜在风险
3.1 输入要求
- 需求文档/PRD
- 用户故事或用例
- 业务流程图（如有）
3.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 需求中的操作路径是否完整，同一用户连续顺序操作后改变前置操作 | 改变前置操作后，需求是否覆盖？（如：选择省→选择市→选择区→修改市→区是否清空并重新加载？） |
| 依赖踏空 | 需求中的依赖关系是否明确，依赖数据/服务变更 | 依赖数据变更后的处理是否定义？（如：商品下架、优惠券过期、部门删除后人员归属） |
| 并发冲突 | 需求是否考虑多端/多用户场景 | 并发操作的冲突解决是否定义？ |
| 新旧兼容 | 需求是否考虑历史数据 | 新旧系统共存的策略是否明确？ |
| 状态迁移 | 需求是否定义完整状态流转 | 订单状态流转是否定义完整？是否有非法跳转的可能？ |
| 因果判定 | 需求中的业务规则是否用判定表梳理 | 满减、折扣、优惠券叠加规则，各种条件组合是否都定义清楚了？ |
3.3 分析流程
- 阅读需求文档：理解业务目标和核心功能
- 识别需求漏洞：边界场景、异常流程、缺失定义
- 应用六大方法论：从需求角度分析逆向/依赖/并发/兼容/状态/因果
- 生成需求评审报告：附改进建议和待确认事项
3.4 检查清单
### 需求完整性
- [ ] 边界条件是否明确？（空值、最大值、最小值）
- [ ] 异常场景是否定义？（网络异常、数据异常）
- [ ] 性能要求是否量化？（响应时间、并发量）
- [ ] 安全要求是否考虑？（权限、敏感数据）
### 逆向操作场景
- [ ] 是否考虑了用户修改前置操作后的系统行为？
- [ ] 级联依赖关系是否完整定义？
- [ ] 状态回退场景是否有明确的处理规则？
### 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 降级方案是否可行且用户体验可接受？
### 并发操作场景
- [ ] 多端操作同一资源的冲突解决机制是否定义？
- [ ] 多用户并发修改的数据一致性方案是否明确？
### 新旧交替场景
- [ ] 版本升级策略是否明确？
- [ ] 历史数据的兼容性访问方案是否定义？
### 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退/撤销是否有明确规则？
### 因果判定场景
- [ ] 复杂业务规则是否梳理了所有条件组合？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 是否遗漏了某些条件组合？
3.5 输出模板：需求评审报告
## 需求评审报告 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **需求文档**: [文档名称/链接]
### 发现的需求漏洞（按严重程度排序）
| 编号 | 漏洞类型 | 严重程度 | 描述 | 建议措施 |
|------|---------|---------|------|---------|
| G001 | 边界场景缺失 | P1 | ... | ... |
### 建议补充的需求点
1. [补充点1]
2. [补充点2]
### 待确认事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
Stage 4: 设计评审阶段工作流
适用场景：已有设计文档，需要评审技术方案和架构设计
4.1 输入要求
- 设计文档
- 架构图
- 接口定义
- 数据库设计（如有）
4.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机、事务回滚设计，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→修改订单→库存是否重新调整？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、缓存一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | 数据迁移、API 版本管理 | 新旧数据共存的适配层如何设计？ |
| 状态迁移 | 状态机设计、状态流转合法性校验 | 是否用状态机模式控制流转？是否存在越权状态变更的接口？ |
| 因果判定 | 复杂业务规则的条件组合设计 | 计费/折扣规则涉及多条件，是否用判定表确保覆盖完整？ |
4.3 分析流程
- 阅读设计文档：理解技术架构和关键设计决策
- 识别设计缺陷：架构不合理、数据一致性风险、扩展性不足
- 应用六大方法论：从设计角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计评审报告：附改进建议和架构优化方案
4.4 检查清单
### 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
### 数据一致性
- [ ] 并发控制的实现方案？
- [ ] 事务边界是否合理？
- [ ] 最终一致性的补偿机制？
### 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 依赖消失的降级策略？
### 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
### 状态管理
- [ ] 状态机设计是否合理？
- [ ] 状态校验逻辑是否集中？
- [ ] 非法状态跳转是否有防护？
### 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合覆盖是否完整？
- [ ] 规则冲突时的优先级是否定义？
### 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？
### 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
4.5 输出模板：设计评审报告
## 设计评审报告 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **设计文档**: [文档名称/链接]
### 发现的设计缺陷（按严重程度排序）
| 编号 | 缺陷类型 | 严重程度 | 描述 | 影响范围 | 改进建议 |
|------|---------|---------|------|---------|---------|
| D001 | 架构设计 | P1 | ... | ... | ... |
### 架构优化建议
1. [建议1]
2. [建议2]
### 待决策事项
- [ ] [事项1] — [负责人]
- [ ] [事项2] — [负责人]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需修改后二次评审）
- [ ] 不通过
Stage 5: 编码实现阶段工作流
适用场景：已有设计文档，需要编码实现，检查并发控制、版本兼容、依赖处理
5.1 输入要求
- 设计文档
- 接口定义
- 数据库设计
- 技术栈要求
5.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 状态机实现、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，后续逻辑是否正确处理？（如：选择商品→选择规格→选择配送→修改规格→配送方式是否重新校验？） |
| 依赖踏空 | 业务数据/事务依赖，依赖数据不存在时 | 业务数据不存在时，是否有容错处理？（如：商品下架、优惠券过期） |
| 并发冲突 | 乐观锁、分布式锁、缓存更新 | 共享资源访问是否线程安全？ |
| 新旧兼容 | 字段兼容、API 版本 | 新旧数据共存时，适配层是否实现？ |
| 状态迁移 | 状态机实现、状态校验代码 | 状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？ |
| 因果判定 | 复杂条件判断的代码实现 | 多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？ |
5.3 分析流程
- 理解设计意图：明确架构设计和关键决策
- 识别编码风险点：并发安全、依赖处理、版本兼容
- 应用六大方法论：从编码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成编码检查清单：附实现建议和注意事项
5.4 检查清单
### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？
### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？
### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？
### 新旧兼容
- [ ] 数据结构变更的兼容处理是否实现？
- [ ] API版本管理是否实现？
- [ ] 新旧数据共存的适配层是否实现？
### 状态迁移处理
- [ ] 状态变更是否集中管理？
- [ ] 非法状态跳转是否有拦截？
- [ ] 状态回退逻辑是否正确实现？
### 因果判定处理
- [ ] 复杂条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？
- [ ] 是否可使用策略模式或表驱动简化？
### 代码质量
- [ ] 函数长度是否合理？（建议\x3C50行）
- [ ] 圈复杂度是否过高？（建议\x3C10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？
### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？
### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 权限校验是否完整？
5.5 输出模板：编码检查清单
## 编码检查清单 — [项目名称/模块]
### 实现要点
- **核心功能**: [一句话描述]
- **技术栈**: [主要技术选型]
- **关键接口**: [接口列表]
### 检查项执行结果
| 检查项 | 状态 | 备注 |
|--------|------|------|
| 逆向操作处理 | [通过/需改进] | ... |
| 依赖踏空处理 | [通过/需改进] | ... |
| 并发安全 | [通过/需改进] | ... |
| 新旧兼容 | [通过/需改进] | ... |
### 实现建议
1. [建议1]
2. [建议2]
### 注意事项
- [注意1]
- [注意2]
Stage 6: 测试用例评审阶段工作流
适用场景：已有测试用例文档，需要评审测试覆盖度和系统化场景设计
6.1 输入要求
- 测试用例文档
- 测试计划
- 需求文档/设计文档（参考）
6.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 测试用例是否覆盖同一用户连续顺序操作后改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | 测试用例是否覆盖兼容性场景 | 是否有新旧数据共存的测试用例？ |
| 状态迁移 | 状态流转路径的测试覆盖 | 是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？ |
| 因果判定 | 条件组合场景的测试覆盖 | 多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？ |
6.3 分析流程
- 阅读测试用例：理解测试覆盖范围
- 识别覆盖盲区：边界条件、异常场景、并发场景
- 应用六大方法论：从测试角度分析逆向/依赖/并发/兼容/状态/因果
- 生成测试场景补充建议：附新增测试用例建议
6.4 检查清单
### 测试覆盖度
- [ ] 是否覆盖所有核心功能路径？
- [ ] 边界条件测试是否完整？
- [ ] 异常场景测试是否充分？
### 缺陷预防场景
- [ ] 逆向操作场景测试用例？
- [ ] 依赖踏空场景测试用例？
- [ ] 同屏并发场景测试用例？
- [ ] 新旧数据兼容测试用例？
- [ ] 状态流转路径测试用例？
- [ ] 条件组合场景测试用例？
### 测试数据
- [ ] 测试数据是否覆盖各种边界值？
- [ ] 是否有足够的异常数据？
- [ ] 是否考虑了数据量对性能的影响？
### 测试环境
- [ ] 测试环境是否与生产环境一致？
- [ ] 多端测试设备是否准备齐全？
- [ ] 并发测试的压力工具是否准备？
### 验收标准
- [ ] 通过标准是否明确？
- [ ] 性能指标是否量化？
- [ ] 缺陷严重程度的分级标准？
6.5 输出模板：测试场景补充建议
## 测试场景补充建议 — [项目名称]
### 评审信息
- **评审日期**: YYYY-MM-DD
- **评审人员**: [参与人员]
- **测试用例文档**: [文档名称/链接]
### 发现的覆盖盲区（按严重程度排序）
| 编号 | 盲区类型 | 严重程度 | 描述 | 建议补充的测试场景 |
|------|---------|---------|------|------------------|
| T001 | 并发场景缺失 | P1 | ... | ... |
### 建议补充的测试用例
1. [用例1]
2. [用例2]
### 测试数据建议
- [建议1]
- [建议2]
### 评审结论
- [ ] 通过
- [ ] 有条件通过（需补充后二次评审）
- [ ] 不通过
Stage 7: 代码评审阶段工作流
适用场景：已有代码，需要评审逻辑正确性、并发安全、代码质量
7.1 输入要求
- 代码文件
- API 文档
- 设计文档（参考）
7.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|---|---|
| 逆向操作 | 前置操作改变后，同一用户后续逻辑是否正确 | 级联依赖的联动更新是否正确？（如：填写订单→选择地址→选择发票→修改地址→发票信息是否重新计算？） |
| 依赖踏空 | 业务数据/事务不存在时，是否有容错 | 业务数据/事务变更时是否有校验？（如：商品下架、优惠券过期） |
| 并发冲突 | 共享资源访问是否线程安全 | 数据库操作是否有并发控制？ |
| 新旧兼容 | 新旧数据共存时，适配层是否实现 | 字段兼容、API 版本是否处理？ |
| 状态迁移 | 状态机实现、状态校验逻辑 | 状态变更是否集中管理？非法跳转是否拦截？ |
| 因果判定 | 复杂条件判断、多重分支覆盖 | if-else 嵌套是否遗漏分支？条件组合是否覆盖完全？ |
7.3 分析流程
- 阅读代码：理解业务逻辑和实现方式
- 识别代码缺陷：逻辑错误、并发风险、安全漏洞
- 应用六大方法论：从代码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成代码审查意见：附改进建议和代码优化方案
7.4 检查清单
### 功能正确性
- [ ] 业务逻辑是否正确实现？
- [ ] 边界条件是否正确处理？
- [ ] 异常场景是否有容错处理？
### 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？
### 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 是否有适当的用户提示？
### 状态迁移处理
- [ ] 状态变更是否有统一的状态机控制？
- [ ] 非法状态跳转是否有拦截逻辑？
- [ ] 状态回退逻辑是否正确实现？
### 因果判定处理
- [ ] 多重条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？是否可用策略模式简化？
- [ ] 条件组合的覆盖是否完整？
### 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？
### 代码质量
- [ ] 函数长度是否合理？（建议\x3C50行）
- [ ] 圈复杂度是否过高？（建议\x3C10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？
### 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 是否有内存泄漏风险？
### 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 敏感信息是否泄露？
- [ ] 权限校验是否完整？
7.5 输出模板：代码审查意见
## 代码审查意见 — [项目名称/模块]
### 评审信息
- **评审日期**: 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 输出：知识更新记录
## 知识更新记录
- **更新日期**: YYYY-MM-DD
- **评审项目**: [项目名称]
- **评审类型**: [Stage 1-7]
- **新增检查项**: [描述]
- **新增示例**: [描述]
- **更新文件**: [文件路径]
Anti-Patterns（禁止行为）
| 禁止行为 | 正确做法 |
|---|---|
| 混用不同阶段的流程和模板 | 根据评审类型路由到对应工作流 |
| 泛泛而谈"代码质量不好" | 指出具体文件/函数/行号和具体问题 |
| 只提问题不给建议 | 每个问题至少附带一条改进建议 |
| 跳过检查清单 | 按清单逐项检查，记录结果 |
| 评审后不跟进 | 明确待办事项、责任人、截止时间 |
| 用完整流程处理明显的小问题 | 快速记录，简化流程 |
| 忽略历史遗留问题 | 评估影响范围，制定渐进式改进计划 |
| 跳过知识沉淀 | 每次评审后更新知识库 |
| 混淆设计意图和实现风险 | 先确认设计意图，再评估实现风险 |
Skill 协作
| 触发条件 | 转交至 |
|---|---|
| 发现具体 Bug 需要修复 | bug-fixing |
| 需要生成测试用例代码 | test-generator |
| 需要架构设计评审 | system-design |
| 需要代码重构 | refactoring |
| 需要绘制流程图/架构图 | diagram-generator |
参考文件
| 文件 | 用途 |
|---|---|
| checklists/review-checklist.md | 评审检查清单（需求/设计/测试/代码） |
| examples.md | 典型场景示例 |
| templates/test-case-template.md | 测试用例模板 |
| templates/concept-clarification.md | 六大方法论概念澄清与区分 |
技能进化
更新此 Skill 的时机：
- 评审过程中发现检查清单覆盖不足
- 出现新的典型缺陷场景
- 团队反馈评审流程可以优化
更新原则：
- 优先更新具体章节，而非添加新规则
- 保持工作流的简洁性，避免过度官僚化
- 更新后验证与其他 Skill 的协作关系是否仍然清晰
Usage Guidance
Install this if you want structured QA and defect-prevention review. Treat its reports as advisory, and only allow it to edit checklists, examples, templates, or track follow-up tasks after you confirm the target files and approve the changes.
Capability Assessment
Purpose & Capability
The artifacts consistently describe a defect-prevention and review workflow for requirements, design, tests, and code review; the implementation section is checklist and guidance oriented, not an instruction to perform concrete code changes.
Instruction Scope
The trigger terms are fairly broad and the workflow includes follow-up tracking, so it may activate for ordinary review requests more often than necessary, but this is disclosed and aligned with quality-review work.
Install Mechanism
The package contains only Markdown and JSON files, all non-executable, with no dependencies, install scripts, shell commands, network calls, or obfuscated content; static scan and VirusTotal telemetry are clean.
Credentials
The skill asks for review inputs such as requirements, designs, test cases, code files, and API documents, which is proportionate to its stated QA review purpose; it does not request broad local indexing, credentials, sessions, or unrelated private data.
Persistence & Privilege
Phase 8 instructs the agent to update named knowledge files and record follow-up items; this is disclosed and narrowly scoped, but should be treated as requiring explicit user approval before any file edits or task tracking occur.
How to Use
- Make sure OpenClaw is installed (local or Docker)
- Run the install command in chat:
/install defect-prevention-expert - After installation, invoke the skill by name or use
/defect-prevention-expert - Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.0
初始版本发布：覆盖七大评审阶段，整合六大方法论
Metadata
Frequently Asked Questions
What is 缺陷预防专家?
缺陷预防方法论专家，覆盖逆向操作、依赖踏空、同屏并发、新旧交替、状态迁移、因果判定六类场景。 适用于需求设计、研发设计、需求评审、设计评审、测试用例评审、代码评审全阶段。 帮助团队在早期识别潜在缺陷，降低修复成本，提升软件质量。 Use when: - 需求设计/评审阶段，需要识别潜在缺陷和风险点 - 研发设计/... It is an AI Agent Skill for Claude Code / OpenClaw, with 43 downloads so far.
How do I install 缺陷预防专家?
Run "/install defect-prevention-expert" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.
Is 缺陷预防专家 free?
Yes, 缺陷预防专家 is completely free, licensed under MIT-0. You can download, install and use it at no cost.
Which platforms does 缺陷预防专家 support?
缺陷预防专家 is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).
Who created 缺陷预防专家?
It is built and maintained by zengqch (@zengqch); the current version is v1.0.0.
More Skills