| 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.1.0 |
| metadata | {"language":"zh","version":"4.1.0","last_updated":"2026-06-12T00:00:00.000Z","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 |
| 需求评审 | 评审 | 需求文档/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 范围确认清单
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 分析流程
- 梳理业务流程：主流程 → 分支流程 → 异常流程
- 识别关键数据依赖：数据实体、关联关系、级联规则
- 应用六大方法论：逐项分析逆向/依赖/并发/兼容/状态/因果场景
- 生成风险清单：按 P0-P3 分级，附改进建议
1.4 检查清单
详见：checklists/review-checklist.md
1.5 输出模板
详见：templates/stage-output-templates.md
1.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
需求风险清单-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个风险点
- ✅ 评审完成，进入下一阶段
Stage 2: 研发设计阶段工作流
适用场景：已有需求文档，需要设计技术方案，评估架构健壮性
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
2.1 输入要求
- 需求文档/PRD
- 业务流程描述
- 性能/安全/扩展性要求（如有）
2.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 状态机设计、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→支付发起→修改订单商品→库存和支付是否重新计算？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架/改价、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、最终一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 数据迁移、API版本管理 | |
| 状态迁移 | 状态机设计、状态校验、非法跳转防护 | 状态流转是否用状态机控制？是否存在绕过状态校验的接口？ |
| 因果判定 | 复杂业务规则的条件组合覆盖 | 折扣计算规则涉及多个条件，是否用判定表梳理了所有组合？ |
2.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|---|
| 性能 | 容量预估（QPS、RT、数据量级）是否明确？ | 秒杀场景QPS > 10万，架构如何支撑？ |
| 安全 | 防刷、幂等、越权访问是否设计？ | 恶意批量刷券接口防护？ |
| 容灾 | 多活架构、异地容灾、数据备份是否考虑？ | 主库宕机时如何切换？ |
2.3 分析流程
- 梳理技术架构：分层架构、服务拆分、数据流向
- 识别技术风险点：并发控制、事务边界、依赖管理
- 应用六大方法论：从技术角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计缺陷报告：附改进建议和架构优化方案
2.4 检查清单
详见：checklists/review-checklist.md
2.5 输出模板
详见：templates/stage-output-templates.md
2.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
设计缺陷报告-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个缺陷
- ✅ 评审完成，进入下一阶段
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 分析流程
- 理解设计意图：明确架构设计和关键决策
- 识别编码风险点：并发安全、依赖处理、版本兼容
- 应用六大方法论：从编码角度预防逆向/依赖/并发/兼容/状态/因果缺陷
- 生成编码指导建议：附实现建议和注意事项
- 质量自评：
- 问题发现率 = 识别的编码风险数 / 实际存在的风险总数（目标 ≥ 90%）
- 严重缺陷识别率 = P0/P1级缺陷数 / 总缺陷数（目标 ≥ 60%）
- 建议可执行性 = 可落地建议数 / 总建议数（目标 ≥ 80%）
3.4 检查清单
详见：checklists/review-checklist.md
3.5 输出模板
详见：templates/stage-output-templates.md
3.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次指导内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
编码指导建议-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个检查项
- ✅ 指导完成，进入下一阶段
Stage 4: 测试用例编写阶段工作流
适用场景：编写测试用例时，系统化设计测试场景，覆盖六类方法论
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
4.1 输入要求
- 需求文档/PRD
- 设计文档
- 代码逻辑（如有）
- 业务流程描述
4.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 测试用例是否覆盖改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 测试用例是否覆盖兼容性场景 | |
| 状态迁移 | 状态流转路径的测试覆盖 | 是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？ |
| 因果判定 | 条件组合场景的测试覆盖 | 多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？ |
4.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|---|
| 性能 | 是否设计性能测试场景？ | 高并发抢券场景的压测用例？ |
| 安全 | 是否设计安全测试场景？ | 伪造优惠券ID、越权使用他人优惠券？ |
| 可测试性 | 测试数据是否覆盖等价类和边界值？ | 优惠券过期时间边界值（前1秒/后1秒）？ |
4.3 分析流程
- 理解业务需求：明确功能范围和核心业务规则
- 识别测试场景：基于六大方法论设计测试场景
- 设计测试用例：覆盖正向、逆向、边界、异常场景
- 生成测试场景设计建议：附新增测试用例建议
4.4 检查清单
详见：checklists/review-checklist.md
4.5 输出模板
详见：templates/stage-output-templates.md
4.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次设计内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
测试场景设计建议-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个场景
- ✅ 设计完成，进入下一阶段
Stage 5: 需求评审阶段工作流
适用场景：已有需求文档，需要评审需求完整性和潜在风险
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
5.1 输入要求
- 需求文档/PRD
- 用户故事或用例
- 业务流程图（如有）
5.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 需求中的操作路径是否完整，同一用户连续顺序操作后改变前置操作 | 改变前置操作后，需求是否覆盖？（如：选择省→选择市→选择区→修改市→区是否清空并重新加载？） |
| 依赖踏空 | 需求中的依赖关系是否明确，依赖数据/服务变更 | 依赖数据变更后的处理是否定义？（如：商品下架、优惠券过期、部门删除后人员归属） |
| 并发冲突 | 需求是否考虑多端/多用户场景 | 并发操作的冲突解决是否定义？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 需求是否考虑兼容性 | |
| 状态迁移 | 需求是否定义完整状态流转 | 订单状态流转是否定义完整？是否有非法跳转的可能？ |
| 因果判定 | 需求中的业务规则是否用判定表梳理 | 满减、折扣、优惠券叠加规则，各种条件组合是否都定义清楚了？ |
5.3 分析流程
- 阅读需求文档：理解业务目标和核心功能
- 识别需求漏洞：边界场景、异常流程、缺失定义
- 应用六大方法论：从需求角度分析逆向/依赖/并发/兼容/状态/因果
- 生成需求评审报告：附改进建议和待确认事项
5.4 检查清单
详见：checklists/review-checklist.md
5.5 输出模板
详见：templates/stage-output-templates.md
5.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
需求评审报告-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个漏洞
- ✅ 评审完成，进入下一阶段
Stage 6: 设计评审阶段工作流
适用场景：已有设计文档，需要评审技术方案和架构设计
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
6.1 输入要求
6.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 状态机、事务回滚设计，前置操作改变后后续逻辑是否正确 | 改变前置操作后，数据一致性如何保证？（如：订单创建→库存扣减→修改订单→库存是否重新调整？） |
| 依赖踏空 | 业务数据/事务依赖，依赖变更或消失 | 业务数据删除/变更后，系统如何处理？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 分布式锁、乐观锁、缓存一致性 | 多实例并发写入，如何避免冲突？ |
| 新旧兼容 | **触发条件：**①新增数据类型/字段/状态 ②业务规则变更 ③新增/变更API ④历史数据/存量数据 ⑤多版本客户端/多端 ⑥系统升级/服务拆分 → 数据迁移、API版本管理 | |
| 状态迁移 | 状态机设计、状态流转合法性校验 | 是否用状态机模式控制流转？是否存在越权状态变更的接口？ |
| 因果判定 | 复杂业务规则的条件组合设计 | 计费/折扣规则涉及多条件，是否用判定表确保覆盖完整？ |
6.2.1 非功能性维度
| 维度 | 检查项 | 典型问题 |
|---|
| 性能 | 数据库索引设计是否合理？ | 优惠券查询是否走索引？ |
| 安全 | 接口幂等性、防重放攻击是否设计？ | 优惠券领取接口是否幂等？ |
| 可测试性 | 单元测试覆盖率是否达标？ | 核心逻辑是否有单元测试覆盖？ |
6.3 分析流程
- 阅读设计文档：理解技术架构和关键设计决策
- 识别设计缺陷：架构不合理、数据一致性风险、扩展性不足
- 应用六大方法论：从设计角度分析逆向/依赖/并发/兼容/状态/因果
- 生成设计评审报告：附改进建议和架构优化方案
6.4 检查清单
详见：checklists/review-checklist.md
6.5 输出模板
详见：templates/stage-output-templates.md
6.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
设计评审报告-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个缺陷
- ✅ 评审完成，进入下一阶段
Stage 7: 编码实现评审阶段工作流
适用场景：已有设计文档，需要编码实现，检查并发控制、版本兼容、依赖处理
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
7.1 输入要求
7.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 状态机实现、事务回滚，前置操作改变后后续逻辑是否正确 | 改变前置操作后，后续逻辑是否正确处理？（如：选择商品→选择规格→选择配送→修改规格→配送方式是否重新校验？） |
| 依赖踏空 | 业务数据/事务依赖，依赖数据不存在时 | 业务数据不存在时，是否有容错处理？（如：商品下架、优惠券过期） |
| 并发冲突 | 乐观锁、分布式锁、缓存更新 | 共享资源访问是否线程安全？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 字段兼容、API版本 | |
| 状态迁移 | 状态机实现、状态校验代码 | 状态变更是否有统一的状态机控制？是否存在绕过校验的直接 UPDATE？ |
| 因果判定 | 复杂条件判断的代码实现 | 多重 if-else 嵌套是否可简化？是否遗漏了某些条件分支？ |
7.3 分析流程
- 理解设计意图：明确架构设计和关键决策
- 识别编码风险点：并发安全、依赖处理、版本兼容
- 应用六大方法论：从编码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成编码检查清单：附实现建议和注意事项
- 评审质量自评：
- 问题发现率 = 发现缺陷数 / 已知缺陷总数（目标 ≥ 90%）
- P0/P1 缺陷占比 = 高严重缺陷数 / 总缺陷数（目标 ≥ 60%）
- 改进建议可执行性 = 每条建议是否可落地（目标 ≥ 80%）
7.4 检查清单
详见：checklists/review-checklist.md
7.5 输出模板
详见：templates/stage-output-templates.md
7.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
编码检查清单-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个检查项
- ✅ 评审完成，进入下一阶段
Stage 8: 测试用例评审阶段工作流
适用场景：已有测试用例文档，需要评审测试覆盖度和系统化场景设计
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
8.1 输入要求
- 测试用例文档
- 测试计划
- 需求文档/设计文档（参考）
8.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 测试用例是否覆盖同一用户连续顺序操作后改变前置操作的场景 | 是否有改变前置操作的测试用例？（如：添加商品A→添加商品B→选择优惠券→修改商品A数量→验证总价和优惠券重算） |
| 依赖踏空 | 业务数据/事务消失场景的测试用例 | 是否有业务数据删除的测试用例？（如：商品下架、优惠券过期、部门删除） |
| 并发冲突 | 测试用例是否覆盖并发场景 | 是否有多端/多用户并发的测试用例？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 测试用例是否覆盖兼容性场景 | |
| 状态迁移 | 状态流转路径的测试覆盖 | 是否测试了所有合法状态跳转？是否测试了非法跳转的拦截？ |
| 因果判定 | 条件组合场景的测试覆盖 | 多条件组合的业务规则，测试用例是否覆盖了所有有效和无效组合？ |
8.3 分析流程
- 阅读测试用例：理解测试覆盖范围
- 识别覆盖盲区：边界条件、异常场景、并发场景
- 应用六大方法论：从测试角度分析逆向/依赖/并发/兼容/状态/因果
- 生成测试场景补充建议：附新增测试用例建议
- 评审质量自评：
- 场景覆盖率 = 已覆盖场景数 / 理论总场景数（目标 ≥ 80%）
- 边界条件覆盖率 = 边界测试数 / 关键边界数（目标 ≥ 90%）
- 无效等价类覆盖 = 是否测试了所有无效输入（目标 = 100%）
8.4 检查清单
详见：checklists/review-checklist.md
8.5 输出模板
详见：templates/stage-output-templates.md
8.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
测试场景补充建议-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个盲区
- ✅ 评审完成，进入下一阶段
Stage 9: 代码评审阶段工作流
适用场景：已有代码，需要评审逻辑正确性、并发安全、代码质量
方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。
新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：
- 涉及新增数据类型、字段、状态、枚举值
- 涉及业务规则变更（计算规则、校验规则、展示规则等）
- 涉及新增或变更 API 接口、数据格式、返回结构
- 涉及历史数据、历史订单、存量数据访问
- 存在多版本客户端、多端、多系统场景
- 涉及系统升级、服务拆分、架构变更
9.1 输入要求
9.2 分析重点
| 方法论 | 应用重点 | 典型问题 |
|---|
| 逆向操作 | 前置操作改变后，同一用户后续逻辑是否正确 | 级联依赖的联动更新是否正确？（如：填写订单→选择地址→选择发票→修改地址→发票信息是否重新计算？） |
| 依赖踏空 | 业务数据/事务不存在时，是否有容错 | 业务数据/事务变更时是否有校验？（如：商品下架、优惠券过期） |
| 并发冲突 | 共享资源访问是否线程安全 | 数据库操作是否有并发控制？ |
| 新旧兼容 | **触发条件：**①新增字段/状态 ②业务规则变更 ③新增/变更API → 新旧数据共存时，适配层是否实现 | |
| 状态迁移 | 状态机实现、状态校验逻辑 | 状态变更是否集中管理？非法跳转是否拦截？ |
| 因果判定 | 复杂条件判断、多重分支覆盖 | if-else 嵌套是否遗漏分支？条件组合是否覆盖完全？ |
9.3 分析流程
- 阅读代码：理解业务逻辑和实现方式
- 识别代码缺陷：逻辑错误、并发风险、安全漏洞
- 应用六大方法论：从代码角度分析逆向/依赖/并发/兼容/状态/因果
- 生成代码审查意见：附改进建议和代码优化方案
- 评审质量自评：
- 问题发现率 = 发现缺陷数 / 已知缺陷总数（目标 ≥ 95%）
- 严重缺陷占比 = P0/P1 缺陷数 / 总缺陷数（目标 ≥ 60%）
- 误报率 = 误判缺陷数 / 总缺陷数（目标 ≤ 5%）
9.4 检查清单
详见：checklists/review-checklist.md
9.5 输出模板
详见：templates/stage-output-templates.md
9.6 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次评审内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
代码审查意见-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个缺陷
- ✅ 评审完成，进入下一阶段
Stage 10: 上线前质量检查阶段工作流
适用场景：代码评审通过，准备上线前，需要确认质量基线达标和风险可控
10.1 输入要求
- 测试报告（功能测试、性能测试、安全测试）
- 缺陷统计数据（缺陷密度、遗留缺陷清单）
- 代码覆盖率报告
- 安全扫描报告
- 性能基线数据
10.2 分析重点
| 质量维度 | 检查项 | 典型问题 |
|---|
| 功能质量 | 核心功能是否全部通过测试？ | 是否存在 P0/P1 级别未修复缺陷？ |
| 性能质量 | 性能指标是否达标？ | 响应时间、吞吐量是否满足基线要求？ |
| 安全质量 | 安全漏洞是否修复？ | 高危/严重漏洞是否清零？ |
| 代码质量 | 覆盖率是否达标？ | 核心模块覆盖率是否 ≥ 80%？ |
| 兼容性 | 新旧版本是否兼容？ | 回滚方案是否验证通过？ |
| 历史问题复验 | 历史问题是否已修复并验证？ | 是否存在重复出现的缺陷模式？ |
10.3 检查清单
详见：checklists/review-checklist.md
10.4 输出模板
详见：templates/stage-output-templates.md
10.5 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次检查内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
上线质量检查报告-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个质量维度
- ✅ 检查完成，进入下一阶段
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 交互选项
分析完成后，向用户展示以下选项：
下一步操作：
- 📝 是否将本次度量内容写入文档？
- 如果用户选择"是"，使用 write 工具生成文件
- 文件名：
质量度量报告-[项目名称]-[日期].md
- 保存路径：当前工作区根目录或
docs/review/ 目录
- 🔍 继续深入分析某个质量指标
- ✅ 度量完成，进入下一阶段
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 |
参考文件
技能进化
更新此 Skill 的时机：
- 评审过程中发现检查清单覆盖不足
- 出现新的典型缺陷场景或质量度量指标
- 团队反馈评审流程或质量度量方法可以优化
- 质量度量基线需要更新
更新原则：
- 优先更新具体章节，而非添加新规则
- 保持工作流的简洁性，避免过度官僚化
- 更新后验证与其他 Skill 的协作关系是否仍然清晰
