z-Zihan 专项 Review / Focused Review
触发条件 / When to Activate
不会自动触发。 仅在以下场景使用：
- 用户明确说明这是重要需求 / 专项需求（如"这是核心链路"、"这个需求优先级很高"）
- 用户提供具体的需求文档并要求针对该需求深入 review
- 二次 review 时用户对某个具体需求不放心，要求重点审查
- 用户明确说"专项 review"、"重点 review"、"仔细看一下 XX 功能"
关键词识别：专项、重点、仔细、重要需求、核心链路、这个需求很重要、不放心、仔细 review
与普通 Review 的区别 / Differences from Standard Review
| 维度 | 普通 Review | 专项 Review |
|---|---|---|
| 审查深度 | 覆盖整体变更，平衡广度和深度 | 聚焦指定需求，深度优先 |
| 边界情况 | 检查明显边界 | 主动穷举边界 case，列出完整清单 |
| 数据流 | 检查关键路径 | 逐层追踪完整数据流（输入→处理→存储→输出→展示） |
| 错误处理 | 检查显式 try-catch | 检查所有异常路径、降级策略、重试机制、错误兜底 |
| 并发/竞态 | 基本检查 | 深入分析竞态条件、资源竞争、时序问题 |
| 类型安全 | 基本检查 | 严格检查类型推导、null/undefined 传播、类型断言风险 |
| 向后兼容 | 基本检查 | 分析 API 兼容性、数据迁移、旧版本影响 |
| 测试覆盖 | 建议补充 | 逐条对照需求点，检查测试覆盖率和遗漏场景 |
专项 Review 流程 / Focused Review Process
Step 1 — 明确审查范围
确认以下信息（缺少则主动询问）：
- 目标需求：具体是哪个功能/模块/需求点？
- 需求文档：有没有需求文档、设计文档、接口文档？
- 关注点：有没有特别担心的地方？（如并发、性能、数据一致性）
- 变更范围：本次涉及的文件/模块有哪些？
Step 2 — 需求逐条对照
将需求文档中的每一条要求，与代码逐一对照：
## 需求对照
| # | 需求点 | 代码位置 | 实现状态 | 备注 |
|---|--------|----------|----------|------|
| 1 | 具体需求描述 | 文件:函数 | ✅ 完整 / ⚠️ 部分 / ❌ 未实现 | 说明 |
- 每条需求必须给出明确的实现状态
- 部分实现要具体说明缺失了什么
- 如果没有需求文档，从代码和提交信息推断需求意图
Step 3 — 深度分析
针对目标需求，执行以下分析（根据需求类型选择重点）：
功能完整性：
- 是否覆盖了需求文档的全部场景
- 正常路径 + 异常路径 + 边界 case 是否都处理了
- 有没有硬编码的临时方案
数据一致性：
- 读写是否有竞态风险
- 事务/锁是否正确使用
- 缓存与数据库的一致性
- 并发写入时的幂等性
错误处理：
- 每个可能失败的操作是否有兜底
- 错误信息是否有用（对排查问题有帮助）
- 失败后是否有重试/降级机制
- 是否有静默失败（吞掉错误不处理）
性能影响：
- 是否引入新的 N+1 查询、大循环、频繁 IO
- 是否有不必要的数据加载（如全量查询后只取几条）
- 高频调用路径是否有性能隐患
安全性：
- 输入校验是否完整
- 是否有注入风险（SQL、XSS 等）
- 权限校验是否到位
向后兼容：
- API 变更是否影响已有调用方
- 数据结构变更是否有迁移方案
- 配置项变更是否有默认值兜底
Step 4 — 边界情况穷举
针对目标需求，主动思考并列举所有可能的边界情况：
## 边界情况检查
| # | 场景 | 预期行为 | 代码处理 | 风险 |
|---|------|----------|----------|------|
| 1 | 空数据/零值 | ... | ✅ 已处理 / ❌ 未处理 | ... |
| 2 | 并发操作 | ... | ... | ... |
| 3 | 超大数据量 | ... | ... | ... |
主动考虑但不限于：
- 空值、null、undefined、零、空数组、空字符串
- 并发/重复操作（重复点击、重复提交）
- 超长输入、特殊字符、非法参数
- 网络异常、超时、服务不可用
- 权限不足、未登录态
- 数据不存在、已删除
- 分页边界（第一页、最后一页、空页）
Step 5 — 输出专项报告
专项 Review 使用专属报告格式（替代普通 Review 报告）：
## 专项 Review 报告
**审查需求**: [需求名称/描述]
**变更范围**: [涉及的文件/模块]
**审查结论**: 可直接合入 / 修复后合入 / 建议进一步验证
### 需求完成度
[Step 2 的需求对照表]
### 边界情况
[Step 4 的边界情况检查表]
### 需要修复的问题
[同普通 Review 格式]
### 建议关注（可选改进）
[同普通 Review 格式]
### 测试建议
| 优先级 | 测试场景 | 测试方法 | 原因 |
|--------|----------|----------|------|
| P0 | 核心路径 | ... | ... |
| P0 | 关键边界 | ... | ... |
| P1 | 异常路径 | ... | ... |
### 最终结论
详细说明 + 是否可合入。
注意事项
- 专项 Review 只聚焦用户指定的需求，其他变更用普通 Review 标准处理
- 不要因为"专项"就对非目标需求过度审查，避免把简单改动复杂化
- 如果用户没有提供需求文档，在报告中标注"⚠️ 无需求文档，以下分析基于代码推断"
- 边界情况不需要全部都覆盖，优先列出对功能正确性有实际影响的，避免为了"穷举"而列无意义场景
问题格式同主 Review 报告 §3（无影响变更/建议关注/需要修复），不再重复定义。