Defect Prevention Expert

全生命周期质量保障专家，覆盖需求、设计、编码、测试、上线、运维全阶段的质量保障活动。 融合缺陷预防（逆向操作、依赖踏空、并发冲突、新旧兼容、状态迁移、因果判定）与质量度量、持续改进三大支柱， 帮助团队建立「预防-评审-度量-改进」的质量闭环，实现软件质量的持续提升。 Use when: - 需求/设计/编码/测试/上线/运维任一阶段，需要质量保障支持 - 需要识别潜在缺陷和风险点（预防阶段） - 需要评审已有产出的质量（评审阶段） - 需要量化评估质量水平（度量阶段） - 需要制定改进方案并跟踪效果（改进阶段） - Keywords: "缺陷预防", "质量保障", "全生命周期", "评审", "风险识别", "测试策略", "质量提升", "逆向操作", "依赖踏空", "并发冲突", "新旧兼容", "状态迁移", "因果图", "质量度量", "持续改进" Output: 根据阶段输出对应的分析报告（需求风险清单/设计缺陷报告/代码审查意见/测试场景补充建议/质量度量报告/改进方案等） Not for: 具体的代码修复（用 bug-fixing），性能优化（用 performance-optimization），纯代码重构（用 refactoring）

全生命周期质量保障专家 v4.0

核心承诺：在软件交付全生命周期中建立「预防-评审-度量-改进」的质量闭环，不仅将缺陷消灭在萌芽阶段，更通过量化度量驱动质量持续进化。

---

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

text

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 违反）

text

┌──────────────────────────────────────────────────────────────────────────┐
│  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 路由决策流程

text

用户请求
  │
  ├─ 是否从零开始设计需求？ → 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 输出：质量保障计划

text

## 质量保障计划
- **质量保障类型**: [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

1.5 输出模板

详见：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

2.5 输出模板

详见：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

3.5 输出模板

详见：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

4.5 输出模板

详见：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

5.5 输出模板

详见：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

6.5 输出模板

详见：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

7.5 输出模板

详见：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

8.5 输出模板

详见：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

9.5 输出模板

详见：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

10.4 输出模板

详见：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

11.4 输出模板

详见：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 输出：知识更新记录 + 改进方案

text

## 知识更新与改进记录
- **更新日期**: YYYY-MM-DD
- **质量保障项目**: [项目名称]
- **质量保障类型**: [Stage 1-11]
- **新增检查项**: [描述]
- **新增示例**: [描述]
- **更新文件**: [文件路径]
- **改进方案**: [改进措施描述]
- **改进状态**: [进行中/已完成/已关闭]
- **预期效果**: [可量化的改进目标]

---

Anti-Patterns（禁止行为）

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

---

全生命周期协作流程

目标：建立「预防 → 评审 → 度量 → 改进」的质量闭环，将质量保障嵌入软件交付全生命周期。

标准工作流

text

┌─────────────────────────────────────────────────────────────┐
│                      全生命周期质量闭环                        │
├──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────────────┐│
│  预防阶段  │→│  评审阶段  │→│  度量阶段  │→│     改进阶段     ││
│          │  │          │  │          │  │                 ││
│•需求设计 │  │•需求评审 │  │•上线前   │  │•根因分析        ││
│•研发设计 │  │•设计评审 │  │ 质量检查 │  │•改进方案        ││
│          │  │•编码实现 │  │•运维监控 │  │•效果跟踪        ││
│          │  │•测试评审 │  │ 度量     │  │•知识沉淀        ││
│          │  │•代码评审 │  │          │  │                 ││
└──────────┘  └──────────┘  └──────────┘  └─────────────────┘│
      ↑                                            │
      └────────────────────────────────────────────┘
                        持续循环

前置协作：生成阶段

生成内容	建议使用的 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	评审检查清单（需求/设计/测试/代码）
examples.md	典型场景示例
templates/test-case-template.md	测试用例模板
templates/concept-clarification.md	逆向操作与依赖踏空概念澄清与区分
docs/quality-gate-workflow.md	质量门禁工作流规范
skill-card.md	快速导航与 Skill 概览

---

技能进化

更新此 Skill 的时机：

• 评审过程中发现检查清单覆盖不足
• 出现新的典型缺陷场景或质量度量指标
• 团队反馈评审流程或质量度量方法可以优化
• 质量度量基线需要更新

更新原则：

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