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-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 大阶段）：

关键词触发：

• "评审" + "需求/设计/代码/测试用例"
• "缺陷预防"、"风险识别"
• "逆向操作"、"依赖踏空"、"并发冲突"、"新旧兼容"
• "质量度量"、"质量门禁"、"持续改进"
• "测试策略"、"质量提升"

不适用场景

铁律（执行时 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 质量保障类型识别矩阵

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 分析重点

1.2.1 非功能性维度

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. ✅ 评审完成，进入下一阶段

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

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

方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。

新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：

• 涉及新增数据类型、字段、状态、枚举值
• 涉及业务规则变更（计算规则、校验规则、展示规则等）
• 涉及新增或变更 API 接口、数据格式、返回结构
• 涉及历史数据、历史订单、存量数据访问
• 存在多版本客户端、多端、多系统场景
• 涉及系统升级、服务拆分、架构变更

2.1 输入要求

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

2.2 分析重点

2.2.1 非功能性维度

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. ✅ 评审完成，进入下一阶段

Stage 3: 代码编写阶段工作流

适用场景：编码过程中，应用预防方法论指导编码，避免常见缺陷模式

方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。

新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：

• 涉及新增数据类型、字段、状态、枚举值
• 涉及业务规则变更（计算规则、校验规则、展示规则等）
• 涉及新增或变更 API 接口、数据格式、返回结构
• 涉及历史数据、历史订单、存量数据访问
• 存在多版本客户端、多端、多系统场景
• 涉及系统升级、服务拆分、架构变更

3.1 输入要求

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

3.2 分析重点

3.2.1 非功能性维度

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. ✅ 指导完成，进入下一阶段

Stage 4: 测试用例编写阶段工作流

适用场景：编写测试用例时，系统化设计测试场景，覆盖六类方法论

方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。

新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：

• 涉及新增数据类型、字段、状态、枚举值
• 涉及业务规则变更（计算规则、校验规则、展示规则等）
• 涉及新增或变更 API 接口、数据格式、返回结构
• 涉及历史数据、历史订单、存量数据访问
• 存在多版本客户端、多端、多系统场景
• 涉及系统升级、服务拆分、架构变更

4.1 输入要求

• 需求文档/PRD
• 设计文档
• 代码逻辑（如有）
• 业务流程描述

4.2 分析重点

4.2.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. ✅ 设计完成，进入下一阶段

Stage 5: 需求评审阶段工作流

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

方法论应用说明：以下六大方法论为本阶段的核心分析框架。每个方法论均须逐一分析，仅在能明确证明该方法论在当前场景下完全不涉及时，方可标注 N/A 并说明具体原因。

新旧兼容强制触发条件（满足任一条件时必须应用，不可标注 N/A）：

• 涉及新增数据类型、字段、状态、枚举值
• 涉及业务规则变更（计算规则、校验规则、展示规则等）
• 涉及新增或变更 API 接口、数据格式、返回结构
• 涉及历史数据、历史订单、存量数据访问
• 存在多版本客户端、多端、多系统场景
• 涉及系统升级、服务拆分、架构变更

5.1 输入要求

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

5.2 分析重点

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 分析重点

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 分析重点

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 分析重点

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 分析重点

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 分析重点

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 分析重点

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 更新知识库文件

10.4 制定改进方案

• 根据质量度量报告中的问题，制定优先级排序的改进方案
• 明确改进措施、责任人、时间节点、预期效果
• 跟踪改进方案的执行情况

10.5 输出：知识更新记录 + 改进方案

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

Anti-Patterns（禁止行为）

全生命周期协作流程

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

标准工作流

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

前置协作：生成阶段

后置协作：修复阶段

度量阶段协作

Skill 协作

协作关系矩阵

快速转交指南

参考文件

技能进化

更新此 Skill 的时机：

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

更新原则：

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